Most users of my app should be creating new documents in my app by importing existing files from an open-source file format through a conversion process into my proprietary format. While they could create files new from scratch in my app, that will cost $4M, and my customers are funded by donations. My app can read the open-source file format, but not write to it because it can't represent some of the information my customers need. I can also open read / write my own proprietary format. With my UIDocumentBrowserViewController-based MacCatalyst app it was possible to do an "import" from the open-source format, I would auto-run the conversion process, and the user could then immediately "save" the newly created file. Unfortunately, UIDocumentBrowserViewController has never worked correctly in MacCatalyst, and the Apple engineers know it and won't fix it. (I've demoed the problem to DTS 2 years ago, they had a bug fix in beta versions of macOS 12 which I'd been waiting for for 2 years, and I spent a month nights and weekends building my app to get it ready for release, but Apple removed the bug fix shortly before final release.) Users just think my app is broken.
SwiftUI DocumentGroups with MacCatalyst don't seem to have the ui document browser bugs, so I'd like to re-write the top-level of the app with SwiftUI document groups. But how do I get the doc opened in the new format after export? I can't replace or delete the original open-source files, they have to remain unaltered in place.
Help?!
Also, one more thing. Because the open-source file format doesn't actually contain all the information my app needs (which is why I need the proprietary format in the first place), for 2/3 of the files files I'll need to get a second file in yet a second open-source file format and combine the data with the first open-source file in my initial conversion process to write out my proprietary file. This turns the $4M content-conversion problem into a $4k problem. This second file is optional for the user to pick, so I'll want to be able to proceed if they skip it. It took months to figure out how to get one .fileImporter to get used twice with different allowed file formats. (because you can't have 2 fileImporters......????.....) and now also I don't know how I'd capture that cancellation on the second import and proceed any way with the export. since the cancellation seems to just go into the ether.
Workarounds I don't want you to offer me: Re-write everything in AppKit I don't want to write an AppKit version of my app, because of how text fields and scroll views work inside collection cells with drag & drop. UIKit makes it "just work". AppKit makes the UX a finicky nightmare people can take months to figure out how to use, and then feel frustrated with how hard it is once they do figure it out. And the issue goes all the way down into how events are assigned to views by the os.
Be iPad-only Yes, my uidocumentbrowserviewcontroller code works perfectly well on iPads, and always has. I don't want to be iPad-only. Yes, I see iPads as better experiences for editing and content creation than a Mac, especially with an Apple Pencil with my painstakingly-crafted UIKit WYSWIG GUI editor. But for now, most of my customers have these files on Macs not iPads and they're probably not tech savvy enough to figure out how to move a complex file / folder structure of categorized files over from one to the other, so we work with what we got.
Create a new document before beginning the import process What if users "open with..." one of the open-source files and pick my app? What if the file they pick to open in the doc browser is in the other format? I can't display the contents of the open-source file without first converting it into my format.