Recently, I've received feedback via the bug report and been suggested to register an undo.
Turnout, the update of ReferenceFileDocument can be triggered, just like UIDocument, by registering an undo action. The difference is that the DocumentGroup explicitly setup the UndoManager via the Environment.
For example,
@main
struct RefDocApp: App {
		var body: some Scene {
				DocumentGroup(newDocument: {
						RefDocDocument()
				}) { file in
						ContentView(document: file.document)
				}
		}
}
struct ContentView: View {
		@Environment(\.undoManager) var undoManager
		
		@ObservedObject var document: RefDocDocument
		var body: some View {
				TextEditor(text: Binding(get: {
						document.text
				}, set: {
						document.text = $0
						undoManager?.registerUndo(withTarget: document, handler: {
								print($0, "undo")
						})
				}))
		}
}
FrankZR
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Post
Replies
Boosts
Views
Activity
It's probably caused by a bug in the ?DocumentUI?
iOS & iPadOS 14 Beta 5 Release Notes
https://developer.apple.com/documentation/ios-ipados-release-notes/ios-ipados-14-beta-release-notes
SwiftUI Known Issues Document-based apps are unable to create new untitled documents in the app document browser. (66936677) Workaround: Open an existing document, or create a new untitled document outside the app.
I've just rollback to beta 4 anyway.
Please support this feature, otherwise we won't be able to use the SwiftUI's FileDocument in a production app!!!
I'm also struggling with the issue.
I used to use the environment variable presentationMode. However, it is not working, at least for the moment.
As a result, I've refactored all my old code to use a isPresented binding to control the view dismiss behavior for workaround.
Maybe it is intended or maybe its a bug?
I've just found a temporary workaround.
Wrap your views in an additional NavigationView so that you get standard behaviors.
Then hide the DocumentGroup's navigation bar.
DocumentGroup(newDocument: SomeDocument()) { file in
NavigationView {
ContentView(document: file.$document)
ContentView(document: file.$document)
}
.navigationViewStyle(DoubleColumnNavigationViewStyle())
.navigationBarHidden(true)
You will then need to manually add a back button ofc, i.e. from your view back to the document selection view.
The importance of navigationTitle(View) api is that, without it we lost the ability to customize the navigation bar. We are therefore limited to only string in the title bar. Even Text(Image(systemName:)) is unsupported!
I can understand the reason only allow string in the title bar, that to work with macOS.
However, we should not give up the ability to use customize view in the navigation bar title area for iOS and iPadOS.
It is much better to simply allow customized view in iOS and ipadOS. And for those unsupported like macOS, fallback to pure string.
If in case navigationTitle(View) is dropped, then in most production app, developers will have to workaround the problem by giving up the built-in NavigationBar by always setting it to hidden. Then manually implement their own version of navigation bar.
@OOPer,
The referred doc of yours is SceneKit instead of SwiftUI.
In SwiftUI, for example,
https://developer.apple.com/documentation/swiftui/hstack/navigationtitle(_:)-4urrw
https://developer.apple.com/documentation/swiftui/zstack/navigationtitle(_:)-9668j
etc. etc.
Availability
iOS 14.0+ Beta
macOS 11.0+ Beta
Mac Catalyst 14.0+ Beta
tvOS 14.0+ Beta
watchOS 7.0+ Beta
Framework
SwiftUI