true... if you don't bother testing your software before rolling it out to the punters...
Except when the Apple compiler caches an old database copy into the app store release which you CANNOT test for. It's submitted to Apple, who after 12 days "test" it (apparently not that we'll), then it's released. The app store copy is identical to our copies which we have been testing for months, except when XCode compiles it incorrectly, and since it's encrypted for the app store we cannot run it.
We release onto App Store at 10pm in case there are any problems, so it affects a minimal number of people. We instantly Realise there's a problem and pull it within 10 minutes. Some people update, which is obviously bad and we'll fix them up with free subscription time.
3 hours later (working till 1am), and we've submitted a new version to Apple and submitted for an expedited review. Apple lose expedited review. We resubmit expedited review. Apple are closed for weekend & 4th July. We call Australian Apple rep contact, who calls USA and is told to get lost. We get another contact (high profile developer in the US) to forward request to a personal contact in the review team. Unsure of result.
Also unable to roll back to previous versions on the App Store.
Totally out of our control - both the bug and the fix time.
So when you say "next time test it" - of course we test it; I've done tons of testing. But when our tools of the trade fail us, the most we can do is work through the problem, and wait. And wait. And wait, it seems. This is the advantage & limitation of the app review process. It stops a lot of bad apps getting through, thus making for a better user experience, but seems to lack any facility to rapidly deal with critical bug fixes in a timely manner.
We're ditching Apple CoreData so this doesn't happen again, so I'm happy to call it a once-off.