Another day, another iOS app forced to remove features because of an unwritten App Store rule. This time it’s Panic’s excellent Transmit iOS, and the feature in question is the ability to upload files to iCloud Drive.

I’m not writing to debate the merits of the particular rule in question. As with lots of Apple’s rules, there are probably good points to be made on both sides. I am, however, interested in promoting just a bit more transparency so that developers have a solid understanding of what they can and can’t do.

Specifically: When possible, Apple should publish not just a list of rules, but a list of principles that underlie them. John Siracusa brought this up on the most recent episode of ATP. The worst thing about Apple’s recent flailing when it comes to the rules is that the changes seem to come out of the blue. A well-meaning developer, looking at Apple’s APIs and other apps that have been approved, could reasonably believe that buttons in a Notification Center widget are permissible. Same goes for uploading files to iCloud Drive.

Some statements of principle would go a long way toward helping developers comply with Apple’s ideas. For example, a principle could be something like “Notification Center widgets are intended primarily for display of information, not for interaction.” It doesn’t cover all possible scenarios, but it does convey important hints about Apple’s intentions for a particular technology. I can forgive the company for not having thought out every edge cases, but I have to believe that these types of principles drive a lot of the individual rules. (If not – which seems at least within the realm of possibility – we have a bigger problem.)

These principles don’t need to be set in stone. Just like the rules themselves, the principles could change over time. If Apple changes its mind about something, it should update the principles. That way, developers won’t need to spend so much time parsing the implications of this or that recent rejection.

As developers, we can’t afford to spend time building features that we won’t be able to ship. Good iOS and Mac developers want to obey the spirit of the law when it comes to the App Store rules. We want to build features that Apple will allow us to ship, and we want to take advantage of the newest features in the OS. As it stands, the company is making it riskier for developers to do so. Giving a window into the thought process behind enforcement of the rules would be a great start toward fixing that.

Today brought the latest in a string of confusing rulings from Apple concerning iOS Notification Center widgets. Drafts author Greg Pierce was told that he must remove most of the buttons from the app’s Today extension. Pierce elaborated that buttons aren’t prohibited per se, but that “buttons that took you to the widget’s containing app to process/complete a task” are. The whole thing reminds me of the drama surrounding the PCalc calculator widget from a few weeks ago.

Here’s the thing I can’t figure out: What’s the reasoning behind the rule change? Most of the App Store Guidelines have a fairly clear rationale behind them: improving user experience, promoting security and performance, keeping the App Store clear of trashy content, etc. A rule against functional, as opposed to informational, Notification Center widgets doesn’t fit clearly into any of those buckets. It’s hard to argue that users suffer by having the option to perform useful tasks from widgets, nor do there seem to be widespread performance issues associated with them. If security were an issue, the solution would almost certainly lie in the API for working with widgets, and not in the selective enforcement of App Store rules. Both Drafts and PCalc are widely-respected apps and their widgets could hardly be accused of lowering the App Store’s standards.

The best explanation I can come up with is that Apple wants to limit Notification Center widgets to information presentation only. But why? How would that help either users or Apple? And why did Apple provide APIs that let developers build more capable widgets if we weren’t meant to do so? Why wasn’t this limit part of the rules before iOS 8 launched? Did something change at Apple in the interim? If so, why?

It feels as though there’s an internal struggle going on at Apple, and we’re experiencing the effects of it. Perhaps there’s been a change in the balance of power between one team and another. I can’t help but thinking there are at least a couple more shoes still left to drop. If Apple truly does aim to restrict Notification Center widgets to read-only presentation, it would be helpful of them to simply add that to the guidelines.

A couple of weeks ago I predicted that WatchKit APIs woudl be Swift-only. I was wrong, at least for now – the APIs Apple released on Tuesday work with both Swift and Objective-C. But I’m not admitting defeat just yet, because these APIs aren’t the whole story.

Essentially, what Apple released on this week is a way to project UI from an iOS app extension onto the Apple Watch. Under the hood, it’s still mostly an iOS app. Apple says developers will be able to create “fully native apps” for the Watch starting “later next year.” It’s clear that the SDK for fully native Watch apps isn’t finished, and that could still be Swift-only. Or, I could just be wrong. We’ll probably know for sure after WWDC in Summer 2015.

Today Apple updated the App Store to show the word “GET” instead of “FREE” for free-to-download apps. Jason Snell has a good write-up of the change on his site, Six Colors. The basic premise is a reasonable one: A lot of apps labeled “free” aren’t really free. They’re free to download, but you can (and often must) make in-app purchases in order for them to be useful. For those apps, the “free” label could be misleading.

