Upward Mobility: The Terror of iOS App Submission

Getting apps into the store is a non-deterministic process

One of the major topics of my Enterprise iOS book is how to plan release schedules around  Apple’s peril-filled submission process. I don’t think you can count yourself a truly bloodied iOS dev until you’ve gotten your first rejection notice from iTunes Connect, especially under deadline pressure.

Traditionally, the major reasons that applications would bounce is that the developer had been a Bad Person. They had grossly abused the Human Interface standards, or had a flakey app that crashed when the tester fired it up, or used undocumented internal system calls. In most cases, the rejection could have been anticipated if the developer had done his homework. There were occasional apps that got rejected for bizarre reasons, such as perceived adult content, or because of some secret Apple agenda, but they were the rare exception. If you followed the rules, your app would get in the store.

The problem is, the rules keep changing, and in ways that can make a formerly acceptable app become a reject overnight. A good example is iCloud backup storage restrictions. I recently had an app that had been getting into the store without issue suddenly get the cold shoulder, because the sqlite file it used to cache images was now getting backed up to iCloud behind my back. Apple rejected the app (perhaps rightfully so), because I hadn’t set the flag on the file to exclude it from backups. Ok, lesson learned, I added code to force it to stay out of iCloud, and resubmitted, having cost a week of delay getting the new version into the store.

Imagine my surprise when I submitted the first version under the new iOS7 SDK, and got another rejection for the same reason. It turns out that in the new SDK, Core Data creates a new journaling file for sqlite, which was raising the ire of the Apple gatekeepers because it was also being backed up. So, with a sigh, I flagged that file as well, offered to commit ritual suicide to my manager for delaying the new release, and moved on.

The point I’m making is that iOS developers are caught in a Catch 22. Apple sets stringent submission standards for applications, and then makes changes to the OS and SDK that can cause apps to fail submission without notice. It makes app authoring a very non-deterministic process, because you can never assume an app will pass muster, and you have to build weeks of extra padding into your release schedule to allow for a bounce or two.

You know what would be awesome? If Apple published the checklist of things that their testers ran apps through on submission, and gave developers access to the same tools the testers use. That way, you could have confidence that you had run your app through the same gauntlet that the testers use. It wouldn’t prevent every bounce, especially for more qualitative evaluations like HID violations, but it could catch a lot of them.


Sign up for the O'Reilly Programming Newsletter to get weekly insight from industry insiders.
topic: Programming
  • alexandra.kwc

    Building robust, integrated, native applications is quickly becoming a requirement across the enterprise, but not having mobile programming skills in Objective C, Java, Javascript, and/or Mobile J Query no longer has to be a roadblock. All developers can now build, test and deliver data rich, native apps quickly and easily without any mobile programming skills required. Those developers with mobile programming experience can leverage their skills to extend development further and significantly faster than ever before.


  • http://www.innovationm.com/ Rashmi Phukan

    I agree. iOS App submission is nerve-racking even for experienced iOS developers. But Apple provides guidelines to help you stay within the sometimes invisible boundaries of what is and isn’t allowed in the App Store. So prepare your app well before submitting it to the App Store.

    Ask the following questions before app submission:-
    1. Does your app follows iOS Human Interface Guidelines?
    2. Have you tested your application on one or more physical devices?
    3. Is it facing any memory leaks & performance issues?
    4. Does your application crash from time to time?
    5. Do you have an App ID, a valid distribution certificate, and a valid provisioning profile?
    6. Have you configured your target’s build settings in Xcode?
    7. Have you set your application’s deployment target correctly?

    If you have a “yes” to all the above questions, get all your Metadata in place & submit your app. If you are looking for iOS design & development support, please reach out InnovationM – http://www.innovationm.com/ios.php.