3

I'm little bit confused with background fetch. I read in Apple Developer documentation that fetch happens when OS decides that it should, user can't control background fetch, while on Apple Developer forum post by Apple employee says that if user kills app (double tap on home and button swipe up) background fetch wont happen, in that case user can control background fetch. So can someone please clarify to me if user kills the app with task manager will background fetch still continue in the background or it's killed at the same time as app.

Apple documentation:

https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html#//apple_ref/doc/uid/TP40007072-CH4-SW1

user4191892
  • 85
  • 1
  • 5

3 Answers3

6

From the doc you link:

When a good opportunity arises, the system wakes or launches your app into the background and calls the app delegate’s application:performFetchWithCompletionHandler: method.

So, it seems that the system is able to launch in the background an app that is not running so it executes a background fetch. On the other hand, though, later in the document you can read:

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.

So, Apple's engineer is right: force quitting an app puts it into a sort of special case where background fetches are not allowed anymore.

sergio
  • 68,819
  • 11
  • 102
  • 123
  • That's really stupid, then there's no way to send local notifications while app is in background (killed by user)? I can't believe Apple did this... – user4191892 Jan 10 '15 at 15:12
  • 5
    @user4191892 You said, "while app is in background (killed by user)..." Just to clarify, the app is not "in background" after the user kills it; it is terminated. From a developer perspective, I can see why you find this feature annoying, but from the iOS device user's perspective, this actually is a good feature. For example, some app is doing something that I find so annoying that I feel compelled to not just leave the app, but actually go through the extra step to explicitly kill it, too: I'm not going to be happy if it just immediately pops back. – Rob Jan 10 '15 at 18:02
  • yeah, I agree with you – user4191892 Jan 10 '15 at 19:36
2

If the user feels the need to allow background operations, he wouldn't kill the app. But when he kills it, it is only appropriate to disallow background fetch. User can only control if background fetch should happen or not by allowing it to stay in background/by killing the app. But once the app is in background, user cannot control "when" the background fetch happens. The OS determines it based on how free it is.

Arvind
  • 41
  • 2
0

I think this quote (from the linked document) is the most important for the scenario you're describing:

Once configured, your NSURLSession object seamlessly hands off upload and download tasks to the system at appropriate times. If tasks finish while your app is still running (either in the foreground or the background), the session object notifies its delegate in the usual way. If tasks have not yet finished and the system terminates your app, the system automatically continues managing the tasks in the background. If the user terminates your app, the system cancels any pending tasks.

mbm29414
  • 11,558
  • 6
  • 56
  • 87
  • @Rob Look at the last sentence. "If the user terminates your app, the system cancels any pending tasks." – mbm29414 Jan 10 '15 at 18:46
  • Very good. I'm not sure I would have extrapolated this quote about pending `NSURLSession` background tasks to the current discussion of background fetch, but I now see what your point was. Thanks for clarifying. – Rob Jan 10 '15 at 19:17