Repository navigation
Ship a universal binary with a real macOS floor (1.4.1) - #25
Merged
Merged
Conversation
The macOS app would not launch for most people who installed it. build-menubar-app.sh passed no -target, so swiftc set the deployment target from the build machine. Once the CI runners moved to macOS 26, every DMG since 1.3.x carried minos 26.0 and an arm64-only binary, while its own Info.plist advertised 13.0 and the cask declared depends_on macos: :ventura. Homebrew installed it on Ventura and on Intel Macs, where it could not start. The binary is now compiled once per architecture and lipo'd into a universal one. The floor lives in a single variable, TOKENFLOW_MACOS_FLOOR (default 13.0), which also writes LSMinimumSystemVersion, so the advertised floor and the compiled floor cannot drift apart again. This shipped three times without failing a release because the swiftc line ended in `| head -40`: a pipe discards the exit status, so a compile that produced no binary left an empty Contents/MacOS and the script reported success. The pipe is gone, and the build now reads minos and the architecture list back off the binary it produced, failing if either disagrees with the bundle. test/bundle.test.js asserts both on a real build. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The defect
The macOS app would not launch for most people who installed it.
scripts/build-menubar-app.shpassed no-target, soswiftcset the deployment target from whatever the build machine ran. Once the CI runners moved to macOS 26, every DMG since 1.3.x shipped:while its own
Info.plistadvertisedLSMinimumSystemVersion 13.0andCasks/tokenflow.rbdeclareddepends_on macos: :ventura. Homebrew installed it happily on Ventura and on Intel Macs, where it could not start at all. Verified on the shipped 1.3.5 and 1.4.0 images — bothminos 26.0, both arm64-only.Why it shipped three times
The
swiftcline ended in| head -40. A pipe discards the exit status, so a compile that produced no binary left an emptyContents/MacOS, the script reported success, and the release workflow packaged a DMG around it. Every other fail-loud guarantee inrelease.ymlchecks the plist — which was the half that was lying.The fix
lipointo a universal binary.TOKENFLOW_MACOS_FLOOR(default13.0), sets both the-targetandLSMinimumSystemVersion, so the advertised floor and the compiled floor cannot drift apart.| head -40removed — a failed compile now stops the build. Verified locally: the script exits1and leaves no binary, where before it exited0.lipo, the script readsminosandlipo -archsback off the binary it just produced and refuses to continue if either disagrees with the bundle.test/bundle.test.jsasserts both on a real build.Verification
bash -nclean; the build fails loudly here (this Mac has no SwiftUI macro plugins) with exit 1 and no binary — the old behaviour was exit 0 with an emptyMacOS/.-target arm64-apple-macos13.0and-target x86_64-apple-macos13.0locally, so the login-item code is not what forces the floor up.npm run lintclean, 841 tests / 838 pass / 3 skipped locally.macos-latestjobs are the gate. They are the only place the full SwiftUI app compiles, and now the only place the 13.0 floor is proven. If 13.0 does not compile, the diagnostic names the version andTOKENFLOW_MACOS_FLOORmoves in one line — withdepends_on macos:in the cask in the same commit.🤖 Generated with Claude Code