Disclosure: I built Perchly, the tool this post ends up recommending. It started as a fix for my own problem, not a product — and this is the honest version of how it happened.
If your team has more than one Swift package that always version together, you've probably hit this: either you split them into separate git repos and juggle a release per package on every single change, or you keep one repo and lean on git submodules / git-subtree hacks just to make each package independently resolvable by SwiftPM. Neither is great, and I kept seeing people run into it — including a Stack Overflow question from someone trying to split a "newskit"/"the-sun" style theming package into independently versioned pieces without blowing up their repo structure.
The root cause is that swift package-registry publish (and Xcode's dependency resolution) publishes whatever package lives at a given path — so each package you want to version independently needs its own Package.swift, not a shared target inside one giant manifest. That part is actually fine once you know it. The part that's genuinely annoying is that Apple's own answer to "how do I host that privately for my team" is SE-0292, a real open protocol — but there was no simple, free way to actually run one if you're not Artifactory/JFrog-scale.
So I built a private SPM registry that implements SE-0292 for real, not a wrapper around git.
Why not just use a private GitHub repo as a dependency
That works fine for exactly one package. The moment you have several related packages that need independent versions in one repo, you're stuck choosing between:
- Splitting into N repos, so every cross-cutting change becomes N pull requests and N releases
- Keeping one repo and hacking around it with git-subtree splits or submodules, which nobody enjoys maintaining
A real registry sidesteps this entirely. Each package resolves and versions independently regardless of how your source is actually organized on disk.
What "real SE-0292" gets you
Because Perchly speaks the actual SE-0292 registry protocol instead of a proxy or a plugin, the standard SwiftPM CLI just works, unmodified:
# once per machine/CI runner
swift package-registry set https://registry.perchly.dev
# from inside a package directory
swift package-registry publish my-org.network-kit 1.0.0
Depending on it elsewhere is just:
.package(id: "my-org.network-kit", from: "1.0.0")
No custom tooling, no forked SwiftPM, no post-install scripts. It even works through Xcode's own "Add Package" dependency resolution once you've run the set command once — Xcode doesn't need to know Perchly exists.
For the actual monorepo case, splitting into independently publishable packages just means giving each one its own Package.swift:
my-monorepo/
├── Sources/
│ ├── newskit/
│ │ ├── Package.swift ← name: "newskit"
│ │ └── Sources/newskit/...
│ └── the-sun/
│ ├── Package.swift ← name: "the-sun"
│ └── Sources/the-sun/...
They still live in one git repo. Nothing about this requires separate repos, submodules, or subtree splits — you just publish each path with its own identifier and version:
swift package-registry publish --package-path Sources/newskit my-org.newskit 1.0.0
swift package-registry publish --package-path Sources/the-sun my-org.the-sun 1.0.0
I also open-sourced a small CLI, perchly-cli, that diffs the last publish against HEAD, figures out which package directories actually changed, and bumps + publishes only those — so you're not doing that by hand every release once you have more than two or three packages.
Other things it does
- GitHub and GitLab OAuth to sign in — no separate account/password to manage
- Versions are immutable once published (no silently overwriting
1.0.0out from under someone who's already pinned to it) - Free plan: 3 members, 5 packages, 2GB storage, no credit card
- Paid tiers exist for bigger teams, but the whole point of the free tier is that a small team shouldn't need to talk to sales to stop fighting git-subtree
What it deliberately doesn't do (yet)
No package signing yet (SwiftPM prints an "is not signed" warning but still resolves fine — that's an SwiftPM-level thing, not specific to Perchly). No self-hosted GitLab instance support, no per-package ACLs. It's intentionally a small, focused tool, not an attempt to out-feature Artifactory.
If you want to poke at it: perchly.dev. Feedback, especially "this doesn't work for my setup because X," is genuinely useful to me right now.
