Having a visible evolution process for the Swift language is great, but it can be easy to get tied up in the weeds of specific proposals and lose the broader picture, so it was great to see John McCall’s post about the Swift project’s plans for 2023.

You should read the whole post, but I was delighted to see a section on a topic close to my heart: Package registries.

It might have been a while since you heard mention of package registries, but they are a critical part of a robust package ecosystem. Your current interaction with Swift packages is from your package manifest directly through to their git repositories. That works well on a basic level, but while git repositories work exceptionally well for code development, they’re not a great repository for package artefact storage. The most serious problem by far is that they are not immutable. Git tags can be moved around, meaning that what two consumers have as a specific version may not be identical. 😬 There are other problems, though. It’s not great to download the entire commit history of a package to use it, and don’t forget that git repositories can move around or change owner. Tying everything to a git URL isn’t perfect.

Package registries solve that by providing a mechanism to deliver guaranteed, compressed versions of packages from a stable location. Anyone can make a registry, too, so it won’t necessarily be a centralised repository hosted by just one company, although we’ll see how that plays out in reality! The client side of package registry support was implemented in Swift 5.7, but you almost certainly won’t have used it yet, because there is no public package registry, and that’s what Apple is announcing in this post. They will be creating an open-source implementation of a package registry server. Exciting news!

Where does that leave the Swift Package Index? Our plan has always been to support package registries as soon as they gain adoption, and we will work with Apple as they implement the package registry service. Once implemented, we will aggregate and provide discovery for packages, just as we do today.

Swift already has a great package ecosystem, and I couldn’t be happier to hear this announcement. 🎉

Dave Verwer  






iOS SDK Developer @ Stream – Do you want to work on an open-source chat SDK used by hundreds of high-profile companies and startups that impact billions of users? If you are a product-minded engineer and care about software quality, apply on the link below. – Remote (within European timezones) or on-site (Netherlands)

Freelance Interview Engineer (US Only) @ Karat – We're dedicated to improving access in tech. If you are too, join us as a Karat Interview Engineer. As such, you'll conduct technical interviews of developers like you on behalf of our hiring clients (including Duolingo, Indeed, and more) using the Karat Platform and its data-tested questions. – Remote (within US timezones)

Senior Swift (iOS) Developer @ Nord Security – iOS developer has an essential role in growing the NordPass product and a lot of freedom to make an impact. There is plenty of space for experiments and constant improvement. You would be a part of a very ambitious and enthusiastic team which gives a lot of support and encouragement every day. – Remote (within European timezones)

Senior iOS Engineer @ Doximity – Doximity, the medical network used by over 80% of US clinicians, is hiring passionate iOS engineers (fully remote!). Come be part of an amazing product team + work on an app that is constantly evolving. Use your skills (Swift, TCA, Combine) to be an integral part of our growing telemed feature. – Remote (within US timezones)

Native iOS Engineer @ MartianCraft – Are you someone who enjoys collaboratively solving challenging problems? At MartianCraft, we work together to create innovative software for our clients. You’ll always be surrounded by the best and brightest in the industry. – Remote (within US timezones)


And finally...

If you thought web3 was going badly, Twitter is asking web3 to hold its beer. 😬