Making Apple-hosted in-app purchase content download by WiFi only

Question

I have a large (>1GB) in-app purchase that I want to deliver using an Apple-hosted download. The Apple docs say the Apple-hosted IAP content doesn't have a limit to the size that can be downloaded on a cellular connection. I'd like to be able to ensure the purchase is only allowed when connected by WiFi.

There's the possibility that during download the user might walk out the door and transition to cellular. At that point I'd like to pause or cancel the download until WiFi was available again.

I raised a TSI and Apple's response was "Our engineers have reviewed your request and have concluded that there is no supported way to achieve the desired functionality"

It seems feasible to use Reachability to check the connection type before starting the download and use the observer delegate during the download to make sure the phone didn't switch to cellular.

Will this work reliably? Is there a better way to do this?

Also in terms on maintaining control as the download proceeds, it's not clear from the Apple docs if the Apple-hosted download that runs in the background is in my app's process, or it happens out of process. In other words, if my app is terminated, is the download guaranteed to be stopped or does it continue outside my app's control?

Update: With the benefit of some experience, the question is somewhat moot. Continuous download of data requires that the phone has a WiFi connection and external power. Without these, the download gets paused a little while after the screen powers off - phone's power management I guess. Also the IAP download is out of process, it continues even of your app crashes (explicitly killing the app stops the download though). When your app restarts the StoreKit delegates are called to complete the download and purchase.

Answer 1

You can write a "download manager" which would monitor network status, and call pauseDownloads: and resumeDownloads: on the payment queue. Take a look here how to observe network changes.

Regarding download in-process vs. a dedicated process, I think it happens in-process. Taking a look at the API, we are told to queue SKDownload objects only when the transaction state is SKPaymentTransactionStatePurchased, but there is no API where we can obtain all purchased-state transactions and currently have queued downloads (like we have in the new NSURLSession API, where one of the modes handles downloads in an external daemon). This, and some experience with apps that have crashed exactly when trying to download leads me to believe it is in-process. In these apps that crashed, I had to restore purchases for download to start again, which is compatible with the exposed API in StoreKit.

---

Another suggestion is, if you could host the content by yourself, you could use Apple's new NSURLSession API, where you can specifically tell it to only download over WiFi.