Apple is making life difficult for Dropbox and for iOS apps that rely on it. Dropbox responded with both alacrity and agility to resolve the issue.
News emerged a week ago on a Dropbox forum that Apple's App Store had rejected an app (Cambox) that uses Dropbox for storage. The Next Web was the first publication to call wider attention to the issue.
The rejection seems to have been triggered because Apple just noticed a 7-month-old change in the Dropbox software development toolkit (SDK). The developer described the way he understood the reason for the rejection this way: "...the fact that if the user does not have Dropbox application installed then the linking authorization is done through Safari. Once the user is in Safari it is possible for the user to... navigate to a place on Dropbox site where it is possible to purchase additional space."
Or as Ars Technica puts it: "...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."
Other developers in the Dropbox forum reported getting similar or identical rejections. One explained that once an Apple rejection is in their knowledge base, it comes up for all later reviewers and so similar rejections are highly likely to occur.
Dropbox quickly released a workaround: a new version of their SDK that omits the problematical call. A Dropbox employee wrote in a forum post: "We're looking for a better long-term solution, but in the mean time this should allow your app to be approved." A Dropbox spokesman told AppleInsider: "We're working with Apple to come up with a solution that still provides an elegant user experience." So far, none of the rejected apps has reported being approved because of using the revised Dropbox SDK.
This is not a case of Apple wanting to channel users to their own cloud app, as opposed to that of a competitor -- Apple has no service even remotely equivalent to Dropbox's. Its iCloud offers only a comparitively limited form of syncing for particluar Apple-supplied apps.
Apple's rejection is based on this wording from their terms of service for the App Store: "Apps utilizing a system other than the In App Purchase API (IAP) to purchase content, functionality, or services in an app will be rejected."
You can see Apple's motivation for this clause. They want to make it impossible for an iOS developer to collect money from users by any avenue not subject to Apple's 30 percent tax. Reasonable enough: it's Apple's platform and they provide ample value to earn that 30 percent.
The slippery slope Apple is going down here is that they are enforcing the no-money-except-through-us rule one step removed from the application developer. It is not Cambox that stands to make money; it is a service that Cambox uses. And Dropbox making money is not guaranteed by the workflow. It is merely a theoretical possibility depending on what the user chooses to do once s/he arrives at Safari.
In the Dropbox forum, another developer added the perspective that the Dropbox rejection, based on a workflow that includes Safari, absolutely is a new expansion of how Apple enforces their terms of service:
Unless something changed just recently, it was OK to sell whatever you want on iOS as [long as you do] it by opening a URL in Safari (as [opposed] to opening a URL in the app via Web view). I had my app rejected because it was opening some Web page in Web view, which allowed [the] user to get to [another] page with a "buy" button. Solution -- suggested by Apple -- was to open the same URL in Safari.
Finally, Dropbox told AllThingsD in a statement that it was perfectly willing to play by Apple's rules, even as the company remains one step removed from the action, but technical details of Apple's own SDK made that impossible:
Apple requires paid services that allow account creation to offer the option to upgrade via In-App Purchase (IAP). We abide by this policy in our [own] 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.
The moral: we're all still sorting out this app thing, not to mention this cloud thing. There will be some friction around the edges of the walled gardens and the open playgrounds until it all settles down.