Which background apps restart when you reboot iPhone? [duplicate]

I’ve noticed that the app switcher doesn’t show screens for the apps but they are shown there (typically with just a blank screen or a solid color screen with the app name/logo). And it seems sometimes iOS just decides to quit apps because for example you re-open the app and they say conversation or article you were looking at is gone, although it hasn’t been deleted (it can be found again.)

I guess it’s impossible to answer this question without a jailbroken phone? And The answer is not a simple yes or no even for a given app?

I can’t find a definitive answer. (Well, except I asked on discussions.apple.com and the answer from Lawrence Finch User level: Level 10 (141,619 points) is clearly definitively ... wrong and I can't comment on it; it's locked. )

I know SOME background apps do restart and some do run in the background!

1. My phone responds when I use a Tile, for example.

2. Apps that have alarms do sometimes go off. (Frustration over this is what motivated the question.)

3. Mail gets checked (sometimes push, sometimes on a schedule).

4. Navigation apps provide alerts even when not in the foreground...

So in some sense they are running in the background.

I doubt anyone without a jailbroken phone or developer tools could answer this question based on experience.

[Edit: I found these settings exist in Xcode, which is mildly informative. ]

Solution 1:

I think the reason you're having a hard time finding a definitive answer is that the concept of a "running" app is different here than many expect. A non-technical user might have one idea of what "running" means, an "old-school" PC programmer might have a different idea - and then there's what actually happens on iOS, which probably only Apple and app developers really have to deal with.

On a traditional PC you'll find that you have a program executable on disk that you start - and now the program is "running". Here "running" means that the program will expect to have its main thread of execution be periodically scheduled to run on the CPU - meaning that its own program code will run on the actual CPU and it will have some power over what actually happens.

On a traditional PC you could have such a running application with a graphical user interface in a window. Whether that window is in the foreground, in the background, or even minimised (i.e. not visible at all) - you still have the programming code being periodically scheduled¹ to run on the CPU. The application is so to speak free to do whatever it wants. The application might have a lower priority in the background, and it might not be scheduled as frequently or for as long as when in the foreground, but it is still basically the same thing.

Still on a traditional PC, you could set the whole PC in sleep mode. There's many different types of sleeping states with different impacts on the system:

For the S1, S2 and S3 sleep states, the application still has its state in RAM, but will not have its program code periodically scheduled to run on the CPU while in sleep. This is basically all what really happens from the context of the application² although from the context of the operating system lots of things need to take place on wake (i.e. drivers need to reinitialise peripherals etc).

For the S4 sleep state, the application's state is saved to disk - although this happens transparently to the application. It is no longer scheduled to run on the CPU (obviously). When the PC is waken up, the state is restored to memory and the application can run again by scheduling its program code to run on the CPU again.

For the S5 power state, the system is basically shut down and powered off. In this case, no application state is saved to disk automatically by the operating system. The application must by itself have stored state in order to resume where you left off when the system is powered on again. On many operating systems, you'll find that it is common that applications do not do this - or at least do not do this in a transparent fashion. I.e. if you power off your system with your favorite game running, you cannot expect that the game will be running and in the same place when you power the system on again.

Now I'll turn to the apps on iOS. Similar to the Sx power states that we talked about before (that are system wide), an app on iOS will also go through various states during its life. Specifically apps are actually made up of scenes² that can be in one of the following states:

• Unattached
• Foreground and inactive
• Foreground and active
• Background
• Suspended

Whether your consider the app to be "running" in either of these states really depends on your point of view. I.e. a non-technical user might think of this differently than an app developer.

If we look at an example of you starting an app for the first time, this is what happens:

When you tap an icon on the home screen to "run" your app, a specific scene in the app will first go into the "unattached" state. This means that parts of the executable code for the application is loaded into RAM, an event loop is setup and a specific, limited functionality in the program code is triggered. This particular code will on the first run typically do next to nothing itself (i.e. it will trigger some UIKit code in system frameworks for example, but not much application specific code). Nothing is visible on the display for the user.

Shortly thereafter the scene will transition into the "Foreground and inactive" state. Here the app will run its own code to setup user interface elements, start timers, acquire shared resources, etc. - but nothing is yet displayed on screen and no user input is given to the program.

Shortly thereafter the scene will transition into the "Foreground and active" state. Now its user interface elements will be visible on the display and user input (such as touches) are sent to the apps' event loop. The app's code is periodically scheduled for execution.

Some time later, iOS can transition scene back into the "Foreground and inactive" state. For example if the user decides to switch to a different app. Again user input events are not sent to the app, but the app's own code is periodically scheduled in order to pause work operations - such as for example saving user data to permanent storage, stop timers, pause threads that empty queues of tasks, stop updating animations, etc.

If the scene was made "Foreground and inactive" only temporarily due to for example a system modal popup (such as for example a 10% battery left message), the scene can soon be transition back into "Foreground and active" again. However, if it was due to the user switching to a different app, the scene will be transitioned into the "Background" state.

