Async Await crash on iOS14 with Xcode 13.2.1

@Keith

Thanks a lot! Downloading 13.1 now.

Have a good day!

@igorvoytovich Did you solve the issue with the 13.1 or 13.0 version?

I have the exact same situation with the Async Await code running on iOS 14

FYI I had the same issue on Big Sur with Xcode 13.2.1. Embedding libswift_Concurrency.dylib from Xcode 13.3 fixes the issue. 13.3 only runs on Monterey so this is good enough for me since its just an internal tool.

In my case, I continue to receive the aforementioned crash in Xcode 13.3 beta 3.

Note, above, there has been a discussion about problems limited to physical devices, whereas others are experiencing the problem on simulators, too. I am seeing it on both.

There are multiple crashes related to the async features. Which one are you talking about? So far, all of my testing shows the crashes caused by simply using async features on older OSes have been fixed.

I simply reference Task { await foobar() } and even if foobar() does nothing but a print, Xcode 13.3 beta 3 (13E5104i) still crashes on simulator running iOS 13.0 with a stack trace almost identical to what tera shared above.

Can you share a project that still reproduces the issue? I can't replicate a crash in that case.

I will do, as soon as I get a chance.

@Douglas_Gregor
Looks like for me it's still crashing in Xcode 13.3 but with this option, I can fix it

We're seeing this on iOS 14 still with Xcode 13.3, but the crash looking like this as noted above:

Termination Description: DYLD, dyld: Using shared cache: 373519A5-8E61-3E63-B248-5368E2B87DD1 | dependent dylib '@rpath/MyFramework.framework/MyFramework' not found for '/private/var/containers/Bundle/Application/7745B3AF-1E72-4A61-B921-193A818E21D3/FordPass.app/Frameworks/MyOtherFramework.framework/MyOtherFramework'. chained fixups, seg_count exceeds number of segments

We have the same issue. The suggested workarounds in this thread did not work for us.

1 Like

So this is kind of a cruel one. 89271047 as noted in the Xcode 13.3 release notes forces you to export the app without bitcode to even get a working build.

But that triggers the chained fixups, seg_count exceeds number of segments because as noted at DYDL error for iOS app on mac runn… | Apple Developer Forums, the stripping of bitcode has a bug that messes with the new chained fixups format.

I don't think there's any solution outside of these, all which have some downsides:

  • Remove all async/await code, which is proving harder and harder to do as the ecosystem (and me!) enjoys it and moves towards it
  • Set ENABLE_BITCODE = NO for all frameworks, which is doable in some instances but I think might not play nicely with Swift packages?
  • -Xlinker -no_fixup_chains which I haven't been able to verify yet, also unsure which modules it need to be placed on.
  • Either drop or raise the iOS deployment target.

Or downgrade to Xcode 13.2.1 I guess.

In our case, disabling Bitcode in Xcode didn’t work, unless you’re supposed to somehow also do it in packages.

Yeah, maybe with some unsafe/linking attributes in the Package file disabling Bitcode, yet I think this used to be a blocker to use with non-leaf packages in the past :thinking: not that I'm aware of such flag reliably working in the first place. I silently expect Swift packages to adopt the Bitcode rule used by the main target.

Did the Xcode 13.3 release fix the underlying issue here, or is the crash on launch listed in the release notes as fixed a separate issue?

It should fix the crashes but adds a new issue:

  • Exporting an app that uses Swift’s concurrency features from an archive with bitcode might fail when the app targets iOS 13.0 – iOS 14.7, watchOS 6.0 – watchOS 7.6, or tvOS 13.0 – 14.7. (89271047)
    Workaround : Either uncheck the box Rebuild from bitcode when exporting the app from an archive or disable bitcode (iOS only).

This also breaks App Store submission. This seems fixable, and there have been recent bug fix merges into the Swift 5.6 branch, so perhaps we'll see an Xcode build which fixes the issue. Longer we go towards WWDC, the more unlikely that becomes. :sob:

1 Like

I've created an Alamofire PR to separate our concurrency support out into a separate CocoaPods subspec and SPM module (Carthage users are out of luck). I really, really don't want to do this, but I don't think I have a choice, especially for users stuck on macOS 11. Is there any hope of an Xcode release to fix this issue?

yo yo, this thread was so helpful so thank you to everyone who contributed. we were losing our minds on this but for us, found the fix was actually stripping bitcode out of both the core target project but also pods too if you use pods (ps we are using Xcode13 official release build tools through Fastlane)

just thought I'd drop in case helpful to anyone else

  installer.pods_project.targets.each do |target|
      target.build_configurations.each do |config|
          config.build_settings['ENABLE_BITCODE'] = 'NO'
      end
  end

This should be fixed in Xcode 13.3.1 release today. That would be great, as I could just limit the concurrency features to that version of the compiler instead of a separate module.

3 Likes