Cocoapods: Custom Framework : dyld: Symbol not found: _$s11CryptoSwift7PaddingO5pkcs7yA2CmFWC

Created on 3 Nov 2020  Â·  6Comments  Â·  Source: CocoaPods/CocoaPods

Report

What did you do?

I am using a custom framework created using 3 different cocoapods. I am using this custom framework in a client app by dropping the xc framework created. As soon as the client app launches it crashes with below crash logs. I have seen this issue reported many other places on apple and stackoverflow but i could not find a proper answer which worked for me. Now i have uploaded both the client app and the framework repo to github so that anyone trying to help me can actually see the set up and code. Please can any one suggest a proper solution to this issue.

pod version : 1.9.3

Framework : https://github.com/deepesh259nitk/PaymentsKit

Client App : https://github.com/deepesh259nitk/PaymentClient

What did you expect to happen?

No crash when the client app launches.

What happened instead?

Crash seen when app launches

see crash logs
dyld: Symbol not found: $s11CryptoSwift7PaddingO5pkcs7yA2CmFWC Referenced from: /Users/deepesh.vasthimal/Library/Developer/Xcode/DerivedData/PaymentClient-bnsircrdeaciebedmqaliyxezdqe/Build/Products/Debug-iphonesimulator/PaymentsKit.framework/PaymentsKit Expected in: /Users/deepesh.vasthimal/Library/Developer/CoreSimulator/Devices/A0876375-98D5-4215-A139-68F29E787388/data/Containers/Bundle/Application/D954732B-EDDC-478E-85C4-C5C9B14FDDEE/PaymentClient.app/Frameworks/CryptoSwift.framework/CryptoSwift in /Users/deepesh.vasthimal/Library/Developer/Xcode/DerivedData/PaymentClient-bnsircrdeaciebedmqaliyxezdqe/Build/Products/Debug-iphonesimulator/PaymentsKit.framework/PaymentsKit dyld: launch, loading dependent libraries DYLDSHAREDCACHEDIR=/Users/deepesh.vasthimal/Library/Developer/CoreSimulator/Caches/dyld/19H2/com.apple.CoreSimulator.SimRuntime.iOS-14-0.18A372 DYLDROOTPATH=/Users/deepesh.vasthimal/Downloads/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot DYLDLIBRARYPATH=/Users/deepesh.vasthimal/Library/Developer/Xcode/DerivedData/PaymentClient-bnsircrdeaciebedmqaliyxezdqe/Build/Products/Debug-iphonesimulator:/Users/deepesh.vasthimal/Downloads/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/system/introspection DYLDINSERTLIBRARIES=/Users/deepesh.vasthimal/Downloads/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/libBacktraceRecording.dylib:/Users/de

CocoaPods Environment

Stack

   CocoaPods : 1.9.3
        Ruby : ruby 2.6.3p62 (2019-04-16 revision 67580) [universal.x86_64-darwin19]
    RubyGems : 3.0.3
        Host : Mac OS X 10.15.7 (19H2)
       Xcode : 12.0 (12A7209)
         Git : git version 2.24.3 (Apple Git-128)
Ruby lib dir : /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib
Repositories : master - git - https://github.com/CocoaPods/Specs.git @ ddd5672892a4cbaacf1c8703ad2578e4f44e05ed

               trunk - CDN - https://cdn.cocoapods.org/

Installation Source

Executable Path: /usr/local/bin/pod

Plugins

cocoapods-clean       : 0.0.1
cocoapods-deintegrate : 1.0.4
cocoapods-plugins     : 1.0.0
cocoapods-search      : 1.0.0
cocoapods-stats       : 1.1.0
cocoapods-trunk       : 1.4.1
cocoapods-try         : 1.1.0

Podfile

# Uncomment the next line to define a global platform for your project
# platform :ios, '9.0'

target 'PaymentsKit' do
  # Comment the next line if you don't want to use dynamic frameworks
  use_frameworks!

  # Pods for PaymentsKit
  pod 'JOSESwift', '2.2.1', :inhibit_warnings => true
  pod 'GMEllipticCurveCrypto', '1.3', :inhibit_warnings => true
  pod 'CryptoSwift', '~> 1.3.1', :inhibit_warnings => true

  target 'PaymentsKitTests' do
    # Pods for testing
  end

end

Project that demonstrates the issue

Framework : https://github.com/deepesh259nitk/PaymentsKit

Client App : https://github.com/deepesh259nitk/PaymentClient

The Client App crashes as it launches when using the XCFramework from the Framework repo above.

Most helpful comment

This issue is fixed , please refer the solution here ( last comment ): https://github.com/CocoaPods/CocoaPods/issues/9775, Thanks for your support.

Solution is to add below in the pod file of the client app and do a pod deintegrate and pod install and the crash goes away.

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

All 6 comments

Can you please try 1.10 release?

1.10

@dnkoutso thanks, i just updated my cocoa-pods to 1.10 ( created the xcframework newly and used it in the client app using the 1.1.0 version ) and still see the same crash. Anything else i can try ? Do you want to check my repo and see if any settings needs change for this crash to go away ?

A sample app always helps, I might not have the time to take a look but others may.

This issue is fixed , please refer the solution here ( last comment ): https://github.com/CocoaPods/CocoaPods/issues/9775, Thanks for your support.

Solution is to add below in the pod file of the client app and do a pod deintegrate and pod install and the crash goes away.

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

@deepesh-vasthimal-cko I confirm it works for me too. My case is that I embedded a .xcframework in a third party app, which framework has pod dependencies and I had the same crash. My Cocoapods version is 1.10.0. Will there be any fix in a future release?

The suggested fix is really a workaround. It has the side-effect of building all pods in the project in "library evolution mode" which means all enums in the pods are nonfrozen. This triggers compiler warnings about needing to add @unknown default: to every switch over one of these nonfrozen enums from every pod. In many cases these are non-sensical since they are not in libraries that are dynamically linked and therefore new unknown cases can't be added without recompiling the parent project anyway. So they aren't protecting us from anything. In these case we _want_ the compiler to give an error for missing case.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

luhui picture luhui  Â·  3Comments

k06a picture k06a  Â·  3Comments

pronebird picture pronebird  Â·  3Comments

dawnnnnn picture dawnnnnn  Â·  3Comments

gerchicov-bp picture gerchicov-bp  Â·  3Comments