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.

Seems that the problem is fixed but partially. Now the issue only appears if UICollectionView.allowsMultipleSelection is true.

I have the same problem. In may case, in the Monetization -> Pricing and Availability -> App Availability section for the app all of a sudden I started to have 2 countries in the Processing state. If your account is in the 'Processing' country then you can view the app in TestFlight but can't install it. I contacted developer support, they redirected me to App Store Notices but no replies from them so far.

Bug report: FB17081839.

Turned out that this is Xcode 16.3 which does it correctly. According to the Expression Macros design, macro parameters should be type-checked, so the macro implementation doesn't receive incorrect code as input. Thus Xcode <=16.2 erroneously allowed the wrong expression to be passed into my macro implementation, and this is fixed in Xcode 16.3.