This story of a CocoaPods security problem set me wondering about the state of dependency management in Swift again this week.

First, the security issue was a serious supply chain vulnerability, with potential attackers able to claim ownership of abandoned libraries. It stemmed from the migration to the CocoaPods “trunk” system in 2014 and while this image doesn’t give a date for when the vulnerability started, I think the public API (and therefore the vulnerability) has been available for several years.

I don’t write this to criticise CocoaPods. Once reported it was handled responsibly, fixed quickly, and there was no evidence of it being exploited. But, the truth is that CocoaPods doesn’t have as many eyes on its maintenance as it used to and it’ll only lose more popularity as more people adopt SwiftPM. The maintenance team are all volunteers and do a great job of a thankless task, but SwiftPM is the future.

But is SwiftPM safe from supply chain attacks? Not in the way that 99% of people use it. There’s an obvious supply chain vulnerability which is implicit in importing a dependency directly from tags in a git repository with SwiftPM. Git tags are not immutable and can be moved at the package author’s convenience, so if you built SomeDependency v3.2.4 into your app and shipped it to the store, it’s not guaranteed to be the same code I have in my app if I also depend on SomeDependency v3.2.4. Yes, that’s not in the same ballpark of security issues as being able to take ownership of someone else’s package, but it’s still serious enough.

So what’s the solution? Do we need a whole new package manager? No, we just need to use SwiftPM package registries. Supported since Swift 5.7, SwiftPM has full support for package registries. Package registries treat versions of packages as immutable and serve zipped archives of packages rather than needing to check out a git repository. They are quicker in use and inherently more secure.

Some artefact hosting companies have even shipped registry implementations as part of their products. JFrog Artifactory announced support in 2022, AWS CodeArtifact in 2023, and just this May Cloudsmith joined in.

What doesn’t yet exist is a public open-source package registry hosting all the packages in, for example, a package index. Sven and I are very aware of that and have been considering whether it might be something we could add to the Swift Package Index. We’ve got nothing to announce today, but when everyone can use a package registry rather than git-based source code dependencies, we’ll get a step forward in dependency management for Swift, too.

Dave Verwer  



Business and Marketing


Software Engineer, iOS @ amo – Amo values speed, creativity, and high performance. Focused on meaningful social apps, they prioritize creation over consumption and simple, fun experiences. The diverse, skilled team uses a modular monorepo tech stack with Rust, Bazel, and RxSwift, leveraging efficient data processing on GCP. – On-site (France)

Senior iOS Engineer @ Leica Camera AG – We are looking for an experienced iOS developer to join our team. We are working as a small, fast-moving unit within Leica, so we are looking for team members who can take charge of projects and work independently. It’s a bonus (but not required) if you are passionate about photography! – Remote (within European timezones) or on-site (Germany)

Product Engineer (iOS, Full-Stack) @ Emerge Tools – Have a huge impact working with our small, technically elite team (just 8), build tools used some of the biggest & best mobile teams in the world (DoorDash, Square, Spotify, Duolingo, Tinder, Bumble) – Remote (within US timezones)

Senior iOS Developer @ Komoot – Your work will contribute to helping millions of people enjoy lovely outdoor experiences and you can work from wherever you want, be it a beach, the mountains, your house, or anywhere else that lies in any time zone between UTC-1 and UTC+3. – Remote (within European timezones)


Are you looking for a job? Get yourself over to iOS Dev Jobs where even more opportunities await!


And finally...

Tell me you’re a Swift developer without telling me you’re a Swift developer. 😂