grpc-swift 1.x: a Swift gRPC runtime in maintenance mode

The first paragraph of the README is a redirect

grpc-swift's README is short, and roughly half of it is a signpost elsewhere. After a one line description of the repository as a gRPC code generator and runtime libraries for Swift, there is a callout marked IMPORTANT telling readers to see grpc/grpc-swift-2 for gRPC Swift 2, described as the current major version of gRPC Swift.

What remains in this repository is gRPC Swift 1, described in the Versions section as being in maintenance mode. The README is precise about what that means: only bug fixes and security fixes will be applied, and the support window for 1.x will decrease over time as new Swift versions are released.

That is a materially different posture from the Rust implementation in the same organisation, whose README still ships active feature notes. Here the release history is consistent with the statement: 1.27.6 was published on 2026-09-01, then nothing until 1.27.5 and 1.26.2 both dated 2026-04-01. Patch releases on the 1.27 line and a maintenance branch release, with no feature tags in sight. The default branch is named release/1.x, which is the kind of detail that tells you the same thing.

The supported versions table is the whole adoption decision

The README lays out the support window as a table keyed on Swift releases. Working through it: when Swift 6.1 is current, gRPC Swift 1.x supports Swift 5.10, 6.0 and 6.1. When Swift 6.2 arrives, the supported set narrows to 6.1 and 6.2. When Swift 6.3 arrives, only 6.3 is supported. And when Swift 6.4 arrives, 1.x is marked unsupported outright.

The README frames this as an assumption rather than a promise, saying that assuming the next Swift releases are 6.2, 6.3 and 6.4, the table follows. So this is a forecast, not a schedule, but the direction is unambiguous and the project states it plainly rather than leaving you to infer it.

Read as an adoption rule, it is fairly sharp. A team that intends to keep moving with Swift releases has two or three versions of runway at most. A team pinned to an older Swift toolchain has more time but is also the team most likely to hit other toolchain constraints. Neither group is being served well by starting a greenfield project here, which is exactly why the README sends them to the 2.x repository.

What the repository tree says about how 1.x is built

The README documents almost nothing about the code, so the directory listing carries the weight. Sources/ holds the runtime libraries, Protos/ the bundled protocol buffer definitions, and Plugins/ is the interesting one for anyone integrating with Swift Package Manager, since a plugin there is what lets the build compile proto files without a separate manual step.

Alongside those sit Tests/, Examples/ with a v1 subdirectory, Performance/, and FuzzTesting/. A dedicated fuzzing target next to a performance directory tells you the project invested in both robustness and throughput measurement, which for an RPC runtime is the pair of things that actually decide whether it can carry production traffic.

The supporting files are conventional and worth a glance. Package.swift is the manifest, .spi.yml configures the Swift Package Index listing that the README points readers to for API documentation, and .swift-format is present, so formatting is enforced rather than argued about. dev/ and scripts/ hold development tooling, docs/ holds documentation, and there is a .gitmodules entry, which means at least one component arrives as a submodule rather than being vendored.

The governance files are just as present: GOVERNANCE.md, MAINTAINERS.md, AUTHORS, CODE-OF-CONDUCT.md, CONTRIBUTING.md and SECURITY.md. A repository that ships a code of conduct and a security policy is behaving like a project that expects to be depended on by companies.

Apache-2.0, PATENTS and the licensing question

The declared license is Apache-2.0, and the README states that gRPC Swift is released under the same license as gRPC, repeated in the LICENSE file. A PATENTS file sits at the repository root alongside NOTICES.txt, which is the standard Apache-2.0 pairing for a project that expects patent questions.

The repository also states its contribution terms: unless a contributor explicitly says otherwise, any contribution intentionally submitted for inclusion is licensed as MIT, with no additional terms or conditions. That dual licensing of contributions against an Apache-2.0 project is a common and deliberate pattern, and it is the kind of detail worth knowing if you contribute code you also use elsewhere.

What the README does not do is interpret the license for you, and nothing here should be read as legal advice. For an organisation with a standard third-party review process, the facts you need are the identifier, the PATENTS file, and the SECURITY.md policy that the README points to.

What moving to gRPC Swift 2 actually means

The README's answer to that question is a link, not an explanation. Everything a reader would want to compare between 1.x and 2.x lives in the other repository, which is a reasonable editorial choice and an unhelpful one for anyone trying to scope a migration.

The related searches that people actually type suggest what that comparison hinges on. Queries include gRPC swift-2, grpc-swift-protobuf, grpc-swift-nio-transport, grpc swift extras, grpc swift versions and gRPC iOS, which points at three concrete axes: which major version to use, which codegen and which transport to pair with it, and whether the result works on Apple platforms.

The transport question deserves attention because it is where implementations usually diverge. Naming a NIO transport as a separate concern implies the networking layer is a choice rather than a given, and choosing between them is an architectural decision rather than a version bump. The extras question suggests an add-on ecosystem that also has to be checked against a major version boundary.

What the README does establish is the timeline you would be moving into: 2.x is current, and 1.x will not receive features. Any comparison you make should start there.

Where the documentation for this repository actually lives

The README points general gRPC questions at grpc.io and Swift-specific API documentation at the Swift Package Index, specifically the release-1.x documentation entry. There is no separate documentation site for 1.x and no usage tutorial in the README itself.

That is the practical boundary of evaluating this project from the repository alone. You can learn its maintenance status, its support matrix, its licence and its structure, and that is genuinely most of what matters for the decision. You cannot learn how to write a service, how the code generator is invoked, or what the transport options are without leaving for another site.

For a project in maintenance mode, that is arguably the right amount of documentation investment, and it is consistent with the README's tone: it spends its words telling you not to start here and points you where you should go. The maintenance and upgrade cost of adopting 1.x now is mostly the future migration to 2.x, and the honest way to price it is to assume you will do that migration.

Editorial conclusion

Start any new Swift gRPC work in grpc-swift-2, because this README says so itself and the 1.x branch has no feature work left. The case for staying on 1.x is narrow: an existing app already integrated, a Swift version your project cannot move off, or a build where changing the networking stack is a larger risk than the shrinking support window. If that is your situation, pin to the 1.27.x line, watch the supported-versions table as each Swift release lands, and read the Swift Package Index entry for the generated API surface, since this repository documents almost nothing about its own code generation.

Frequently asked questions

Official sources

1. grpc/grpc-swift on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases