Drafts, and what's happening with iOS 8 widget rejections

The developer behind Drafts, a popular time-shifting text app, was told by the App Store review team that he needed to remove their Today view widget from iOS's Notification Center due to the behavior of its buttons. It's one of a growing number of post-review rejections for Notification Center widgets that began with PCalc. Though Apple later reversed its PCalc decision, the company has continued to reexamine other widgets. So, what's going on... and why?

Extensibility, which includes Today view widgets, has been one of the biggest additions to iOS since the launch of the App Store. Unsurprisingly, it's why we're seeing something akin to the kind of growing pains first witnessed during the App Store's debut. When PCalc's Notification Center widget first faced rejection, I wrote about how the App Store works — specifically when it comes to the introduction of something as new and important as Extensibility. The TL;DR version is:

1. New technologies get introduced at WWDC.
2. Developers race to include them in their apps and get them submitted to the App Store prior to launch day.
3. Apple's software team races to get iOS shipped, the marketing team to get apps approved, and the services team to get approved apps featured for launch day.
4. After launch, apps that were approved (and even featured), but used iOS's new technologies in "unforeseen" ways, can eventually get looked at again within Apple.
5. Most of those apps fit with how the marketing and services team believe the technologies should be used, and stay approved. Some don't, however, and face post-approval rejection — in whole or in part. A smaller amount still result in the executive review board changing how the marketing and services teams believe the technology should be used.

I'm using terms like "marketing" and "services" instead of "Apple" here because referring to Apple as a singular entity makes it easy to forget the company is not a hive mind. There are different people from different orgs that have different perspectives and opinions. It's a human-driven system, which means there will be inconsistencies over time — but also improvements.

Sometimes this benefits us: Apple stops bad developers from doing bad things like stealing our contacts or conning us into buying fake apps. Sometimes it frustrates us: Apple stops smart developers from giving us a one-swipe-away calculator or a way to start a new draft.

In-between, we have a lot of turbulence. A lot of edge-cases and judgement calls. And a lot of frustration.

On the developer portal, Apple describes Today view widgets as a way to "provide quick updates or enable brief tasks". Examples included posting updates on package deliveries, or getting the latest surf reports or breaking news stories. In the programming guide, Apple describes widgets as way to 'give users quick access to information that's important right now". Examples there include checking current stock prices or weather conditions, or performing quicks task like marking a checklist item item as done.

Incredibly resource-constrained and severely limited for privacy and security reasons, developers were still able to get entire calculators in there, as well as games, keyboards, app launchers, and more. They were able to get a lot of things in there in part because those use-cases were unforeseen.

There's an argument to be made that if Apple was far more explicit about its policies up front, this wouldn't happen. Yet if there had been an explicit "no calculator widgets" at the start, James Thomson would never have made one. Maybe he would have lobbied for a change, and maybe we'd have gotten it eventually, but we wouldn't have had a PCalc widget as quickly as we did.

Likewise, if the letter of the law allowed for a widget type but its experience or content was antithetical to Apple's platform, it could result in other complications. ("Apple sued by contact-stealing app, developer claims no rules broken!").

There's also an argument to be made that these sorts of things should be settled faster — and settled internally — before any developer is ever contacted. Yet escalation doesn't scale, and appeal, by definition, can only happen after the fact.

I say all this not to excuse Apple, but to explain — not to claim the system is perfect, but that improving it will take some serious thinking and, likely, a lot of trial and error. (I've shared some of my own thoughts on this already.)

And that sucks for everyone, because it hurts everyone. Apple faces bad press and strained relations with developers, developers face uncertainty and unhappy customers, and customers lose features and get mad at developers and Apple.

Calculator widgets, unforeseen in the original iOS Notification Center plan, were ultimately allowed. Keyboards, which Apple expressly said couldn't be called, were ultimately not allowed to be independently implemented. What will happen with Drafts and buttons that send you to the app and initiate actions? We'll have to see. (I personally like it and find it useful, so I'm very much hoping it also gets approved.)

Over time, developers should get a clearer idea of what will and won't be approved, while Apple should see fewer and fewer "unforeseen" implementations. Like with apps, controversial rejections will become exceedingly rare.

And that, for better and for worse, is how the current system works.