Repository navigation
Source builds need the macOS 27 SDK since v1.15.0 - require loudly or guard the 27-only files #520
Description
Source builds need the macOS 27 SDK since v1.15.0 - decide: require it loudly, or guard the 27-only files
Found in the v1.16.0 pre-release review. Building the sources against the macOS 26.5 SDK (SDKROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX26.5.sdk swift build -c release --build-system native) fails since v1.15.0 and more so at v1.16.0:
- v1.15.0:
Sources/UsageAccounting.swift(3 errors),Sources/VisionSupport.swift(5) - v1.16.0: plus
Sources/Session.swift(init(samplingMode:)does not exist in the 26.5 SDK),Sources/ToolCallingSupport.swift(toolCallingMode, 4),Sources/TypedErrorSupport.swift(LanguageModelError, 2)
The binary still runs on macOS 26 (floor 26.0, #available gates at runtime), but a person on Xcode/CLT 26.x can no longer compile it. The shipping channels are not affected today: the GitHub tarball and the tap are built here with SDK 27.0, homebrew-core's macOS 26 runners build with the 27 SDK (v1.15.0 PR #315623 green), nixpkgs builds on this Mac's hash. docs/install.md now states the macOS 27 SDK requirement (v1.16.0).
Options for Franz:
- Keep requiring the 27 SDK (status quo, documented) and make
make build'scheck-toolchainfail early with a clear message when the active SDK is < 27. - Guard the five files with
#if canImport(FoundationModels, _version: ...)/compiler checks so a 26-SDK build compiles with the 26 behaviour everywhere (more code, two source configurations to test).
Activity
Arthur-Ficial commentedon Oct 5, 2026
Good catch on the pre-release review.
I verified the code paths.
UsageAccounting.swiftandVisionSupport.swiftboth do a bareimport FoundationModelsat the top and reference 27-only types (LanguageModelSession.Usage,LanguageModelSession.Response,LanguageModelSession.ResponseStream.Snapshot) behind runtime#availablegates only - no compile-time SDK guards. That's enough to break any build whereSDKROOTpoints at a 26.x SDK, since the compiler can't even see those type declarations.The two options in the issue are clear-cut. Option 1 (fail early in
check-toolchain) is less code and matches the current documented SDK 27 requirement indocs/install.md. Option 2 (#if canImport(FoundationModels, _version: ...)guards) gives wider source compatibility but doubles the configurations to test. Both preserve the runtime story - the binary still runs on macOS 26 either way.Labelling as
bugso the bug-solver routine can draft a fix PR for Franz to review. The choice between option 1 and option 2 is Franz's call.Cheers, Arthur
cc @franzenzenhofer
Generated by Claude Code
fix(review): mid-stream overflow truncates on macOS 27 again, preflig…
Arthur-Ficial commentedon Oct 5, 2026
Fix drafted - see #525. Implements option 1 (raise
check-toolchainto require SDK >= 27, updatedocs/install.mdto match). The error message now names the actual requirement, explains why it fails, and points macOS 26 users to pre-built binaries.Option 2 (guard the five files with
#if canImportfor 26-SDK compilation) is a bigger architectural call - left that for you to decide.Needs @franzenzenhofer to review and run the tests locally before merging.
Cheers, Arthur
cc @franzenzenhofer
Generated by Claude Code
Arthur-Ficial commentedon Oct 5, 2026
Fix drafted - see #526. Goes with option 1:
check-toolchainnow rejects SDK < 27 with a clear message naming the cause and offeringbrew install apfelas the no-build path.docs/install.mdtroubleshooting updated to match.Needs @franzenzenhofer to review and run the tests locally before merging.
Cheers, Arthur
cc @franzenzenhofer
Generated by Claude Code