NSURLSession background download over cellular possible in iOS 8?

Question

I need to make small downloads initiated when my app is in the background and woken up by Significant Location Changes. BUT Apples documentation of NSURLSessionConfiguration here:

https://developer.apple.com/library/IOs/documentation/Foundation/Reference/NSURLSessionConfiguration_class/index.html#//apple_ref/occ/instp/NSURLSessionConfiguration/discretionary

says the following for the discretionary property:

When transferring large amounts of data, you are encouraged to set the value of this property to YES. Doing so lets the system schedule those transfers at times that are more optimal for the device. For example, the system might delay transferring large files until the device is plugged in and connected to the network via Wi-Fi. The default value of this property is NO.

The session object applies the value of this property only to transfers that your app starts while it is in the foreground. For transfers started while your app is in the background, the system always starts transfers at its discretion—in other words, the system assumes this property is YES and ignores any value you specified.

This seems to imply that if a download is started in the background the OS always has discretion as to whether and when to proceed with the download. It seems that the OS is always waiting for a wifi connection before completing these tasks. My experience supports this conjecture. I find that I can send several notifications for downloads while device is on cellular. They remain stuck. When I switch the device to wifi they all go through.

WTF? Why Apple prohibits configuring this behaviour, especially since they HAVE the neccessary properties on the NSURLSessionConfiguration object (discretionary, allowsCellularAccess). Of course the user is not always in WiFi when download tasks are started. I need to do this in response of app wake-ups by significant location changes. I schedule download tasks on a background session and never receive delegate callbacks on cellular network until I switch to WiFi. So does that mean I cannot finish these tasks unil WiFi is available again or I bring the app back to foreground?

Has anybody of you a workaround for this?

I already thought of the following:

Starting a long running background task (old style) after a location update and download my stuff there by using a defaultSessionConfiguration. Any experiences if that can work? If this doesn't I will use NSURLConnection I think (even more old style).

Sweven

In a word, battery. Can you store the updates and send the, later? – Multilateral

Yeah, battery is very important. And in many developing countries people pay much money for a small amount of cellular traffic. People don't want to pay money for this kind of invisible long-consuming cellular traffic. – Vesical

Answer 1

Forgive my chiming in on an old question, but a few observations…

---

As you noted, downloads initiated from the background are automatically “discretionary” (i.e., launched at a time of the discretion of the OS, generally when on wifi and connected to power).

This is done because:

• downloads consume the user’s mobile data plan (which can get expensive if you’ve exhausted the billing period’s “free” data); and
• downloads in the background consume the user’s battery at a higher rate.

These activities (consuming battery and data plan) are problematic if triggered in the background, because all of this is happening without the user’s knowledge/consent. Clearly, these background concerns are eliminated if the user is on wifi and is connected to power.

---

In answer to how to resolve this, there are two approaches:

• When the app is launched in the background, you actually have enough time (15-30 seconds, IIRC) to perform most network requests. You would just just launch a standard network request (a standard URLSessionConfiguration, not a background configuration). You only need to use background configuration for downloads that will exceed this allotted time.

• If you really need to start a very large download based upon geofencing data, you can only do this with the user’s consent. So, you could, for example, just present a notification to the user (using User Notifications UI), and if they tap on the notification, thereby launching your app, you can then initiate the large download once the app is in the foreground.

---

For more information, see Handling location updates in the background.

You might also consider whether you really need the “significant change” service (which can fire up the app every time the user’s location changes substantially), or whether you can accomplish the goal using geofencing, i.e., to identify when the user enters a particular region. For this latter approach, which is even more battery/data friendly, see Monitoring the user's proximity to geographic regions.

Jampack