Maybe this is not the place to ask since is Apple specific but I'm sure a lot of folks are wondering: will the async features be backwards deployable or only work on the new OSs?
41 Likes
The biggest challenge for me to migrate my real world iOS app is that it requires iOS 15.0 or newer 
5 Likes
If you read the Xcode 13 (beta 1) release notes, macOS 12 and iOS 15 is currently required when using async features, but that is listed under issues. So I assume Apple is attempting to resolve that issue (aka allow some form of backwards deployment of the async feature requirements).
1 Like
Concurrency requires runtime support that does not backward deploy. The release notes imply that this is an "issue" that just needs to be fixed. It's not. It's a feature that would need to be implemented. At this time, folks should assume that concurrency does not backward deploy. That said, everyone is aware of the value of it doing so, and is something that is being explored/considered.
35 Likes
This is a language feature or an iOS version feature.
3 Likes
It is tempting to try to just put it into one bucket or another, but respectfully I feel that this is an oversimplification.
Concurrency, as a whole, is a language feature. It requires specific runtime support. Most languages, including Objective-C and C++, have language runtimes that provide logic that power many language features. On Apple platforms, that runtime support ships with the OS.
In the case of backward deployment on Apple platforms, it is about finding a way to provide the needed runtime components for concurrency when the underlying OS does not provide it. I'm not saying that is or isn't possible; Swift definitely has provided backward deployed runtime support for a variety of features before.
All I am saying is that is that backward deployment of concurrency earlier than iOS 15, as of right now, does not exist, and that the Xcode 13 release notes may accidentally be interpreted that this is a "known issue" rather than something that just isn't there. As folks need to make choices regarding their applications' minimum deployment targets, I just wanted to clarify that concurrency, as of right now, requires iOS 15 and higher.
23 Likes
Damn, I guess that means I and many others won't be using it for a few years 
36 Likes
Exactly. On macOS, it's not entirely uncommon to support versions all the way back to macOS 10.11 or 10.12. Each year dropping one version means that you can't use this feature until 5 years from now (!). On iOS, most companies (that I've worked with) require backward compatibility to iOS 12 (at least). Each year, dropping one version means at least 3 years of not using this - and to be honest this is something I've really been looking forward to...
12 Likes
I get there are reasons for this stance, but it seems like Apple is not really acknowledging the reality for developers in companies and mid sized teams that cannot act like small indies focused on one OS at a time or like internal teams in Apple maybe.
Seeing compose be developed in the open and back deploy back to Android 5 and Kotlin advance their concurrency efforts again backdeploying to very old Android versions and more and more Android OS components being updated on the Play Store and not requiring OS updates are reality for the industry I feel sometimes Apple is ignoringā¦ same thing about Enteprise environments for devs, continuous delivery and automation expectations, etcā¦ it would be nice if we could follow Appleās train as they balze the new trail, but the reality is that in most mid to large software companies that are not mostly native app focused (very few) the native app developers are the thorny pariah / under represented and a bit resented minority that always does their own thing and does not really get with the program.
Sometimes Apple makes it very very hard not to say āoh well just use something like Flutter, Cordova/PhoneGap, or React Nativeā for the developers that would want to work on the native frameworks directly and give the best possible experience to the users.
36 Likes
If it requires special runtime support that will come out with iOS 15 and MacOS 12 then how was it possible to use those features with development toolchains? I was using async/await on Big Sur and it worked very well.
I am not sure about actors but supporting async await on older systems would come a long way and developers could replace their callback code.
If the features are not backwards compatible that means that a large portion of developers won't be able to use them for a couple of years as usually clients want to support at least 3 last OS versions.
10 Likes
This is especially important as MacOS 12 drops support for some machines, so that many users are not able to upgrade (I also still have a 2013 MacBook Air which works perfectly, but which will have to stay on MacOS 11).
3 Likes
I strongly believe that Swift Team needs to find a way to backward deploy runtime features. It's such a disappointment to find out that great features like these won't be usable by many of us developers for years to come.
29 Likes
I had no idea that Swift concurrency required iOS 15. It's on me to not have gotten that information in advance, but I suspect that it's going to be "news" for many Swift developers, and it's going to be terrible news because, in practice, the vast majority of iOS developers are simply not going to be able to use these features for years, and that I guess includes library authors, that won't be able to update libraries (that use asynchronous code) with async/await. Please explore/consider enabling developers to actually use these features in production code without waiting for years.
EDIT: I realized that, given that all iOS 13/14 compatible devices are still compatible with iOS 15 it's not really going to take years. It's OT, but ditching iOS 12 is going to be the big step for many developers, that could mean jumping directly to iOS 15 without leaving anybody out.
10 Likes
I think that's why v15 updates compatible with all v14 devices, apple make more old devices capable of running the latest version of OS; and the new features like concurrency could be deployed to them gradually.
Of course it needs some time to upgrade hundreds of millions iDevices with latest OS, 90% in one year is OK for most cases.
1 Like
It's certainly came as an unpleasant surprise to me that Swift 5.5 concurrency features require the latest OSes. Given that most (all?) new Swift features that have landed in the previous Swift 5.x releases did not have this limitation, it makes it very confusing. I had no idea that new Swift features could be tied to minimum OS versions 
7 Likes
Hi everyone ā I moved the discussion of back deployment to a separate thread, do avoid crowding out other discussion about the feature on the original thread.
17 Likes
The lack of support for anything earlier than this years OS versions will definitely stop my company from investing any time & effort in Swift Concurrency for several years.
We support users on older OSs because a) its what our clients want, and b) its the right thing to do.
Ideally I'd support 2 years back (ie move to iOS 13 minimum this year) but in reality we go back as far as iOS 10 and get push back each time we drop a version.
That means the plans I had for a major refactoring with Swift 5.5 concurrency will be dropped - there's no way we want a code base with #if available all over it - the idea of the concurrency changes was to make the code cleaner.
Internal macOS tools might get to use it, but probably not encouraged as it will disconnect from the core iOS work and change patterns of development.
See you in ~2025...
16 Likes
I'm glad to hear this is being explored! If there is any way to make this happen, the community would be incredibly appreciative.
Most places I've worked support [current iOS major version] minus 2 or 3. That's a long time to have to wait to touch any of this, especially given the enormous benefits. Yes, we could #if available, add complementary async APIs, etc. But the reality is we don't have the bandwidth to support so much duplicate surface area.
27 Likes
In echo a lot of what is being said here. Apple really need to find a way for apps to bundle runtime extensions to allow language features like async/await to work on older iOS versions. Gosh Google have been doing Support Libraries on Android for years.
7 Likes
Limiting async/await & actors to macOS 12 and iOS 15 will severely damage the uptake and impact of this game changing language feature.
It seems disingenuous to argue that only the new OSās provide the foundation for this language feature, as has been pointed out above, the tool chain currently allows building and testing on Big Sur.
It is understandable that OS APIās offering async functions or properties would not be available, such as await URLSession or others, but that should not limit the language features being available on older OSs. Swift Concurrency has been designed to be interoperable with older callback based API.
I truly hope that backwards compatibility is an āissueā which will be addressed in XCode 13 over the summer.
6 Likes