I am programming an iPhone app, and I need to force it to exit due to certain user actions. After cleaning up memory the app allocated, what's the appropriate method to call to terminate the application?
-
35There is only one proper way - Home button.. – beryllium Feb 21 '12 at 10:07
-
5The only situation I can imagine anyone considering to quit programmatically is the following scenario: App starts, displays terms of use, refusing to accept then quits the app. This is something brands sometimes pressure the developer to do. But it is wrong. – Daniel Aug 27 '12 at 15:03
-
6@Daniel Normally you put your disclaimer/terms of use (EULA) on itunes connect when you upload the app. If the user downloads your app it means they have accepted your EULA – Paul de Lange Dec 17 '12 at 09:51
-
even hitting the home button doesnt quit the app technically, the app only goes in the background.. right?? – Firdous Dec 23 '12 at 18:04
-
If someone is searching for this, and **can** use Private APIs, [see this answer](http://stackoverflow.com/a/15997772/119114). – Nate Apr 14 '13 at 10:14
-
1I don't understand why you would even need to quit the app. Even for something like the EULA within the app, just don't go to next page of the app until user taps the "accept Terms & Conditions" button, so they keep staring at the same page until they accept. Or do you want the comic answer ? Hasta la vista, baby! – Zhang May 23 '13 at 13:17
-
@Daniel it's not only wrong, if the user can't use your app in any way if you don't agree to their EULA or fail any other conditions, Apple will simply not approve such an app. This happened to an app that required an active Internet connection to launch/use. – CodeSmile Jul 24 '13 at 11:22
-
9There are completely valid reasons for needing to force quit an ios app. My case is that I'm distributing pre-launch beta versions of my app. The beta versions open up all the IAP's for free. These have a time limit and need to expire after a few weeks. So I'm using the answer below to kill the app after the beta period is over. I'll remove this in the LIVE version. But still the answer helped me and is correct! – badweasel Oct 09 '13 at 11:40
-
6One valid reason to quit an app is if it is a long-lived background executing app, and the app enters a state where it no longer needs to run in the background. For example, the user logs out. In this case it would make sense to exit so that when the app next starts it starts clean. This would act as a safety net against memory leaks, among other reasons. Note, in this case the app would be exiting *out of the background*, so the user would not notice anything wrong. – frankodwyer Oct 12 '15 at 16:19
24 Answers
On the iPhone there is no concept of quitting an app. The only action that should cause an app to quit is touching the Home button on the phone, and that's not something developers have access to.
According to Apple, your app should not terminate on its own. Since the user did not hit the Home button, any return to the Home screen gives the user the impression that your app crashed. This is confusing, non-standard behavior and should be avoided.

- 12,139
- 3
- 29
- 30
-
Even if the user has pushed an exit button in the app and confirmed their selection? – user21293 Dec 10 '08 at 15:56
-
13As I said, it's non-standard behavior and should be avoided. iPhone apps are not desktop apps. Don't treat them as such. – August Dec 10 '08 at 17:13
-
1If you plan to submit your app to the AppStore, you may get a note from ITC saying that an "exit button" is non-standard interface. That's what the big button below the screen is for :) – Olie Dec 18 '08 at 20:58
-
8I can understand Apples opinion but I have a similar situation, my application requires internet access, if it isn't available they should be able to leave the app instead of just having an error message – Anthony Main Jan 26 '09 at 15:10
-
No, not really. Think of the iTunes app. If it doesn't find a connection it tells you. You then navigate away from the app to close it. – August Feb 01 '09 at 22:32
-
25We have apps that helps people sleep. They want the app to terminate after a set period to reduce battery drain. I think this case is acceptable - as the user is hopefully asleep and can't exit the app manually. – JamesSugrue May 09 '09 at 22:47
-
39I'd still disagree. When they wake up, the app is "gone" leaving the user to wonder what happened. Instead, set a timer in your app, then when the time is up, idle the app -- no activity. An app doing absolutely nothing won't drain the battery.The Springboard is an app, too -- it doesn't shut down just to save energy. Instead, it simply waits for user input. – August May 10 '09 at 13:53
-
3I'm making an exit button to deal with the case when we are unable to initialize the phone on first launch. If there is insufficient free space, I can't build the database I need and the user can't use the app. I can't call applicationWillTerminate because that does lots of work for normal shutdowns and I think it's an ugly hack to instruct the user to push the home button. – Carl Coryell-Martin Aug 18 '09 at 07:37
-
2My client wants to show a minimal EULA in a UIAlertView upon first launch (with Decline / Accept options). If they decline, the app is to shut down immediately. Otherwise, it proceeds. They only see this once, after installation. What about then? Is it still non-standard? – Joe D'Andrea Sep 22 '09 at 20:28
-
2@KiwiBastard: The proper way to handle this situation is to turn off the idle timer so that the device doesn't turn itself off and your app continues to run. When your app's internal timer expires, re-enable the idle timer and let the device turn itself off. – Steve Madsen Nov 05 '09 at 15:06
-
6@jdandrea: Customers have already implicitly accepted Apple's standard EULA or your clients' substitute EULA. I'd expect a rejection from Apple with a EULA dialog at app start-up. – Steve Madsen Nov 05 '09 at 15:09
-
3@jdandrea Is this app a free app? If not, how do you return the money to those users who reject the "minimal EULA"? – Andrew J. Brehm Aug 12 '10 at 10:46
-
9This doesn't really answer the question. It's 100% accurate, but I think ideally would have been a comment either on the OP's question or on the accepted answer. – Ben Zotto Sep 20 '10 at 00:51
-
1@quixoto It does answer the question. The answer to this question is "there isn't one". – ceejayoz Dec 08 '10 at 03:32
-
1I know Apple doesn't want you to quit your app, but since iOS4 "multi taksing" it can be annoying to leave apps running. So what if I make a setting that lets users choose if the app should quit or not (it's a game, and nothing is lost when its quit) and let it default to off (not quitting)? BTW, the different answers suggesting that exit(0); should work: the app does quit, but its icon stays in the application tray. Not good! – zmippie Feb 14 '11 at 11:01
-
1@zmippie - Late answer, but leaving the icon in the application tray is expected behavior from an iOS app. Even if it reinitializes when switching back to it (which I find highly annoying), the tray should contain *everything* I've used lately. – Bobson Aug 19 '12 at 18:52
-
5The aim of any app developer should be to have an app that is user friendly, not user hostile. One of the key rules of that is to fit in with their expectations. That's why platforms have UI standards, official or de-facto. The iOS standard is that apps don't ever quit when they are in the foreground. No ifs, no buts, no special cases. Your app consumes too much power when it's running? Fix it. You need an EULA? No you don't. You don't have enough memory to run? Display an error, with a try-again button, so the user can switch apps or use iTunes to fix the problem, then come back. etc. – Steve Waddicor May 23 '13 at 12:19
-
4I have an app that gets pushed to users' iPads from a government client. Since users don't download this app from the Apple app store, there is no chance for them to read the EULA before opening the app itself, and we have to show them the EULA immediately on the first time they open the app. Most of our users are not particularly tech-savvy, and if the app doesn't close when they click "Decline", they get confused. – Brian Feb 04 '14 at 16:02
-
1Old question, I know, but for clarity: "I'd expect a rejection from Apple with a EULA dialog at app start-up" <- Not true. We present a EULA agreement VC on app start-up and have been through at least 15 reviews (updates) without a rejection. We do NOT however exit() on disagree. If the user doesn't agree to the EULA that's all they can see from the app until they agree. – braden Feb 18 '15 at 01:26
-
1The question does not ask for advice on best practises, but for a technical answer. Perhaps the OP has a very good reason to want to do this, which you simply do not know. – Stephan Bijzitter Mar 06 '17 at 18:31
-
I have an app which only purpose is to open a website then it should close. I need to solve it that way, because the webview is bugged and you cannot download pdf for example – Black Nov 27 '19 at 11:56
Have you tried exit(0)
?
Alternatively, [[NSThread mainThread] exit]
, although I have not tried that it seems like the more appropriate solution.

