When swift-numerics debuted in 2019, Steve Canon mentioned that you might have expected some of the APIs to be a part of the standard library. He talked about a few reasons why, but the primary benefits were that more people could be involved with the API design and that enhancements to new APIs could be independent of the slower pace of the standard library.

At first, it wasn’t clear whether this was a one-off experiment or part of a new strategy, but it’s clear now. It’s a strategy, and in my eyes, it’s been a great success.

We’ve seen several other packages incubated in the same way since then. They added swift-crypto just a few months later, then swift-atomics, swift-system, swift-algorithms, swift-collections, swift-distributed-actors, to swift-async-algorithms, released last Friday.

Apple also released a package in early 2020 named swift-standard-library-preview, which, as the README describes:

The Swift Standard Library Preview package provides access to new functionality that has been accepted into the standard library through the Swift Evolution process, but has not yet shipped as part of an official Swift release.

A standard library feeder package is an interesting idea, but it’s not seen many updates in the last two years. Maybe it was an experiment that didn’t quite pan out, and if it is, that’s OK. I’m reasonably indifferent as to whether the APIs end up in the standard library or stay as separate packages. There are advantages and disadvantages to both approaches.

I won’t go into too much detail here on what I consider the pros and cons of each approach are, but I’ll give a couple of examples. If Apple integrated these APIs into the standard library, they would be easier to discover as Apple would document them alongside the rest of the standard library where people are already reading. On the other hand, it’s much easier to accept contributions to individual open-source packages, and having separate projects enables more focused discussions around their functionality.

Whether this approach stays as is, with separate packages seeming to win out, or whether they act as a feeder mechanism for the standard library as their APIs stabilise, I thought it was worth highlighting what’s happening, as it’s the kind of thing that may have slipped past some of us. Either way, I like what’s happening and hope it continues.

Dave Verwer  






Mobile Architect @ Bounteous – We are seeking a Mobile Architect to design and lead the development of our iOS and Android applications. Strong candidates will be able to direct the design of new applications from conception to completion, mentor and manage technical teams, and possess strong client and communication skills. – Remote (within US timezones) or on-site (Canada or United States)

Senior iOS Developer @ Flightradar24 – With over 2 million daily users, Flightradar24 is the world’s most popular flight tracking service. As a member of our small iOS team, you'll work on every part of our app and have a lot of impact. We care about code quality and building the best possible product, and so should you. – Remote (within European timezones)


There are plenty more jobs available over at the main iOS Dev Jobs site. Or, if you're hiring, don't forget you can post your job for free!


And finally...

On this day in 1976. 😵