iOS app shutdown


when i press the home button on an OS4 device, it quits my app. i see the destructors for my components being called. However, on an OS5 device, the app does not quit, instead it lurks in the background.

Question #1, is there an event to detect this?

Now, it seems the usual way to finish an app under OS5 is to hold the home button and press the little minus that appears over the apps that are revealed to be running in the background.

Question #2, is this the normal way people terminate apps under OS5?

It seems that terminating apps in this way really terminates them. ie they are killed outright. the destructors of components are not called.

Question #3, is there an event received shortly before this happens?

Based on these observations, i have discovered that it’s a bad move to do anything useful on shutdown, such as save unsaved data. instead it has to be saved as you go.

Can anybody enlighten me on this subject.

thanks for any help.

– hugh.


I don’t have answers to any of your questions. I remember being perplexed by this as well and switching to a scheme where I just saved application state in response to certain user actions.

On my iPad with iOS4 on it doesn’t quit the app either when you press the home key. What sort of device were you seeing this behavior on? Maybe, some apps are shutdown if the system is running low on resources?

If you do run across an event for this, please post a link to the documentation back to the thread. I looked through the iOS documentation myself sometime ago trying to track one down but came up empty handed.


i’m seeing the home button shut the app down most of the time on an old 3G os4 device. I say “most” of the time, because i’m convinced that sometimes it doesn’t, but instead allows it to run in the background. Although i can never catch it doing this in the debugger.

It’s possible that your resource theory is correct here and that iOS allows as many apps as possible until it needs to kill them. it would explain why i seeing approximately one most of the time on such an old device.

the same as you, what i do now is save everything the moment it changes. i was surprised to discover OS5 can just kill apps without proper shutdown - at least i think so. I don’t get any destructors called anyhow.

Another problem i’m having is that pressing the off button allows all background threads to continue. i need to get an event here to manually suspend them. For example, any background music continues to play on.

If i get any answers, i’ll post them.


I think you’re right in how iOS handles application lifetime these days. It is my understanding that an application has 4 states, active, inactive, background and terminated. The inactive state appears to be an intermediary between active and background. In real terms these relate to:

active: normal use, on the screen with interactivity
inactive: the sort of paused state you get when loading an app from the task bar
background: app sitting in the task bar
terminated: killed when removed from the task bar via the red minus

When a user closes an iOS app it goes into a background state although still resides in memory. If iOS runs out of memory it can forceibly kill your app. I think you get a callback before this happens.

The problem with JUCE is that it doesn’t currently pass all of these callbacks onto the JUCEApplication class. This is something I’m sure Jules will add with time (quicker if some help is provided).

The functionality is described in the following Apple documentation UIApplication with particular attention to UIApplicationState (do a search on the UIApplication page) and UIApplicationDelegate which deals with the callbacks. I think the cleanest approach would be to add some more virtual methods to JUCEApplication about these extra states, I’m sure Android has something similar and Lion too probably.

Shouldn’t be too much work to implement if you take a look in


aha! i’ve figured out you can opt out of this background running malarkey which might be useful for some app (eg mine).

if you add


to your plist, it will immediately terminate your app on the home key. In fact, you are delivered back into Juce at JUCEApplicationBase::appWillTerminateByForce

i’ve also discovered (when you dont opt out) there are notifications not currently picked up by Juce (as dave mentioned). I think there are delegates,


i might try hooking these, but for now, my app is fine to opt out!


i’ve discovered that even if you exit on suspend, you are still on the task bar. so, i think the task bar represents the application history as well as potentially background apps. for sure, my app is not running anymore when i can see it on the task bar and “minus” it.


That makes sense, it provides a consistent user experience. The user shouldn’t need to know whether the app has saved its state or not, just that when you press the icon that it will open again.

I often wondered about this before I looked at the APIs, why some apps need to load every time you open them from the task bar and some just ‘re-appear’ as they were. I guess the developers just didn’t implement the resume state stuff. It is a nice feature though.

Good to know about the plist option.


FWIW, it’s not at all hard to add going-to-the-back-ground, resuming to the JuceApplication methods. I posted a link to a simple implementation for both Android and iOS awhile back. I needed to do some network IO cleanup. The advantage to doing this over forcing a quit is that the user will generally come back to the state he/she left the app, as opposed to the same startup state each time.

On iOS, most apps don’t really keep running in the background unless you take special steps and note the need in the bundle .plist. So there is seldom a reason to force a quit double clicking and then holding home.