In a macOS 27 app using DocumentGroup(editor:makeDocument:) with a type conforming to the new Document protocol, choosing File › Duplicate hangs the app permanently (0% CPU, spinning beach ball, must force quit).
The main thread is blocked in URLPlatformDocument.read(from:ofType:) waiting on a dispatch semaphore. That synchronous NSDocument read path is reached from NSDocumentController.duplicateDocumentWithContentsOfURL(:copying:displayName:) → makeDocumentForURL(:withContentsOf:ofType:) → NSDocument.init(for:withContentsOf:ofType:). The work the semaphore waits for never runs: the app's makeDocument closure is never called. The SDK declares makeDocument and ReadableDocument.apply(snapshot:previous:) as @MainActor, so blocking the main thread while waiting for them can never complete.
This reproduces with Apple's unmodified sample code project "Building a Document-Based App with SwiftUI" (no code or project changes; only a signing team set). Our own app, which uses a custom DocumentReader/DocumentWriter with Source/Destination == URL, hangs with the identical stack.
Has anyone found any workaround?
Filed Feedback FB24949862
Thanks for the clear report, and for filing FB24949862. I can reproduce this with the unmodified []"Building a document-based app with SwiftUI" sample](https://developer.apple.com/documentation/swiftui/building-a-document-based-app-with-swiftui), built with Xcode 27.0 and run on macOS 27.0.1. After saving a document, File > Duplicate hangs, and the main thread is waiting in URLPlatformDocument.read(from:ofType:) under duplicateDocumentWithContentsOfURL(_:copying:displayName:), as you describe.
