I documented the problems their app was causing, sent the documentation to the offending app. They promised to fix it in their next update. In the mean time, I have deleted their app off my machine and the bugs caused by their incorrect UTI declarations are gone. This doesn't answer the question of how to correct the mdls entry, but it is a workaround.

The bugs preventing UIDocument-based UIScene-based MacCatalyst apps from working properly have been fixed in the macOS 12 betas a few weeks ago. Still don't work right in macOS 11.6.

This is fixed in macOS 11. (tested in 11.5.1)

I've had good luck providing a Formatter which just passes through its string value, in which you can override methods like func isPartialStringValid(_ partialStringPtr: AutoreleasingUnsafeMutablePointer<NSString>, proposedSelectedRange proposedSelRangePtr: NSRangePointer?, originalString origString: String, originalSelectedRange origSelRange: NSRange, errorDescription error: AutoreleasingUnsafeMutablePointer<NSString?>?) -> Bool and do whatever you want with the user's entered string, change it, move the selection, etc...

You'll have to be more precise about the context in which you're placing this code. For instance addChild(_:) is a method on a UIViewController, and not on a UIView. But frame is a property on a UIView, not a UIViewController. So I don't know where you're getting the frame from on the right hand side of the = operator on line 4. If it's the parent view controller's view frame, then... frame is the view's position in its super view's coordinate system, whereas bounds is its position in its own coordinate system. So depending on frame, maybe you're covering it up? But if you're trying to add the hosting controller onto the navigation stack, then you should be using pushViewController(_:_:) not addChild(_:). And then, if you have navigationBarHidden(_:) (which we don't know is not the case from the code you posted) in your swiftUI view, who knows, maybe the hosting controller is setting that property correctly, too? And if your swift view has a navigation view in it, I don't even know how much more could go wrong. But we can't see that from your example. If you have a particular bug in particular code, please construct a minimal example that still causes the bug, and post that, and then we can tell for sure.

Removing all debug print() statements from scene/document code seems to have fixed the watchdog timer issues.

Doh! I used to remember that setting existed, probably 11 months ago when I first started investigating why this was failing. Changed that and I got the sessions coming back. Still no idea why the doc browser gives a posix error 22 "invalid argument" when I try to ".revealDocument(at:" the url of the doc during my restoration. Can I open the document anyway?

Filed a DTS incident... It turns out that the os does not correctly handle typing command-q, whereas it does "correctly" handle using the mouse to select quit from the application menu. How does it not handle that correctly? The sandbox does not know that the file is still 'ok' to be written to. So writing out contents to autosave works, but when UIDocument goes to replace the original file with the version it wrote to the temp dir, it gets a sandbox error. This bug is still in macOS 11.2.2. I know, I know, isn't it just a UIKeyCommand? Well, it is, but actually it's hacked somehow, because the quit command selector is terminate:, which is not a documented selector in UIKit. And if you try to make your own, it just crashes. And using a Mac obj-c plug-in to access appkit to call terminate: on the nsapplication instance doesn't do any of the things the uiscenes need done. BUT, when I click the menu command for quit instead of the shortcut, it goes ahead and proactively discards my scene sessions, thus meaning there's never going to be a scene to restore when the app launches again. Which, I think is definitely not the expectation, but it's better than opening blank windows and never giving me a session to restore. A year and a half of my life.... a year and a half. That's how long I've been re-writing apps to UIKit so I could more easily and more rapidly release apps than using AppKit. And the OS literally just never worked.

It appears the system is throwing the sessions away because the watch dog timer killed the app. After 5 seconds after hitting command-q, I see this in the console. [Lifecycle] Watchdog: App took too long to enter the background-only state. Exiting immediately! (5.0s) [Lifecycle] Watchdog timeout. Exiting immediately. (App took too long to enter the background-only state.) [Assert] App took too long to enter the background-only state. When I pull up the Console console, I get a serious of incomprehensible excuses for not saving the document. UIDocument unrecoverable error with description: You don’t have permission to save the file “Untitled.txt” in the folder “Documents”. reason: You don’t have permission. Failed to recover from error with description: You don’t have permission to save the file “Untitled.txt” in the folder “Documents”. reason: You don’t have permission. Why not? I opened it? I have read/write permissions in the entitlements. Sandbox: MyAppName(5631) deny(1) file-read-data /Users/myusername/Documents/mydocument.txt Why? If I close the doc by dismissing the view controller and calling .close directly, it saves successfully. So how did I lose permissions to save my work just because I'm quitting the app? Seems like a major major major design flaw in the OS.