Alamofire: Resume Data bug in iOS 10

[amosavian]

Hi,
iOS URLSessionDownloadTask.cancel(byProducingResumeData:) gives unusable resume data. To rectify these data you can add my tricky method to your project:

http://stackoverflow.com/questions/39346231/resume-nsurlsession-on-ios10/39347461#39347461

Best Regards

[jshier]

@cnoon I think you're the best one to handle this.

[imfaker]

@amosavian I use oc ,so i don't familiar with swift.So i can't understand a part of code. Can you use oc for writing Solution again ,or tell me how to solve this by oc in detail? thank you very much!

[amosavian]

@imfaker I know literally nothing on objc. However you can either bridge this code using bridge-header to objective c or convert it.

[imfaker]

I have slove this problem that use your way by objc.Thank you very much for your idea .You're genius.hahah.

[cnoon]

Thank you for reporting this issue @amosavian. I've added a test in acc7361c that verifies the behavior works correctly in the official Xcode 8 release on iOS 10 and iOS 9. Looks like the issue has been resolved in the underlying URLSession logic.

Cheers. 🍻

[amosavian]

Hey @cnoon , This problem will occur when you use background session configuration.

[cnoon]

Thanks for letting me know @amosavian. I'm going to re-open and see if I can reproduce the behavior in a sample app since background session configurations no longer work in the simulator in Xcode 8.

[amosavian]

@cnoon I can reproduce this behavior in both simulator and device. You will get error -3003 in case you try to use resume data to start and resume a new background download task.

[mat0pad]

Any news on this?

[cnoon]

Hi @amosavian,

Thank you for bringing the error to our attention. After much debate, we've decided to leave this out of Alamofire due to the instability of this type of solution. Apple has really made a huge mess here and we're not sure about what all the permutations of various uploads and downloads could actually be. We also wouldn't be able to test any of the logic since the background URL sessions are broken in test targets. Because of all these issues, we're not comfortable taking ownership of such a fragile solution for a black box Apple feature.

With that said, we fully support the approach you've put in place for users that "have" to solve this issue. We just won't be implementing the solution directly into Alamofire. We have updated our docstrings and README in 4af61a69 to reflect the current state of resume data on the latest platforms. Hopefully this gets people started in the right direction.

Thanks again. 🍻

[amosavian]

Hi @cnoon

Thanks for your attention. Your decision makes sense. It's enough to inform users about this bug and the workaround so they won't be like a headless chicken when they encounter this issue.
The interesting point is I didn't test this issue on macOS and tvOS and this is first time I found out it's universal.

Thanks much 🍻

[neducatio-content]

Hi @amosavian

I'm having the same problem and, quite frankly, don't know how to implement your workaround in Alamofire. I've tried replacing the session.downloadTask(withResumeData: resumeData) function with session.correctedDownloadTask(withResumeData: resumeData) in the DownloadRequest class but the problem is that the download task fails (instead of being suspended) as soon as the user loses internet connection.

Thanks!

[amosavian]

@neducatio-content

"unsupported url" (-1002) error which you get can't be fixed though it's due to exactly the same underlying bug. I tried to fix this issue but found out nsurlsessiond deamon not only doesn't return NSURLSessionDownloadTaskResumeData userInfo object but also deletes temporary file which is unrecoverable with standard methods.

Quinn the Eskimo, the support guy of Apple team is aware of this issue and emailed me an official workaround which is principally improved version of mine, and solves the same issue. But he said they are working to fix the bug.

Unfortunately for now, there is not workaround to overcome this issue

"Share and Enjoy"

[jshier]

@amosavian Are you able to share the official workaround?

[amosavian]

@jshier I asked him and he told me I'm not allowed. But the improvement is they use a NSKeyedUnarchiver with archiver.requiresSecureCoding = true instead of directly mangling with keyed archived object in correct(requestData:) method to change top level key from "NSKeyedArchiveRootObjectKey" to NSKeyedArchiveRootObjectKey = "root", otherwise it's the same with exhaustive documentation.

[neducatio-content]

@amosavian thanks for your help!