One more slight step forward. I have found a way to make the "Take Photo", "Scan Documents", and "Add Sketch" menus do nothing. It's still a poor user experience having the menus at all, but at least now the user doesn't get to go through all of the motions of taking a photo or scanning a document with their iOS device just to have the results ignored. I was able to make this happen by adding the following code: @objc func importFromDevice(_ sender: Any) { // no-op } override func target(forAction action: Selector, withSender sender: Any?) -> Any? { if action == #selector(importFromDevice) { return self } return super.target(forAction: action, withSender: sender) } You can add this to a custom UITextView subclass or to the view controller class containing a text view. The only issue with this code is that it results in assertion failures and big old stack traces in the console each time the menu gets validated. There's a message about: -[UINSResponderProxy validateMenuItem:]: We're being asked to validate a menu item whose proxy isn't the one we wrapped. But I've tested via TestFlight and the app continues to run just fine.

I have not found any way to remove the "Import from iPhone or iPad" menu. But I have at least found a way to prevent the ensuing image from being added as an attachment. When a user selects a menu, such as "Take Photo", and then takes a picture with their iOS device and chooses "Use Photo", the UITextViewDelegate textView(_:shouldChangeTextIn:replacementText:) delegate method is called. The replacement text will contain the character NSTextAttachment.character. So to prevent the picture from being added as an attachment to the text view, return false if you find that the replacement text contains NSTextAttachment.character. It's still a terrible user experience. The user sees the menu, goes through all of the steps to take a photo, and then nothing happens. It would be so much better if there was a way to remove the menu when not wanted.

Overdue update - The AVCam demo now runs under Mac Catalyst. Much of AVFoundation has been supported since Mac Catalyst 14.0. The AVCam demo needs a few small changes to build for Mac Catalyst. By default, the project is not setup with a Mac Catalyst destination. It only supports iPad apps running on Apple Silicon. Delete the "Mac (Designed for iPad)" destination and add the "Mac (Mac Catalyst)" destination. You may also have to change the macOS Deployment target in the Build Settings depending on the version of macOS running on your Mac. Thanks Apple for adding support for AVFoundation. Now I just need to figure out if I can support Camera Continuity under Mac Catalyst.

I recently figured out a way to remove the "Show Fonts" and "Show Colors" menus from the context menu of a UITextView. This only works on iOS 16.0/Mac Catalyst 16.0 or later. The following is my Objective-C code. Should be easy enough to translate to Swift. I started by adding new method to UIMenu: Category declaration: @interface UIMenu (Additions) - (UIMenu *)menuByRemovingChildWithAction:(SEL)action; @end Category implementation: @implementation UIMenu (Additions) - (UIMenu *)menuByRemovingChildWithAction:(SEL)action { NSArray<UIMenuElement *> *children = self.children; for (NSInteger i = 0; i < children.count; i++) { UIMenuElement *element = children[i]; if ([element isKindOfClass:[UICommand class]]) { UICommand *cmd = (UICommand *)element; if (cmd.action == action) { NSMutableArray *newChildren = [children mutableCopy]; [newChildren removeObjectAtIndex:i]; if (newChildren.count == 0) { return nil; } else { return [self menuByReplacingChildren:newChildren]; } } } else if ([element isKindOfClass:[UIMenu class]]) { UIMenu *menu = (UIMenu *)element; UIMenu *newMenu = [menu menuByRemovingChildWithAction:action]; if (newMenu == nil) { NSMutableArray *newChildren = [children mutableCopy]; [newChildren removeObjectAtIndex:i]; return [self menuByReplacingChildren:newChildren]; } else if (newMenu != menu) { NSMutableArray *newChildren = [children mutableCopy]; newChildren[i] = newMenu; return [self menuByReplacingChildren:newChildren]; } } } return self; } @end This recursively goes through a menu hierarchy and removes any menu item that is a UICommand with the given action. With that in place you need to implement the iOS 16.0 UITextViewDelegate method: - (UIMenu *)textView:(UITextView *)textView editMenuForTextInRange:(NSRange)range suggestedActions:(NSArray<UIMenuElement *> *)suggestedActions API_AVAILABLE(ios(16.0)) { UIMenu *menu = [UIMenu menuWithChildren:suggestedActions]; menu = [menu menuByRemovingChildWithAction:NSSelectorFromString(@"toggleFontPanel:")]; menu = [menu menuByRemovingChildWithAction:NSSelectorFromString(@"orderFrontColorPanel:")]; return menu; } That's it. All other attempts failed. I was able to disable the "Show Fonts" menu by overriding canPerformAction:sender: in the App Delegate. But for some reason it did nothing for the "Show Colors" menu. - (BOOL)canPerformAction:(SEL)action withSender:(id)sender { if (action == NSSelectorFromString(@"toggleFontPanel:") || action == NSSelectorFromString(@"orderFrontColorPanel:")) { return NO; } BOOL res = [super canPerformAction:action withSender:sender]; return res; }

This is asked and answered already: https://developer.apple.com/forums/thread/714388

Without you posting a symbolicated crash report it's impossible to determine the issue. One suggestion with testing though - delete your app from your real test device (or even the simulator) and do a clean build so you are testing a fresh install like the reviewer. It's not uncommon for an app to work in development over time but fail on a fresh install.

When debugging a message such as: [general] *** -[NSKeyedUnarchiver validateAllowedClass:forKey:] allowed unarchiving safe plist type ''NSNumber' (0x205da88f8) [/System/Library/Frameworks/Foundation.framework]' for key 'NS.objects', even though it was not explicitly included in the client allowed classes set: '{(     "'NSDictionary' (0x205da1178) [/System/Library/Frameworks/CoreFoundation.framework]",     "'NSString' (0x205da8948) [/System/Library/Frameworks/Foundation.framework]" )}'. This will be disallowed in the future. you want to look for a use of NSKeyedUnarchiver where you only list NSDictionary and NSString. Then you want to add NSNumber. Do not add NSObject.

Same issue but on an Intel MacBook Pro running macOS 12.6. One would have hoped that today's Xcode 14 would support all of the versions of iOS and iPadOS also released today. Oh well. I guess we all need to wait for Xcode 14.0.1 or something. Can't wait to download yet another 7+GB Xcode release on my 10Mbps Internet connection.

I was dealing with this same issue in some older Objective-C code I was trying to update. After lots of different attempts I found the following solution (Swift version): if let token = FileManager.default.ubiquityIdentityToken {     do {         let data = try NSKeyedArchiver.archivedData(withRootObject: token, requiringSecureCoding: true)         if let newToken = try NSKeyedUnarchiver.unarchivedObject(ofClass: NSData.self, from: data) {             print("We got the token")             if newToken.isEqual(token) {                 print("tokens match")             } else {                 print("tokens do not match")             }         }     } catch {         print("oops: ", error)     } } This works and it compiles cleanly. But I'm worried that passing in NSData.self could possibly fail in some future implementation if Apple changes how the token is encoded.

I have recently found that the message assigned to the NSUserNotificationsUsageDescription key is ignored on some devices and works as desired on others. In my tests it worked correctly on a device running iOS 15.5 but the generic message was shown on a device running iOS 14.8.1. My tests were with Xcode 13.4.