Swift concurrency back deployment

Evolution Discussion
1

So @Douglas_Gregor 's PR to allow the concurrency library for back deployment was merged :heart: but it's not clear to me how this will actually be used.

This looks to me like a build option that has to be specified when building Swift, and not something that could be used by a developer using Swift.

Is there any news on whether concurrency will in fact be back deployed to older OSes?

NOTE: I would like to request that this thread just discuss the technical details involved, and not descend into an unproductive discussion about what Apple should or should not do, or speculation about their motives :pray:

19 Likes
2

It's referred to as a "build-script option", which is new to me.

--back-deploy-concurrency

3

The PR you linked is one of dozens of changes needed to make this work, which have been landing over the last few weeks and span LLVM, Clang, and Swift.

The specific PR enabled the build of back-deployment versions of the Swift concurrency library. These are different versions of the shared libraries (libswift_Concurrency.dylib) that would have to be embedded in apps for those apps to run on older OS's, much like the embedded shared libraries one gets for the Swift standard library and overlays if you build an app with a deployment target that predates Swift being in the OS (e.g., iOS 11). But these are harder, because they need to work with older Swift runtimes and standard libraries.

Subsequent PRs have changed the way the compiler generates code for back-deployed binaries (because we currently require a Swift 5.5 runtime), fixed up the back-deployed versions of the shared libraries to work on older OSs, and added compatibility code to monkey-patch older Swift runtimes. Some things run (as of today), but others still crash.

You're certainly welcome to follow along on GitHub as we work through the issues, and ask questions if something you see there looks technically interesting, but we're not ready to commit to an answer to this:

Is there any news on whether concurrency will in fact be back deployed to older OSes?

because, as we said before, it's technically challenging and we're not 100% sure it'll work out.

Doug

95 Likes
4

In any case, thanks for the heads-up and your obviously continued work on that issue!

1 Like
5

Thanks for the detailed reply Doug :+1:

6

Is there any larger thread we can follow to track the progress?

7

There’s no thread per se. Work continues in the main GitHub repository, with a bunch of stuff having been recently merged. There are still known crashes at runtime, although most of the regression tests are successfully running now.

27 Likes
8

Any news about this? Since I know about this I can't wait for it (especially because Apple does not allow me to upgrade my fully working MacBook Pro to Monterey)

1 Like
9

It appears this has shipped with the Xcode 13.2 beta.

  • You can now use Swift Concurrency in applications that deploy to macOS 10.15, iOS 13, tvOS 13, and watchOS 6 or newer. This support includes async/await, actors, global actors, structured concurrency, and the task APIs. (70738378)

One question I have is whether there's a way to properly conditionalize concurrency code so that it can build in Xcode 13.0/.1 and 13.2 at the same time. I can't think of one offhand.

16 Likes
10

Wow, a massive, massive thank you to the core team for getting this done! This makes a HUGE difference to a lot of us.

8 Likes
11

Seriously! Thank you to everyone involved in making this happen. This is huge. :clap:

3 Likes
12

@Douglas_Gregor Incredible news. Sooner than I had hoped. Many many thanks. Are there any pitfalls or things we should look out for when deploying back to those older versions?

1 Like
13

I think most libraries (like NIO) are using

#if canImport(_concurrency)

I imagine that will still work since the 13.0 and 13.1 don’t know how to import it.

2 Likes
14

13.0/.1 know how to import concurrency, it's the OS availability I'm worried about. Assuming the concurrency types have had their availability set back to the new deployment target, using the new target on 13.0/.1 would cause errors. Guess I'll check once the download is complete.

1 Like
15

Incredible news. This makes a huge difference in my development plans going forward, because my organization wouldn't move to Monterey for users for many months now.

2 Likes
16

Wow, that is great! Thank you so much for that!!! The .zip-file of the Beta is already extracting... :smiley:

17

Thank you very much indeed for what must've been a long and arduous journey! This will have a huge impact on the Swift ecosystem as a whole.

18

Thanks! Means a world, will change the way we develop apps right now. I'll be able to adopt concurrency in a month, not in a year. Feel like Christmas!

1 Like
19

wow, i am speechless.. didn't expect this so soon, and thank you so much! would also like to know about pitfalls if any.

20

The main tradeoff would be that, in order to deploy to older OSes, your app will need to bundle a copy of the Swift 5.5 concurrency runtime for older OSes, similar to how back-deploying Swift to OSes before the stable ABI requires bundling a copy of the Swift 5.0 runtime.

23 Likes