5 Apr 2015

Fixing the iOS App Store Policies

(Disclosure: I work for Google, but not on Android, and in any case, these are my personal opinions.)

It has been a few years since the last news cycle of Apple capriciously rejecting iOS apps. It seemed like developers understood what kind of apps to build, and not build, for iOS, and users accepted the tradeoffs with this platform. So, when it looked as if things had settled down and Apple has put this problem behind it, comes this uncomfortable news, disconcerting even by the low expectations people have of the iOS app store’s transparency and policies.

Apple should change their philosophy and hold themselves to higher standards of transparency and objectivity.

To begin with, make all the rules as precise as possible. Apple shouldn’t keep the rules vague in a deliberate attempt to give themselves greater room to manoeuvre. That’s disrespectful to developers’ time, efforts and money, and discourages them from building iOS apps. There will obviously be some grey areas, but Apple should try their best to document everything as clearly as possible, both things that are okay for developers to do and things that are not.

When it comes to things like forbidden functionality, like whether a widget can have a calculator or not, Apple should switch to a “default permit” model, where an everything that’s not explicitly forbidden is automatically allowed. If Apple wants to reject an app for such reasons, they should have to point to a specific rule that outlaws the said behavior. And this rule should be precise and objective enough that you should be able to ask two observers whether a particular app falls afoul of the rule, and get a consistent answer.

An example of such a clear rule is the one that prohibits non-WebKit browsers. Whether that’s a good idea or not, we can all agree whether a given app is in compliance with the rule. Developers won’t waste their time building an app that won’t be approved, which in turn causes bitterness all around.

Building an iOS app should be as risk-free as creating a Tumblr blog or uploading a video to Youtube. Youtube doesn’t come along and delete your video because they didn’t like the camera angle.

So, every app should be approved unless Apple can point to a specific rule that it falls afoul of, and this rule should be objectively worded. Obviously, this doesn’t apply to things like spam, abuse, and privacy or security issues.

And, if a new rule comes along, it should be announced first via a blog post, and not by rejecting an app as a way of communication, which is disgraceful. Not only should the rule be announced first but it shouldn’t apply for, say, a quarter after it’s announced.

If Apple does reject an app for a particular reason, like having a calculator widget, they should update their rules to say so. Developers shouldn’t have to reverse-engineer Apple’s policies from third-party blogs. And, once Apple rejects an app for having a calculator widget, they should be consistent in that policy, and, in the future, reject all apps that come along that have a calculator widget.

Each rule should have a clear user-visible benefit. If Apple can’t articulate one, that rule should be removed, as with the rule that prohibits non-WebKit browsers. To address the elephant in the room, use the rules to help users, not Apple. Doing right by users also helps Apple in the long term.

Developers should also be able to ask Apple for clarification as to whether an app is okay, before they start developing it. Let them communicate to Apple over email, or by sharing wireframes, etc. And if Apple says it’s okay to go ahead and build that app, then they shouldn’t allow themselves the choice of rejecting that app later. Not everything is black-and-white, but some cases are: if a developer says they want to build a calculator widget, and Apple says that is okay, then Apple shouldn’t reject the app later for having a calculator widget.

These are simple, fair, common-sense rules that will go a long way in increasing the health of the iOS ecosystem, and help Apple, as well. So, even if Apple doesn’t care about the health of the ecosystem, and cares only about itself, it still makes sense to adopt these suggestions, or similar ones.

No comments:

Post a Comment