Apple didn’t announce this like a product launch. No keynote. No press release.
Just a quiet update on a GitHub repo, a Mastodon post from Dave Verwer, and a single article in The Register. But if you’re a Swift developer—especially one who’s ever cursed the lack of a reliable package registry—you know this matters.
The Swift Package Index (SPI) isn’t flashy. It doesn’t have a slick UI or a viral TikTok campaign. It’s just… there. A quiet, persistent tool that tells you whether that package you found on GitHub actually works on VisionOS, or if it’s still stuck on iOS 14. And now, Apple owns it.
This isn’t the kind of acquisition that turns heads in Silicon Valley. No $2 billion price tag. No layoffs. No rebranding. Just a team of three engineers, a GitHub repo, and 11,000 packages, quietly folded into the most powerful tech company on earth.
And honestly? I’m not scared. Not yet.
I’m curious.
Because if Apple plays this right, SPI could become the most trusted package index in open source. Not because it’s Apple’s, but because it finally stops being a glorified GitHub search bar.
I’ve spent the last two years trying to use SPI to find reliable Swift packages. I’ve watched the build queue crawl. I’ve seen packages with no compatibility data for iOS 18, because the build server hasn’t touched them since last July. I’ve asked myself: why is this still so broken?
Now, maybe it won’t be.
—
I don’t trust Apple. Not completely. I’ve seen what happens when they "open source" something: they keep the control, the roadmap, the monetization. They’ll make it work. But they won’t make it ours.
But here’s the thing: the old SPI was already broken. It was a community project that ran on goodwill, a few volunteers, and a server that probably cost less than a MacBook Air. It was a miracle it worked at all.
And now? Now Apple has the resources to fix the build backlog. To add package signing. To make SPI indifferent to whether a package lives on GitHub, GitLab, or a private server in someone’s basement.
That’s not a threat. That’s a promise.
—
Let’s rewind.
SPI launched in 2020 with 2,500 packages. That’s tiny next to PyPI’s 8 million. But Swift isn’t Python. It’s a language that lives mostly inside Apple’s walled garden. Outside iOS, macOS, and watchOS, it’s a niche. A passionate one, sure—but still niche.
So SPI didn’t need millions of packages. It needed reliable ones.
And that’s where it failed.
For years, SPI only indexed packages hosted on GitHub. That made sense at first. GitHub was the default. But as Swift grew beyond Apple’s platforms—Linux, Wasm, even Android—it became a bottleneck. Developers wanted to use packages from GitLab, Bitbucket, or self-hosted Git servers. And SPI? It just… didn’t care.
I remember reading a comment from 2023: "Being attached only to GitHub is not good for the wider Swift community." The response? "This isn’t a current priority."
That’s not a bug. That’s a death sentence for adoption.
And then, in May of this year, Dave Verwer dropped a line on Hacker News:
"The great thing about a registry is that it doesn’t care where the original source is hosted. We will be moving away from that model completely as we work towards this."
That’s not a comment. That’s a manifesto.
And now, Verwer works for Apple.
—
The real shift isn’t ownership. It’s intent.
Apple didn’t buy SPI because they needed a package index. They bought it because they realized: if Swift is going to be a first-class language outside their own ecosystem, they need a registry that doesn’t look like a GitHub plugin.
They need trust.
Right now, SPI shows you: number of contributors, open issues, README, release notes. All pulled from GitHub. That’s fine if you’re building an app for your own use. But if you’re a company shipping to enterprise customers? You need more.
You need to know: Is this package signed? Is it audited? Has it been tested on ARM64 Linux? Has it been scanned for vulnerabilities?
Apple’s got the tools for that. Code signing. Secure builds. CI/CD pipelines that can run on every platform Swift supports—macOS, iOS, watchOS, VisionOS, Linux, Wasm, Android.
They can turn SPI into a security layer.
Not a feature. A foundation.
—
I’ve used SPI to find packages that broke my app. I’ve used it to find ones that saved me weeks of work. I’ve watched it lag for months while developers waited for compatibility data.
That’s not just inconvenient. It’s dangerous.
If a package doesn’t have a build result for iOS 18, and you install it anyway? Your app crashes. Your users leave. Your reputation takes a hit.
And you didn’t even know.
Because SPI didn’t tell you.
Now, Apple can fix that. They can make it impossible to install an untested package. They can make it so you don’t have to guess.
That’s not corporate control. That’s responsibility.
—
I’m not naive. I know Apple will want to control the narrative. They’ll want to push their own tools. They’ll want to make SPI feel like a native Apple product.
But here’s the thing: the Swift community doesn’t want another Apple product.
We want a reliable tool.
If Apple can make SPI work like PyPI—open, transparent, platform-agnostic, and trustworthy—then they’ve done something no other tech giant has managed: they’ve earned the trust of open source.
And that’s worth more than any patent.
So yeah. Apple owns SPI now.
But the real question isn’t who owns it.
It’s whether they’ll make it better.
And I, for one, am willing to give them the benefit of the doubt.
Because if they don’t? The whole ecosystem loses.
And that’s not a risk any of us can afford.
