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

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

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.

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.

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.

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

No conversion.

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

Updated version with workaround for otool arm64 weirdness: https://gist.github.com/mikeyh/89a1e2ecc6849ff6056b7391c5216799

@eskimo This is an otool thing not an OS thing. If you open the file with Hex Edit, you’ll see that strings like CFBundleIdentifier are not byte swapped. What do you see with otool -V -s __TEXT __info_plist test or otool -v -s __TEXT __info_plist test on Apple Silicon vs Intel. On Intel the correct host architecture appears to be selected. On Apple Silicon all architectures are output: otool --version llvm-otool(1): Apple Inc. version cctools-1000 otool(1): Apple Inc. version cctools-1000 disassmbler: LLVM version 14.0.0, (clang-1400.0.17.3.1) otool -V -s __TEXT __info_plist test test (architecture x86_64): (__TEXT,__info_plist) section <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <snip> </dict> </plist> test (architecture arm64): (__TEXT,__info_plist) section <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <snip> </dict> </plist>

@Arafaer Try something like this: import SwiftUI struct VisualEffect: NSViewRepresentable {   func makeNSView(context: Self.Context) -> NSView { return NSVisualEffectView() }   func updateNSView(_ nsView: NSView, context: Context) { } } @main struct VisualEffectApp: App {   var body: some Scene {     WindowGroup {       ContentView()         .background(VisualEffect().ignoresSafeArea())     } .windowStyle(.hiddenTitleBar)   } }

@cstewart Try something like this: import SwiftUI struct VisualEffect: NSViewRepresentable {   func makeNSView(context: Self.Context) -> NSView { return NSVisualEffectView() }   func updateNSView(_ nsView: NSView, context: Context) { } } @main struct VisualEffectApp: App {   var body: some Scene {     WindowGroup {       ContentView()         .background(VisualEffect())     }   } }

Should be resolved now.

Did you add brew python@3.7 to your PATH? The output from brew install python@3.7 should include: python@3.7 is keg-only, which means it was not symlinked into /usr/local, because this is an alternate version of another formula. If you need to have python@3.7 first in your PATH, run:  echo 'export PATH="/usr/local/opt/python@3.7/bin:$PATH"' >> ~/.zshrc For compilers to find python@3.7 you may need to set:  export LDFLAGS="-L/usr/local/opt/python@3.7/lib"

This appears to be a unicode multi-byte string length defect which assumes the numbers of characters = number of bytes when decoded. Any attributed string with multi-byte unicode scalars will truncate. eg ~! (0x7E 0x21) will not truncate and ¡! (0xC2 0xA1 0x21) will truncate to ¡ (0xC2 0xA1) when decoded. Attributed strings with no attributes (fast path?) will not truncate when decoded.