Using Xcode 14 beta 5, I have the same error when using UIDocumentBrowserController in the iOS 16 simulator. I don't have a device with iOS 16, so I'm not sure if it's just a simulator issue. I only get this error with certain simulators, like iPhone. None of my iPad simulators have this issue.

In iOS 16, you can use the presentationDetents modifier. ScreenView() .presentationDetents([.medium]) There are variations other than medium. See the documentation.

I've submitted a bug report about this as well.

You need access to the internal UndoManager that TextEditor uses. Then you can use it to configure your undo button and to call undo()/redo() on, BUT I don't know of a way to get to that UndoManger. You can however, create your own UIViewRepresentable that wraps a UITextView and then get access to the internal undo manager that UITextView uses. Here’s how I did that: Declare a binding in your UITextView:UIViewRepresentable to an UndoManager. Your UIViewRepresentable will set that binding to the UndoManager provided by the UITextView. Then your parent View has access to the internal UndoManager. struct MyTextView: UIViewRepresentable { /// The underlying UITextView. This is a binding so that a parent view can access it. You do not assign this value. It is created automatically. @Binding var undoManager: UndoManager? func makeUIView(context: Context) -> UITextView { let uiTextView = UITextView() // Expose the UndoManager to the caller. This is performed asynchronously to avoid modifying the view at an inappropriate time. DispatchQueue.main.async { undoManager = uiTextView.undoManager } return uiTextView } func updateUIView(_ uiView: UITextView, context: Context) { } } struct ContentView: View { /// The underlying UndoManager. Even though it looks like we are creating one here, ultimately, MyTextView will set it to its internal UndoManager. @State private var undoManager: UndoManager? = UndoManager() var body: some View { NavigationView { MyTextView(undoManager: $undoManager) .toolbar { ToolbarItem { Button { undoManager?.undo() } label: { Image(systemName: "arrow.uturn.left.circle") } } } } } }

I’m using Xcode 12.4 and ran into this same issue. My document is a ReferenceFileDocument (don't know if that influences this bug). My app initially presented an editor screen via a sheet. Closing the sheet and then backing out to the document browser would trigger an immediate save. Then I switched the editor view to be displayed via a NavigationLink. Then, as you report, the save would only be triggered after 15 seconds. I have decided to switch back to using a sheet to present my editor. Regarding the 15 seconds, that’s the normal delay that triggers a save after making an edit. Normally that’s OK while you are still editing a document. But yeah, the minute you close the document, it should trigger a save.

You might need to wrap your FontPicker in a nav view         NavigationView {             FontPicker(fontName: $newFontName)         }         .navigationViewStyle(StackNavigationViewStyle())

Use Menu in a ToolBarItem. swiftwithmajid.com/2020/08/05/menus-in-swiftui

LazyHStack might help if your view is inside a scroll view

This is NOT fixed in Xcode 12 GM

If you just need to know when the text changes, this works for TextEditor, so I assume will work on TextField: TextEditor(text: $text)     .onChange(of: text, perform: { newValue in         print(newValue)     })

There is no substitution for testing on a real device, especially if you have timing-sensitive code. Over the years, the simulator has had bugs that aren’t present on devices, and vice versa. Use it as a convenience, but not as an indicator of real world performance. “use the simulator to tune code performance’ simply isn’t practical.

Firstly, make sure you don’t have "Slow Animations" turned on under the Debug menu in simulator. Secondly, I don’t think you should expect performance to be accurate. It’s simply a simulator.

I’ve asked this as well - https://developer.apple.com/forums/thread/655113 I also submitted a feature request to Apple but have received no feedback from them.

Working again in Xcode 12 beta 5

You might need to fallback to using the old UIKit App Delegate life cycle type instead of the newer DocumentGroup. With the old pattern, you are totally responsible for presenting the document view after the user selects a document. That gives you more control. With DocumentGroup, you only provide your content which DocumentGroup then embeds in it’s own view hierarchy. I have found that DocumentGroup doesn’t provide all the flexibility that was previously available. I’m hoping it will in the future, but for now, I’m avoiding it.