dyld: Symbol not found: swift34swift50override_conformsToProtocol

I have the same problem !!!!

look, i found this:

When the *** not found symbol appears, the following situations will generally occur

1. You added library ***, but the supported CPU structure is not consistent with the mobile phone you are running. Right now, use lipo-info to see the supported CPU structure per library.
2. The *** version used does not match what you need. The above is the solution.

I had the same error message, I recompiled the dependency in question to a XCFramework and it fixed the issue.

This issue happens for chained dependencies. Suppose you have App -> A.framework -> B.framework. If you change B's target OS version and rebuilt B, this error occures.

The solution is to rebuilt A as well.

Of course, if you don't have the source code of A, you will have to revert to the old version of B

from iOS developer @ authing

In my case, in Podfile I have code that replaces IPHONEOS_DEPLOYMENT_TARGET for all pod targets with 'some' min version. Originally I had a '13.0' version. When I changed '13.0' to '9.0', did pod update, clean the project, and build & run again, the error didn't appear again.

Below is a piece of that code I have now:

post_install do |installer|
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      if Gem::Version.new(config.build_settings['IPHONEOS_DEPLOYMENT_TARGET']) < Gem::Version.new('9.0')
        config.build_settings['IPHONEOS_DEPLOYMENT_TARGET'] = '9.0'
      end
    end
  end
end

Hope my answer will help somebody and save time.

I am working with a framework from a private vendor through CocoaPods. The framework is targeted as iOS 12 but one of its dependencies (SwiftDate) is actually targeted for iOS 13, which raised the following error in Xcode: Compiling for iOS 12.0, but module 'SwiftDate' has a minimum deployment target of iOS 13.0

To fix that I did what @ababykina suggested and applied iOS 13 to all pods in post_install

post_install do |installer|
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      config.build_settings['IPHONEOS_DEPLOYMENT_TARGET'] = '13.0'
    end
  end
end

By doing so I got the crash mentioned in the original post:

dyld[30013]: Symbol not found: __ZN5swift34swift50override_conformsToProtocolEPKNS_14TargetMetadataINS_9InProcessEEEPKNS_24TargetProtocolDescriptorIS1_EEPFPKNS_18TargetWitnessTableIS1_EES4_S8_E
  Referenced from: [...]/TestSDK.app/Frameworks/TheVendor.framework/TheVendor
  Expected in:     [...]/TestSDK.app/Frameworks/Alamofire.framework/Alamofire

The error mentioned the issue at hand: Alamofire was missing in my case.

From what I understand when you force a IPHONEOS_DEPLOYMENT_TARGET to a higher value than actually supported you'll see no error, yet it will not be included in the app afterwards and causes this crash. And indeed the vendor's podspec mentioned Alamofire 5.5.0 which targets iOS 10, and not 13 or up.

To fix this I had to isolate the offending dependency in post_install and execute pod install

post_install do |installer|
  installer.pods_project.targets.each do |target|
    if target.name == 'SwiftDate'
      target.build_configurations.each do |config|
        config.build_settings['IPHONEOS_DEPLOYMENT_TARGET'] = '13.0'
      end
    end
  end
end

And now it runs properly.

Hope this helps.

@sebastienk The solution you gave above worked perfectly till Xcode 15.x, but on Xcode 16 it crashes with the same stack trace. Did you find out how to fix it for Xcode 16?

I got the same error on Xcode16, still the alamofire. Error: __ZN5swift39swift51override_conformsToSwiftProtocolEPKNS_14TargetMetadataINS_9InProcessEEEPKNS_24TargetProtocolDescriptorIS1_EEN7__swift9__runtime4llvm9StringRefEPFPKNS_35TargetProtocolConformanceDescriptorIS1_EES4_S8_SC_E Referenced from: <E1C1F7C9-955A-3A02-A498-C3D514919E5B> /private/var/containers/Bundle/Application/42380089-254A-44E8-9871-F32735658C9A/Mx.app/Frameworks/xxxx.framework/xxxx Expected in: <168E9987-FB09-3D71-9A17-E4CD11CDFBA2> /private/var/containers/Bundle/Application/42380089-254A-44E8-9871-F32735658C9A/Mx.app/Frameworks/Alamofire.framework/Alamofire

Are you also using CocoaPods?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hello, sorry to get back to you. I can't send you information about my build logs because I'm on the company's internal network and I'm not allowed to send you outgoing emails. What I can confirm is that this problem only occurred after xcode16, and when I rolled back to xcode15, it was running fine.

