Hi all. We are facing an issue where DownloadAssetsAsync will fail on iOS when we background the app and resume. It will throw exception with the result of “Cannot connect to destination host”. However, it runs fine on Android.
I am aware that iOS has certain limitations on background tasks but didn’t have the luck to figure out how to solve this issue. So far we have tried:
Turn on “Enable Custom Background Behaviors” and check “Background Fetch”. This doesn’t help.
Raise Retry Count. This would cause the download to start from the beginning when resuming before it runs out of retry count and fails.
Attached is our remote config for addressables. Any help would be appreciated. Thanks!
We had been unable to repro it locally, but I don’t think we tried on iOS. Just on android, and from your post here, it sounds like android handles a failed & resumed download fine, but perhaps iOS doesn’t. To clarify…
no matter how high the retry count, it never works, right? And if I’m understanding correctly, even if you did a manual retry (once you get the failed op back, repeat the call into Addressables), it still won’t work. Right?
I’m not sure if this is intentionally designed this way, but the retry does not work like network retries in other network frameworks, where retry would attempt to recover from error and re-establish lost connection. What I am seeing is that the retry in addressables will only go back to the very beginning of the download process and start all over again. If you set a retry number, say 3, after each failure addressables would restart the download process each time a connection is lost. And after 3 times it will throw an error.
Intentional? Not exactly. How it works? yes. Addressables currently just uses the engine’s UnityWebRequest as it has a lot of built in asset bundle magic (cache, recompression, etc.). UWR doesn’t have a “resume” ability.
Long term we (Unity) intend to replace this, but I’m not sure exactly when that’ll be dealt with, or which teams might tackle it.
@lxzeng (or perhaps @unity_bill ) Have you found any solution? We are currently experiencing the same issue, with “Cannot connect to destination host” errors popping up just on iOS devices (other platforms work just fine). I have been looking for a fix, but no luck yet…
We are still trying to reproduce the issue on iOS. If someone is able to submit a bug report with a small project that reliably reproduces the issue, that would help a lot!
Hi @KenDots the status is pretty much the same. We are unable to reproduce the issue locally, and haven’t received a sample project that reliably reproduces the issue.
When testing on iOS, I was able to reproduce the **Cannot connect to destination host** error by starting an addressables download, backgrounding the app, turning off wifi/cell (so, turning off internet connection), turning it back on, and then foregrounding the app. This was able to cause current downloads to fail with the error. However, I was always able to successfully retry in the same app session and eventually complete the download.
Should also note that this was during downloading an updated version of a bundle from a new app version, while having an older version of the bundle downloaded from a previous app version already, though I’m not sure if that is important, that is the case where we had a lot of failure metrics pop up for us in production.
I apologize I’m a little late to comment, but the download is almost certain to fail in that situation. Addressables uses UnityWebRequest which doesn’t have a pause and resume feature for IOS. And if the download stops and fails due to internet connectivity, the retry does restart the download again from the beginning and is independent of any other retries. Those behaviors have to do with which IOS native methods UnityWebRequest is implemented with. You could implement a custom bundle provider with different ones that support backgrounding downloads. This project uses Apple/IOS API calls that will be able to background download. However, you would then need some custom caching and CRC for bundles too.
That aside, Addressables should be able to retry the download after resuming the app. I haven’t been able to reliably produce any issues doing so, but I did at least see once where it failed the first retry and succeeded on the second. In that case, I increased timeout values in group settings and haven’t been able to reproduce it again. So it may be helpful to increase those timeout values. And if it is possible, using more but smaller bundles would make it less costly to restart the download on retrying.
