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.
Wow, that is great! Thank you so much for that!!! The .zip-file of the Beta is already extracting...
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.
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!
wow, i am speechless.. didn't expect this so soon, and thank you so much! would also like to know about pitfalls if any.
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.
totally reasonable price, i'm buying.
Does this have any impact when running the same binary on macOS 12 or later, or are the bundled libraries ignored there?
This is amazing news. Huge thanks to everyone involved!
A couple of questions:
Same for iOS. Will the App Store strip the concurrency library when downloading our app on iOS 15? or do iOS 15 users have to pay the price too?
- Does this mean that old OSs won't have the memory corruption issues since the embeded library will have the fixes already?
I'm really happy to hear this! Thank you everyone for making this possible!
Thanks for everyone involved in making this happen for all the hard work. Much appreciated!
Thank you so much! What a great day!
The bundled concurrency library will be ignored in favor of the OS runtime on newer OSes, similar to how the core Swift runtime libraries work for back-deployed Swift apps.
It'll get stripped out.
Most of those fixes were in the compiler, not the concurrency runtime. But yes, the embedded concurrency library has addressed all known runtime issues.
Great news! Thanks for all the hard work from everyone who made it happen.
It looks like Xcode's
builtin-swiftStdLibTool copies the concurrency runtime using a new
--back-deploy-swift-concurrency flag that the standalone executable in
XcodeDefault.xctoolchain/usr/bin/swift-stdlib-tool doesn't support (and the source code for that tool on GitHub was last updated 2 years ago). That tool is critical for other build systems like Bazel to bundle the Swift runtime the same way as Xcode does—is there any chance the source code could be updated (and more importantly, the binary in Xcode updated to match)?
(I also filed FB9727485 since what goes into Xcode is usually out of scope for Swift forum discussions.)
Please report your findings!
(This question is important for library maintainers, Can we ship code that supports Xcode 12, 13.0, 13.1 and 13.2 or not? And if yes, will it ruin our code base?)
If you're okay limiting your concurrency support to Xcode 13.2 or greater, you can use
#if compiler(>=5.5.2) rather than
#if swift(>=5.5) to limit your APIs. However, there doesn't seem to be a way to conditionalize the availability checks. That said, the Concurrency types are now properly available back to the earlier OSes, but the various framework extensions, like
URLSession's async request methods, are not.
I guess I'll be OK with this for GRDB. Do you already have a plan for Alamofire?
Just wanted to say thank you for all involved in making this happen. You not only listened to the community but delivered the feature in light speed. You guys are stars!
I’m not saying they’re not rockstars (they are!) but I don’t think this was a situation where they folded to community pressure, but rather one where a feature took longer to develop than hoped and they couldn’t promise it and be wrong without losing a lot of goodwill with the community. They could however not promise it and still deliver it later and then release it to (well-deserved) cheers.