Nonetheless, I have a few concerns with the change:

• It doesn’t differentiate between apps that are “free with in-app purchases” and apps that are just FREE. I think it’s worth labeling apps that are free with no in-app purchases as such.
• The “GET” label doesn’t give users enough information about what will happen when they download the app. Unlike the “FREE” button, it’s not immediately obvious that you won’t be charged when you tap “GET.” True, there’s no price listed, but you do have to enter a password or fingerprint using Touch ID. I’m sure that’s enough to raise concern among some users that they’re about to be charged money to “GET” the app.

I propose two changes that would go a long way toward easing user confusion:

• List totally free apps (those without in-app purchases) as “FREE.”
• Replace the “GET” button with either the iCloud download icon or change the button text to “FREE TO DOWNLOAD.” The former is used elsewhere on iOS in situations where no money changes hands, and the latter uses much clearer wording than “GET.” Browse screens, such as the App Store home screen, could retain the “GET” label to save space because it’s not a button in that context.

Reading (Underscore) David Smith’s excellent post about expectations for WatchKit got me thinking about some of my own. The idea I keep coming back to is: Wouldn’t it be interesting if WatchKit APIs were Swift-only?

Swift-only Watch APIs wouldn’t prevent Apple from re-using other iOS APIs on the Watch. (I’m assuming that Watch OS will be some variant of iOS.) Because Swift can access Objective-C APIs (albeit a little awkwardly), Watch apps could still use existing APIs that make sense across devices. (Take the notifications and extensions APIs as an example.) Basically, Apple would do what we’re all expecting them to do eventually: Make new APIs Swift-only, without backwards compatibility to Objective-C. Existing apps that don’t need the new APIs, like iPhone apps, would continue to run just fine. But if you want access to the new goodness (including new devices), you have to write some Swift code.

The Watch represents Apple’s best opportunity to jump-start their new language in a production context. There will be a lot of developer interest in the Watch, and this gives Apple a chance to push developers into giving Swift a try. Apple has been extremely aggressive in pushing new versions of their OSes and developer tools, and this is a chance for them to go further. Most developers I know are hesitant to use Swift in a production app because it’s so new. That situation could persist for years unless Apple gives us a little nudge or two.

The Watch is an ideal candidate for that kind of nudging. It doesn’t have the backwards-compatibility issues that the iPhone and iPad do. Nobody needs to maintain support for previous versions of the Watch OS, because they don’t exist. Nobody will complain because they have years of experience with the old way of doing things on the Watch, because there is no old way. Just as the first version of the iPhone SDK set the tone for iOS development, the first Watch SDK will set the tone for Watch development. Now is Apple’s chance to make that tone be Swifty.

Of course, we have no idea whether the Watch team knew anything about Swift before WWDC. It sounds like Swift was as much a surprise to many Apple employees as it was to the rest of us. If the Watch folks didn’t know about Swift, it’d be extra work for them to go back and update APIs to be Swift-only. But wouldn’t it be just like Apple to go back and remove Objective-C compatibility, or make things Swiftier, just to promote a larger objective?

Either way, with the Watch SDK set to drop sometime this month, we won’t have to wait long to find out if I’m right or spectacularly wrong.

Apple’s new Retina iMac and my own aging work hardware have me thinking a lot about multi-computer setups lately. Right now I have two machines:

• A mid-2011 Mac Mini that I use mostly for work. 8GB of RAM and an aftermarket Fusion drive courtesy of iFixIt’s handy dual drive kit. It’s hooked up to a 23″ monitor on my desk.
• A late-2012 13″ Retina MacBook Pro, also with 8GB of RAM, which is mostly for personal stuff. I’ll occasionally use it for work when traveling.

The Mac Mini in particular is really starting to show it’s age, and the Retina iMac is VERY tempting, due both to the amazing screen and much improved performance. But the thing that keeps nagging at me is whether I want to keep maintaining two machines at all. To try and sort it out, I’ve put together a few pros and cons of a two-Mac setup:

PRO: Keep work and personal stuff separate

As an independent developer, it’s important for me to maintain some separation between work and non-work. That means closing down work projects at the end of the day so that I can focus on the rest of my life without getting sucked back into work. With two computers, that’s pretty easy: Put the work Mac to sleep and walk away. With just one machine, that’s harder. (I think the best way to deal with this is probably to use two user accounts on the same Mac, one for work and one for everything else.)

CON: Maintaining separate development environments