When transitioned to the "Background" state, the app's own code will be scheduled for execution only for a very limited amount of time (typically 5 seconds, but an app can request an extension). Here the app is supposed to free up any large data objects in memory (such as for example images and audio files loaded from storage earlier), release any shared resources held (such as for example the camera, the address book or many other different types of shared resources). It is also supposed to clean up its user interface to "declutter" it and remove any sensitive information³. After a short while, iOS will stop scheduling the app's code for execution, and it will take a "screenshot" (remember that the user interface is not displayed on screen, so it is taking a bitmap copy of what would have been displayed on screen, if it had been on screen). This screenshot is now what will be presented to user as the "running app" in the app switcher for example. The actual user interface elements could have been purged from memory, but the screenshot will still look the same.

One important thing to notice is that apps can tell iOS that they support specific use cases that will earn them the benefit of their code being scheduled for execution even when in the "Background" state. The app does not itself decide when its code is run - that is decided by iOS depending on which use cases the app has registered for. For example it might be that the app is an email app that has requested that it be allowed to check for new mail using a timer approach. It might be an application that has requested some execution time when the user's geographical location changes a certain amount. There's several other use cases, such as for example a recipient of push notifications, apps that play audio that the user wants to keep playing when the app is backgrounded, etc.

In the "Background" state, some of the programs code is usually still in RAM, but most of its larger resources are not. The app can perform some limited functionality, but controlled by iOS - not itself. The user interface is basically a screenshot.

Later the scene can be suspended at the discretion of iOS. This means that the app is given time to execute code that will allow its state to be preserved in permanent storage in order to be able to restore the app to the same state later. This is done to give the illusion that the app is always running. For apps using Apple's tools, this can be done more or less automatically by the system without the developer of app having to implement much. For some apps however, the developer has to do lots of work to be able to correctly persist its state.

Now when the app is "Suspended", iOS is free to remove it completely from RAM. Although to the user, very little if anything at all visibly happens when the app is suspended. Most importantly iOS hangs on to the saved state - it is preserved also across reboots of the phone. It is discarded when the user uses the app switcher to force quit the app, and if the app crashes at launch (indicating a bug in the app - this is done to prevent the app from hanging on every launch).

When the user switches back to an app in the "Suspended" state, the scene again enters the unattached state. The difference from the "fresh start" is that this time, the app is also given its preserved state. The app can now use this data to setup user interface elements, internal state, etc. so that the app looks to the user exactly as it did before it was suspended.

Some developers use only Apple's own tools in a matter where this happens effortlessly or they are skilful at implementing this restoration for themselves. This essentially makes it so that the user cannot tell the difference between an app transitioning from the "Background" state into a foreground state, and an app transitioning from the "Suspended" state into a foreground state.

However, some developers do not provide this seamless restoration. In the most basic case (i.e. they do no nothing), the app will essentially "restart" and look like it was force quit and started again.

This explains part of the reason why some apps seem to be "running all the time", and others appear to be "stopped" and "restarted". It does not necessarily mean that iOS has "decided to quit" that app more so than others, but rather that the app itself wasn't built with the same care or was for other reasons unable to preserve and restore its state.

Note that iOS might suspend apps for various reasons other than rebooting your phone. For example app might be backgrounded and suspended in order to release memory or other resources to be used by other programs. They might also be brought back from suspension when resources are less scarce.

Basically apps can be backgrounded and suspended without the non-technical user being aware of anything. The app will still look the same in the app switcher - and the user can resume using that app without there necessarily being any difference between a suspended and not-suspended app. Note that often a suspended app will take slightly longer to bring up than a non-suspended app.

To sum all of this up, the definition of when a program is "running" is contextual and can be quite complex. Would the average user consider a PC program with a minimised window to be "running"? - If that PC goes to the S1 sleep state temporarily, is the program still "running"? You could argue that it is not, but could you argue that the program has "quit"?

Similarly an iOS app could probably be considered running by a non-technical user in either of the states mentioned as long as its state is preserved. The user can switch to the app and it will respond and look as expected - it does not "restart" (as in starting over from scratch). Obviously some might not consider the app as running when the phone is powered off... but from the point of view of the app itself, it doesn't actually "know" whether the phone has been turned off or not.

UPDATE:

From the comments I have learned that the practical problem behind this question is the MediSafe app and its failing to properly alert the user in some cases - and wanting to learn whether that's a short coming of iOS or the app itself.

The MediSafe app is supposed to give an alert at (or as soon as possible after) specific times to remind the user to take their medications. In order for that to work in every case, even when the phone has just rebooted, the app is not running, the app is backgrounded - or whatever has happened - the developer needs to use the User Notifications API and more specifically the UNNotificationRequest() function.

This API has nothing to do with the mentioned "background modes".

^{1: Note that the program might have asked the operating system specifically to not schedule it again unless some event happens.}

^{2: I'm talking about iOS 13 and newer here - it's slightly different on iOS 12 and older, where this isn't handled on a per-scene basis, but rather on a per UIApplication basis.}

^{3: This explains why some apps appear in the app switcher as "blank" or a "solid color" only. Some apps on purpose change their user interface to look like that just before the screenshot is taken in order to protect sensitive information from prying eyes. It does not mean that the app is "cleared out from memory" or is "less running" (if that makes any sense) than other apps.}