Swift ends Amazon Linux 2 support at the distribution boundary

The Swift project announced the end of Amazon Linux 2 support on July 1, 2026. New nightly toolchains for main and release/6.4.x stop that day. Swift 6.4 and later releases will not support the distribution. The announcement follows Amazon Linux 2's end of support on June 30, which AWS also records in its distribution notice.

The scope is specific. Swift is ending a supported distribution target for future toolchains. The announcement does not say that existing programs cease to run, and it does not publish an inventory of failures that every installation will encounter. I would use it to trigger a review of the operating system and compiler combination required for future builds. I would not infer a particular runtime failure without testing the affected application.

I like Swift's language design, including its collection value semantics and explicit optionals. Its build times remain a frustration for me. A distribution transition is relevant to that experience because it affects how an application gets built and reproduced. Even a program with no source changes needs an understood environment if its next toolchain update is to remain routine.

The supported unit includes an operating system

AWS describes Amazon Linux 2 as an environment for developing and running cloud applications. Its notice recommends migration to Amazon Linux 2023. That is an operating-system support decision independent of the Swift language's syntax or source compatibility. Swift's announcement aligns its future support with that changed distribution status.

A follow-up in the Swift thread, posted on the same day, says that Amazon Linux 2023 is already supported. This supplies an alternative to evaluate. It does not establish that changing a base image is sufficient for every application. The application still has its own dependencies and configuration, and those need an assessment against the replacement environment.

I would begin by identifying where the old distribution appears. The build environment and the deployed environment should both be part of that inventory. A developer may use a toolchain locally while automation builds in a container. A release procedure may then package the result into another image. I would want the actual procedure written down before deciding which part needs to change.

The distinction matters for planning. If a compiler upgrade is the immediate goal, its supported host environment is a direct prerequisite. If the goal is to move an existing service onto a maintained operating system, the runtime environment needs its own validation. Those changes may happen together, but I would still describe the evidence for each one separately.

Preserve a reproducible comparison

My preference would be to establish the existing build before changing the distribution. I would record the source revision and dependency selection alongside the current toolchain. That baseline would make it possible to compare the proposed environment without also changing application behavior. It would also reveal whether the old procedure relied on an installation step nobody had documented.

Then I would evaluate the replacement operating system with a deliberately narrow application scope. The first objective would be a successful clean build with the intended compiler. The next would be the application's own relevant tests. I would include tests that exercise native dependencies because those are part of the compatibility question, even when the application's Swift sources compile unchanged.

These are proposed checks, not a claim that Amazon Linux 2023 introduces any particular incompatibility. The announcement does not enumerate such incompatibilities. I would avoid writing speculative workarounds into the migration before observing a problem. A failing check should produce a concrete investigation of the dependency or build assumption involved.

I would also keep the previous build inputs identifiable while evaluating the new ones. If the comparison fails, I want to know which environment produced each result. A mutable label alone would not be adequate evidence for my review. The procedure should identify the actual inputs closely enough that another person can reproduce the test and inspect the same output.

I would document any remaining untested paths explicitly. A migration report should say which application behaviors its evidence covers and which still need evaluation.

Support status and observed behavior answer different questions

A locally successful build on an unsupported distribution would not change the project's support announcement. It would show that one specific build succeeded under the tested conditions. Conversely, the end of support does not prove that a specific application is currently broken. I would report those facts separately to avoid turning either one into a broader claim than the evidence permits.

This distinction also affects how I would prioritize work. If an application needs a future Swift release, it needs a supported environment for that release. Keeping the old environment because it currently runs does not resolve that requirement. For an application staying on an existing compiler, I would still review the operating system's support status through the AWS notice.

I would want a migration proposal to name its intended toolchain and operating system together. It should explain how the build obtains those inputs and where the resulting application will run. A review limited to the compiler version would miss the distribution decision that caused this event. The recorded combination would also make the next update easier to assess.

For an application with a deployment procedure, I would include its normal startup and shutdown checks in the evaluation. Those checks should reflect the application's actual responsibilities. I would not substitute a successful invocation of the compiler for evidence that the packaged program performs its work. The final review should distinguish build success from the behavior of the deployed artifact.

The July announcement therefore establishes a concrete limit for future planning. Swift 6.4 onward needs a different supported distribution from Amazon Linux 2. My next step for an affected application would be to document the existing environment and evaluate Amazon Linux 2023 with the application's own dependency and deployment requirements. I would retain the tested combination in the release procedure so later compiler changes can be assessed against a known operating system.