Announcement: Vapor 4 will no longer support macOS 10.14

This is more an announcement to make people aware but happy to open it up to discussions. Over the last week or so, there have been two developments that will make the case for dropping support for macOS 10.14 compelling.

Note - this has no effect for any Linux distros

First - Apple released the new Swift Crypto library last week which has a minimum requirement of 10.15 due to it being built on top of CryptoKit. Whilst there has been some discussion about using BoringSSL to polyfill to older macOS versions, this doesn't seem likely, at least in the short term. Vapor really, really, really does not want to maintain it's own Crypto library and using a shared, 'recommended', Crypto library across all of server-side Swift has much the same benefits as everyone using NIO. This also allows Vapor to completely remove any dependency on OpenSSL, which would make it easier for people to build Vapor projects.

Second, Xcode 11.4 Beta was released yesterday which includes the first Xcode integrated version of Swift 5.2. It's likely that Vapor 4 will require Swift 5.2 and since Xcode 11.4 requires macOS 10.15, it provides another reason to make Vapor 4, 10.15 and greater.

15 Likes

When will vapor 4.0 be officially released? :smile:

Soon :tm: !

Some point after Xcode 11.4 is released, depends on bugs found etc

2 Likes

That's great to hear that Vapor will move towards using a shared recommended libraries instead of maintaining their own. Looking forward to the 4.0 release!

Do we already know which features will require runtime support from 10.15.4? Because so far, going through a few of those mentioned in the CHANGELOG, they all work when running under 10.14.6.

If none of the new features require runtime support which is not available in earlier versions of the OS, then dropping 10.14 is pointless.

Edit: I mean, crypto is one thing, but if that's the only thing, I guess it would make sense to allow polyfilling it

Polyfilling Crypto (at least Vapor doing it) would be basically the same as just not using Swift Crypto since Vapor would have to maintain, update and write the filler etc. If Swift Crypto can provide it, then that would help

Well, it's completely understandable. It just would be nice to be able to "use the old package" as polyfill, even if it is not supported by Vapor anymore. I mean if that is the only thing that would bump the deployment target.