+1 for backporting concurrency on macOS.
This isn’t just a small quality-of-life improvement to Swift; it’s a fundamental refactoring of how Swift apps are structured.
Asking developers to wait 3 years (on iOS) or 5 years (on macOS) should never have been on the table. The change in the language is too big and too important.
If it’s not backported, we’ll all spend the next few years writing outdated concurrent code because, for all practical purposes, Swift will still lack concurrency.
With all the ABI stability work in place, would it be possible to include the new runtime in a point release? This way, new language features could be used, without having to resort to shims or replacement runtimes and keep all the benefits of one true system runtime.
Isn't the problem due to people not updating, either by choice or by necessity?
policy and technical reasons aside, it seems there is a blurring of os and language that alot of people werent expecting... myself included...
A point update is a much smaller ask that most users don't think about than a major version bump - especially when we're talking about hardware support of the point release version compared to the entire new OS version
I personally have skipped over at least a few major versions of MacOS over the years: Lion, Yosemite, and Sierra. But I have never intentionally skipped a point release.
One point I don’t think I’ve seen raised so far: if concurrency effectively can’t be used in apps for another 3-5 years, it will put those using Swift both in their app and on the server in a really tight spot. If you want to share code between your app and your server, you’ll have to architect things very carefully, or you’ll have your own personal dependency hell as the server ecosystem moves on. That’s not going to be good for the public perception of serverside Swift — after all, one of the best arguments for using Swift on the server is that it’s easy to share code with your app.
There are many devices that cannot update to iOS 13 and I think smaller numbers of devices that can't update to iOS 12 and possibly also some numbers on iOS 11 and 10. If Apple (and I have no idea of the cost of this which would likely be largely in QA) could release point releases for all major versions that have end of support devices I could potentially sell clients on the benefits of a release that will only work if people update but won't absolutely lock out hundreds of thousands of users (we are still supporting iOS 12 currently on several apps).
Obviously this would be a second best to actual backwards support (even if it needed a runtime to be shipped with the app again) for iOS 14 and below. However either approach would allow adoption over the next year rather than probably not before 2023 which is the earliest we could start to migrate any existing apps.
My personal little indie apps are different. I've already started the migration there, the old version should continue to work but updates will only be for iOS 15 and I'd likely have made that change anyway for the latest SwiftUI changes and to avoid having to test across the old version. That just isn't possible in my current professional role where I've only been able to use SwiftUI on one feature so far (conditional compilation and a web view fallback for iOS 12).
Apple, I know it would be a large undertaking (though I don't know how large) but please find a way to support Swift Concurrency on older OSes. This doesn't need to be done from the launch day of iOS 15 though, if an intention and a timeline is announced it could be done late in the year or even into next year. It would still allow much earlier adoption generally. Many libraries won't adopt it while they still need to support the old way
I work in a mid-sized development team that is accustomed to not being able to use new Apple-specific APIs immediately (Combine, SwiftUI etc.) but it came as quite a shock that we probably won’t be able to use the most significant Swift update yet for at least a couple of years.
I understand technically it’s not as simple as “just bundle the runtime” but it certainly seems within the realms of possibility this could have been considered ahead of the iOS 15 release.
knowing all concurrent code we write for the next two years is essentially tech debt whilst the Android guys continue to use coroutines and deploy all the way back to API level 21 leaves a bit of a sour taste.
Without getting into the technical "what about" questions, it is highly disappointing that Apple designed Swift to takes years for devs supporting the App Store to use once it is available. This doesn't even include the years it took to go from proposal to available.
To make an analogy, imagine if Apple said "Here is the new M1X MacBook Pro and it is only available to Windows switchers and Apple employees. This new product will be made available to existing Apple customers to upgrade in 3 years."
This is not an Apple-like experience.
I was going to suggest this as well. I know I usually wait a little bit to install a major version, but I pretty much always install a point release immediately. I think that is pretty common behavior.
I don't think it would need to support the new API, just concurrency primitives. Then people can pretty easily write frameworks and wrappers to make everything work on older systems...
I agree with the sentiment above.
@tkremenek It may be too late to save Async/Await, but you should address this issue so we’re not all stranded again when the next fundamental language feature ships.
When Swift adds a new language feature as wide-reaching and fundamental as Concurrency, support for at least the current versions of iOS and macOS ought to be non-negotiable. It’s work, but it’s important work that makes the new feature ACTUALLY USABLE.
The way concurrency was deployed is frustrating and a really big letdown for the community—especially because the implementation is so good!
I don’t understand this distinction. Could you explain what you mean?
Sure.
There are two major parts to the concurrency story:
The second part is basically what makes up the OS, so porting that would basically be porting a significant portion of the OS. But if they just back port the language primitives to a point release... then people in the community can (with some effort) replicate the API in packages. Without the primitives, there isn't much the community can do...
I want to thank everyone for their impassioned feedback on this thread. I hope everyone feels heard. I, and everyone else who works on Swift, recognize the immense value of Swift concurrency working on earlier OS releases. I'll reiterate again that backward deployment is something we're exploring. That's not a token statement to throw to a group of disappointed people, but a genuine statement of intent. That's not a promise that we can even deliver backward deployment, but we will look into it.
We understand that requiring the latest OS limits the adoption of language features. In general, we try very hard for language features to have maximum availability. But sometimes this is not easy to do. In the case of Swift concurrency, some of the runtime support being alluded to relates to changes to Dispatch to support Swift concurrency. Dispatch is plumbed through both userspace and the kernel, and those changes were important to meet performance (and in some areas, correctness) goals to support Swift concurrency in code that makes heavy use of it.
You have all been heard, and your candid feedback is appreciated. I'm not really sure if there is more that I can say at this point to acknowledge the concerns and points raised. I recognize that many of you feel Swift concurrency remains a far off thing that you cannot consider using for some time because of the requirement on iOS 15. The possibility of backward deployment will be explored — but as I said I cannot promise an outcome at this moment. While many of you may be sour about this, I do ask that you all continue to look at Swift concurrency in some way, as it is still taking full shape and will continue to evolve with community discussion on the road to Swift 6.
Thank you Ted, I appreciate your candid and honest response and I take you at your word. It makes the difference between being heard and listened to (there is a gulf between the two and I care far more about the latter, sorry for the semantics point) .
It would be good to see, maybe even more than concurrency being backwards deployed, how this kind of problem will be prevented in the future. What kind of change could happen, what kind of changes will happen, to improve this aspect of the developer experience.
Is there a real possibility iOS/macOS itself and the way frameworks and the language runtime are shipped and structured will change to directly attack this problem and ensuring this does not happen again?
Same thing as when dealing with a bug or a process issue, normally the question you are asked is “… and what is the strategy to prevent a similar problem to occur again?”. I am not being sarcastic or trying to be insulting if the opinionated part of the process says “look, what have thought about it again and we do not think we can/want/have the business buy in etc… to change all the required moving pieces so do expect this issue to unfortunately happen again”. That will not be popular but honest and people have a chance to “disagree but commit” to the shared vision.
I really appreciate your openness on this!
Neither Combine nor SwiftUI are considered a Swift language feature.
In addition to that, I think that what we see here is a failure in expectation management: Concurrency was (and still is) advertised as language feature. For the time being, it looks more like a runtime feature that has language support.
Just like SwiftUI: Function builders are the language feature, these work on all platforms, SwiftUI is a library that is only available on a few platforms. I never heard anyone expect SwiftUI to be available on older OS versions.
Not sure if irked or troll 
, but I'm nonplussed.