Ted Kremenek, Dave Verwer, and Sven A. Schmidt published a short post on the Swift Package Index blog on 23 June 2026 with the kind of headline that sounds like a finale: Swift Package Index joins Apple. SPI — the search engine and metadata index that has, since 2020, been the de-facto discovery layer for the Swift package ecosystem — is now an Apple project. The full SPI team, including Verwer and Schmidt, are Apple employees. SPI Operations Limited, the UK company that operated the site (registered in London, company number 13466692, the corporate structure Dave Verwer built so the project could take sponsorships and a real payroll), is now part of Apple.
This is being read in two opposite ways, and both readings are correct.
The optimistic reading: SPI finally has the money and the people to do the things a community project could not. The site has indexed 10,000+ Swift packages. It ran more than 3.5 million compatibility builds across all supported platforms in 2025 alone, on a CI matrix that includes macOS, iOS, tvOS, watchOS, Linux, visionOS, WebAssembly, and Android. That is a real load, and it has been running on community donations, sponsor slots, and Dave Verwer's own time for years. One HN commenter (dragon-hn) noted that Verwer also just handed off ownership of his iOS Dev Weekly newsletter, which is consistent with a full transition: the man who ran the project is now spending the same hours at Apple.
The skeptical reading: an Apple-controlled package index is an Apple-controlled package index. jshier, who works on the Swift toolchain, posted the day's most quoted comment: "Not optimistic here. While I'm glad the SPI guys are getting paid (that is, a full time job), Apple is pretty bad at open source and developer services both, and they explicitly call out developer identity as a future direction, which doesn't fill me with hope." Another commenter (classified) put it more starkly: "And there I was hoping the Swift ecosystem could emancipate itself from Apple instead of getting eaten up." Both comments are well-formed and not paranoid. Apple has a real track record of building good developer tools, a real track record of building bad developer services, and a real track record of letting community projects rot when they conflict with platform strategy. The three records are all true at once.
The interesting question is not which reading is right. The interesting question is what the indexer of an indexer looks like.
What the announcement actually says
A close read of the post — the announcement has three structural commitments worth pinning:
-
The site continues to operate. "Swift Package Index will continue to operate as it does today. You can continue to rely on it to discover packages, check compatibility, and explore documentation." This is a non-trivial concession, because the alternative — quietly relaunching as
developer.apple.com/packagesand breaking a thousand scripts that point at the old URLs — would have been easier and was, until the announcement, the default expectation. -
The source stays open. "Swift Package Index will remain open source. ... Apple engineers will be contributing alongside the community as we build new features and improvements." This is the line that has to hold. SPI is a Metadata index, a CI matrix, and a documentation crawler. All three are pieces of infrastructure the Swift community can copy if Apple misbehaves — but only if the source is actually open. The license matters; the commit history matters; the rate of outside contributions matters.
-
The future is package signing and identity. "Over time, we plan to introduce new capabilities around areas like package signing and identity to add robustness and security to the ecosystem." This is the part jshier is right to be nervous about. Package signing is a feature Apple wants. Apple has wanted it for a long time. The 2024 Swift Forum discussion of SPM trust was a four-year stalemate because Apple could not agree with itself on whether to ship its own format. The 2026 forum discussion, presumably, will be different — Apple now controls the registry.
Six angles worth your attention
1. The community project was always a platform feature in disguise
SPI's reach is broader than its visibility. The site processes 3.5 million compatibility builds a year, which is more than Apple's own first-party developer.apple.com documentation search gets in that window. Almost every Swift developer has, at some point, hit a "this package supports macOS 13" badge that was generated by SPI's CI. The package manager's "add dependency" UX is, in practice, "go to SPI first, then paste the URL." The whole discovery and evaluation layer of the Swift ecosystem was, for five years, a side project run by two people and a community payroll.
The acquisition is not Apple buying a project that competed with the platform. It is Apple absorbing a project the platform had been quietly depending on. That is a different kind of deal, and the precedent is bad. The risk is not that SPI disappears; it is that SPI becomes a first-party feature with the reliability characteristics of a first-party feature: maintained, but slow, and impossible to fork because the talent has moved in.
2. The funding problem was the real problem, and it is now solved (or not)
The most charitable reading of this announcement is that Dave Verwer, who has been running SPI for five years on a combination of sponsorships, Patreon, and personal time, hit the limit of what a community project can fund. Three and a half million builds a year is a real AWS bill. The build matrix expanded — visionOS, WASI, Android — every expansion added a new platform's worth of CI minutes. The unit economics of a community index that runs a build for every package on every supported platform, every commit, were always going to collapse. Apple buying SPI is Apple paying for the build matrix. That is a real benefit, and it is not a small one.
The less-charitable reading is that the funding problem could have been solved with a more aggressive sponsorship tier, a foundation model (the Rust Foundation, the Python Software Foundation), or a multi-vendor consortium. None of those happened. The single-vendor acquisition is a real failure of the community-foundation model for Swift, and it is worth asking why. The answer is structural: Swift the language is open-source, but Swift the ecosystem is held together by Apple-employee time on the forums, Apple-employee review of Swift Evolution proposals, and Apple-employee maintenance of the toolchain. A vendor-neutral foundation cannot fund what a vendor already pays for in kind.
3. Package signing is the actual fight
The 2024 Swift forum thread on SPM trust died in committee. The deadlock was over format: Apple's preferred approach (a notarized, signed manifest that ties a package to a developer ID) is a stricter variant of what xcodebuild does for app signing, and the community wanted something closer to sigstore or The Update Framework (TUF). The two sides had a four-year argument about whether the package index should be a registry (which can require signatures to list a package) or a search engine (which lists whatever its crawler can find).
The SPI announcement ends that argument. With Apple controlling the index, "package signing" means Apple's signing. The jshier comment, "they explicitly call out developer identity as a future direction, which doesn't fill me with hope," is not a complaint about a hypothetical future; it is a recognition that the future is now structurally locked. Swift packages will get the same identity story as iOS apps. That is a strict win for supply-chain security, and a strict loss of escape velocity — once a package is signed, the package ecosystem is not portable to a non-Apple-run index without re-signing.
This blog's own post on the LinkedIn-recruiter backdoor made the case that package registries are supply-chain attack surface. The SPI move is the right answer to that problem if you trust the registry. The harder question, which the post on the 10,000-GitHub-trojan-repos also raised, is what to do when you cannot.
4. The "two sites that look the same" question is now an Apple problem
A second thread in the HN comments (from frou_dh) surfaced a question many Swift users have quietly had: why are there two package sites — swiftpackageregistry.com and swiftpackageindex.com — that seem to be the same thing? The answer is that they are not the same thing. The Swift Package Registry is the spec and the hosted, official implementation that Apple has been running since 2024. SPI is the discovery and metadata layer that has been running on top of the registry since 2020. They were built by different people, at different times, for different reasons.
The acquisition collapses the distinction. The new SPI is going to be, structurally, the front door of Apple's package registry. The community project called SPI was, structurally, a third-party discovery layer. These are different jobs, with different incentives, and the announcement's careful language — "the site continues to operate as it does today" — is going to run out of shelf life the first time the front door and the registry diverge.
5. The CI matrix is the part that was always going to break
A 3.5M-builds-a-year CI matrix that runs across macOS, iOS, tvOS, watchOS, Linux, visionOS, WASI, and Android is not a feature; it is an infrastructure. Each platform requires a real Mac, a real iOS device simulator, a real Linux VM, a real visionOS device or simulator, a real WASI runtime, and a real Android device. The current SPI implementation pays for the Macs and the Linux machines; the iOS and tvOS work runs on Apple's own CI, which the community was getting for free because Apple employees happened to be working on the project.
If SPI becomes a first-party project, the build matrix is paid for in Apple's CI credits. That is unambiguously good. It is also the kind of dependency a vendor-neutral foundation cannot replicate. The community fork, if it ever has to happen, will lose the iOS / tvOS / visionOS columns, because the macOS hosts for those are first-party Apple assets. This is a structural fact, not a hypothetical one, and it is the strongest reason the announcement's "open source" commitment is incomplete.
6. The "should have built it themselves" comment is the wrong take
One HN commenter (aaronvg) wrote, "kind of surprised Swift didn't launch with this by default, built in-house." This is the Apple-developer-services take, and it is wrong. Apple did try to build a package index. The original Swift Package Manager, in 2015, was a CLI that downloaded tarballs from arbitrary git URLs. The 2020 Swift Package Index project was a community response to a gap Apple had not filled. Apple tried, in 2024, to ship a first-party registry and ran into the same supply-chain politics the community had been arguing about for years. The community project, run by people who were not Apple, was the only path that produced a working system. The acquisition is Apple finally admitting the gap and buying its way out. That is not, on the merits, a bad thing. It is the kind of thing Apple does well.
The original take
The acquisition is good for Swift developers and bad for the precedent it sets, and the most honest position is to hold both.
It is good because the build matrix is paid for, the team has full-time jobs, the discovery layer is going to keep running, and package signing is finally going to ship. None of these are small wins. The supply-chain implications in particular are real: signing is the right answer to the threat model the npm incidents and the GitHub-trojan-repo waves have established, and a registry that can require signing is a strict improvement over an index that can only warn.
It is bad because the precedent is "platform vendor acquires the community's discovery layer." The Swift community tried the foundation model, the consortium model, the sponsorship model, and none of them funded a 3.5M-builds-a-year CI matrix. The model that funded it was a single-vendor acquisition. The next time a small language ecosystem faces the same problem, the only exit they have seen work is to wait to be bought. That is a bad equilibrium, and it is going to be reproduced.
The pragmatic position, which is the one I would take if I were shipping a Swift package tomorrow: do not depend on SPI for anything that is not already on the page. Discovery: SPI. Build matrix: SPI. Documentation hosting: SPI. Anything that requires a trust decision — who signs my package, what identity I publish under, which packages get listed — assume the Apple-controlled version of that decision and design accordingly. The community fork is still possible, and the source is still open, but the structural gravity of the project has shifted. The community that builds the fork will be working with the same source code, the same commit history, and a strictly smaller build matrix. The community that runs the index, going forward, is Apple.
What this means for you
- If you maintain a Swift package: your package's discoverability just got a permanent Apple-shaped tailwind. Plan for an SPI-hosted version of your README, a
spi.devbadge, and — within 12-18 months, based on the announcement's pace — a signed release pipeline. Start sketching what your signing identity looks like, because the answer is going to be "Apple Developer ID" and the question is whether you opt in early or late. - If you consume Swift packages: nothing changes this week. The build matrix still runs. The site still works. The dependency you added last month is still the dependency you add today. The change is structural and slow, and the announcement's "operates as it does today" is going to hold for at least the next year.
- If you work on a small language's package index: the lesson is that vendor-neutral funding models for registries that need to run a real build matrix are a dead end. Either you get a single-vendor acquisition (Swift, npm under GitHub, crates.io under the Rust Foundation backed by AWS money) or you get a project that cannot fund the build matrix and dies slowly. The 2020s answer is acquisitions. The 2030s answer is going to have to be different.
- If you are an iOS developer who has never looked at SPI directly: you have been using it. The next time you paste a Swift package URL into Xcode, the autocomplete is pulling from an index Apple now owns. The decoupling between "I use it" and "I think about it" is exactly the surface area the acquisition exploits.
What to do this week
# 1. If you maintain a Swift package, add the SPI badge to your README.
# The site is at https://swiftpackageindex.com and the badge is a
# single Markdown image. Five minutes.
# 2. Pull the announcement's source directly. The Cloudflare front
# door on swiftpackageindex.com blocks scripted fetches, but the
# Internet Archive has the canonical capture:
# https://web.archive.org/web/20260623190839/https://swiftpackageindex.com/blog/swift-package-index-joins-apple
# 3. Read the Swift forum thread on SPM trust
# (https://forums.swift.org/c/development/swift-package-manager/)
# and search for "trust" or "signing." The "Apple cannot agree
# with itself" deadlock is the conversation that the SPI
# acquisition just ended. The signatures we are about to get
# are the ones Apple wanted three years ago, and the
# alternative proposals (sigstore, TUF) are not going to ship
# for Swift packages.
# 4. If you maintain a non-Apple package ecosystem (npm, PyPI,
# crates.io, RubyGems, Maven Central), read the SPI
# announcement and ask: who is your Dave Verwer? The
# "single-vendor acquisition is the only working funding
# model" precedent applies to you.
# 5. Skim the HN thread (item 48648779) and notice which
# comments are from people with Swift-toolchain context
# (jshier, classified) and which are generalists. The
# informed skepticism is concentrated. The generalist
# reactions are more positive. The pattern is familiar.
Disclosure
Drafted with AI assistance from MiniMax-M3 under editorial direction. Primary source: the Swift Package Index blog post titled "Swift Package Index joins Apple," by Ted Kremenek, Dave Verwer, and Sven A. Schmidt, dated 23 June 2026. The canonical URL (https://swiftpackageindex.com/blog/swift-package-index-joins-apple) returned HTTP 403 to a scripted fetch on 2026-06-24; the post was read in full via the Internet Archive capture (https://web.archive.org/web/20260623190839/https://swiftpackageindex.com/blog/swift-package-index-joins-apple). The HN discussion (item 48648779, 160 points and 49 comments) was fetched via the Algolia HN API; the eight top-level comment IDs (48649278, 48649349, 48649786, 48650180, 48650247, 48650546, 48652021, 48652933) and the quoted excerpts from jshier, classified, aaronvg, dragon-hn, and frou_dh are reproduced from that fetch. The "10,000 packages indexed" and "3.5 million compatibility builds in the last year" figures are taken verbatim from the announcement body. The "visionOS, WebAssembly, and Android" list of added platforms is from the announcement. The "company number 13466692" and "registered in England and Wales" facts are from the announcement's footer. The framing of the acquisition as a single-vendor acquisition, the jshier quote, the classified quote, the structural argument about CI matrix lock-in, and the "single-vendor acquisition is the only working funding model" thesis are the post's original analysis. The two internal links point to prior posts on this blog; both URLs were verified live on 2026-06-24 and returned HTTP 200.
Sources
- Ted Kremenek, Dave Verwer, and Sven A. Schmidt, "Swift Package Index joins Apple," Swift Package Index Blog, 23 June 2026: https://swiftpackageindex.com/blog/swift-package-index-joins-apple — canonical URL returned HTTP 403 to scripted fetch on 2026-06-24, content verified via the Internet Archive capture below. Primary source.
- Internet Archive capture of the same post, captured 2026-06-23 19:08:39 UTC: https://web.archive.org/web/20260623190839/https://swiftpackageindex.com/blog/swift-package-index-joins-apple — used as the working primary because the canonical URL is Cloudflare-gated against scripted access. 21,117-byte HTML, full body content.
- Hacker News discussion, item 48648779 ("Swift Package Index joins Apple," submitted by JDevlieghere, 160 points and 49 comments as of 2026-06-24 morning UTC+8): https://news.ycombinator.com/item?id=48648779 — 160 points and 49 comments. Eight top-level comments (IDs 48649278, 48649349, 48649786, 48650180, 48650247, 48650546, 48652021, 48652933). Quotes from jshier, classified, aaronvg, dragon-hn, and frou_dh are reproduced from this thread.
- Related tutorialoflife.blogspot.com post on the LinkedIn-recruiter backdoor (the case that package registries are supply-chain attack surface, and what to do about it): The Recruiter's Repo. The npm install Was the Backdoor. — verified live, returned 200.
- Related tutorialoflife.blogspot.com post on the 10,000-GitHub-trojan-repos wave (the case that "you cannot trust the registry" is the threat model the SPI signing story is designed for): 10,000 GitHub Repos Distribute Trojans. Reddit Saw It First. — verified live, returned 200.
