Swift Concurrency back-deploy issue

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.

6 Likes

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.

Doug

2 Likes

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).

We really hope for a quick resolution :crossed_fingers:

1 Like

I encountered the bug with the current version 1.3.1 of Touchgram on the app store, with a user running 14.8.1. I build with XCode 13.1.

I did not explicitly add the Concurrency features but they may have been included via Realm.

1 Like

Yes Realm confirm it's a bug Only TestFlight Crash (iOS ... <15) · Issue #7562 · realm/realm-swift · GitHub

we can no longer target iOS 12. With weak linking flags from Xcode release notes are able to target iOS 13+.

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.

From Xcode 13.3 Beta release notes:

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)

Seems like a fix is in place?

Yes, it’s fixed in Xcode 13.3 beta 1

11 Likes

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! :heart_eyes:

1 Like