iOS 26.1 is released, iOS 26.2 beta appeared, but no signs that UIManagedDocument loses @MainActor. Does anybody have the same concern? Anybody uses UIManagedDocument and wants to transition to Swift 6? Or, perhaps, already use it?

Thank you! I'll definitely send an improvement suggestion.

The thing with foo attribute is done on purpose to make a direct lightweight migration from V1 to V3 impossible. At the same time, it's possible to migrate using the intermediate V2.

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.

Bug report: FB17081839.

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.

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

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.

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. :)

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.

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.

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