- 139,698
- 36
- 220
- 238

- 2,779
- 1
- 16
- 3
-
85As doing this is an Apple no-no (may cause your app to be refused in the app-store for non-standard interface), consider August's answer as "the right one." FYI, this answer (Brett's) is correct for ALL C programs, and NSThread for all Cocoa programs. – Olie Dec 18 '08 at 20:57
-
22In Tech Q&A QA1561, Apple strongly discourages use of exit as it makes the app appear to have crashed. http://developer.apple.com/iphone/library/qa/qa2008/qa1561.html – progrmr May 06 '10 at 12:47
-
8[[NSThread mainThread] exit] causes your application to crash, because exit is not an instance method. exit(0) will send the app to the background in iOS 4. Calling exit(0) again will crash it. At least in the simulator. – user123444555621 Jul 06 '10 at 14:22
-
I have an app which should only be run continuously in the background (closely monitoring location) under certain circumstances, and it will drain the battery very fast otherwise. Turning off the GPS and all client-server communications don't seem to improve battery life when the app is in the background, so it seems like in my case exit(0); is the only option. In fact, under iOS4 the behavior will look identical to the user - app still goes to quick-launch area. – Eric Jul 12 '10 at 17:14
-
Also, I've seen apps on the App Store that already do this. So, you could probably get past the reviewers. But, it's still a risk. – Plumenator Nov 22 '10 at 06:58
-
-1 Not sure why this answer is voted up so much; exit(0) is very much against Apple's advice. See http://developer.apple.com/library/ios/#DOCUMENTATION/UserExperience/Conceptual/MobileHIG/UEBestPractices/UEBestPractices.html – occulus Mar 11 '11 at 16:21
-
I use this for development only, but exit(0) keeps the icon in the application tray (iOS4+), eventhough the app is not running anymore. – zmippie Jun 11 '11 at 07:17
-
Zynga's Words With Friends does this, and it's really awful. I've complained to the developers but they don't listen. Can I report them to Apple? I know it sounds nasty to do so, but they need to be made aware that this is wrong! – jowie May 02 '12 at 16:32
-
2more understandable is to use it like this: `exit(EXIT_SUCCESS);` – NeverHopeless Nov 28 '12 at 09:07
-
14I understand why so many people are advising against this, but how about giving us developers some credit? We're all adults here, and we want to know about this feature. I find it very useful for internal QA builds and, when I first searched for it, was glad to see this "incorrect" answer. – evanflash May 20 '13 at 21:00
-
I know this is old but I can't believe this has been accepted as the correct answer. This is so wrong. -1 – Popeye May 23 '13 at 12:28
-
There are cases where you would want to do this - for example if an evil developer copies your bundle and reskins your app and submits to the store you could check for a list of allowed bundle id's and exit the application if the bundle id is not valid. – jjxtra Jan 16 '14 at 15:48
-
PsychoDad: I'd suggest making your apps cooler instead of worrying about pirates and copycats. They'll find ways to break your systems anyway. And the measures that you suggest might backfire and when that happens you are history. – Jonny Jan 30 '14 at 02:19
-
@GlennMaynard How is it correct though? The Op asked for a "proper way" to exit an iOS application, since there is no proper way (Apple doesn't want you to kill your app), the only correct answer is "don't do that". – Kevin May 24 '16 at 07:50
-
12@Kevin "Don't do that" is never the correct answer. Give warnings and disclaimers if you like, but the only correct answer to "how do I do this" is "here's how to do it". If I'm searching for how to do something (maybe I want to force it to exit while debugging), people righteously declaring "you don't!" and trying to bury the answer I need is a waste of my time. However many people might have bad reasons to do something, the correct StackOverflow answer is the one that answers the question, because people with good reasons will search their way to it as well. – Glenn Maynard May 25 '16 at 01:56
-
@GlennMaynard That may be, but the voting system exists to filter out stupid shit and bad practises from quality content that future SO users can use as well, not to find you an answer to your edge-case that is never going to be used be someone else. Hence the "too localised" flag on questions. – Kevin May 25 '16 at 07:19
-
3@Kevin No, votes on answers aren't a way to say you don't like the question. The voting system doesn't exist to filter out correct answers, regardless of whether the question is often a bad idea or not. People downvoting answers because they actually answer the question is just silly, and something isn't an "edge case" or "too localized" just because you didn't think of it. At least in this case, averages won out. – Glenn Maynard May 27 '16 at 00:14
-
@GlennMaynard I believe if the question is "how to do x properly" and "x" is not something you should do, then it's a bad question and it has no correct answer. You can't do something properly that you shouldn't do at all, answers that still try to answer it are clutter and they encourage people to do things they shouldn't do. You might use the answer responsibly because you are aware it shouldn't be used in production, but future readers might not. I think ensuring quality for both the OP and future readers is more important than solving a single user's problem, that is likely an edge-case. – Kevin May 27 '16 at 09:55
-
-
@Kevin No, it's irrelevant. (No question is asking "what's the wrong way to do this".) – Glenn Maynard May 27 '16 at 21:16
-
Core data is leaking memory big time, so in my case I have to do the initial import (24 tables, 50 MB json in total) in phases and exit in between each step. (is an enterprise app so app store review is not a concern) – JKvr Feb 27 '17 at 10:29
-
1In addition to @progrmr comment. The working link: https://developer.apple.com/library/archive/qa/qa1561/_index.html – MintSet Mar 05 '19 at 07:17
exit(0)
appears to a user as crashes, so show a confirmation message to user. After confirmation suspend (home button press programmatically) and wait 2 seconds while app is going background with animation then exit behind user's view
-(IBAction)doExit
{
//show confirmation message to user
UIAlertView* alert = [[UIAlertView alloc] initWithTitle:@"Confirmation"
message:@"Do you want to exit?"
delegate:self
cancelButtonTitle:@"Cancel"
otherButtonTitles:@"OK", nil];
[alert show];
}
-(void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex
{
if (buttonIndex != 0) // 0 == the cancel button
{
//home button press programmatically
UIApplication *app = [UIApplication sharedApplication];
[app performSelector:@selector(suspend)];
//wait 2 seconds while app is going background
[NSThread sleepForTimeInterval:2.0];
//exit app when app is in background
exit(0);
}
}

- 22,897
- 2
- 80
- 94

- 14,325
- 6
- 82
- 89
-
1Will apple approve this "exit(0)" ? Because some people says apple will reject your app when you use exit 0. – Gajendra K Chauhan Jan 24 '14 at 09:27
-
2@GajendraKChauhan `exit(0)` doesn't matter. Point is your app has "quitting behaviour". Quitting behaviour itself is prohibited in AppStore except a few apps that are made by very important 3rd-parties. Also, imitating home button behaviour is also subject to be rejected. – eonil Feb 03 '16 at 03:09
Check the Q&A here: https://developer.apple.com/library/content/qa/qa1561/_index.html
Q: How do I programmatically quit my iOS application?
There is no API provided for gracefully terminating an iOS application.
In iOS, the user presses the Home button to close applications. Should your application have conditions in which it cannot provide its intended function, the recommended approach is to display an alert for the user that indicates the nature of the problem and possible actions the user could take — turning on WiFi, enabling Location Services, etc. Allow the user to terminate the application at their own discretion.
WARNING: Do not call the
exit
function. Applications callingexit
will appear to the user to have crashed, rather than performing a graceful termination and animating back to the Home screen.Additionally, data may not be saved, because
-applicationWillTerminate:
and similarUIApplicationDelegate
methods will not be invoked if you call exit.If during development or testing it is necessary to terminate your application, the
abort
function, orassert
macro is recommended
-
2Just added an AlertView without buttons to comply with this. Easy. – Schultz9999 Sep 08 '13 at 21:11
-
Great answer, just worked with exit(0) and didn't know it belongs to the private api – Alex Cio May 10 '17 at 22:27
Its not really a way to quit the program, but a way to force people to quit.
UIAlertView *anAlert = [[UIAlertView alloc] initWithTitle:@"Hit Home Button to Exit" message:@"Tell em why they're quiting" delegate:self cancelButtonTitle:nil otherButtonTitles:nil];
[anAlert show];
-
2At least on the simulator, if you do this, the alert will still be there when the user re-opens the app. Thus, I suggest giving them at least one button. – cheshirekow Aug 31 '12 at 15:16
-
Use Kalyan's answer so that app quits when home button is pressed. – Timur Kuchkarov Feb 18 '13 at 16:27
-
The problem with this is that it doesn't actually exit the app, so anything the developer might want to accomplish by exiting (throwing out invalid/old UI, clearing constants, etc.) won't be performed unless the user swipes the application closed. – Ky - Jun 23 '15 at 16:04
-
Go to your info.plist and check the key "Application does not run in background". This time when the user clicks the home button, the application exits completely.

- 371
- 3
- 2
Add UIApplicationExitsOnSuspend
property on application-info.plist
to true
.

- 13,264
- 3
- 57
- 82

- 727
- 6
- 15
-
Can this setting be changed in run-time? I mean, I want to live in the background, except when my app CHOOSES to quit on the next suspend - in which time I'll want to introduce the UIApplicationExitsOnSuspend. Is this possible? – Motti Shneor Mar 13 '19 at 14:16
After some tests, I can say the following:
- using the private interface :
[UIApplication sharedApplication]
will cause the app looking like it crashed, BUT it will call- (void)applicationWillTerminate:(UIApplication *)application
before doing so; - using
exit(0);
will also terminate the application, but it will look "normal" (the springboard's icons appears like expected, with the zoom out effect), BUT it won't call the- (void)applicationWillTerminate:(UIApplication *)application
delegate method.
My advice:
- Manually call the
- (void)applicationWillTerminate:(UIApplication *)application
on the delegate. - Call
exit(0);
.

- 2,360
- 24
- 29
-
Apple says not to use exit due to "Applications calling exit will appear to the user to have crashed, rather than performing a graceful termination and animating back to the Home screen" https://developer.apple.com/library/ios/#qa/qa2008/qa1561.html – Sep 05 '12 at 22:20
Your ApplicationDelegate gets notified of intentional quitting by the user:
- (void)applicationWillResignActive:(UIApplication *)application {
When I get this notification I just call
exit(0);
Which does all the work. And the best thing is, it is the useres intent to quit, which is why this should not be a problem calling it there.
On my Audio-App it was necessary to quit the app after people were syncing their device while the music was still playing. As soon as the syncing is complete I get a notification. But quitting the app right after that would actually look like a crash.
So instead I set a flag to REALLY quit the app on the next backgrounding action. Which is okay for refreshing the app after a sync.

- 117
- 1
- 1
-
1This is not a good solution as the application will resign active for other reasons, such as incoming phone call. – frankodwyer Oct 12 '15 at 16:17
-
The solution is to add a check that exits only if it is useful to do so. For example if the user is on the start screen. Then it is ok even if a phonecall is coming in. Apple has not rejected this since iOS 2 in my apps. https://stackoverflow.com/a/43906936/712124 – cat Aug 31 '18 at 10:56
Apple say:
"Warning: Do not call the exit function. Applications calling exit will appear to the user to have crashed, rather than performing a graceful termination and animating back to the Home screen."
I think that this is a bad assumption. If the user tap a quit button and a message appears that say something like: "The application will now quit.", it doesn't appear to be crashed. Apple should provide a valid way to quit an application (not exit(0)).

- 364
- 3
- 10
-
3They do it's call the Home button it can be located at the bottom of any iDevice. So because of this there is never any need to build your own quit button in. – Popeye May 23 '13 at 15:15
My App has been rejected recently bc I've used an undocumented method. Literally:
"Unfortunately it cannot be added to the App Store because it is using a private API. Use of non-public APIs, which as outlined in the iPhone Developer Program License Agreement section 3.3.1 is prohibited:
"3.3.1 Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs."
The non-public API that is included in your application is terminateWithSuccess"
You should not directly call the function exit(0)
as it will quit the application immediately and will look like your app is crashed. So better to show users a confirmation alert and let them do this themselves.
Swift 4.2
func askForQuit(_ completion:@escaping (_ canQuit: Bool) -> Void) {
let alert = UIAlertController(title: "Confirmation!", message: "Do you want to quit the application", preferredStyle: .alert)
alert.addAction(UIAlertAction(title: "Yes", style: UIAlertAction.Style.default, handler: { (action) in
alert.dismiss(animated: true, completion: nil)
completion(true)
}))
alert.addAction(UIAlertAction(title: "No", style: UIAlertAction.Style.cancel, handler: { (action) in
alert.dismiss(animated: true, completion: nil)
completion(false)
}))
self.present(alert, animated: true, completion: nil)
}
/// Will quit the application with animation
func quit() {
UIApplication.shared.perform(#selector(NSXPCConnection.suspend))
/// Sleep for a while to let the app goes in background
sleep(2)
exit(0)
}
Usage:
self.askForQuit { (canQuit) in
if canQuit {
self.quit()
}
}

- 13,264
- 3
- 57
- 82
This has gotten a good answer but decided to expand a bit:
You can't get your application accepted to AppStore without reading Apple's iOS Human Interface Guidelines well. (they retain the right to reject you for doing anything against them) The section "Don't Quit Programmatically" http://developer.apple.com/library/ios/#DOCUMENTATION/UserExperience/Conceptual/MobileHIG/UEBestPractices/UEBestPractices.html is an exact guideline in how you should treat in this case.
If you ever have a problem with Apple platform you can't easily find a solution for, consult HIG. It's possible Apple simply doesn't want you to do it and they usually (I'm not Apple so I can't guarantee always) do say so in their documentation.

- 111
- 3
Hm, you may 'have to' quit the application if, say, your application requires an internet connection. You could display an alert and then do something like this:
if ([[UIApplication sharedApplication] respondsToSelector:@selector(terminate)]) {
[[UIApplication sharedApplication] performSelector:@selector(terminate)];
} else {
kill(getpid(), SIGINT);
}

- 4,093
- 5
- 44
- 54
-
9No, you don't have to terminate it. The iTunes app, for example, when it can't detect a proper connection simply puts up a screen that says they're not connected. It doesn't quit, it simply informs the user of what's going on. The user then quits by tapping the home button. – August Dec 11 '08 at 14:52
-
1
We can not quit app using exit(0)
, abort()
functions, as Apple strongly discourage the use of these functions. Though you can use this functions for development or testing purpose.
If during development or testing it is necessary to terminate your application, the abort function, or assert macro is recommended
Please find this Apple Q&A thread to get more information.
As use of this function create impression like application is crashing. So i got some suggestion like we can display Alert with termination message to aware user about closing the app, due to unavailability of certain functionality.
But iOS Human Interface Guideline for Starting And Stopping App, suggesting that Never use Quit or Close button to terminate Application. Rather then that they are suggesting to display proper message to explain situation.
An iOS app never displays a Close or Quit option. People stop using an app when they switch to another app, return to the Home screen, or put their devices in sleep mode.
Never quit an iOS app programmatically. People tend to interpret this as a crash. If something prevents your app from functioning as intended, you need to tell users about the situation and explain what they can do about it.

- 14,144
- 10
- 61
- 92
- (IBAction)logOutButton:(id)sender
{
//show confirmation message to user
CustomAlert* alert = [[CustomAlert alloc] initWithTitle:@"Confirmation" message:@"Do you want to exit?" delegate:self cancelButtonTitle:@"Cancel" otherButtonTitles:@"OK", nil];
alert.style = AlertStyleWhite;
[alert setFontName:@"Helvetica" fontColor:[UIColor blackColor] fontShadowColor:[UIColor clearColor]];
[alert show];
}
- (void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex
{
if (buttonIndex != 0) // 0 == the cancel button
{
//home button press programmatically
UIApplication *app = [UIApplication sharedApplication];
[app performSelector:@selector(suspend)];
//wait 2 seconds while app is going background
[NSThread sleepForTimeInterval:2.0];
//exit app when app is in background
NSLog(@"exit(0)");
exit(0);
}
}

- 731
- 5
- 19

- 869
- 1
- 9
- 13
In addition to the above, good, answer I just wanted to add, think about cleaning up your memory.
After your application exits, the iPhone OS will automatically clean up anything your application left behind, so freeing all memory manually can just increase the amount of time it takes your application to exit.

- 7,225
- 11
- 43
- 66
[[UIApplication sharedApplication] terminateWithSuccess];
It worked fine and automatically calls
- (void)applicationWillTerminateUIApplication *)application delegate.
to remove compile time warning add this code
@interface UIApplication(MyExtras)
- (void)terminateWithSuccess;
@end

- 22,224
- 10
- 78
- 108

- 143
- 1
-
5This is a private method, Diego Mercado has explained above that his app got rejected, then why take such a risk. – RVN Oct 15 '10 at 09:02
-
-
2
-
- (IBAction)exitApp:(id)sender { SEL selector = NSSelectorFromString(@"terminateWithSuccess"); [self performSelector:selector withObject:[UIApplication sharedApplication]]; } – unom Oct 01 '14 at 05:48
-
I used the [[NSMutableArray new] addObject:nil] approach mentioned above to force-quit (crash) the app without making a tell-tale exit(0) function call.
Why? Because my app uses certificate pinning on all network API calls to prevent man-in-the-middle attacks. These include the initialization calls my financial app makes on startup.
If certificate authentication fails, all of my initialization calls error out and leave my app in an indeterminate state. Letting the user go home and then back into the app doesn't help, as unless the app has been purged by the OS it's still uninitialized and untrustworthy.
So, in this one case, we deemed it best to pop an alert informing the user that the app is operating in an insecure environment and then, when they hit "Close", force quit the app using the aforementioned method.

- 1,046
- 8
- 15
-
I can't see what holds you from displaying a single full-screen mundane alert, telling the user that the app isn't usable for those "certificate pinning" reasons, and that's it. User will eventually close the app. You may not know, but iOS reserves the right to kill your process (maintaining its state) and restoring it later, and the "life-cycle" of iOS application isn't really in your hands. Your crash - is simply a crash, and the OS may choose to revive the app anyway. – Motti Shneor Mar 13 '19 at 14:12
-
Wow, three year old post. Anyway, the new app architecture pretty much does that, with a retry button that retries the API and either drops the block screen, or returns them to the block screen with a new error. – Michael Long Mar 14 '19 at 20:08
-
The old app structure pretty much didn't allow any good way to retry the startup API calls and the app was in an inconsistent state without them. We could have used a permanent block screen, but that required the user to force-quit the app himself and it was decided that not every user knew HOW to double-click and force quit apps. Easier today, but quite hidden three years ago. – Michael Long Mar 14 '19 at 20:10
The user should decide when an app exits. I don't think it is a good user interaction when an app quits. Therefore there is no nice API for it, only the home button has one.
If there is an error: Implement it better or Notify the user. If there have to be a restart: Implement it better of Notify the user.
It sounds dumb, but it's bad practice to exit the app without letting the user decide and not notifying him. And since there is a home button for the user interaction, Apple states, there should not be 2 things for the same function (exiting an app).

- 12,296
- 8
- 53
- 84
Exit an app other way than the home button is really non-iOS-esque approach.
I did this helper, though, that use no private stuff:
void crash()
{ [[NSMutableArray new] addObject:NSStringFromClass(nil)]; }
But still not meant for production in my case. It is for testing crash reportings, or to fast restart after a Core Data reset. Just made it safe not to be rejected if function left in the production code.

- 15,810
- 18
- 109
- 172
It may be appropriate to exit an app if it is a long lived app that also executes in the background, for example to get location updates (using the location updates background capability for that).
For example, let's say the user logs out of your location based app, and pushes the app to the background using the home button. In this case your app may keep running, but it could make sense to completely exit it. It would be good for the user (releases memory and other resources that don't need to be used), and good for app stability (i.e. making sure the app is periodically restarted when possible is a safety net against memory leaks and other low memory issues).
This could (though probably shouldn't, see below :-) be achieved with something like:
- (void)applicationDidEnterBackground:(UIApplication *)application
{
if (/* logged out */) {
exit(0);
} else {
// normal handling.
}
}
Since the app would then exit out of the background it will not look wrong to the user, and will not resemble a crash, providing the user interface is restored the next time they run the app. In other words, to the user it would not look any different to a system initiated termination of the app when the app is in the background.
Still, it would be preferable to use a more standard approach to let the system know that the app can be terminated. For example in this case, by making sure the GPS is not in use by stopping requesting location updates, including turning off show current location on a map view if present. That way the system will take care of terminating the app a few minutes (i.e. [[UIApplication sharedApplication] backgroundTimeRemaining]
) after the app enters the background. This would get all the same benefits without having to use code to terminate the app.
- (void)applicationDidEnterBackground:(UIApplication *)application
{
if (/* logged out */) {
// stop requesting location updates if not already done so
// tidy up as app will soon be terminated (run a background task using beginBackgroundTaskWithExpirationHandler if needed).
} else {
// normal handling.
}
}
And of course, using exit(0)
would never be appropriate for the average production app that runs in the foreground, as per other answers that reference http://developer.apple.com/iphone/library/qa/qa2008/qa1561.html

- 13,948
- 9
- 50
- 70
Swift 4.2 (or older)
Library called Darvin
can be used.
import Darwin
exit(0) // Here you go
NB: This is not recomanded in iOS applications.
Doing this will get you crash log.

- 11,242
- 5
- 69
- 122
In iPadOS 13 you can now close all scene sessions like this:
for session in UIApplication.shared.openSessions {
UIApplication.shared.requestSceneSessionDestruction(session, options: nil, errorHandler: nil)
}
This will call applicationWillTerminate(_ application: UIApplication)
on your app delegate and terminate the app in the end.
But beware of two things:
This is certainly not meant to be used for closing all scenes. (see https://developer.apple.com/design/human-interface-guidelines/ios/system-capabilities/multiple-windows/)
It compiles and runs fine on iOS 13 on an iPhone, but seems to do nothing.
More info about scenes in iOS/iPadOS 13: https://developer.apple.com/documentation/uikit/app_and_environment/scenes

- 22,394
- 11
- 96
- 107