-
Notifications
You must be signed in to change notification settings - Fork 507
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Files shared for "open in place" editing with third-party apps do not work correctly in iOS17 #19352
Comments
I have been experiencing the same issue on Word with .docx documents they seem to only open in Read-Only mode. with ios17. I have been looking for a solution for some time now and cant seem to find what could be causing this. |
My guess would be that this is an intentional change by Apple, but only they can confirm. Apple's documentation also isn't 100% clear that your code is supposed to work (the documentation for LSSupportsOpeningDocumentsInPlace seems to imply it's only for file provider (extension?)s, the fact that it worked for apps might not have been Apple's intention). I would start diagnosing this by trying to replicate the problem in an Xcode project (which would rule out any problems in our bindings). If the Xcode project works, please attach both the Xcode project and the Xamarin/.NET project here, reopen the issue, and we'll investigate to try to figure out what we're doing wrong. If the Xcode project doesn't work, then I'd post a question on Apple's Developer Forums. I'm closing this for now since it does not look like a bug on our side (as I said, feel free to reopen if you determine otherwise). |
Just a quick follow-up. We posted a corresponding question in the Apple Developer Forum as suggested. No answers at time of writing, but one more "that's happening to me too" response. We also submitted a formal TSI (Technical Support Incident) to Apple Developer Technical Support, but the response was, in short:
We agree with Rolf's advice that the next best step is to recreate this natively in an XCode project. Unfortunately we don't have the resourcing available to do this at the moment, so for now we'll keep our ear to the ground to see if a solution naturally emerges; perhaps eventually someone very important will have the same problem and Apple will jump on it. Thank you for your responses to date. |
Also, just in regards to this:
I may be wrong, but my reading of the File Provider documentation is that with the flags we set and to simply provide access to our files, we wouldn't need to implement a File Provider extension:
|
I came across the same problem. @Eagle104 and @gavinschultz. Did you make any progress on this problem? I'm stuck. |
@MartinWegner No further progress yet - sorry. We are using the workaround of making the users share the file back from the third-party application to our application and re-saving it. It's not ideal to have the users perform that extra step, but the best we have for now. As a starting point, we do this by overriding
|
@gavinschultz Thank you for sharing the workaround. We have the same function in place and it works for now. But we struggle with the fact, that our initial opening of the file is read only. This isn't the case in iOS 16. |
@MartinWegner I feel your pain but, like you, I too would guess that Collabora is probably not doing enough in this case. It makes some intuitive sense that, without open-in-place working properly, the file being shared wouldn't be initially writeable to other apps unless they make the local copy themselves. We've been fortunate in our own case that we haven't had to deal with that problem, as the third-party PDF apps we typically suggest (PDF Viewer and Xodo) do behave more like what you describe for Microsoft Office. Sorry I can't be of more help! |
Steps to Reproduce
Our app has PDFs which we allow third-party PDF apps to "open in place" for editing. The mechanism works basically like this:
Info.plist
has all the necessary flags for opening a document, namelyUIFileSharingEnabled
andLSSupportsOpeningDocumentsInPlace
, both set to true/YES.Environment.SpecialFolder.MyDocuments
); resolving ultimately to, for example:/var/mobile/Containers/Data/Application/788C7161-32EB-4AF0-964D-2A473257A791/Documents/7cafe7e7-9da9-40cd-b233-a85b0174fe00/624cbc1e-a7c5-4c0d-8937-b0a00013b2a9.pdf
.UIDocumentInteractionController.PresentOpenInMenu
, allow the user to open the PDF for editing in a third-party app:The absolute URL generated at this point is a simple variation of the original e.g.
file:///var/mobile/Containers/Data/Application/788C7161-32EB-4AF0-964D-2A473257A791/Documents/7cafe7e7-9da9-40cd-b233-a85b0174fe00/624cbc1e-a7c5-4c0d-8937-b0a00013b2a9.pdf
Expected Behavior
The original PDF files in our app's Documents directory can be opened in third-party PDF applications, and saved without any additional work from the user.
Actual Behavior
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:
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: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 I have not been able to find primary sources or much specific detail. For example:
I have not been able to figure out if this is a flaw in our code, or iOS 17, or Xamarin's implementation of the API. Note that we are fairly sure this is not due to specific flaws in the third-party apps, as all of the ones we have tried (PDF Viewer, Xodo etc) exhibit basically the same behavior.
Environment
Version information
Build Logs
N/A, build works fine
Example Project (If Possible)
None
The text was updated successfully, but these errors were encountered: