1

I heard that merely using exit() and even providing a zero parameter will result in iOS generating a crash report. But in some cases it is better to perform an exit(0). So, what is the accepted way to exit an app if exit() is not allowed? Thanks.

4 Answers4

1

A) do not call exit as part of normal application flow. That will get your app rejected from the app store for certain.

and B) if you want a backtrace and or crash report, throw an exception and the resulting crash log will show where the exception happened (with a backtrace).

I sense that your question is simply about quitting your app though. You're not supposed to quit the app programatically but instead let the user quit when s/he decides it's time to kill the app. In any event, when your app is finished up doing whatever it is that it's doing, one nice thing you can do is release all the resources you can as your app goes into the background state. Here's a related question that might help you out.

Community
  • 1
  • 1
Michael Dautermann
  • 88,797
  • 17
  • 166
  • 215
  • I think Apple's ideas about this are short-sighted. There really are cases where exiting is preferred. Simple apps that have simple data may not need to use exit but a complex app with a convoluted data set could benefit from use of exit, because the cost of untangling the data may be high. –  Dec 12 '11 at 19:33
  • 1
    An app should never ever exit, the user will not understand what happened, and the developer will never get any data on what is going wrong. Never write corrupt data, so check before writing. Rather check if writing was successful and if not don't commit the transaction. If still anything goes wrong, let the app crash, collect the crash report, and on app start make sure to replace corrupt data with safe data. – Kerni Dec 14 '11 at 20:45
1

There is no accepted way for an application to quit itself. From the iOS Human Interface Guidelines:

Don’t Quit Programmatically

Never quit an iOS application programmatically because people tend to interpret this as a crash. However, if external circumstances prevent your application from functioning as intended, you need to tell your users about the situation and explain what they can do about it. Depending on how severe the application malfunction is, you have two choices.

Display an attractive screen that describes the problem and suggests a correction. A screen provides feedback that reassures users that there’s nothing wrong with your application. It puts users in control, letting them decide whether they want to take corrective action and continue using your application or press the Home button and open a different application

If only some of your application's features are not working, display either a screen or an alert when people activate the feature. Display the alert only when people try to access the feature that isn’t functioning.

Community
  • 1
  • 1
Jim
  • 72,985
  • 14
  • 101
  • 108
  • The above quote does not seem to apply if there is something seriously wrong with the application that will prevent the app from continuing. – hotpaw2 Dec 12 '11 at 19:47
  • If there is something seriously wrong with the application, then the solution is to fix the bug that causes something to go seriously wrong with the application. It is not to "switch it off and on again" in the hopes that the problem goes away. Apple have numerous quality guidelines, and an application that requires a restart button because of bugs is an application that will not be approved. – Jim Dec 12 '11 at 20:04
  • What bug? The app failed an integrity check that is not on the list of bugs. – hotpaw2 Dec 12 '11 at 20:06
  • *2.1: Apps that crash will be rejected. 2.2: Apps that exhibit bugs will be rejected.* – Jim Dec 12 '11 at 20:15
  • The app has never crashed or exhibited the problem being checked. – hotpaw2 Dec 12 '11 at 20:24
  • Apps that crash are often approved. I've downloaded several featured games and magazines from the App store that require restarts on older devices. – hotpaw2 Dec 12 '11 at 20:26
  • @hotpaw2: then why do you think you need to handle it? – Jim Dec 12 '11 at 20:30
  • There are plenty of applications that slip through the cracks when Apple tests them, that doesn't mean that it's okay to have a buggy application, it just means Apple's testing abilities are finite. – Jim Dec 12 '11 at 20:31
  • Good practice for functions and methods might be to check parameters, even if you've never seen bad ones, and/or fixed all the problems previously found. – hotpaw2 Dec 12 '11 at 20:35
  • These are called assertions, and they are typically disabled in production code. You're either looking for approval to be sloppy or you're over thinking this. Don't worry about handling bugs that a) don't exist and b) can't be recovered from even if they did. – Jim Dec 12 '11 at 20:40
  • The user may prefer the developer to worry, rather than continuing to (further) corrupt their data or purchase transaction, etc. – hotpaw2 Dec 12 '11 at 20:45
  • You are seeing problems where there are none. You admit yourself the app doesn't exhibit the problem you are checking for. You are more likely to introduce a bug by complicating your code unnecessarily. – Jim Dec 12 '11 at 20:51
  • Problems that have not yet exhibited themselves certainly do not need an existence proof in this industry. Trying to do error recovery from an unknown problem is likely to introduce far more bugs than simply exiting cleanly. – hotpaw2 Dec 12 '11 at 21:04
0

Why would you want to quit / crash your app programmatically? If you tell us more about what you are trying to do people could think of a work around

pmk
  • 1,897
  • 2
  • 21
  • 34
  • If an app's data in the course of running becomes disorganized, sometimes it makes more sense to just exit the app and start from scratch, because dis-entangling it would be more work intensive. –  Dec 12 '11 at 19:24
  • If you mean disorganised as in corrupt, then fix the bug that causes this. A bail out button is incredibly sloppy. If you mean disorganised as in the user has entered data that should be discarded, provide a button that clears the current data. – Jim Dec 12 '11 at 19:33
  • @Philipp : App self detects a serious top level bug of unknown character that was never found in test, QA or app review. – hotpaw2 Dec 12 '11 at 19:36
0

If you want your app to no longer be in the foreground, have it send a valid URL to Safari. If you don't want your app to be in the background when Safari comes to the foreground, set the UIApplicationExitsOnSuspend key in your app's plist. If "somehow" an app integrity check fails (bad checksum of receipt validation code, etc.), then maybe trash some memory pools and/or your own call stack and let the OS deal with it.

hotpaw2
  • 70,107
  • 14
  • 90
  • 153