Correction.... When MULTIPLE "Products" are opened in their ImageScenes, from the main scene using the long press + "Open in New Window", then dismissed using the close button "x", ImageScenes are not deleted - rather it seems that they either swapped, or deleted and immediately restored.

Nice one. Thank you! It looks as if ".browser", ".automatic", ".navigationStack" each eliminate the extra (left hand) back button nicely. Choosing ".editor" is the odd-ball. I've not made sense of the documentation on this - but - for now I'll run with .automatic. Thanks again.

I've now reported this in bug report FB15567398.

No response on filing FB15567398 - and two months on and the bug remains. It would be great to get some feedback and an indication that something will be done to make DocumentGroup do what it says on the tin. This is blocking me from going fully SwiftUI for an App - so I am stuck with Frankenstein mode for a while longer.

This sounds promising - hopefully both will be GA in the next couple of weeks. I recently noticed that - as of Xcode 16.3 and iOS 18.4 - when using DocumentLaunchScene with DocumentGroup, the document name in the navigation bar INCORRECTLY adopts the name of the first file opened after starting the App for ALL subsequent files opened. This occurs with or without wrapping the contentView in with NavigationStack{ ContentView(...) } All works fine on macOS because I remove DocumentGroupLaunchScene with #if os(macOS) #endif. The entire scenario can be repeated easily using Apple's "Building a document-based app with SwiftUI" sample code. Tra la la.

The Apple "WritingApp" download provided in "Building a document-based app with SwiftUI" is a clear demonstration of this - and yes it is problematic if you use .alert() on StoryView(). Alerts are presented and immediately dismissed with the log / error message indicating an attempt to present an alert when already presenting. Run the same App on macOS and there is only one DocumentHostingController, and no problem with .alert

Correction: my alerts problem had a different cause. However. the Apple WritingApp sample is still a good example of the scenario described by randomdev.

Further correction - iOS 13.0-15.8 style alerts: .alert(isPresented: $showAlert) { Alert(title: Text("App Alert"), message: Text(alertMessage)) } work fine. iOS 15.0 onwards style alerts: .alert( "Alert title", isPresented: $showAlert, actions: { }, message: { Text(alertMessage) }) appear then disappear with the following log message: Attempt to present <SwiftUI.PlatformAlertController: 0x121019400> on <SwiftUI.UIKitNavigationController: 0x105836a00> (from <TtGC7SwiftUI32NavigationStackHostingControllerVS_7AnyView: 0x10383be00>) which is already presenting <SwiftUI.PlatformAlertController: 0x106809800>. I hope this helps.

This appears fixed as of iOS 18.5. The NavigationStack {} fix is no longer needed to solve duplication of toolbar items. The duplicate DocumentHostingController has gone Alerts are working as expected. Test environment is Apple's WritingApp sample code built with Xcode 16.3 on macOS 15.5 and running live on an iOS 18.5 iPad Pro. Will test again as soon as Xcode 16.4 is available with an 18.5 simulator. Thank you!!

These problems appear solved on iOS 18.5 GA. Building with Xcode 16.3 on macOS 15.5 GA and running live on iOS 18.5 GA: No more duplication of toolbar items( the NavigationStack wrapper workaround is no longer needed) The Toolbar now correctly adopts name of the file you open each time Of course I'll be retesting as soon as Xcode 16.4 is available with an iOS 18.5 simulator. This is a huge relief as these problems started with iOS 18.0 and have been blocking me from adopting DocumentLaunchScene and converting 100% to SwiftUI. I've not used the "prepare document closure" so cannot comment - sorry.