Reason for rejection is the fact that if the user does not have Dropbox application installed then the linking authorization is done through Safari (as per latest SDK).
Once the user is in Safari it is possible for the user to click “Desktop version” and navigate to a place on Dropbox site where it is possible to purchase additional space.
Apple views this as “sending user to an additional purchase” which is against rules.
Through five rounds of rejection and revision, over eight weeks, we and our appeals team kept bowdlerizing our signup links and verbiage to no avail: every week the big red dot would descend again on our iTunes Connect icon
Eventually it became clear that, from the reviewers’ perspective, there was a problem with that, at all: it wasn’t the (already redacted) signup links that we were being rejected for, but any GitHub link. At all.
In the specific case of Dropbox, they have an SDK that will let you sign into an existing account. According to MacStories:
[..] the Dropbox team has already released a “beta” version of the 1.2.2 SDK, which removes the option to create an account on Dropbox.com. The beta SDK was seeded a few hours ago, and there’s the possibility Apple will reverse its decision on those rejections once they see the removal of the incriminated links.
So, if I’m trying to write a client app against a third party API, I have exactly one option – put a username/password login form for that service directly into my app – not exactly good security practice – and offer the user no help at all in creating accounts on this service.
If I’m integrating against, say, the Flickr API, which doesn’t offer this ability, I’m stuffed. No more third party Flickr clients on the App Store, I guess. Or I could write to Yahoo! and ask them to provide a login flow that doesn’t provide any links that lets my users escape and get to a page that’ll let Yahoo! ask for money. Good luck with that.
As someone who wants to write apps against third party APIs, I now limited to writing clients against:
- free services that have no intention of ever charging money (i.e., services that are going to go out of business)
- or paid services that are willing to not try to up-sell their customers during account creation and won’t ever change this policy (i.e., services that are going to go out of business)
And if I have a web service with an API and would like people to write against it, my options are limited to one of
- Don’t charge money, or provide the option to charge money, and never plan to charge money
- Don’t provide any easy way for users who are new to the service and are coming from a third-party client to give me money
- Don’t have an ecosystem