Updated SMJobBlessUtil-python3.py with workaround for otool arm64 weirdness: https://gist.github.com/mikeyh/89a1e2ecc6849ff6056b7391c5216799

No conversion.

Also see: https://developer.apple.com/forums/thread/700997

Hopefully my project issue might be fixed in Xcode 14 as not seeing the same random build cycle errors. Also might have been fixed in Xcode 13.4.x while work on this project was paused.

MARKETING_VERSION (CFBundleShortVersionString in Info.plist): https://developer.apple.com/documentation/xcode/build-settings-reference#Marketing-Version CURRENT_PROJECT_VERSION (CFBundleVersion in Info.plist): https://developer.apple.com/documentation/xcode/build-settings-reference#Current-Project-Version CFBundleShortVersionString: https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleshortversionstring CFBundleVersion: https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleversion (important for App Store updates) Targets inherit from project settings so you could just set the CURRENT_PROJECT_VERSION and MARKETING_VERSION in the project, delete the target specific build settings and each target will then use the project settings. Customised / Levels at the top left of build settings helps to see what is customised or inherited in each target. You can also use build configuration files to specify build settings for the project or specific targets / configurations which are often easier for scripts to update, avoiding any parsing of project.pbxproj files: https://developer.apple.com/documentation/xcode/adding-a-build-configuration-file-to-your-project eg setting the following project.xcconfig for all configurations (and removing CURRENT_PROJECT_VERSION / MARKETING_VERSION from the project / target build settings) will use the xconfig versions for all targets: project.xcconfig CURRENT_PROJECT_VERSION = 1.0.0 MARKETING_VERSION = 1.0 You can also reference custom build settings just like any other build setting. eg $(MY_CUSTOM_BUILD_SETTING) One of my projects uses xcconfig to manage custom TOOLS_OWNED / HELPER_AUTHORISED_CLIENTS (SMPrivilegedExecutables / SMAuthorizedClients) build settings for multiple targets and debug / release / distribution configurations as an alternative to SMJobBlessUtil-python3.py updating Info.plist files.

Thanks so much for your detailed response. I wondered whether it was supposed to inherit, but couldn't get that to work. (I wasn't advanced enough to understand the "levels" setting or to look at that). It turns out the Apple build template overrode the default and the way to reset a default is to highlight the row and hit delete. (Don't try leaving it blank, or setting it back how you found it after the build template set it) Next task is explore your build configuration advice. @obscurebug This was something I looked at again recently. My last post about versions and auto incrementing build numbers in Xcode was 2008-12 for Leopard / Xcode 3.x! Build configuration files are a lot cleaner in source commits (vs project.pbxproj) especially if they are high change like build numbers. You can also include other xcconfig files eg #include "versions.xcconfig" for further separation. Not modifying project.pbxproj provides more flexibility for auto incrementing build numbers in a Run Script Phase.

Customizing the notarization workflow: https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/customizing_the_notarization_workflow

Check this thread on using build configuration files to externalise versions for easier updating by your own scripts: https://developer.apple.com/forums/thread/709065?answerId=718911022#718911022

@eskimo any update from your discussion?

Not an expert but Developer ID certs do not use WWDR intermediate certificates (those are for Apple Development). In Keychain Access: right click your Developer ID Application: Name (Team) certificate select Evaluate "Developer ID Application: Name (Team)" click Continue click Show Certificate First click of Show Certificate (without changing selection) should show a chain like: Apple Root CA Developer ID Certification Authority Developer ID Application: Name (Team) Depending on issue date, Developer ID Certification Authority would be one of: Developer ID - G1 (Expiring 02/01/2027 22:12:15 UTC) Developer ID - G2 (Expiring 09/17/2031 00:00:00 UTC) For that WWDR it looks like you are missing Apple Root CA - G3 Root in your system roots.

So that looks like you are missing the entire chain of intermediate and root certificates probably because you are on outdated macOS 12.3 and haven't used Xcode managed certificates which will usually install everything you need. Ideally you want to be on the latest macOS release which includes the latest root certificates in System Roots AND highly recommend you use Xcode managed certificates (Xcode > Preferences > Account tab > Manage Certificates) to download and install your Developer ID certificate even if you are not using Xcode automatic signing (or using a third party build system). If you do need to install manually then based on your expiry, you will probably need to install the following from https://www.apple.com/certificateauthority/: Login keychain: Developer ID - G2 (Expiring 09/17/2031 00:00:00 UTC) System Root: Apple Root CA - G2 Root Manual installation and trust of root certificates is not recommended. Update your macOS and use Xcode managed certificates.

Shows in System Settings > Desktop & Dock under Stage Manager on my macOS 13.0 Ventura Beta 3 (22A5295h) installs. Do you have multiple browsers installed?

Which method did you use? Updating macOS should install the Apple root certificates then use Xcode managed certificates for your Apple Development certificate. That WWDR may actually be the Apple Inc. Root (not G3).

Please mark my second reply as the correct answer to close this topic: https://developer.apple.com/forums/thread/709545?answerId=719589022#719589022

within the system area Are you trying to share an identity for both users via a single entry in the system keychain? Try importing into each user login keychain.