A little bit of background: If you make an app with no compiled Arm64 binaries in the Content/MacOS folder, MacOS erroneously identifies it as an Intel based app. After launching the app, MacOS will prompt the user to install rosetta, despite the app running fine natively. I found a simple solution to this issue, either include a do-nothing compiled binary to Contents/MacOS, or add <key>LSArchitecturePriority</key> <array> <string>arm64</string> </array> to the plist. The problem is this change only fixes the issue if you also change the BundleID. If you run the app even once with the bad configuration, MacOS seems to cache the intel flag somewhere based on the BundleID. It does not seem to be cached in the usual places. How to reproduce: (On apple silicon) You probably already have rosetta, and it is a pain to remove, so a VM is likely needed. Make an empty app with Script Editor, export with file format: Application. Replace Example.app/Content/MacOS/applet with a script of the same name. Make sure the old applet is gone, don't rename it and leave it in the directory. I used: #!/usr/bin/osascript display dialog "Hello, world" Make it executable sudo chmod +x ./Example.app/Content/MacOS/applet Run the app and observe that it asks you to install rosetta Add the previously mentioned fix to you plist, including the BundleID change Run it again and observe that it now works Change your BundleID back. Running this now raises the rosetta prompt despite the fact that it runs fine on a clean install of MacOS. Things I have tried: Rebooting, no effect Reforming the app, no effect Reboot in recovery mode, no effect lsregister -delete, no effect ~/Library/Preferences, ~/Library/Caches, /Library/Preferences, and /Library/Caches, none contain an entry for the BundleId defaults delete, domain not found

According to the documentation on SecTrustSettingsSetTrustSettings "When making changes to per-user trust settings, the user is prompted with an alert panel asking for authentication (user name and password or other credentials normally used for login). Therefore, it is not possible to modify per-user trust settings when not running in a GUI environment (that is, when the user is not logged in via the login window). When making changes to system-wide trust settings, the user is prompted with an alert panel asking for an administrator’s name and password unless the calling process is running as root, in which case no further authentication is needed." And under SecTrustSettings.h it says * Trust Settings are configurable by the user; they can apply on three levels * (called domains): * * -- Per-user. * -- Locally administered, system-wide. Administrator privileges are required * to make changes to this domain. * -- System. These Trust Settings are immutable and comprise the set of trusted * root certificates supplied in Mac OS X. As we can see, kSecTrustSettingsDomainAdmin is the "system-wide" options that we should be using in SecTrustSettingsSetTrustSettings but when I run the following code, I get a GUI prompt regardless. SecKeychainRef keychain; SecKeychainCopyDomainDefault(kSecPreferencesDomainSystem, &amp;keychain); SecCertificateRef test = SecCertificateCreateWithData(NULL, certData); SecCertificateAddToKeychain(test, keychain); SecTrustSettingsSetTrustSettings(test, kSecTrustSettingsDomainAdmin, NULL); I am running the project as root via the xcode scheme.