The faulty module is manually recompiled in xcode16 and then referenced. It does not crash at run time. However, the module is provided by a third-party vendor, so it is difficult to replace the module.

In addition, I analyzed the symbol table by nm. The symbol is local symbol (small t). The symbol disappears (stripped) in the binary, so the caller cannot find it. Normally, the value should be Global (T). Swift's patching mechanism was beyond my knowledge, and I had to roll back the system and xcode due to time constraints. If you have any problems, feel free to let me know and I can upgrade the system again to try.

Hi,

I'm having the same problem here with Xcode 16. I've made an example project to try replicate the issue.

In this example, when a build the sample app with Xcode 16 I get this same crash in launch time.

The app structure is the following:

App target > Depends on Dynamic Framework (pre-built) > Depends on Dynamic Framework (target created with Cocoapods)

The dynamic framework was pre-built with this transitive dependency using Cocoapods but with Xcode 15, using vtool I can see this info like:

➜ vtool -arch arm64 -show DynamicFrameworkSample.framework/DynamicFrameworkSample

DynamicFrameworkSample.framework/DynamicFrameworkSample (architecture arm64):
Load command 8
      cmd LC_BUILD_VERSION
  cmdsize 32
 platform IOS
    minos 12.0
      sdk 17.5
   ntools 1
     tool LD
  version 1053.12
Load command 9
      cmd LC_SOURCE_VERSION
  cmdsize 16
  version 0.0

If I recompile the framework with Xcode 16 it runs fine. I only get this crash in a real iOS device, not in simulator.

I also noticed that if I recompile the framework with Xcode 15 but with iOS target 13 or later it also works fine.

I was hopping that using the BUILD_LIBRARY_FOR_DISTRIBUTION flag for my pre-compiled framework I could update future versions os Xcode with no trouble.

Hope this sample can help some understanding more about the problem. Maybe something wrong with Xcode 16 compiler when compatibility with older iOS is needed?

In my current project I'm not able to recompile all the XCFrameworks with Xcode 16 :(

Folks, Please reply as a reply, rather than in the comments. See Quinn’s Top Ten DevForums Tips for more on that.

Thanks for that. However, that project is based on CocoaPods, which limits how much I can help you. Are you able to reproduce the issue just using Apple tools? So, Xcode and Swift Package Manager?

If so, please post a link to your updated project and I’ll take a look.

If not, that makes things tricky. Normally when people have problems with third-party tools I encourage them to escalate the problem with the tool’s vendor. That’s harder in this case because CocoaPods is in maintenance mode [1].

Now, it’s possible that someone with deep familiarity with CocoaPods might be able to come up with a clever fix for this. However, that person is not me )-: Given that, my specific advice is that you move off CocoaPods.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] https://blog.cocoapods.org/CocoaPods-Support-Plans/

@rb13 I see that you or someone else filed FB16388677 with a link to your project, and we thank you for doing so.

For an app that can build all of its code from source that you control, you should make sure that the deployment targets for all modules are set uniformly. So for example, if an app supports iOS 15 as its deployment target, and you also own all of the frameworks that go into that app, make sure to set all of those minimum deployment targets to iOS 15. This obviates the need for the system to insert some backwards compatibility code beyond the oldest OS version that the app supports. That compatibility support is what the symbol __ZN5swift34swift50override_conformsToProtocolEPKNS_14TargetMetadataINS_9InProcessEEEPKNS_24TargetProtocolDescriptorIS1_EEPFPKNS_18TargetWitnessTableIS1_EES4_S8_E represents.

For many apps, the above is not possible, as you import dependencies from different sources which you cannot modify, such as an XCFramework. In these cases, the library author should add -runtime-compatibility-version none to the Other Swift Flags build setting. The compatibility support that I reference in the prior paragraph only is needed in executables (i.e. app targets), and not framework libraries, so adding this complier flag eliminates the addition of those backwards compatibility code paths from the complied framework.

— Ed Ford,  DTS Engineer

@rb-iu, in a comment, you said:

I'm worried now about future compatibility with newer iOS versions in the future to come, and with the use of the ABI stability setting with BUILD_LIBRARY_FOR_DISTRIBUTION flag.

There isn't a risk to ABI stability by adding -runtime-compatibility-version none to the build settings.

You also said:

In my project I do create a lot of XCFrameworks, with some hierarchy between then, some this it is not possible to re-compile than all.

In rare situations, it's possible that one framework linking to another will pick up the compatibility symbols from the other framework, rather than from its own internal copy. If that were to affect you, the solution remains the same, to rebuild with this extra build setting of the affected framework.

— Ed Ford,  DTS Engineer