1

I am doing this in applicationWillTerminate but alert does not show up only the log will be printed.

- (void)applicationWillTerminate:(UIApplication *)application {
    NSLog(@"Went to Background");


    UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Error" message:@"app is terminated " delegate:self cancelButtonTitle:@"Ok" otherButtonTitles:nil, nil];
    [alert show];
}
Meet Doshi
  • 4,241
  • 10
  • 40
  • 81
Shilpa M
  • 151
  • 1
  • 1
  • 7
  • 1
    Once this method is called it is basically all over for your app. You can't display anything. You have a couple of seconds to clean up before your app is killed. – Paulw11 Jul 21 '16 at 12:04

3 Answers3

1

You cannot do this. It's how iOS apps are designed, you can't block the user from closing your app. From this answer:

The alert view is never shown because the 'show' method does not block, and therefore, the end of 'applicationWillTerminate' is reached immediately after you create the alert view and try to show it. I believe this is by design. You can't really begin asynchronous operations in 'applicationWillTerminate'.

Community
  • 1
  • 1
LS_
  • 6,763
  • 9
  • 52
  • 88
  • What happens if you stay in a loop and pump the run-loop? – Droppy Jul 21 '16 at 12:09
  • @Droppy the app will probably keep running the loop in background until it gets killed, but it won't show the alert anyways – LS_ Jul 21 '16 at 12:18
  • But that's not really what your answer says. You simply state that there are no blocking calls in that method and hence the method will terminate and so will the app. This says nothing about showing the alert sheet and I suspect that it is possible if you pump the correct events in the run-loop. Also why would the app go into the background if that method is not allowed to terminate? How long before iOS hard-kills the app? – Droppy Jul 21 '16 at 12:25
  • Once iOS determines that it will call `applicationWillTerminate`, it is effectively setting a timer whose event will kill the app. The timer has approximately a 5 second interval, but this is not documented and is subject to change. Meanwhile, `UIApplication` object will be notified of the impending death, and it will in turn call the delegate method, if implemented. The app has until that internal (to the OS) timer fires. After that, it's too late. – Avi Jul 21 '16 at 13:07
  • @Droppy it goes in background because there are no blocking calls, I've tried your example with the loop: the app calls it and the loop starts but the app will still get closed/enter background without showing the alert while the loop keeps running. It's how those methods works and it will go against apple guidelines to prevent the user to leave the app – LS_ Jul 21 '16 at 13:08
1

In short, unless you have UIApplicationExitsOnSuspend in your Info.plist set to YES, in iOS4 and above there is no guarantee that applicationWillTerminate: will ever get called.

As the documentation says:

For applications that support background execution, this method is generally not called when the user quits the application because the application simply moves to the background in that case. However, this method may be called in situations where the application is running in the background (not suspended) and the system needs to terminate it for some reason

(Emphasis mine.)

If you need to do something before the app exits you need to do it in applicationDidEnterBackground:. There is no way to catch SIGKILL.

Ahmed Abdallah
  • 2,338
  • 1
  • 19
  • 30
  • And of course, if the app is in the background, it can't show an alert, whether it's about to be killed or not. – Avi Jul 21 '16 at 13:03
-1

You can schedule a local notification some seconds later. This will be shown to the user.

manta
  • 369
  • 1
  • 9