Swift 6.0 Release Process

Swift 6.0 Release Process

This post describes the release process, and estimated schedule for Swift 6.0.

Snapshots of Swift 6.0

Downloadable snapshots of the Swift 6.0 release branch will be posted regularly as part of continuous integration testing. As support is available, snapshot downloads will be added for newly supported platforms.

Once Swift 6.0 is released, the official final builds will also be posted in addition to the snapshots.

Getting Changes into Swift 6.0

On March 15th 2024 the release/6.0 branch will be cut from main in the swift repository and related project repositories. This will contain the changes that will be released in Swift 6.0. After the branch is cut, changes can be landed on the branch via pull request if they meet the criteria for the release.

Philosophy on Taking Changes into Swift 6.0

  • All language and API changes for Swift 6.0 will go through the Swift Evolution process. Evolution proposals should aim to be completed by the branch date in order to increase their chances of impacting the Swift 6.0 release. Exceptions will be considered on a case-by-case basis, particularly if they tie in with the core goal of the release.
  • Other changes (e.g., bug fixes, diagnostic improvements, SourceKit interface improvements) will be accepted based on their risk and impact.
  • Low-risk test tweaks will also be accepted late into the release branch if it aids in the qualification of the release.
  • As the release converges, the criteria for accepted changes will become increasingly restrictive.

Impacted Repositories

The following repositories will have a release/6.0 branch to track
sources as part of Swift 6.0 release:

The llvm-project and swift-experimental-string-processing will have a corresponding swift/release/6.0 branch.

Release Managers

The overall management of the release will be overseen by the following individuals, who will announce when stricter control of change goes into effect for the Swift 6.0 release as the release converges.

Platform Release Managers

Please feel free to post on the development forum or contact Ted Kremenek directly concerning any questions about the release management process.

Pull Requests for Release Branch

In order for a pull request to be considered for inclusion in the release branch (release/6.0 ) after it has been cut, it must include the following information:

  • Explanation: A description of the issue being fixed or enhancement being made. This can be brief, but it should be clear.
  • Scope: An assessment of the impact/importance of the change. For example, is the change a source-breaking language change, etc.
  • Issue: The GitHub Issue link if the change fixes/implements an issue/enhancement
  • Original PR: Pull Request link from main branch
  • Risk: What is the (specific) risk to the release for taking this change?
  • Testing: What specific testing has been done or needs to be done to further validate any impact of this change?
  • Reviewer: One or more code owners for the impacted components should review the change. Technical review can be delegated by a code owner or otherwise requested as deemed appropriate or useful.

All changes going on the release/6.0 branch must go through pull requests that are accepted by the corresponding release manager.


Is 6.0 what was previously sometimes called 5.11? And the plan is still to have a 5.10 before 6.0?

Yes, 5.10 branched in September.


Exciting to see the Swift 6.0 :tada:

quick comment : )
the link for swift-markdown is wrong


Swift 6 will then be included in a Xcode version that is going to be released in September 2024?

I doubt you'll get an official response there. Xcode is a closed, Apple-proprietary tool. The Xcode team make a point of not discussing their future plans publicly.

Hazarding a guess, I would tend to assume that 5.10 is planned for this year's WWDC and thus 6.0 is next year, but the Xcode 15.3 betas include 5.10 already. Unless there won't be an Xcode 16 this year (bucking convention and IMO unlikely given the rumours) that might indicate an attempt to get 6 out this year. This would make some sense if 5.10 were a roughly parallel "long term support" release for the 5.x series, except that as far as I know the Swift 6 compiler is supposed to be fully backwards-compatible via its Swift 5 mode. :man_shrugging:

1 Like

If the usual release process is followed, as a March 15 branch date indicates, Swift 5.10 will ship with Xcode 15.3 in the second or third week of March, and Swift 6 will ship with Xcode 16 in the fall, after an announcement at WWDC.


That's correct. The Swift 6.0 compiler still supports the Swift 5 language mode. The Swift 6.0 compiler makes the Swift 6 language mode available as an opt-in mode via -swift-version 6, just like the Swift 5.0 compiler made the Swift 5 language mode available with -swift-version 5.


Can I assume that binary frameworks (.xcframework ) compiled with Swift 5 language mode can be used as-is by app developers who choose to opt-in for Swift 6 language mode to compile their app?

Yes, you can mix and match dependencies that use different language modes, including binary frameworks. Binary framework dependencies will still have the same restrictions on having library evolution enabled in order for clients to import them using a newer version of the compiler than the one they were built with, but those constraints are not new with the Swift 6.0 compiler and it's not related to language mode.


Ahh… interesting! Other than .enableExperimentalFeature("StrictConcurrency") is there anything I can do to build from SPM with 5.9 (or 5.10) to begin to see any low-hanging fruit that could be fixed now before 6.0 ships?

You can use a Swift.org development snapshot where -swift-version 6 is available, and you should be able to set the language mode to Swift 6 in a package manifest using the swiftLanguageVersions API.


Good news ! Does Swift 6 support running on FreeBSD ?

1 Like

@mhjacobson had the compiler and stdlib running on FreeBSD last year, and submitted several pulls but has disappeared on github since. I think it would make for a good GSoC project to get the rest of the toolchain ported: feel free to publicize that option in the FreeBSD community, as all it takes is for some student to apply and the relevant teams to accept the proposal.


You can use upcoming feature flags in the shipping release of Swift to enable changes that cause source incompatibility that will be present in Swift 6 mode.

You can find proposals that have upcoming feature flags on the Swift Evolution Dashboard. (The flag button turns on a filter for upcoming feature flags.)

You can learn more about upcoming feature flags including how to enable them in this blog post: Swift.org - Using Upcoming Feature Flags.


Any chance on making any Proto? valid syntax equivalent to (any Proto)? in by that branch date?? :pray:


So exciting!! Would be amazing to get function body macros in before release - those are going to be (yet another) incredible addition to macros!