Conditionally disable backgrounding for an iOS app?

Question

I am working with an app that is powered by data fetched from a server. The fetching logic is fairly robust and fault tolerant; most connectivity errors are automatically retried, which usually works great. However, given a very rare set of circumstances (which include a race condition involving network latency and the backend database), it is possible for the app/server to get into a inconsistant state which cannot be recovered from.

What I would like to do is have the app, when in this state, simply terminate the next time the user presses the home button (instead of going to the background). The app, when relaunched, would re-sync with the server and the user would go about his/her merry way.

My first thought is to call exit() from applicationDidEnterBackground when the inconsistant state is detected. Does anybody have any experience with this sort of thing or know of another way to disable backgrounding on a conditional basis? I understand this is frowned upon, does anybody have experience with Apple explicitly rejecting an app by detecting the use of exit()? UIApplicationExitsOnSuspend = YES isn't an option since multitasking needs to work as expected the other 99.999% of the time.

Note: my apologies for the lack of specifics. The ideal solution is to come up with a way to recover from the inconsistent state; trust me when I say much time and effort has gone into figuring out a way to do so.

Answer 1

Using exit() is highly discouraged by Apple, per their Technical Q&A QA1561:

WARNING: It is possible to quit the application by calling exit. Applications calling exit will appear to the user to have crashed, rather than performing a graceful termination and animating back to the Home screen. Such usage provides a negative experience and is strongly discouraged.

Use of exit() should show up as a crash, like a failure in an assertion would. If a reviewer hit this condition while testing your application, odds are that it would be rejected.

However, if this is a very infrequent case you could roll the dice and hope that the reviewer would never encounter it. It's a gamble, and you may be able to get away with that, but I don't know if that's the best plan of attack.

If you can identify this inconsistency, I can't see why you couldn't wipe all in-memory stores and effectively start things from scratch, as you would on a fresh boot of the application. I had a rare case where my Core Data database would become inconsistent due to an undo / redo / undo cycle, and this is what I did to recover from that.