Thanks for mentioning that. Moving async apis to an external library is indeed a possible workaround for libs that have introduced async apis as "leaves", which means that nothing internally depends on them, and that they are all "conveniences" around other non-async public apis.
But other libraries won't be able to do that. And I have questions about retroactive conformances to Sendable, especially for protocols. Ultimately, moving async apis to external libraries hinders further integration of Swift concurrency and future developments.
Swift Concurrency has never been described as a breaking language feature that requires libraries to bump their OS requirements. Library authors have done their job with #if and conditional compilation. That's why the fix is seen as belonging to Xcode or Swift.
FYI for folks who are worried about this slipping into their binaries while they still deploy to iOS 12, you can validate that you shouldn't hit this issue by checking that the output of otool -L path/to/foo.app/foo doesn't contain libswift_Concurrency.
Sorry, we don't know of any mitigations nor can we publish a timeline when this will be fixed. I know it's frustrating. Folks deploying prior to iOS 13 / macOS 10.15 will likely need to stay on Xcode 13.1 or not expose themselves to any async.
Thanks for acknowledging that this need to be "fixed", Doug!
That's both good and bad news:
It's good news because we can hope for a fix to come eventually.
It's also bad news because this is a strong incentive to do nothing, from the point of view of library authors. This means that library users will face crashes, and won't be able to upgrade their libs. This also means that library authors will have to support those users, and also apply eventual critical patches and fixes in two branches of their libs (the one without async, and the one with async).
may trigger the problem in apps which don't otherwise use the concurrency APIs
That's exactly what happened to me - Realm brought them in and Touchgram 1.3.1 failed as a result. As I don't install any analytics or crash tracking, it took an in-person encounter with someone running 14.8 to work out what was happening.
Lessons learned, even if Testflight is of limited use (iMessage app extensions are more complicated case), it's still worth doing a smoke test. Also, keep some devices around on older iOS - I had nothing left between 12.5 and 15.0. Took 10 tries to find an old iPhone on eBay that's not been updated from 14 to 15.
Apps that use back-deployed Swift Concurrency on operating systems prior to macOS 10.15, iOS 13, tvOS 13, or watchOS 6 no longer crash on launch. (87789769)
This is wonderful, thank you so much @Douglas_Gregor and team. My team encountered this issue today, read through this thread with increasing concern, then cheered at the surprise happy ending!
