My workaround it to check if the font is available and load it manually if required: if ( ! [UIFont fontWithName:@"GO" size:24] ) { // probably maccatalyst bug, load GO-Regular manually NSString *filePath = [bundle pathForResource:@"GO-Regular" ofType:@"ttf"]; NSURL *fonturl = [NSURL fileURLWithPath:filePath]; CGDataProviderRef fontDataProvider = CGDataProviderCreateWithURL((__bridge CFURLRef)fonturl); CGFontRef newFont = CGFontCreateWithDataProvider(fontDataProvider); CGDataProviderRelease(fontDataProvider); CFErrorRef fonterror; BOOL didRegisterGORegular = CTFontManagerRegisterGraphicsFont(newFont, &fonterror); if ( ! didRegisterGORegular ) { NSLog(@"FONTERR=%@",fonterror ); } CGFontRelease(newFont); } // ifend custom install GO-Regular font

I do not spend as much time finding obscure bugs as I did on this issue. In hindsight, this is probably the solution: (cd ~/Library/MobileDevice/Provisioning\ Profiles/; rm *)Really short story before my brain glazes over:This was an iPad app that I had checked the Mac box, and after the proper machinations there were two distinct Apps in Connect, and the Xcode project had co-mingled build settings and a new Mac target. You all know the drill. 2/3 sister Apps continue to work in that mode, although I wonder for how long?I grep-ed through Provisioning\ Profiles and removed those which seemed relevant, no luck.I grep-ed through Xcode project files and didn’t see anything to filemod!I tried “joining” the Apps, which required I remove the MacCat app from sale. Bad move, now I have one instance of the App, of which only the iOS half is usable.I found this SO page, https://stackoverflow.com/questions/60611420/error-itms-90283-with-invalid-com-apple-application-identifier-entitlement-va, which describes the *exact* same problem, so taking hints from that …I turned off automatically generated MacCat bundle ID and made a new one, created a new App ID with that bundle name, manually provisioned that new App, and … still no luck.… lots of other stuff … fail.Finally I went berserk: (cd ~/Library/MobileDevice/Provisioning\ Profiles/; rm *)Then everything worked. So I’m guessing I wasted a lot of time, profiles, App Ids and sleep.At least that the gist of what went down, the details are no doubt only fuzzily correct.

Per Apple's docs I ran these commands on the current App's archive bundle and the previous (which uploaded to the Store 10 weeks ago):codesign -d --entitlements :- XYZZY.app/security cms -D -i XYZZY.app/Contents/embedded.provisionprofileand diff-ed the output, other than date/time, version number there are no differences. (OK, I did add the com.apple.security.files.user-selected.read-write entitlement, but the App's sister App also had this added entitlement and it verifies and has uploaded OK).In particular, the application-identifier and associated-application-identifier (whatever that is!) are unchanged. Any suggestions on how to proceed?Thanks,

Well, on second thought your code fails because variable configBundle is NIL.

Thanks for your time. I suppose one Gatekeepr OK is not bad, compared to what happens when I do not sign items. Also thanks for your tip from another thread to use a pristine macOS virtual machine that is revertible when testing this stuff.

Message gone with Xcode 11.4 / iOS 13.4

I think my situation is similar but am not sure I understand possible solutions. I do not have an App proper but a folder to distribute. Essentially, it contains bin and lib folders, with a shell script (with a .command extension) for the user to double-click and run the program in bin. In the bin folder I’ve placed a static build of an ancient FORTRAN program and, because of the deprecation of script languages, Perl5, it too built statically. The perl wrapper does all the pre- and post-execution file manipulations.I codesign perl, its library modules, and the FORTRAN executable. I codesign the .command file as well. I package the entire folder as a DMG, code sign that, then notarize the signed DMG.When I download the DMG and open it, double-click the .command icon, it fails to open because Apple cannot check it for malicious software. If I open a Terminal window and “open” the command file the same thing happens.. But if I run it directly like ./commandFile the program runs. I am hoping to spare a Mac user that unfamiliar chore.You mention there are "various techniques that let you package a shell script as a tool, and thus move from B to C." Would you give an executive summary of those methods?Thank you.

I get my Dev ID Installer from Keychain Access in the Certificates section: Developer ID Installer: Your Name (123456). Use the string "Your Name (123456)".Generate the App Specific PW here: https://support.apple.com/en-us/HT204397You have to run stapler againsts every item in the archive, then recerate the archive. For me, there's only one item the saver module.

Adding to the prior excellent advice, here's additional info on notarization:You can’t notarize the .saver directly, but you can in a round-about-way notarize a ZIP file, which is how I distribute my screen saver. Here are the steps I use for my simple saver, your mileage will undoubtably vary:/usr/bin/codesign -f -o runtime --timestamp --sign “insert Developer ID Installer certificate identifier here” XYZZY.savercompress the code signed .saver e.g. XYZZY.saver.zip/usr/bin/xcrun altool --verbose --notarize-app --primary-bundle-id “insert identifier here" -u “xyzzy@plugh.com" -p “insert app-specific PW for your Apple ID here" -t osx -f XYZZY.saver.zipAside: store the App-specific password in your keychain and reference it from the command line like this:/usr/bin/xcrun altool --store-password-in-keychain-item "AC_PASSWORD" -u xyzzy@plugh.com -p “insert App-specific PW from Apple here”wait for notarization, check status like this:/usr/bin/xcrun altool --notarization-history 0 -u “xyzzy@plugh.com" -p "@keychain:AC_PASSWORD”While you can notarize a ZIP archive, you can’t staple the notarization ticket to it directly. Instead, run stapler against each individual item that you originally added to the archive. Then create a new ZIP file containing the stapled items for distribution. /usr/bin/xcrun stapler staple XYZZY.saverRe-zip the saver and distribute

Reply to self with what I’ve done for Catalina:You can’t notarize the .saver directly, but you can in a round-about-way notarize a ZIP file, which is how I distribute my screen saver. Here are the steps I use for my simple saver, your mileage will undoubtably vary:/usr/bin/codesign -f -o runtime --timestamp --sign “insert Developer ID Installer certificate identifier here” XYZZY.savercompress the code signed .saver e.g. XYZZY.saver.zip/usr/bin/xcrun altool --verbose --notarize-app --primary-bundle-id “insert identifier here" -u “xyzzy@plugh.com" -p “insert app-specific PW for your Apple ID here" -t osx -f XYZZY.saver.zipAside: store the App-specific password in your keychain and reference it from the command line like this:/usr/bin/xcrun altool --store-password-in-keychain-item "AC_PASSWORD" -u xyzzy@plugh.com -p “insert App-specific PW from Apple here”wait for notarization, check status like this:/usr/bin/xcrun altool --notarization-history 0 -u “xyzzy@plugh.com" -p "@keychain:AC_PASSWORD”While you can notarize a ZIP archive, you can’t staple the notarization ticket to it directly. Instead, run stapler against each individual item that you originally added to the archive. Then create a new ZIP file containing the stapled items for distribution. /usr/bin/xcrun stapler staple XYZZY.saverRe-zip the saver and distribute

Suggest a few NSLogs and error checks, which may help, although at first glance all looks reasonable. Here is what my code looks like:- (NSWindow*)configureSheet { if ( ! self.configSheet) { if ( ! [[NSBundle bundleForClass:[self class]] loadNibNamed:@"ConfigureSheet" owner:self topLevelObjects:nil] ) { NSLog( @"Failed to load configure sheet." ); NSBeep(); } } ... return self.configSheet; }

In Pricing and Availability:1) remove App from sale2) Save3) make it available for sale once again4) saveA new App review is not required.Over the years I've had to do this 3 times, it always works.

Reply to self with solution. This iPad app dates from day zero, hence the App Delegate declaration generated by Xcode way back then looks like this:@interface BlahAppDelegate : NSObject <UIApplicationDelegate, UIMenuBuilder>Looking at the Swift sample code I noted this:class AppDelegate: UIResponder, UIApplicationDelegate, UISplitViewControllerDelegateI don't know Swift, but it looked to me like there was a difference in the superclass: old = NSObject, new = UIResponder. After making my App Delegate a subclass of UIResponder buildMenuWithBuilder is now invoked.