Hello,
We have an iOS app which stores PDF files locally and allows them to be opened in place for editing by third-party apps (e.g. PDF Viewer / Xodo). We have found that the technique we were using to do this is not working as expected in iOS 17, where it does in all previous iOS versions.
As per the File Provider documentation,:
- we are storing files locally, so presume we do not need to have a File Provider extension
- we set to true/YES both
UIFileSharingEnabledandLSSupportsOpeningDocumentsInPlace - we generate an NSUrl and, via UIDocumentInteractionController presentOpenInMenu, allow the user to open the PDF in an external app
On iOS 16 and lower, it works as expected; the third-party app is able to read and automatically save changes to the PDF directly in our app's folder path. For example, the Xodo logs indicate that it's opening directly from our app's path (788C7161-32EB-4AF0-964D-2A473257A791 is our application's ID):
Xodo initialized document instance: <PTCoordinatedDocument: 0x282453a00> fileURL: file:///private/var/mobile/Containers/Data/Application/788C7161-32EB-4AF0-964D-2A473257A791/Documents/7cafe7e7-9da9-40cd-b233-a85b0174fe00/624cbc1e-a7c5-4c0d-8937-b0a00013b2a9.pdf
Xodo opening document: <PTCoordinatedDocument: 0x282453a00> fileURL: file:///private/var/mobile/Containers/Data/Application/788C7161-32EB-4AF0-964D-2A473257A791/Documents/7cafe7e7-9da9-40cd-b233-a85b0174fe00/624cbc1e-a7c5-4c0d-8937-b0a00013b2a9.pdf
On iOS 17, this no longer works correctly, and although the third-party PDF editor can read our PDF, it's quite clear that it's actually using a copy. If not quite identical to what happens when LSSupportsOpeningDocumentsInPlace is false/NO, the end result is very similar (6830EDC5-F776-4BEF-8C30-046BCA1F2DF0 is Xodo's application ID):
Xodo initialized document instance: <PTCoordinatedDocument: 0x2828aae00> fileURL: file:///var/mobile/Containers/Data/Application/6830EDC5-F776-4BEF-8C30-046BCA1F2DF0/Documents/Processed%20Files/624cbc1e-a7c5-4c0d-8937-b0a00013b2a9.pdf
Xodo opening document: <PTCoordinatedDocument: 0x2828aae00> fileURL: file:///var/mobile/Containers/Data/Application/6830EDC5-F776-4BEF-8C30-046BCA1F2DF0/Documents/Processed%20Files/624cbc1e-a7c5-4c0d-8937-b0a00013b2a9.pdf
The third-party app will immediately prompt the user to save the file, but regardless, the copy is now beyond the purview of our app so we can no longer see any changes made to it.
The only workaround is to have the user explicitly share the file from the third-party app back to our app (we have the code in place to handle this), but much preferred the seamless "open-in-place" integration which did not require this.
There have been vague allusions to changes in the file system in iOS 17, but we have not been able to find primary sources or much specific detail. For example:
Are there specific changes in iOS 17 that invalidate our strategy? Are there any other things we may be missing that are needed to make this work?
Note, for further reference, this issue is described in Xamarin terms here.. Although, yes, we are Xamarin developers so do not have native code to show, we (and, based on the comments, the Xamarin devs) suspect that this is most likely due to a change in iOS rather than in Xamarin.