Can't access iOS file
Hi,
Can you provide more details on how to access the final downloaded file on iOS please?
I'm able to complete the download but it seems the file isn't actually being copied from the temp directory to the final directory.
I added a boolean value to determine if the replaceItemAtURL operation completes and it returns false.
[code=CSharp] NSFileManager* fileManager; NSURL* destUri = GetDestinationUri(downloadTask.taskDescription, &fileManager); [fileManager replaceItemAtURL: destUri withItemAtURL: location backupItemName: nil options: NSFileManagerItemReplacementUsingNewMetadataOnly resultingItemURL: nil error: nil]; UnityBackgroundDownload* download = [backgroundDownloads objectForKey: downloadTask]; download.status = kStatusDone;[/code]
Hoping someone who's familiar with iOS might have an idea about what is wrong?
I'm using Unity 2019.1.14f.
Thanks,
Can you show your C# code? Including the destination for your file.
I am having the same issue.
My C# code is this:
_backgroundDownload = BackgroundDownload.Start(new Uri(url), MakeBundleRelativePath(moduleData.BundleName));
and the destination path is: "moduleBundles/aed.assetbundle"
I debugged the iOS plugin and found that in UnityBackgroundDownloadStart(void* req, const char16_t* dest) in BackgroundDownload.mm, dest is NULL, even when I pass in a string literal to BackgroundDownload.Start.
The download completes, I can see the progress increasing, however the file is nowhere to be found. The same code works on Android. I am on Unity 2019.2.6
What does the MakeBundleRelativePath() do? And, when debugging, make sure you build and run XCode in Debug mode (Unity defaults to release when exporting).
MakeBundleRelativePath just returns "moduleBundles/aed.assetbundle".
After debugging in debug mode, I see that dest in UnityBackgroundDownloadStart(void* req, const char16_t* dest) is actually set correctly. However the file still does not exist when the download completes. I used XCode to show the container for my app and do not see it anywhere.
Try debugging the completion code and see where the file is saved.
replaceItemAtURL completes with an error: NSCocoaErrorDomain 513 destURI is: "file:///var/mobile/Containers/Data/Application/A75442A2-A4C1-41DC-A861-7E459D546CFB/Documents/moduleBundles/burns.assetbundle"
Check the path it is trying to save to. Does directory exist? If not, you probably need to upgrade, I see in the code, that the directory should be created prior to download.
The directory does exist. I also tested with the destination being in the root Documents directory and have the same issue.
Which iOS version are you using?
13.2.3
I thought I commented but I fixed this a while ago. I think there's an odd discreprency between provinding the full file url for Android and doing the same for iOS. On iOS it seems to attempt to prepend part of the directory. I amended the .mm file's code (green being new lines, red being removed)

What do you mean by "I think there's an odd discreprency between provinding the full file url for Android and doing the same for iOS"? The destination file path must be relative path and will be saved under Application.persistentDataPath.
The log on XCode has more information. Seems like there is an underlying error?
2020-09-16 17:56:21.353818-0400 emanmomot[5820:406849] Failure Error Domain=NSCocoaErrorDomain Code=513 "You don’t have permission to save the file “aed.assetbundle” in the folder “Documents”." UserInfo={NSFileOriginalItemLocationKey=file:///var/mobile/Containers/Data/Application/E0AED388-FDD2-4444-937C-DF0C132D0287/Documents/aed.assetbundle, NSURL=file:///var/mobile/Containers/Data/Application/E0AED388-FDD2-4444-937C-DF0C132D0287/Documents/aed.assetbundle, NSFileNewItemLocationKey=file:///var/mobile/Library/Caches/com.apple.nsurlsessiond/Downloads/com.emanmomot/CFNetworkDownload_c5SXp9.tmp, NSUnderlyingError=0x281d96760 {Error Domain=NSCocoaErrorDomain Code=513 "You don’t have permission to save the file “CFNetworkDownload_c5SXp9.tmp” in the folder “com.emanmomot”." UserInfo={NSURL=file:///var/mobile/Library/Caches/com.apple.nsurlsessiond/Downloads/com.emanmomot/CFNetworkDownload_c5SXp9.tmp, NSFilePath=/var/mobile/Library/Caches/com.apple.nsurlsessiond/Downloads/com.emanmomot/CFNetworkDownload_c5SXp9.tmp, NSUnderlyingError=0x281d96730 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}}}}
@aurimasc So the directory I would provide would be Application.persistentDataPath + the local relative directory I wanted to save it to. So I think on Android this worked without any sort of hitch. However when I did the same on iOS, I think the Application.persistentDataPath would include the full path which then the DestinationURI function would also prepend some of the path on to as well. My memory is a little vague now but I remember that being the crux of my problem anyway. Might not relate to this issue as obviously I originally posted a while ago.
No, the path you have to provide must be relative. If you pass "xxx/yyy.zzz", then the directory named "xxx" will be created under Application.persistentDataPath and then file will be saved in it. Note, that on iOS on different app runs the absolute path does change, so an absolute path cannot be used, after app is killed and relaunched, the destination folder is no longer accessible to your app.
So, it seems this issue was related to how I was signing the app. I guess using a dummy testing certificate prevented the app from having the permissions it needed to read & write the download files or something. When I used my company's provisioning profile & signing certificate everything worked properly.