Sunday, March 10, 2013


The app I work on (AsdeqDocs) has been rejected from the App Store, by my count, three notable times (and accepted probably a dozen times). The first time was because we hadn't gone through the correct process to get an export exemption for using weapons grade encryption or whatever that particular US insanity is called that means you need to apply for permission to use strong encryption (in fact I think it still isn't available in the French App Store because they have even more ridiculous restrictions around encryption). The second time was because we had a link to the purchase page for our server product in the app. Their logic on that is fine, they don't want people selling app-related content that Apple don't get a cut of, and fair enough. We took the link out of the PDF and we were golden again. The third time I can't remember the exact reason just that it was a rejection of some feature that was already in the approved version in the App Store which held up a critical fix being pushed for a solid three weeks.

One of the features we support is the ability for administrators and device owners to log into the web app and issue a remote wipe command on the app. This destroys all of user's documents, deletes encryption keys, and generally nukes everything related to our app. It's a pretty obvious feature for anything that stores documents on a mobile device prone to being lost/stolen and something that didn't make the 1.0 release for various reasons.

I was in charge of implementing the feature and it was pretty straightforward: when a remote wipe request was received delete everything then quit the app. The first part was trivially easy, which just left quitting the app. The quit part is pretty important because although deleting the data out from under the app renders it prone to crashing, we wanted to make sure the period of time from wipe command issued to app is completely unavailable as short as possible. I was going to just use the old C++ stalwart exit(0) but thought I should hit the Internet to find the correct way to quit an iOS app programmatically. There is no way to do it. In fact Apple's human interface guidelines have this to say:
Don’t Quit Programmatically
Never quit an iOS app programmatically because people tend to interpret this as a crash.
If you have ever dealt with Apple as anything but a regular consumer you may be aware that things in their documentation that use the word guideline are only being polite: it's a special definition of guideline that means you can and will be rejected for not following it. You might know such things by the more common name of rules. Look at the above guideline in its original form here. That font size does not brook opposition.

Further investigation revealed stories of people whose apps had been rejected for the specific reason of including an exit statement. After talking with the other developers and tossing around some silly ideas like just doing something deliberately asinine (e.g. dividing by zero) to make the application crash and thus achieve the same as an exit call, we eventually decided on including the exit call and having a backup plan for when it got rejected.

In this case, the "we" who made the final decision was more precisely "me" and a not 100% accurate description of the final implementation given to the product manager. To be honest I assumed it was something that the automated testing Apple do on submissions would pick up as a matter of course and that it would be rejected quick smart. In close to record time (for our submissions at least) the email came back saying that the build was accepted and was now available in the app store.

Ever since then I've been waiting for a version to be rejected for our app having the temerity to terminate.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.