One more thought on this: It seems like it would be nice to have the ability to configure a UIDocumentBrowserViewController to behave like a UIDocumentPickerViewController, as far as having the option for it be presented modally, with a cancel button. Perhaps I'm misunderstanding the use cases, but these classes seem very similar, with the exception of UIDocumentPickerViewController having the limitation of not being able to create new documents (which is not actually a desirable behavior in my use case, though I can live with it). Since UIDocumentBrowserViewController is newer, I have the impression that it's mostly meant to replace UIDocumentPickerViewController for many use cases. Since we seem to be stuck with UIDocumentBrowserViewController in the new UIDocumentViewController (unless we implement it ourselves), it seems like having such capability would allow for greater adoption in apps that don't fit the mold of Pages and Swift Playground.

Please see the UITextInputTraits property, writingToolsBehavior. You can ... implement it on your custom UITextInput-conforming view OK, I was able to try this and, unfortunately, it does not achieve the desired result: the Writing Tools menu item is still present in the custom view's Edit context menu (though it does nothing when selected). I have a custom UIView subclass conforming to UITextInput, which uses UIEditMenuInteraction to provide an Edit context menu. The relevant code looks like this: @implementation ConsoleView { UIEditMenuInteraction * _editMenuInteraction; BOOL _editMenuIsVisible; ... UIWritingToolsBehavior _writingToolsBehavior API_AVAILABLE(ios(18.0), macos(15.0)); } ... @synthesize writingToolsBehavior = _writingToolsBehavior; ... - (instancetype)initWithCoder:(NSCoder *)coder { self = [super initWithCoder:coder]; if (self) { ... // disable iOS 18+ Writing Tools menu if ( @available(iOS 18, macOS 15, *) ) { _writingToolsBehavior = UIWritingToolsBehaviorNone; } ... I confirmed using the debugger that both the initialization code and the property accessor are executed, so that the property value is UIWritingToolsBehaviorNone. Yet the menu item remains. Any other ideas? I am able to use the -removeMenuForIdentifier: method, as mentioned above, to remove all other unwanted menu items from the edit context menu. It seems curious that the Writing Tools item should be handled differently.

FB13420491 is claimed to be fixed in macOS 15 WWDC developer beta 1 (24A5264n). In my testing, things seem to work OK now on this macOS build. It would be good to hear what others are seeing for their use cases.

Here's what works for me: [builder removeMenuForIdentifier:UIMenuReplace]; // includes iOS 18 `Writing Tools` Implementing the writingToolsBehavior property, either via @synthesize or hand-coded methods to always return UIWritingToolsBehaviorNone from getter and ignore setter calls, has no effect.

Problem remains in iOS 18.0 beta 2 (22A5297f). No change. I’m unable to mask all appearances of the NLE by keeping the document non-nil. it still appears in transition when opening a new document by assigning the document property. My understanding from discussion with the UIKit team is that this is a known issue that they are working on. I had hoped it would be fixed in the second beta or at least before the public beta.

Problem remains in iOS 18.0 beta 2 (22A5297f). No change. I had hoped this would be fixed in the second beta or at least before the first public beta, since it completely breaks my app.

Problem remains in iOS 18.0 beta 2 (22A5297f). No change.

@Frameworks Engineer Could you explain how UIKit presents the browser UI in front of my own custom view? Since the problem is not resolved in beta 2, I am looking for ways to work around it myself. The browser UI doesn't appear to be presented as a normal view controller. I suspected that it was added as a subview of the UIDocumentViewController's view, but that does not appear to be the case, either. I tried stopping in Xcode during a transition where the browser UI was visible and inspecting the view hierarchy in the Xcode view debugger, but this offered no clues. From what I saw there, I would expect my UI to be onscreen. Also, while trying to inspect state in the Xcode view debugger, the app managed to advance so that the browser was no longer shown on the device's screen. Perhaps this indicates what I'm seeing is some transitional animation captured in a CATransaction or something like that?

I see the same thing on macOS 15 beta 2 and I am also curious to know what can be done to fix this. References: https://developer.apple.com/documentation/uikit/uicommandtagshare?language=objc https://www.mattmoriarity.com/2019-10-18-share-menus-with-mac-catalyst/

Still occurs on iOS 18.0 beta 3 (22A5307f).

Problem remains in iOS 18 beta 4 (22A5316j). No change.

Problem remains on iOS 18 beta 4 v2 (22A5316k). No change.

Problem remains on iOS 18 beta 4 v2 (22A5316k). No change.

Confirming this is still regressed in iOS 18.0 beta 5 (22A5326f)! This is extremely concerning, as it is starting to appear that this regression is not going to be fixed.

Please file your own feedback report if you are hitting this problem (error -9,808) in the iOS 18 betas (feel free to reference FB13825638), as the more feedback received, the more likely Apple will be to fix the problem. If the appearance is that only a handful of users are affected, it will not be prioritized among the myriad of other problems that likely exist.