Mention of this build setting should be in the Xcode documentation.

It turns out that the problem occurs when you have UIManagedDocument.revert() and external coordinated writing synchronized. What's more—the hanging occurs on macOS also. I simplified test to just call revert() and coordinate(writingItemAt:). If you run exactly the same test on UIDocument, everything works fine. I'm pretty sure that this is a bug in UIManagedDocument. As of now, I incline to override revert() in order to skip super's implementation of this method, because it's UIManagedDocument and, by logic, we can work with managedObjectContext.

Confirm this for the main menu. uncached works only for context menus. Perhaps, the main menu (because of its persistence) needs to be rebuilt in order the closure ofUIDeferredMenuElement be called again. Dynamic menu item for the main menu can be achieved through UIResponder.validate(_:). Also, you can call UIMenuSystem.main.setNeedsRebuild() to update all menu items.

Reasons for my post. Could you, colleagues, confirm that this is a bug but not incorrect setup of mine? If it's a bug then to bring attention of Apple engineers to the problem. :)

According to the step 2 of the doc you need to save the new document to a temporary location first. Try something like this: if let newDocumentURL = newDocumentURL, let appropritateURL = try? FileManager.default.url(for: .cachesDirectory, in: .userDomainMask, appropriateFor: nil, create: false), let newDocumentTempURL = try? FileManager.default.url(for: .itemReplacementDirectory, in: .userDomainMask, appropriateFor: appropritateURL, create: true).appendingPathComponent(newDocumentURL.lastPathComponent) { try! FileManager.default.copyItem(at: newDocumentURL, to: newDocumentTempURL) importHandler(newDocumentTempURL, .copy) } Btw, the doc's sample project also stopped to work for it creates a new document the same way. But with the above changes it starts to work.