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.

5 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
Terms of Service

Privacy Policy

Cookie Policy