We have a GPS tracking type iOS app which runs in the background. We are seeing infrequent cases where the app appears to be getting terminated with the applicationWillTerminate method being called while the tracking process is taking place.
We have more or less ruled out low RAM as the reasons. Also definitely not a battery level issue or users terminating the app.
Any suggestions what would be the next most likely causes for iOS to terminate the app?
Some thoughts we had were CPU usage, phone temperature level or simply because the app is running in the background for extended periods (e.g. days or weeks).
Are any of these likely or even possible causes for iOS to terminate the app?
From Apple's Background Execution docs:
Do minimal work while running in the background. The execution time
given to background apps is more constrained than the amount of time
given to the foreground app. Apps that spend too much time executing
in the background can be throttled back by the system or terminated.
Also, I assume you've verified you're not running afoul of the below (from the same doc):
Each call to the beginBackgroundTaskWithName:expirationHandler: or
beginBackgroundTaskWithExpirationHandler: method generates a unique
token to associate with the corresponding task. When your app
completes a task, it must call the endBackgroundTask: method with the
corresponding token to let the system know that the task is complete.
Failure to call the endBackgroundTask: method for a background task
will result in the termination of your app.
Related
I'm working on an iOS application and I want the app to terminate after hanging in the background for more than 5 minutes and when the user opens the app again it should display the login. For now the app terminates immediately when it reaches the background and the login screen when the user re-opens the app. I did this by adding a property called "Application does not run in background" to the info.plist file and I set the value to "YES". As I mentioned at the start what I want to do is to terminate the app after 5 minutes in background but not immediately. And the login screen appearing after the user re-opens the app is working fine.
Application does not run in background property in info.plist
I guess you this is managed by the operating system that for how long the app runs in the background, and the os terminates it when it require resources to get free.
A workaround that could be done is, store the time value in UserDefaults whenever the app goes to background, and whenever the app comes foreground, check for the previous time value. If the difference is greater than 5 minutes, you may direct to login.
You can request background time when you are told that you are being suspended. I believe the max you will get is 3 minutes, not 5. That will prevent your app from being terminated, and keep your app getting CPU time during that time. (Which will use extra battery power.) You will get a notice when that time expires, and you can save your app state and log off at that point.
Search on "Extending Your App's Background Execution Time" in the Xcode help system or Apple's docs for more information. The overview section of that document reads:
Overview
Extending your app’s background execution time ensures that you have adequate time to perform critical tasks. For tasks that require more background time, use Background Tasks.
When your app moves to the background, the system calls your app delegate’s applicationDidEnterBackground(_:) method. That method has five seconds to perform any tasks and return. Shortly after that method returns, the system puts your app into the suspended state. For most apps, five seconds is enough to perform any crucial tasks, but if you need more time, you can ask UIKit to extend your app’s runtime.
You extend your app’s runtime by calling the beginBackgroundTask(withName:expirationHandler:) method. Calling this method gives you extra time to perform important tasks. (You can find out the maximum background time available using the backgroundTimeRemaining property.) When you finish your tasks, call the endBackgroundTask(_:) method right away to let the system know that you are done. If you do not end your tasks in a timely manner, the system terminates your app.
The key bits of that are:
"When your app moves to the background, the system calls your app delegate’s applicationDidEnterBackground(_:) method."
And "You extend your app’s runtime by calling the beginBackgroundTask(withName:expirationHandler:) method"
Note that you should really implement an app level "heartbeat" where the app sends periodic "I'm still here" messages to the server to keep the user logged in. Your server should log the user off if they miss more than one heartbeat message.
How can we detect when an iOS App has been suspended?
There is no method that mentions this in the official UIApplicationDelegate documentation.
These are the states that an App can have:
(source: apple.com)
Use case:
I want to log when an app stops running subsequently to being woken up due a location event. For example I have got an iBeacon that the app is montioring. I activate the iBeacon and the app gets launched successfuly in background (for 10 seconds). I would like to detect when the App stops running after these 10 seconds have elapsed. However there is no AppDelegate method that seem to allow to intercept this (please consider that I am investigate this specific case.
Previous question:
I had asked a previous similar question which did not get answered. Please find it here.
While I am unaware of any callback, you can query for the amount of background time remaining with:
NSLog(#"background time remaining: %8.2f", [UIApplication sharedApplication].backgroundTimeRemaining);
Theoretically, you can put this in a thread and execute custom code a second or so before your app terminates. See my blog post here for more info:
http://developer.radiusnetworks.com/2014/11/13/extending-background-ranging-on-ios.html
I think you won't get any feedback form Suspended state. Suspended means that app is in memory but no code is executing right now.
Documentation:
The app is in memory but is not executing code. The system suspends apps that are in the background and do not have any pending tasks to complete. The system may purge suspended apps at any time without waking them up to make room for other apps.
So in my understanding, if an app would give you a callback with something like applicationDidEnterSuspendedState it will be a paradox, cause Suspended state means that no code is executed.
Before asking a question, let me clarify what I understand about iOS App states:
Backgrounded: In this state, your app is not in the foreground anymore but it is still able to run code.
Suspended: Your app enters this state when it’s no longer able to run code.
Now, I wanted to keep downloading going on when App is in background, i.e. it still does exist in multitasking screen. It is working as expected with background transfer service.
But, in some tutorial reference, I have read that you can perform downloading even when App is Backgrounded / Suspended. Can it work even when my App is suspended, i.e. removed from multitasking screen ?
I have been reading many documents including Apple class reference regarding background transfer service with download task, but no one clarifies that the download will not work when App is suspended (killed).
Appreciate your thoughts and advices !!!
If your app has been suspended by the system (without force quiting from multitasking screen) your background session will continue to work.
If you force quit the application all download tasks will be canceled.
The following is from backgroundSessionConfigurationWithIdentifier(_:) documentation :
If an iOS app is terminated by the system and relaunched, the app can use the same identifier to create a new configuration object and session and retrieve the status of transfers that were in progress at the time of termination. This behavior applies only for normal termination of the app by the system. If the user terminates the app from the multitasking screen, the system cancels all of the session’s background transfers. In addition, the system does not automatically relaunch apps that were force quit by the user. The user must explicitly relaunch the app before transfers can begin again.
Apps displayed in the multitasking UI aren’t necessarily executing code or fetching data. Listed apps may be suspended or not running at all
[[UIApplication sharedApplication] applicationState] will check your application state, you can test your app.
NSURLSession class can hand off downloads and uploads to the operating system when the app becomes inactive. As with almost all background execution APIs, if the user force quits from the multitasking UI, the background operation will terminate
In iOS 7, Apple added support for background fetch—a kind of smart, per-app crontab that wakes up at opportunistic times. There is no way to force background fetches to execute at exact intervals. iOS checks how much data and battery power was used during previous background fetches when scheduling future callbacks.
Background fetches can also be triggered by remote push notification and have a very similar delegate method with the same completion handler.
Full Tutorial is here
https://blog.newrelic.com/2016/01/13/ios9-background-execution/
I've written a geo-fencing iOS app that uses startmonitoringsignificantlocationchanges to trigger an action that requires network query. It does not work reliably because sometimes the network delay causes the app to be terminated. I do realize that the documentation says, iOS may terminate the app if I try to do network query that takes too long:
"If you leave this service running and your application is subsequently suspended or terminated, the service automatically wakes up your application when new location data arrives. At wake-up time, your application is put into the background and given a small amount of time to process the location data. Because your application is in the background, it should do minimal work and avoid any tasks (such as querying the network) that might prevent it from returning before the allocated time expires. If it does not, your application may be terminated."
Is there an alternative way to start network query in the background when iOS launches my app as a result of entering a region?
Yes, you have to call beginBackgroundTaskWithExpirationHandler. See here:
http://www.mindsizzlers.com/2011/07/ios-background-location/
I am using core location framework inside my application and I set the location string in UIBackgroundMode or Required background modes(in Xcode 4.2) for getting the updated location from didUpdateToLocation method when app is running in background and also sending this updated location to server by hitting the specific link inside didUpdateToLocation method of core location framework.
My question is that will the app be terminated after some time when running in background or not?
No, there is no specific time defined for this.But app will definitely terminate based upon certain parameter - battery drain, memory footprint issue etc.
In developer documentation it is clearly mentioned - "The system keeps suspended apps in memory for as long as possible, removing them only when the amount of free memory gets low. Remaining in memory means that subsequent launches of your app are much faster."
Go through this for complete details -
http://developer.apple.com/library/ios/#DOCUMENTATION/iPhone/Conceptual/iPhoneOSProgrammingGuide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html
I am sure it is not useful for the author because the question was asked in June 2012 and I am giving an answer in June 2019. This answer maybe is useful for other users.
I am posting this answer because Everyone is said that it is OS default behaviour, We can not change it....bla....bla.
Recently, I was working with the same requirement. After 2-3 week hard
work, I did it. For other users, I create a helper class for it. My
app will never be killed by OS until the location tracking enabled.
You can also verify that OS will never kill this app tracking app
Use HSLocationManager for infinite location tracking in the active and inactive state.
Refer my app which is available in the app store(App will never kill by OS if location tracking is enabled)
Location manager that allows getting background location updates every
n seconds with desired location accuracy.
Advantage:
OS will never kill our app if the location manager is currently
running.
Give periodically location update when it required(range is between 2 -
170 seconds (limited by max allowed background task time))
Customizable location accuracy and time period.
Low memory consumption(Singleton class)
iOS app may get terminated due to following reasons:
Watchdog Timeout
As you’re probably aware, since iOS 4.x, most of the time when you
quit an iOS app, the app isn’t terminated – instead, it’s sent to
the background.
However, there are times when the OS will terminate your app and
generate a crash log if the app didn’t respond fast enough. These
events correspond with the implementation of the following
UIApplicationDelegate methods:
- application:didFinishLaunchingWithOptions:
- applicationWillResignActive:
- applicationDidEnterBackground:
- applicationWillEnterForeground:
- applicationDidBecomeActive:
- applicationWillTerminate:
In all of the above methods, the app gets a limited amount of time
to finish its processing. If the app takes too long, the OS will
terminate the app.
User Force-Quit
iOS 4.x supports multitasking. If an app blocks the UI and stops
responding, the user can double-tap the Home button from the Home
screen and terminate the app.
Note: You may have noticed that when you double-tap the Home button,
you also get a list of all the applications you’ve run in the past.
Those apps are not necessarily running, nor are they necessarily
suspended.
Usually an app gets about 10 minutes to stay in the background once
the user hits the Home button, and then it gets terminated
automatically by the OS. So the list of apps that you see by
double-tapping the Home button is only a list of past app runs.
Low Memory Termination
When subclassing UIViewController, you may have noticed the
didReceiveMemoryWarning method.
Any app that is running in the foreground has the highest priority in
terms of accessing and using memory. However, that does not mean the
app gets all the available memory on the device – each app gets a
portion of the available memory.
When total memory consumption hits a certain level, the OS sends out a
UIApplicationDidReceiveMemoryWarningNotification notification. At the
same time, didReceiveMemoryWarning is invoked for the app.
At this point, so that your app continues to run properly, the OS
begins terminating apps in the background to free some memory. Once
all background apps are terminated, if your app still needs more
memory, the OS terminates your app.
I have seen that the background location updates will work for several hours. But if I go to a place without reception the device will stop to send GPS updates it wont start when I go to a place with reception. This occurs after approximately 30min.
But if I add this, in iOS6, the app won't terminate
[locationManager setPausesLocationUpdatesAutomatically:NO];
Quick answer is pretty much no. Read below though for in depth.
Since multitasking has been enabled on iOS devices that a)your app gets allocated amount of memory and b)the device limits the amount of tasks, that is applications using memory, that occur at any given time. If you take an iOS device and open several apps you'll begin to notice that the app you opened first may have been terminated and reload from the viewDidLoad.
Generally it's safe to say if your app is a recently opened app (or even on a phone where someone clears the multitasking menu often) that the device will not terminate your application in the background.