Repository navigation
Conversation
The release was built with a macOS 26 deployment target, so the linker
made the executable depend on Swift runtime libraries that only exist on
macOS 26 (libswift_DarwinFoundation1.dylib and libswift_DarwinFoundation2.dylib).
On macOS 14 and 15 dyld cannot find them and the process aborts before
main() runs:
dyld: Library not loaded: /usr/lib/swift/libswift_DarwinFoundation1.dylib
Referenced from: .../removemacai (built for macOS 26.0 which is newer than running OS)
The new system design comes from building against the macOS 26 SDK, not
from setting the deployment target to 26, so lower the target back to 14
and keep the 26 SDK. The runtime guards and the app bundle's
LSMinimumSystemVersion are lowered to match.
Fixes running on macOS 14 (Sonoma) and macOS 15 (Sequoia).
|
Note Currently processing new changes in this PR. This may take a few minutes, please wait... ⚙️ Run configuration
📒 Files selected for processing (3)
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to The app and CLI now accept macOS 14. The inspected startup and optional-service paths revealed no actionable compatibility blocker, so no merge-blocking risk is evident. Pre-merge checks |
|
Apple Intelligence starts at macOS 15, so there is nothing to remove on 14. Raise the deployment target, the runtime guards and the app bundle's LSMinimumSystemVersion to 15.
|
Superseded by #47. Apple Intelligence starts at macOS 15, so the floor is 15 rather than 14. Closing this in favor of the correctly-scoped PR. |
What this fixes
The published 1.1.0 build (release tarball and the Homebrew bottle) crashes on every macOS older than 26, before
main()even runs:The binary's load command says it all:
Because the deployment target is 26.0, the linker emits dependencies on Swift runtime libraries that only ship starting in macOS 26 (
libswift_DarwinFoundation1.dylib,libswift_DarwinFoundation2.dylib). On macOS 14 and 15 they do not exist, so dyld aborts. The/opt/homebrew/opt/unixodbcpath in the message is just a stray Homebrew rpath; none of the tried paths can exist on those systems.This traces back to #70bf1af ("Build for macOS 26 so the app gets the current system design"), which changed exactly one line:
The premise behind that change is wrong: the new system design comes from building against the macOS 26 SDK, not from setting the deployment target to 26. Building with the 26 SDK and a lower minimum target keeps Liquid Glass on macOS 26 while letting the same binary run on macOS 14 and 15.
Changes
Package.swift—platforms: [.macOS("26.0")]→.macOS(.v14). The real crash fix; the SDK is still macOS 26.Sources/removemacai/main.swift— the two hard runtime guardsmajorVersion >= 26→>= 14. Even a correctly linked binary was refusing to run below 26.tools/build-app.sh—LSMinimumSystemVersion26.0→14.0so the app bundle agrees with the binary.Verified on macOS 15.8.1
Rebuilt and installed locally from this branch:
removemacai statusalso runs cleanly on 15.8.1.Here is the app running on macOS 15.8.1 (built from this branch):
Notes
Models.matching/Models.bytesskip asset sets this macOS does not describe, and tweaks carry asince: (major, minor)field, so 26-only entries are left alone rather than forced. A couple of Apple Intelligence entries (allowExternalIntelligenceIntegrations, Spatial Photos model sets) are 26-only and will show as skipped/unknown on 14–15. Happy to add per-featuresincegating to the Apple Intelligence catalog as a follow-up if you want those hidden instead.off,apply,clean) was run while verifying; only read-onlystatusandselftest..github/workflows/*run onmacos-26, so once this lands every new artifact will carryminos 14.0and run back to Sonoma. The Homebrew formula pulls the prebuilt tarball, so it needs a new release (and bottle) to pick this up.Summary by CodeRabbit