Our project supports iOS 12, and we use libswift_Concurrency.dylib for a specific feature.

After switching to Xcode 16 for building, we noticed that the load path for libswift_Concurrency.dylib changed to /usr/lib/swift/libswift_Concurrency.dylib (compatibility version 1.0.0, current version 0.0.0, weak).

This causes a critical issue: when the app launches on iOS 14, it fails to load the library because iOS 14 does not include libswift_Concurrency.dylib at /usr/lib/swift/. Consequently, when invoking methods related to the library (e.g., Task, async, await), the app crashes due to unresolved symbols. The crash stack trace includes:

SWITT::ResoLveAsSymbolicketerence: operator swift: Demange: symbolicreterencekina, swift:: Demange: Directness, int, void const + 126  
swiTt::Demange::Demanger:.demangesymbolicketerenceunstghed char) + 408  
swITt.:Demange..Demanger..demangesymbolicketerenceunstghed char) + 200  
SWITT:.DemangLe::Demanger:.aemangtelypeTvm:stringket, sta::.TunctIOn<SWITT:.DemangLe::Node~SWITT::Demangte::ymbol1CReterencekina, SWITT::Demangue::DIrectness, Int, vola const)) + 200  
swift_getTypeByMangledNameImp1(swift: :MetadataRequest, 11vm::StringRef, void const* const*, std:: 1:: function<swift:: TargetMetadata<swift:: InProcess> const*(unsigned int, unsigned int)>, std::_ 1:: function<swift:  
argetWitnessTable<swift:: InProcess> const*(swift: :TargetMetadata<swift:: InProcess> const*, unsigned int) >) + 480  
swift:: swift_getTypeByMangledName(swift::MetadataRequest, Ilvm::StringRef, void const* const*, std::_1:: function‹swift:: TargetMetadata‹swift:: InProcess> const*(unsigned int, unsigned int)>, std::_1:: function<swi  
t:: largetwitnesslable<swift::lnProcess> constswift::largetmetadata<swift::InProcess> const, unsigned int> + 604  
swift getlypebymangLedNamelncontext + 148  

Additionally, we observed that setting the IPHONEOS_DEPLOYMENT_TARGET to ​iOS 13 changes the load path of libswift_Concurrency.dylib to @rpath/libswift_Concurrency.dylib, which resolves the crash because the library is correctly loaded from xxx.app/Frameworks/. However, our app must support ​iOS 12, so this workaround is not viable.

Key Notes:

1. This issue ​only occurs in Xcode 16; it works as expected in Xcode 15.
2. We need a solution to maintain iOS 12 support while avoiding the library load path conflict on iOS 14. How can we resolve this compatibility issue?

Our project supports iOS 12, and we use libswift_Concurrency.dylib for a specific feature.

After switching to Xcode 16 for building, we noticed that the load path for libswift_Concurrency.dylib changed to /usr/lib/swift/libswift_Concurrency.dylib (compatibility version 1.0.0, current version 0.0.0, weak).

This causes a critical issue: when the app launches on iOS 14, it fails to load the library because iOS 14 does not include libswift_Concurrency.dylib at /usr/lib/swift/. Consequently, when invoking methods related to the library (e.g., Task, async, await), the app crashes due to unresolved symbols. The crash stack trace includes:

SWITT::ResoLveAsSymbolicketerence: operator swift: Demange: symbolicreterencekina, swift:: Demange: Directness, int, void const + 126  
swiTt::Demange::Demanger:.demangesymbolicketerenceunstghed char) + 408  
swITt.:Demange..Demanger..demangesymbolicketerenceunstghed char) + 200  
SWITT:.DemangLe::Demanger:.aemangtelypeTvm:stringket, sta::.TunctIOn<SWITT:.DemangLe::Node~SWITT::Demangte::ymbol1CReterencekina, SWITT::Demangue::DIrectness, Int, vola const)) + 200  
swift_getTypeByMangledNameImp1(swift: :MetadataRequest, 11vm::StringRef, void const* const*, std:: 1:: function<swift:: TargetMetadata<swift:: InProcess> const*(unsigned int, unsigned int)>, std::_ 1:: function<swift:  
argetWitnessTable<swift:: InProcess> const*(swift: :TargetMetadata<swift:: InProcess> const*, unsigned int) >) + 480  
swift:: swift_getTypeByMangledName(swift::MetadataRequest, Ilvm::StringRef, void const* const*, std::_1:: function‹swift:: TargetMetadata‹swift:: InProcess> const*(unsigned int, unsigned int)>, std::_1:: function<swi  
t:: largetwitnesslable<swift::lnProcess> constswift::largetmetadata<swift::InProcess> const, unsigned int> + 604  
swift getlypebymangLedNamelncontext + 148  

Additionally, we observed that setting the IPHONEOS_DEPLOYMENT_TARGET to ​iOS 13 changes the load path of libswift_Concurrency.dylib to @rpath/libswift_Concurrency.dylib, which resolves the crash because the library is correctly loaded from xxx.app/Frameworks/. However, our app must support ​iOS 12, so this workaround is not viable.

Key Notes:

1. This issue ​only occurs in Xcode 16; it works as expected in Xcode 15.
2. We need a solution to maintain iOS 12 support while avoiding the library load path conflict on iOS 14. How can we resolve this compatibility issue?

• ios
• swift

• You should begin dropping iOS 12, Xcode 16 will be required next month and iOS 12 is no longer supported. – lorem ipsum Commented Mar 20 at 11:22
• Is there really no way to support iOS 12 anymore? Xcode 16 doesn't explicitly state that it doesn't support iOS 12 either. – user3910365 Commented Mar 20 at 11:57
• Looks like iOS 15 will be the minimum next month. – lorem ipsum Commented Mar 20 at 12:07

1 Answer 1

Xcode 15 supports iOS 12-17

https://developer.apple/documentation/xcode-release-notes/xcode-15-release-notes

Xcode 16 supports iOS 15-18

https://developer.apple/documentation/xcode-release-notes/xcode-16-release-notes

In April 2025 iOS 18 SDK will be required, meaning that all apps will have to be built with Xcode 16.

https://developer.apple/ios/submit/

Apple is dropping submissions for apps that support iOS 14 and below.