Is Apple blanket-rejecting iOS apps that make use of Dropbox because of an evil plan to push developers toward iCloud? If you asked this question five days ago, the answer from the Internet at large might have been a resounding "yes!" But days later, as is often the case, details have come out that reveal the answer is probably "no."

As it turns out, Dropbox inadvertently put other developers using its SDK in violation of one of Apple's app guidelines, resulting in a string of rejections that looked as if apps using Dropbox were being banned. The Web flew into a fury over what is essentially an annoying but long-standing clause in Apple's guidelines. The problem has now been remedied and the fury has died down, but what, exactly, happened during this sordid drama and how did it end up being fixed?

"Apple is rejecting apps using Dropbox!"

A thread in the Dropbox forums began just under a week ago with several app makers reporting that Apple rejected their apps due to an issue with Dropbox. Their apps had made use of the Dropbox SDK. When users set up this feature for the first time, they are directed to Safari where they're prompted to authenticate their Dropbox accounts for use with the app in question. This functionality was required by Dropbox's latest SDK at the time, and app makers were left confused as to who was really responsible for their app rejections. Most people blamed Apple.

It eventually came out that the rejections were apparently due to the fact that users could click through to Dropbox's main website while they were busy authenticating through Safari. This could lead them to an account sign-up page and could lead to them paying Dropbox money for storage. And the reason Apple doesn't want that? In its own roundabout way, the ability for Dropbox to potentially bring in revenue without going through Apple's in-app purchasing mechanism is a violation of Apple's guidelines:

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

This is the same guideline that has led to Amazon's Kindle app—plus a plethora of others—removing links to outside content stores where customers can purchase content outside of Apple's system. Customers can still purchase content outside of Apple's system, but Apple doesn't want them to be able to get there (directly, anyway) via the iOS app itself. "We have not changed our developer terms or guidelines," Apple spokesperson Trudy Muller told Ars in February of 2011. "We are now requiring that if an app offers customers the ability to purchase books outside of the app, that the same option is also available to customers from within the app with in-app purchase."

Indeed, this guideline has been around for years, and has been actively enforced for some types of apps for more than a year. A violation is a violation, but that doesn't make it user-friendly at all. For the Kindle and other reading apps, the removal of any store links (and refusal to add in-app stores) makes the process of obtaining new content quite convoluted on the user end. And in the case of apps that use Dropbox, the situation was even more of a reach—the apps themselves didn't link to a way for users to create accounts to buy Dropbox storage at all. The app only used the Web for Dropbox authentication, and the Web page in question had the potential to lead users there.

Already patched

Apple did not respond to our repeated requests for comment, but did confirm to All Things D that the above guideline was indeed what Dropbox's SDK had violated. Once Dropbox figured out the issue, it was quick to update its iOS SDK so that there would be no links available for users to click around and make their way to an account creation page. Functionally, the crisis was over.

But Dropbox still defended itself. The company argued that although its own app makes use of Apple's in-app purchasing mechanism, it's not possible for Dropbox to offer that ability to other app-makers through its own SDK. Basically, it can't allow third parties to include an in-app way for users to sign up for paid Dropbox accounts. "Apple requires paid services that allow account creation to offer the option to upgrade via In-App Purchase (IAP)," a Dropbox spokesperson told All Things D. "We abide by this policy in our app, where we offer upgrades only via IAP. However, we are unable to offer IAP in our SDK to third-party developers due to limitations of IAP. Additionally, our SDK allows only free accounts to be created from third-party apps and has never been used to promote our paid plans."

As of Thursday, several developers making use of the updated Dropbox SDK are still waiting for approval on the App Store after re-submission. (We have heard that the average approval times on the App Store have dropped to 3-5 business days recently, down from about a week. Still, it may take a few more days for those apps to make their way through the process.) But the thread in the Dropbox forum has begun to devolve into a debate over whether Apple specifically targeted Dropbox because of its services that seem to compete with iCloud.

"I can't believe it took that many posts for someone to mention iCloud. It's very obvious that Apple are just protecting iCloud," one user wrote.

"This term in their developer docs (11.13) has been there for AGES and they have been enforcing it more and more over the past 2-3 months," another user responded. "I've had the same, identical rejection for apps which work in spaces that Apple would never have reason to enter (small business accounting!?). I had to work around it in the same way—don't link to external sites, and if I do, don't have them contain links to anything with a signup page. Saying it's an attack on DB because of iCloud is FUD/BS/Redherring."

Considering Apple's past enforcement of the same guideline on numerous other apps, it doesn't seem as if Apple was acting maliciously against Dropbox in particular. Apple has, however, faced issues with inconsistently enforced guidelines in the past. This incident only highlights some of the frustrating challenges developers face when it comes to the App Store. It's sometimes hard to know whether something you're doing—or something the SDK you're using is doing—will land you in hot water and cause a ruckus in the tech press.