I've turned off my iPhone.
Then I turn it back on.
I have my phone connected to the macOS console. I filter by process:SomeAppName
And about 1 minute after reboot, I see app name appear with that filter.
Is that expected?
It would not “open all apps.” But certainly, it may open some apps (e.g., particularly certain “Background Modes” that are configured under a target’s “Capabilities”). See About the Background Execution Sequence, About the App Launch Sequence, Choosing Background Strategies for Your App, and WWDC 2020 Background execution demystified. None of these enumerate the specific cases where apps can be launched in the background automatically, but might be a starting point for your research.
FWIW, each of the target “Capabilities” » “Background Modes” has slightly different behaviors (i.e., some cause an app to be relaunched in the background triggered by some system event, others launch at the discretion of the OS, for example, if on wifi and/or when charging, and some gather data out-of-process and are delivered when the user launches the app). So you have to go through these individual “background capabilities”, one by one, and see which cause the app to be launched in the background and which do not.
But if an app has one or more background capabilities enabled, it could easily be relaunched. The “Background fetch” and “Background processing” are two prominent examples that can easily cause the app to be launched in the background without user intervention. The background location services can be configured either way (launch the app on location change vs. deliver location updates when the user next launches the app). It just varies for each of these background modes. As a general rule, Apple tries to offer out-of-process solutions where it can (to minimize power-draining launches of apps in the background), but provides methods to have the app launched in the background where needed.
In the past we would have concerned ourselves solely with apps being launched as a result of background capabilities. But, as About the App Launch Sequence says, iOS 15 complicates the “which apps might launch” question, as it has “prewarming”. So that might cause apps to launch in the background without user intervention, too.
You ask:
Would the app get killed/suspended after getting launched?
As a general rule, apps are never “killed”, unless you violate the contract of the background execution (e.g., fail to call the completion handler appropriate for that background service or block the main thread and get killed by the watchdog process). All of the various background modes have some mechanism to gracefully inform the OS that your background process is done and that the app can now be suspended again. But in those cases where the OS kills a misbehaving app, it generally no longer participates in future background execution, which is why it is so important to finish background processes gracefully.
Obviously, suspended apps can be evicted/jettisoned when memory is required by the OS. But this graceful termination is very different than an app being “killed.”
BTW, to clarify the observation that killed apps will not be launched by most background services, the old “App Programming Guide for iOS” gave us hints about how most background services will not be launched again, but that background location services might. The guide is no longer found on Apple’s site, but here is the relevant excerpt:
In most cases, the system does not relaunch apps after they are force quit by the user. One exception is location apps, which in iOS 8 and later are relaunched after being force quit by the user. In other cases, though, the user must launch the app explicitly or reboot the device before the app can be launched automatically into the background by the system. When password protection is enabled on the device, the system does not launch an app in the background before the user first unlocks the device.
The new documentation verifies that background location services “relaunch an app … even after the user force-quits your app.” But this older quote places that observation in a broader context.
Related
I understand that this issue has already been covered extensively in the past, but I'd like to readdress it it appears that there is a lot of mixed messaging around the subject.
I have an application that should be periodically updated, roughly once a day at the minimum, to run some maintenance tasks. I have researched extensively on how to achieve this behaviour, but options such as background fetch and silent push notifications do not appear to work when the app has been terminated (swiped up on) by the user. (see this link for app states)
Will IOS wake up my app if it is in the terminated state, for example, if a user has swiped up on the app? I would like to find a solution that allows me to have the app run in the background in as many circumstances as possible.
What are my options here?
It is not possible to run a terminated app with Swift. Once an app has been terminated, it is no longer running and cannot be restarted. The only way to run the app again is to open it from the device's home screen or app launcher.
What I'm trying to achieve is detecting when the system terminates an app while it is running in the background (not suspended). According to this article it can be done by process of elimination. One of the steps is deciding that user didn't force quit the app. I assume this is done by checking whether applicationWillTerminate was called. However, according to Apple's documentation this method can also be called by the system, so I'm not sure how it eliminates that option.
For apps that do not support background execution or are linked
against iOS 3.x or earlier, this method is always called when the user
quits the app. For apps that support background execution, this method
is generally not called when the user quits the app because the app
simply moves to the background in that case. However, this method may
be called in situations where the app is running in the background
(not suspended) and the system needs to terminate it for some reason.
Is it possible to detect background system termination, and if so, what am I missing here?
The App Programming Guide for iOS: The App Life Cycle says:
Suspended apps receive no notification when they are terminated; the system kills the process and reclaims the corresponding memory. If an app is currently running in the background and not suspended, the system calls the applicationWillTerminate: of its app delegate prior to termination. The system does not call this method when the device reboots.
In addition to the system terminating your app, the user can terminate your app explicitly using the multitasking UI. User-initiated termination has the same effect as terminating a suspended app. The app’s process is killed and no notification is sent to the app.
The above is consistent with empirical tests.
In that Reducing FOOMs in the Facebook iOS app article, they mention the force quit situation where the app did "receive a termination call the last time the app was open": That only applies if the app was actively running and the user force quit it. But if the user first returns to the home screen (or otherwise suspends the app) and then force terminates the app, you will not receive that termination.
Bottom line, if the app is suspended at the time it was terminated, I do not believe that you have any reliable way of knowing whether it was jettisoned due to memory pressure or because the user force quit. The force quit scenario contemplated in that FOOM/BOOM article clearly only applies if the app was running when it was force quit.
I'm building an iOS app for iOS 8 & 9 and I am facing the problem that when the app goes to background the system is terminating it after just 2 or 3 minutes.
My testing is easy:
I kill all running apps from my iPhone.
I restart my iPhone (to ensure no other apps are taking memory).
I launch my app.
I do nothing inside my app.
I press the "Home" button, moving my app to background.
I wait doing nothing else for 2 or 3 minutes.
I open my app again and surprise, the system has terminated it and now it is restarting as a new launch.
Some comments:
The app does not use CoreLocation in background neither any other service.
I've profiled the app, trying to understand if it is consuming too much memory. When moving to background, it consumes around 25Mb of RAM memory. I'm attaching a screenshot below.
This behavior has been tested on iPhone 5, 5s, 6, 6+.
In iPhone 6s and 6s+ seems to take a bit more time to happen, but still happens.
My question is: Do you know why would this be happening? anything I might not be considering or just forgetting?
I don't want to force my app to run in background by using CoreLocation or something similar. And I'm ok if the system kills my app eventually. What I don't want is that everytime I move my app to background the system terminates it.
Any hint or help will be appreciated.
Thanks,
All applications are automatically killed by the system
According the Apple documentation:
App Termination
Apps must be prepared for termination to happen at any time and should not >wait to save user data or perform other critical tasks. System-initiated >termination is a normal part of an app’s life cycle. The system usually >terminates apps so that it can reclaim memory and make room for other apps >being launched by the user, but the system may also terminate apps that >are misbehaving or not responding to events in a timely manner.
Suspended apps receive no notification when they are terminated; the >system kills the process and reclaims the corresponding memory. If an app >is currently running in the background and not suspended, the system calls >the applicationWillTerminate: of its app delegate prior to termination. >The system does not call this method when the device reboots.
In addition to the system terminating your app, the user can terminate >your app explicitly using the multitasking UI. User-initiated termination >has the same effect as terminating a suspended app. The app’s process is >killed and no notification is sent to the app.
https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/TheAppLifeCycle/TheAppLifeCycle.html#//apple_ref/doc/uid/TP40007072-CH2-SW1
You can track position but you will certainly see a blue status bar to indicate that an application use GPS tracking.
Maybe you can try to "wake up" your app in background with silent notification...
If it is not necessary to keep your app alive, trust the system...
Some error in inside your code. Please select debug Navigator before run your app... Now you can able to find your error..
Or too much memory also it will terminated..
Apps which are running in the background drain battery life faster, It gives you a bad perception of the device, instead of the app, because the average consumer has no idea that it's an app draining battery.
Thus iOS won't allow your app to run in the background, more than a few seconds. But there are some exception, an app can request extension to this by declaring that its starting a Background Task.
for more info you can check below links:
http://blog.dkaminsky.info/2013/01/27/keep-your-ios-app-running-in-background-forever/
http://www.speirs.org/blog/2012/1/2/misconceptions-about-ios-multitasking.html
Does anyone know if core BLE continues to run in the background after a user force quits the app in iOS 7.1? Or does just iBeacon continue to run? I know that neither will continue to broadcast on force quit, but will both continue to scan?
EDIT: I've attempted to test the current implementation I've had and it doesn't appear to be running in the background after force quit. What I've heard so far from other sources is that it does but it doesn't appear to be running for me with the standard CoreBluetooth implementation.
For CoreBluetooth (CBCentralManager and CBPeripheralManager), the following rules apply:
If the user closes the app manually using the app switcher, the BLE part of your app also gets killed.
If the user does not close the app manually, you can use the bluetooth-central and bluetooth-peripheral background modes to get relevant callbacks while your app is backgrounded. However, iOS may still kill your app under memory pressure or for whatever reason, in which cases the BLE part is also gone.
To keep the BLE part alive, you can use restore identifiers when instantiating CBCentralManager and CBPeripheralManager. Managers with a restore identifier are kept alive even after iOS killed your app, and if an interesting BLE event occurs), your app will be launched into background and you will be passed the state of the managers when the app got killed for restoration.
The main queue is suspended during background execution - make sure to configure the managers in a way that events are not dispatched on the main queue.
If the user closes the app manually using the app switcher, restoration is forfeited and the BLE part of your app won't stay alive.
To test restoration, you need to resolve to using tools like BackgroundKill. Note that the Xcode debugger may keep your app alive, so make sure to disconnect the debugger first (which will kill the app), then launch your app, then open BackgroundKill and examine the Console output in the Xcode Organizer window.
Yes, it continues to run. This is a change in iOS 7.1.
See my detailed answer and test procedure in the comments here: https://stackoverflow.com/a/22365156/1461050
I found this line in the iOS App Programming Guide:
Including the voip value in the UIBackgroundModes key lets the system
know that it should allow the app to run in the background as needed
to manage its network sockets. An app with this key is also relaunched
in the background immediately after system boot to ensure that the
VoIP services are always available.
And I find this statement to be true in general. However, if the user force closed the application before rebooting their device, my experience has been that the app is not automatically relaunched on device boot. Can I get some clarification on the expected behavior in this particular case?
All credit goes to "The Eskimo" on this one...
It's generally true that apps that the user 'quits' using the
multitasking UI are not automatically launched again. The system
takes that as a hint from the user that it should not relaunch the
app. If the user wants the app to be automatically launched in
future, they must manually launch it at least once.
For VoIP apps this has been the case since VoIP support was introduced. For other
types of automatically launched apps the implementation of this
heuristic has been less consistent, although I believe that with iOS 7
it's now applied across the board.