Two machines means twice as many things to keep up to date. Software updates, Xcode betas, and especially provisioning profiles are a pain to deal with across two Macs. Unfortunately, Dropbox or iCloud drive don’t help much with this kind of thing, and we don’t have the kind of tools for replicating dev environments that are so useful when doing web development.

PRO: No docking/undocking

With two Macs, there’s none of the docking/undocking setup involved with hooking a laptop up to an external monitor. I don’t want to just leave my laptop on my desk all the time – that defeats the purpose. That means every time I want to move it, I have to unplug a few cables before I can take the laptop with me. When I come back, I have to reconnect everything. Even with something like a HengeDock (which I’ve used before and liked a lot), there’s the inevitable window rearranging and other snafus that come along with changing screen resolutions.

CON: Cost

Having two Macs means keeping the hardware for both up to date. I could probably let my personal laptop slip a bit, since it usually doesn’t have to do anything too intensive. Combine that with the old adage that you should buy the best Mac you can, and it’s possible to stretch the lifetimes out a bit. Nevertheless, maintaining two computers is always going to be more expensive than maintaining just one. (Then again, that iMac is pretty pricey…)

PRO: Desktop Retina

Right now, the only real way to get a Retina display on the desktop is with the Retina iMac. That doesn’t seem likely to change in the near future. Maybe Apple will release a standalone Retina display and update the Mac Pro to support it, but I think it’ll be a while before a laptop can drive that many pixels. Marco Arment’s guess of 2016 for a standalone Retina display sounds about right to me. Granted, Retina isn’t a must-have feature, but it sure would be nice, especially when developing for iOS devices that all have Retina screens. Those simulators take up a lot of screen real estate!

WILD CARD: Desktop + iPad?

I’ve always had a Mac for personal use. But I wonder: Do I really need one? Could I replace most of my personal laptop usage with the iPad? (Somewhere in Italy, Federico Viticci is cheering.) If so, that mostly negates a lot of the con arguments. Maybe I’ll give that a try for a while and see how it works out.

Have thoughts or experience about resolving this dilemma? Let me know on Twitter!

Apple changed the way apps can ask for permission to use your location in iOS 8. Previously, apps simply asked for permission to use your location, which you could allow or deny. If you allowed access, the app could use your location anytime, even while it was in the background. Once set, the permissions could be changed in the Settings app.

In iOS 8, Apple added some additional granularity to location permissions. Instead of a one-size-fits-all permission, apps can now choose whether to request access to your location only when the app is in use, or all the time (even in the background). It’s a great distinction to make from a user’s standpoint, because it means you have more control over your privacy.

However, there are a couple of catches that make for a bad user experience. Apps can only ask for one level of access, and can only ask once. Developers have to choose how much access to request. Once you’ve asked for “when in use” authorization, for example, you can’t ask again for “always” permissions. You also can’t display a dialog asking the user to choose between “Always,” “When in use,” or “Never.” (You could work around this with some clever use of dialogs, but it feels a little hacky.)

The best practice Apple is promoting to developers is to ask for the least permissions you need at first, then move up in response to user action. In the WWDC talk about Core Location this year (session 706, “What’s New in Core Location”), Apple used the example of an amusement park app. Most of the time, the app only needs “when in use” authorization to show your location on a map, so it asks for that level of access at launch. But there’s also an extra feature that uses region monitoring to let you know when you get near specific attractions, even when the app is in the background. For that feature, the app needs “always” authorization. The problem is, once you’ve granted “when in use” authorization, the app can’t prompt you for more access.

Apple’s solution to this problem is to let developers send users to the Settings app so that they can change the location permissions for your app. This feels like a classic “sweet solution.” It’s not a good experience to boot users out into the Settings app, even if it’s directly to the settings for your app’s location permissions. It breaks the user out of your UI, and there’s no obvious way to get back to your app after they’ve changed settings.

I’m sure the goal here is to prevent apps from constantly badgering you for access to your location. It’s a good goal, and one Apple should stick with. The problem is, in the pursuit of that goal they’ve created a disincentive to follow the best practice. Because you can only ask for location access once, developers will feel that they need to ask for the maximum permissions they think they’ll ever need, even if a minority of users will ever benefit. Moreover, a dialog offering to send you over to the settings app to change a preference doesn’t feel like much of an improvement over a dialog asking for greater location permissions.

A relatively minor change could resolve a lot of these problems: Allow apps to ask for permission once per type of authorization. If a user allows “when in use” authorization, then allow the app to ask for “always” authorization later. (But only once. If the user says no, that’s it.) If the user denies “when in use” authorization, the app can’t prompt again for any level of access. If the user denies “always” authorization, allow the app to ask for “when in use” authorization instead, or give them both options at the outset.

