Downloading iAP Hosted Content gets stucks on SKDownloadStateWaiting for some users - ios

Question

Pretty much what the title says. The code works fine for all my development devices in the sandbox environment and for a majority of my users. However, there are some users reporting that the download process doesn't move beyond the waiting state (SKDownloadStateWaiting), even when left through the night. Some do manage to get the download started after a few tries (closing the app completely and going through restore purchases feature), so it does look to be completely random.
Here is the code I'm using to manage downloading:
- (void)paymentQueue:(SKPaymentQueue *)queue updatedDownloads:(NSArray *)downloads
{
SKDownload *download = [downloads objectAtIndex:0];
SKPaymentTransaction *transaction = download.transaction;
// Keep track of download status
switch (download.downloadState) {
case SKDownloadStateActive:
// Present time remaining and percentage
break;
case SKDownloadStateWaiting:
// Present "Waiting..." label
break;
case SKDownloadStateFinished:
[self purchaseNonconsumableAtURL:download.contentURL forProductIdentifier:productIdentifier];
[[SKPaymentQueue defaultQueue] finishTransaction:transaction];
break;
case SKDownloadStateFailed:
[[SKPaymentQueue defaultQueue] finishTransaction:transaction];
break;
case SKDownloadStateCancelled:
[[SKPaymentQueue defaultQueue] finishTransaction:transaction];
break;
default:
break;
}
}
Any help would be much appreciated.

Answer 1

You can try to start a download that's in SKDownloadStateWaiting by calling
[[SKPaymentQueue defaultQueue] startDownloads:[NSArray arrayWithObject:download]];
My application would always get downloads that were in a permanent "waiting" state when it attempted to resume earlier transactions. I edited the paymentQueue updatedDownloads function so that whenever it's called with a download that's in a waiting state, it will pass that download to startDownloads, and this seemed to fix the issue.

Answer 2

It's worth checking whether your users have a 12 hour (AM/PM) or 24 hour time setting on their devices, especially if you're performing receipt validation locally and ensuring certain date fields are present / valid (e.g., purchase date). I had problems with receipts not being validated with users who have 12 hour time setting. To make this even more of an edge case, the receipt validation for 12 hour time users will only fail if the purchase has been made in the afternoon in GMT. This is certainly a thing worth testing in sandbox.
If you use DateFormatter / NSDateFormatter in your receipt validation at all, ensure you set the locale to one that uses 24 hour time (e.g., en_GB) to ensure it uses a 24 hour time format.
For example, in Swift 3, my receipt validator's time formatter property would be something like this:
private let dateFormatter: DateFormatter = {
let formatter = DateFormatter()
formatter.timeZone = TimeZone(secondsFromGMT: 0)
formatter.locale = Locale(identifier: "en_GB")
formatter.dateFormat = "yyyy'-'MM'-'dd'T'HH':'mm':'ss'Z'"
return formatter
}()