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.

So it seems that the name of the app shown in a Mac Catalyst app comes from the "Product Name" build setting for your target. I changed that from MyCoolApp to My Cool App and I started seeing the results I wanted. I find it odd that the app display name comes from the resulting .app name and the executable name and not the "Bundle display name" from Info.plist. Maybe this will help someone else.