Swift Concurrency back-deploy issue

Hi,

I have an iOS app that has a minimal deployment target of iOS 11.0. It has some concurrency code with available check as below:

import Foundation

#if swift(>=5.5.2)

@available(iOS 13.0, *)
public func someAsyncMethod() async throws -> ReturnType {
    ...
}

#endif

After compiling with Xcode 13.2 RC, it crashed on an iOS 12.5.5 device with the following message:

dyld: Symbol not found: ___chkstk_darwin
Referenced from: /private/var/containers/Bundle/Application/XXX/XXX.app/Frameworks/libswift_Concurrency.dylib (which was built for iOS 13.0)
Expected in: /usr/lib/libSystem.B.dylib
in /private/var/containers/Bundle/Application/XXX/XXX.app/Frameworks/libswift_Concurrency.dylib

Other test cases:

  • Using Xcode 13.2 RC with iOS 12 simulator cannot reproduce the issue.

  • Using Xcode 13.1 with the same iOS 12.5.5 device cannot reproduce the issue either.

  • Add libswift_Concurrency.tbd to Build Phases - Link Binary With Libraries and set its Status to Optional cannot solve the problem.

Is this a back-deploy issue?

2 Likes

i have same question, do you deal with it?

Possibly similar and/or related:

  • A couple of days ago I added the lib swift_Concurrency.tbd workaround for Xcode 13.1 to fix the crash on iOS 15 when app opens
  • Today, I upgraded to Xcode 13.2 and now app crashes on iOS 14, but only when you go to a view using if #available(iOS 15, *) around code that uses view modifiers like .searchable, .refreshable, .badge, .swipeActions
  • My fix was to remove the swift_Concurrency.tbd lib workaround and turn off optimisations (-Onone)

Xcode 13.2.1 released on Dec 17 has this:

Resolved Issues

  • Fixed an issue where apps built with Xcode 13 or Xcode 13.1 sometimes crashed at launch with an error reporting that the libswift_Concurrency.dylib library was not loaded. This only affected apps that used Swift Concurrency features (such as async / await ), deployed to iOS prior to 15, tvOS prior to 15, or watchOS prior to 8, and had bitcode enabled. (86349088)

No :( I have not found a solution to the problem, I can only remove the concurrency-relevant code and wait for Apple to fix the problem.

Thank you for your reply.
I have tried everything but the problem is still not solved :(

Unfortunately, after testing, Xcode 13.2.1 still has this problem.

Yes, it seems iTunes Connect doesn't remove the concurrency library when deploying to versions predating the back deployment. Anyone on iOS 12 will a crash if the app includes any concurrency code at all. It would be a good idea to report the issues using Feedback and post the number here.

OK, I have submitted a bug report: FB9815225

1 Like

Does the following workaround from Xcode 13.2 release notes help?

Known Issues

  • Apps built with Xcode 13 or Xcode 13.1 that make use of Swift Concurrency features (such as async / await ), deploy to iOS prior to 15, tvOS prior to 15, or watchOS prior to 8, and have bitcode enabled may crash at launch with an error reporting that the libswift_Concurrency.dylib library was not loaded. (86349088) Workaround : Add -Wl,-weak-lswift_Concurrency -Wl,-rpath,/usr/lib/swift to Other Linker Flags in the app’s build settings.

No, that only fixes the crash on iOS 13. 12 and lower still crash.

I've filed FB9815812 as well. This isn't just an ASC issue like I though, it happens when running the app directly from Xcode.

1 Like

Just adding here - failing for us too. The workaround does not work for us.

They are two different issues, one in 13.2, another in 13.2.1. The workaround only applies to 13.2.

At this time, there is no known workaround for the issue with iOS 12.

Doug

Not sure if this fits the topic, but is there a possibility that back-deployed Concurrency support will become available for iOS 12.2 at some point (as that's the first version that bundles a Swift runtime with the OS)?

I wouldn't waste time on that even if that was theoretically possible.

Just to add here - this is also an issue on macOS 10.12 / 10.13 at the moment. Downgrading to Xcode 13.1 seems to have helped for now.

I'm sorry, I know this isn't appreciated, but is there any update on this or the other concurrency deployment issues? This is a rather critical issue, especially for those of us shipping frameworks which may trigger the problem in apps which don't otherwise use the concurrency APIs. Aside from just telling users to lock to the last pre-concurrency release, is there anything that can be done to mitigate the issue? Any timeline on fixes? I really hope we don't have to wait until the spring Xcode release for this to be fixed.

3 Likes

We (Realm) are considering just ripping out all of our async functions and moving them to a separate library to work around this.

2 Likes