It started when a developer, whose Cambox photography app uses Dropbox, posted a note to Dropbox’s message board claiming the app had been rejected by Apple. The reason for the rejection: “…the fact that if the user does not have Dropbox application installed then the linking authorization is done through Safari,” wrote the developer, noting that this occurs because of a mechanism present in the latest Dropbox API.
(LIST: 50 Best iPhone Apps 2012)
A second developer then posted one of Apple’s actual rejection notes, which reads:
We found that your app provides access to external mechanisms for purchases or subscriptions to be used in the app, which is not in compliance with the App Store Review Guidelines. Specifically, your app enables to user to create accounts with Dropbox and Google.
At first blush, Apple seems to be within its App Store Review Guidelines, specifically the part where the guidelines say “Apps utilizing a system other than the In App Purchase API (IAP) to purchase content, functionality, or services in an app will be rejected.” But it’s the part where Apple targets account creation that the ice appears to thin. There doesn’t appear to be anything in the App Store Review Guidelines where redirecting a user to a browser for purposes of creating an account violates Apple’s terms — not unless you read the account creation redirection as a bait-and-switch to get users through the door to then buy stuff, say extra Dropbox storage space, via the web interface. That, it seems, is how Apple’s reading what these apps are doing.
Another developer whose app was also rejected dropped by the thread to clarify: According to the note he received from Apple, “Apps that link to external mechanisms for purchases or subscriptions to be used in the app, such as a ‘buy’ button that goes to a web site to purchase a digital book, will be rejected.” Apple cites the rejected app for providing “external mechanism for purchases and subscriptions,” and says that’s because the app “provides an external link to Safari to create a Dropbox account.” (The in-app link in question simply reads “Need a Dropbox Account?”)
Dropbox has ostensibly remedied the issue by posting a version of its API that removes the “create account” option. But the question stands: Is Apple overreaching by essentially blocking any external calls that could be linked — directly or indirectly — with a purchasing mechanism? Apple seems to be saying developers whose apps want to reference other services, where the other service isn’t natively present on the device, can only do so if they provide an in-app mechanic.
In other words, if you’re using App X, which happens to invoke Dropbox for storage purposes, but you don’t have Dropbox natively installed and/or a Dropbox account, Apple’s saying App X can’t redirect you to set one up because you might, while there, notice Dropbox’s upgrade options, purchase one, and cut Apple out of the sale.
Is that an overzealous attempt by Apple to safeguard its App Store revenue model? A closed loop that makes it impossible (or at least problematic) for app developers to reference other apps? That’s the reaction from others in the thread. As one user sarcastically puts it: “Apple should reject all web browser apps because they can take you to a page that lets you purchase stuff.”
Then again, we’ve known about Apple’s App Store policies for nearly a year, and we know Apple’s not bashful about enforcing them. From Apple’s standpoint, the company no doubt believes it’s closing a potential backdoor that might be exploited were it to approve external linking of this sort. The downside is that, in pursuing this sort of aggressive protectionism, the company appears to be obstructing simplicity and usability by problematizing the way interdependent apps interact.