Artifact management has been a solved problem in mobile CI for years, with one notable exception. As we covered in 5 Advantages of Using Artifact Management Tools in CI Pipelines for Mobile Applications, routing dependencies through a central repository gives teams better version control, stronger security, faster builds, and real traceability. Android teams have been doing this with Gradle and hosted Maven repositories for a long time. iOS teams could do it with CocoaPods.
The exception was Swift Package Manager. Despite SPM becoming the default choice for new iOS projects, there was no registry standard for artifact managers to support, so there was nothing for Nexus or any comparable tool to sit in front of. This was a gap in the ecosystem rather than in any one product, and it left iOS teams with a governance blind spot precisely where their most modern projects were.
That gap is now closed. Sonatype Nexus Repository can act as a Swift Package Registry, which means SPM dependencies can be cached, hosted, grouped, scanned, and versioned exactly like every other format in your organization.
Why Swift Package Manager Was Hard to Govern
Historically, Swift Package Manager resolved dependencies by cloning Git repositories directly. There was no registry layer to intercept, no stable package coordinates to govern, and nothing meaningful to cache. Every build reached out to the public internet, and every dependency was identified by a URL that could move, change, or disappear.
The Swift Package Registry standard changed that model. Packages are addressed by a registry identity rather than a repository URL, and they are served by a registry that any tool can implement. Because Nexus implements that standard, SPM now behaves like Maven, npm, or PyPI in your supply chain: one governed source, one policy surface, one cache.
For an enterprise iOS team, this is less a convenience feature than a compliance milestone. The packages that ship inside your app are no longer resolved from wherever a manifest happens to point.
Swift Proxy, Hosted, and Group Repositories in Nexus
Nexus offers three kinds of Swift repository, and most teams will end up using all three:
- Swift proxy sits in front of external packages and caches them as they are requested. This is your governed door to the open source ecosystem. Available in Nexus 3.89.0 and later.
- Swift hosted stores your own internal packages with proper versioning and metadata. Available in Nexus 3.90.0 and later.
- Swift group combines the other two behind a single address, so clients only ever need to know one URL. Available in Nexus 3.91.0 and later.
Swift repositories are supported in both the Community and Pro editions of Nexus. On the client side, SPM 5.7 or later is required and Sonatype recommends 5.9 or later, which in practice means keeping your build agents on a current Xcode toolchain.
The group repository deserves particular attention. When developers and CI agents all point at the same group address, adding an internal package or changing where external packages come from becomes a configuration change inside Nexus, not a pull request against every repository in your organization.
One constraint to plan around: proxy repositories can only mirror sources that implement the Swift Package Registry standard. Since there is currently no official public Swift registry, this effectively means GitHub. That covers the overwhelming majority of real-world SPM dependencies, but it is better designed around than discovered later.
What Nexus SPM Support Changes for iOS Teams
Dependencies come from infrastructure you control. Instead of every build agent pulling from public sources, packages are served from your own Nexus instance. Network outages, rate limits, and upstream repositories that vanish stop being release-day risks.
Security scanning finally covers iOS. Once SPM packages flow through Nexus, they enter the same vulnerability and license policy workflows your backend and Android teams already rely on. Approving a package becomes an organizational decision rather than something that happens quietly inside a pull request.
Internal packages get a real distribution channel. Shared modules such as a design system, a networking layer, or a common analytics wrapper can be published as versioned artifacts instead of being wired together through Git submodules and branch pins. Consumers depend on a version number, not on someone else's default branch.
Builds get faster and more predictable. Cached packages resolve from a nearby server rather than across the public internet, which flattens the variability that makes CI build times hard to reason about.
Traceability becomes automatic. Every package that entered a build has a record: which version, when, and requested by whom. That is exactly the evidence an audit asks for, and exactly what nobody wants to reconstruct after the fact.
Using a Nexus SPM Registry in Appcircle iOS Pipelines
Appcircle is built for mobile, so the value of connecting it to a Swift registry shows up in the parts of the pipeline that iOS teams actually spend their time on.
Your project structure stays as it is. Registry-based and Git-based dependencies can coexist in the same project, so migration happens package by package on your schedule rather than as a single disruptive commit. Nothing about your Xcode project has to be restructured to start pulling from Nexus.
Registry access becomes part of the workflow, not tribal knowledge. Appcircle's Nexus integration handles registry configuration and credentials as ordinary workflow steps. New team members and new build profiles inherit a working setup instead of a document that explains how to recreate one.
Credentials stay out of your repository and out of your logs. Registry access runs through service credentials stored as secrets in Appcircle, masked in build output. No developer needs a personal token on a build machine, and no configuration file with embedded credentials needs to be committed.
The same pipeline covers every iOS target. Whether you are building native iOS, React Native, or Flutter projects that carry Swift package dependencies, dependency resolution is configured once per profile and behaves consistently across all of them.
It works in air-gapped and regulated environments. For teams running Self-Hosted Appcircle alongside an on-premise Nexus, this combination closes the loop: source, dependencies, build, signing, and distribution all stay inside your own network. That is often the specific requirement that made public package resolution a blocker in the first place.
Android and iOS finally share one dependency story. Gradle already resolves from Nexus. Now the iOS side of the same Appcircle organization does too, which means one artifact policy, one set of approvals, and one place to look when someone asks where a library came from.
Before You Start: SPM Registry Migration Considerations
A few decisions are worth settling with your team before the first build:
Confirm the version prerequisites. The repository type you need determines the minimum Nexus version, and your build agents need a Swift toolchain of 5.7 or later. Verify both before committing to a timeline.
Decide who owns registry credentials. Access should go through service credentials rather than personal accounts. It is a small decision that becomes painful to unwind once several pipelines depend on it.
Sort out certificates early. If your Nexus instance runs behind a self signed certificate, that certificate needs to be properly trusted on your build machines. Unlike some other package managers, SPM offers no shortcut here. For self-hosted runners, see the custom certificates guide.
Verify the whole dependency graph. It is possible to end up in a state where your direct dependencies come from Nexus while their own dependencies quietly go elsewhere. Confirm that the full tree resolves through your registry before treating the migration as finished. Sonatype's Swift CLI documentation covers the resolution behavior in detail.
If Your Nexus Instance Is Below 3.89.0
Swift repository support requires Nexus 3.89.0 or later depending on the repository type, and there is no backport for older instances. If upgrading is not on the near-term roadmap, the interim approach is the one teams have been using all along: gather the packages you need into a private Git repository that only your organization can reach, and pull from there.
It works, and it keeps external network access out of the build. But it is maintenance you own. Those packages need to be reviewed and refreshed on a schedule, or your team ends up pinned to versions nobody remembers choosing. Treat it as a bridge rather than a destination.
Conclusion
The case for artifact management in mobile CI has not changed: centralized dependencies, enforced policy, faster and more repeatable builds. What has changed is that iOS teams working with Swift Package Manager can now make that case without an asterisk.
With Nexus acting as a Swift Package Registry and Appcircle resolving dependencies through it, the packages that ship inside your app come from infrastructure you own, reviewed against policies you set, with a record of how they got there. For iOS teams in regulated industries, that is the difference between a supply chain you can describe and one you can prove.
Frequently Asked Questions
1. Which Nexus version do I need for Swift package support?
It depends on the repository type. Proxy repositories require 3.89.0 or later, hosted repositories 3.90.0 or later, and group repositories 3.91.0 or later. Since most teams want a group repository in front of both a proxy and a hosted repository, 3.91.0 is the practical target.
2. Do I need Nexus Pro?
No. Swift repositories are available in both the Community and Pro editions. Pro adds capabilities such as user tokens that many teams prefer for CI authentication, but the format itself is not gated behind a license.
3. Can I keep some dependencies on Git URLs while moving others to the registry?
Yes. Registry identities and Git URLs can coexist in the same project manifest, which is what makes an incremental migration possible.
4. Does this replace CocoaPods support in Nexus?
No. Nexus continues to support CocoaPods, and many projects use both. Swift package support extends the same governance to SPM dependencies rather than replacing anything.
5. Can I proxy a registry other than GitHub?
Not currently. Swift proxy repositories only support remote sources that implement the Swift Package Registry protocol, and there is no official public Swift registry today, so GitHub is the supported remote.
6. Can I publish my own internal Swift packages to Nexus?
Yes, through a Swift hosted repository. Internal packages get versioned artifacts and metadata, which is a meaningful upgrade over sharing modules through Git submodules. See Sonatype's registry configuration documentation for the setup.
7. What about Carthage?
Carthage is not supported by Nexus. For projects still on Carthage, migrating to SPM is the path that brings dependencies under registry governance.