Apple was smart to give users more control over their location data in iOS 8. It would be even smarter if they tweaked the implementation so that choosing those permissions is a better experience.

Russell Ivanovic, hitting the nail on the head:

Tim Cook keeps telling us that ‘Only Apple’ could do the amazing things it does. I just wish that Apple would slow down their breakneck pace and spend the time required to build stable software that their hardware so desperately needs. The yearly release cycles of OS X, iOS, iPhone & iPad are resulting in too many things seeing the light of day that aren’t finished yet.

One thing that’s striking is how many of Apple’s troubles are self-inflicted. Gone are the days when Apple planned product announcements around conferences like Macworld Expo. That the company controls its whole ecosystem, from hardware to software to services, is supposed to be a strength. Controlling everything should mean that you can get all your ducks in a row before pulling back the curtain. The only thing that Apple is truly constrained by are its own self-imposed deadlines. The problem is, Apple keeps shooting itself in the foot. Rather than waiting until a new version of iOS is fully finished, for example, they rush an update out the door to coincide with the release of new iPhones.

Of course, new hardware usually requires some updates to support it. To deal with this, Apple could decouple major iOS releases from hardware releases. For example, release an iOS 7.2 update to handle the larger screens of the iPhone 6 and 6 Plus, without all the other stuff in iOS 8 like extensions, HealthKit, etc. A more fully-baked iOS 8 could be released later. The change would undoubtedly be difficult for developers, but Apple usually (rightly) chooses what’s best for users first and whats best for developers second. (This might even have a side benefit for developers, by potentially uncoupling Xcode releases from SDK versions as well.) It’s also worth remembering that Apple has done this before, when the iPad was released in 2010. It wasn’t ideal from a developer perspective, but it was workable.

Another option is to slow down the OS release cycle. It’s not hard to imagine Apple setting up a rotation where iOS and the Mac OS get a major update every other year. Those cycles could be offset by a year: iOS 9 in 2015, Mac OS X 10.11 in 2016, iOS 10 in 2017, etc. On “off years” between major updates, the company could do point releases to introduce minor features and support new hardware, especially on iOS. Both operating systems are sufficiently mature at this point that they don’t need yearly updates. Sure, it might be nice, but not at the expense of overall quality. I’d rather have a polished, stable product that I can rely on than a buggy bunch of features that I can’t.

It’s time for Apple to stop setting itself up for failure. At the same time, it can do right by users and make sure that people still get the “it just works” experience they deserve.

I haven’t had much to say about the Apple Watch because there are so many things we don’t know about it yet. But there are some interesting things to speculate about. One idea that’s been floating around the Apple developer community is that apps for the Apple Watch will be extensions of iPhone apps. They’d run on the Watch, but be downloaded and installed as extensions of an iPhone app, and get to take advantage of the shared data container used by iOS app extensions.

At first blush the idea makes sense, but the more I think about it, the more I don’t think it’s the way Watch apps will work. Ben Thompson pointed out that Apple is thinking long-term about the Watch.

This approach – the one that Apple chose – allows the hard work of UI iteration and app ecosystem development to begin in 2015. Moreover, that iteration and development will happen with the clear assumption that the Watch is a standalone device, not an accessory. Then, whenever the Watch truly is standalone, it will be a complete package: cellular connectivity, polished UI, and developed app ecosystem. It will be two years closer to Digital Hub 3.0 than Alternative #1 or #2.

The tradeoff is significant confusion in the short-term: the Watch that will be released next year is not a standalone device. It needs the iPhone for connectivity. To be clear, this is no small matter: the disconnect certainly tripped me up for a week, and if the feedback I’ve gotten is any indication, it continues to befuddle a lot of very smart people.

Although today the Watch requires an iPhone for connectivity and other assistance, Apple is clearly looking forward to a day when it does not. With that in mind, it would be silly to constrain apps to mere iOS extensions. Why design an app ecosystem around the presence of an iPhone if your long-term goal is to make the watch a standalone device?

I suspect that Watch apps will be installed and managed via a connected iOS device, but will run more or less autonomously. Something like Handoff will be used to pass data back and forth between the Watch and the iPhone. In the short run, Apple may also offload computational tasks to the iPhone CPU to save battery, but that will happen behind the scenes in such a way that developers don’t have to give it much thought. Over time, as the Watch becomes more powerful, it will gradually hand off fewer tasks to the iPhone. By making Watch apps independent of an iOS app container from the outset, Apple can make this transition as seamless as possible.

Of course, we’ll know a lot more once we get a look at the SDK for Watch apps, hopefully sometime this fall or winter.