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.