Document Darwin SDK requirement in Swift Versions table - #364
Merged
Conversation
Add rows for 0.5.x and 1.0.x, which the table omitted, and note that the Xcode column states an SDK requirement on Darwin.
jakepetroules
approved these changes
Aug 13, 2026
iCharlesHu
approved these changes
Aug 13, 2026
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
3 participants
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 Swift Versions table ends at 0.4.x, so a client on a released 0.5.x or 1.0.x has no row to check. This PR adds explicit rows for both versions, and notes that on Darwin the Xcode column states an SDK requirement rather than only a toolchain one.
Building 1.0.0 with a swift.org 6.3.3 toolchain fails at
Sources/Subprocess/SubprocessFoundation/Input+Foundation.swift:154withvalue of type 'Data' has no member 'bytes'when an older Xcode is selected, since Foundation comes from the SDK rather than from the toolchain. I tested this on one macos-15 image, holding the OS, the toolchain, and the checkout constant and varying onlyDEVELOPER_DIR: Xcode 16.4 (macOS 15.5 SDK) reproduces the failure and Xcode 26.0.1 (macOS 26.0 SDK) builds clean.The requirement is build-time only.
Package.swiftdeclares.macOS(.v13), and that target compiles clean against the macOS 26 SDK with no availability diagnostic, so the accessor back-deploys and a client's deployment target is unaffected.The requirement didn't change in 1.0. #326 removed the internal
Data.bytesshim, soAsyncIO.write(_:to:for:)now binds to Foundation's accessor; 0.5 declared Xcode 26 but carried the shim and so didn't depend on the macOS 26 SDK. The alternative to documenting this is making that call site SDK-agnostic: every backend already accepts[UInt8], soself.write(Array(data), ...)would compile everywhere, at the cost of a full copy of eachDatawritten to standard input and of supporting a new-compiler/old-SDK configuration that no CI job covers. I went with documentation since 1.0 requires exactly what the project already stated.Note: The README in
release/0.5has the same table, with itsmainrow standing in for 0.5's requirement; I can open a follow-up targeting that branch if it's still being patched.Reported in #363.