Customizing the notarization workflow: https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/customizing_the_notarization_workflow
mikeyh
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
User for
Post
Replies
Boosts
Views
Activity
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.
Looks like old code. Update your packages to latest.
@inlinable
public subscript(bounds: Range<Index>) -> SubSequence {
get {
return self._buffer[bounds]
}
set {
var index = bounds.lowerBound
var iterator = newValue.makeIterator()
while let newElement = iterator.next(), index != bounds.upperBound {
self._buffer[index] = newElement
formIndex(after: &index)
}
precondition(iterator.next() == nil && index == bounds.upperBound)
}
https://github.com/apple/swift-nio/blob/main/Sources/NIOCore/MarkedCircularBuffer.swift