The recent disappearance of the popular Camera+ app from the App Store—allegedly for violations of Apple policies—has once again thrown the topic of app approval in the spotlight. Sooner or later, all developers who write for App Store distribution need to come to grips with the stark reality that is otherwise known as the approval process, in which Apple engineers get to vet whether an app conforms to the many and sundry rules that make it App Store-worthy.
Said rules have been decried by many in the Mac community, particularly when they do not seem to be clear, or prevent the introduction of a capability that apps written by Apple already feature. Their application by the review team has, on various occasions, been called capricious, arbitrary and just plain wrong. Elsewhere on this site, for example, my colleague Lex Friedman argues that Apple should relax the volume button ban that led to Camera+’s App Store ouster.
By and large, though, Apple has done a reasonably good job of maintaining the consistency of its approval process. If it’s true that the company does, every now and then, make mistakes (typically when considering borderline cases), it’s also difficult to believe that 300,000 apps made their way on the App Store by sheer accident. And, while not all the rules are collected in a single convenient manual, it’s not all that difficult for developers who are “plugged in” to the community to gain a good understanding of what is allowed and what gets you a short trip to the rejection bin.
Among the several rules that regulate app approval are three that should be well-understood by everyone: first, you cannot use functionality that has not been officially sanctioned by Apple (the so called “private APIs”). Second, you cannot alter the behavior of an iOS device in such a way that will confuse the user. And third, you cannot keep any features hidden from Apple.
On the first point, Apple usually keeps APIs private for one of three reasons: the company thinks that exposing them would be problematic. (For example, giving direct access to the cellular interface could raise significant security issues.) Apple also doesn’t think that developers will need access to them (as was the case with the camera interface prior to iOS 3.0), or those APIs are simply not finalized and ready for public consumption.
This last reason is particularly important: APIs are the language that apps use to communicate with the world around them; once they’re let loose in the wild, they tend to stick around for a really long time. Therefore, Apple is rightly cautious before publishing them, as the consequences of a mistake can be significant and long-lasting.
As far as behavior alteration is concerned, there are many different factors at play, but they usually revolve around the concept that Apple wants the user experience associated with iOS devices to be both predictable and consistent. Any deviation from the “standard” interface behavior has the potential to confuse users, even when some sort of manual input is required to activate it.
Besides the aesthetics associated with device usage—never to be discounted with a company like Apple—there are practical considerations behind this rule: degradation in the user experience reflects on the device as much as it does on the app. If even 1 percent of all users becomes confused by an app and 1 percent of those needed special attention in the form of customer support or a refund, with 100 million devices in circulation, Apple would be faced with 10,000 unhappy customers.
Finally, on the topic of Easter eggs, Apple doesn’t prohibit their introduction in an app, but the company does request that developers disclose all of them during the approval process. Apple agrees to keep the existence of any hidden feature confidential and, as long as they don’t break any of the other rules, simply tests them the way it tests the rest of the app.
Breaking the rules
In the case of Camera+, developer Tap Tap Tap appears to have run afoul of two of these rules by first allowing the volume button to double as a shutter mechanism and then, after having been told by Apple that this wouldn’t be allowed, simply hid the functionality so that it wouldn’t be visible to the approval team.
Leaving aside the mechanics or the ethics of what happened, and keeping into consideration the fact that Tap Tap Tap has not publicly commented on this matter, I think that Apple has made just the right call in refusing to allow the volume-click shutter to be included in Camera+.
Within the isolated context of the app, the feature may well make sense and be a great addition—but, then again, the app doesn’t run in isolation. At any given moment, the user might be playing music or be on a phone call, in which case pushing the volume button will affect something other than Camera+. Chances are that, even if the function is off by default and must be activated by the user, most people will eventually forget that they have enabled it, and blame the resulting odd behavior on their device.
If a conflict between Camera+ and a phone call happened while, say, the user is driving, it could be downright dangerous. Of course, one could claim that it’s unlikely that anyone would be reckless enough to take pictures while driving and on a phone call, but I’ve seen enough people on the highway reading, writing, solving crossword puzzles, shaving, making their faces up and eating (with a fork and knife from a plate) to know that this scenario is not quite as far fetched as common sense would seem to suggest.
Changing the rules
In the end, however, this problem is not one of rules, but of their application. People seem to forget that the app review team doesn’t decide what is acceptable or not—rather, they decide whether the apps submitted conform to rules that other people within Apple have set. Despite their undeservedly bad reputation, there are numerous reports that app reviewers are usually very approachable and they do try, when possible, to help developers get their apps into Apple’s store, so long as everything is above board and everyone is acting in good faith.
No matter how unfair the rules may seem, attempting to circumvent the app review team is a strategy that may work in the short term, but will inevitably backfire sooner or later. Apple has an established process for requesting changes to its products. As the Tap Tap Tap folks themselves have pointed out, users and developers alike can submit a bug report and request that a new feature be added or allowed into the store.
The bug reporting process can be frustrating, but it often does work and has resulted in a number of new APIs being opened to developers as the iOS SDK matures. For example, the initial hacks that were necessary to access the camera data have, over the years, given way to the very same rich audio/video interface that makes apps like Camera+ possible.
[Frequent Macworld contributor Marco Tabini is a web specialist based in Toronto who has built a few iPhone apps of his own.]