yutatanaka.tokyo logo

yutatanaka.tokyo

Published on

【Xcode】ライブラリが参照できずクラッシュする時はビルドターゲットを見直す

Authors

起きた問題

自作のフレームワーク (Xcode11から対応している最新の方法

.xcframework

でなく、

lipo

コマンドで生成したユニバーサルフレームワーク) を組み込んだiPhoneアプリのXcodeプロジェクト。起動直後にエラーが出てクラッシュする問題にめちゃくちゃ詰まりました。

治し方がわかれば速攻で、シンプルに解決できました。

経緯

今回の問題につき当たった時の前提条件は以下。


Xcode12でのビルド時はクラッシュなどは発生していませんでした。


Xcode13に乗り換え、実機でビルドを行ったところ、以下のようなエラーメッセージが発生してクラッシュが生じました。



dyld[33014]: Symbol not found: __ZN5swift34swift50override_conformsToProtocolEPKNS_14TargetMetadataINS_9InProcessEEEPKNS_24TargetProtocolDescriptorIS1_EEPFPKNS_18TargetWitnessTableIS1_EES4_S8_E
  Referenced from: /private/var/containers/Bundle/Application/D683B472-9999-47D8-87ED-79C29F239688/Test.app/Frameworks/test.framework/test
  Expected in: /private/var/containers/Bundle/Application/D683B472-9999-47D8-87ED-79C29F239688/Test.app/Frameworks/Alamofire.framework/Alamofire
Symbol not found: __ZN5swift34swift50override_conformsToProtocolEPKNS_14TargetMetadataINS_9InProcessEEEPKNS_24TargetProtocolDescriptorIS1_EEPFPKNS_18TargetWitnessTableIS1_EES4_S8_E
  Referenced from: /private/var/containers/Bundle/Application/D683B472-9999-47D8-87ED-79C29F239688/Test.app/Frameworks/test.framework/test
  Expected in: /private/var/containers/Bundle/Application/D683B472-9999-47D8-87ED-79C29F239688/Test.app/Frameworks/Alamofire.framework/Alamofire
(lldb)

Alamofireが見つからないという話のようだが、これだけではヒントとして十分でないところです...。


iOS Simulatorでビルドを行った際にも、参照パスが異なるだけで同様のエラーメッセージとなり、起動直後にクラッシュしました。

解決方法

かなり試行錯誤をしました。。

他にも、自作フレームワークを取り込む際にはちょっと状況が変わると、ハマりポイントが多いように感じます。例えば、

  • ライブラリの方のビルドが古いと、Swiftバージョン不整合としてエラーメッセージが吐かれる。


    =>

    こちらのポスト

    が参考になる

  • No such module"Alamofire"

    とでて、

    ビルド以前にPodsの各ライブラリへの参照が通らない


    => アプリのDerivedDataを消して、再起動、クリーン、ビルドで解決。

    こちらのポスト

    を参照


こうした問題を過去に解決した上で、今回の事象につきあたったため、他の原因などを色々疑り時間を浪費してしまいました。



結果としては、灯台下暗しというか...

ライブラリの方のプロジェクトの、Deployment Targetのバージョンを「13.0」から「14.0」に変更した

ら。


これだけで無事アプリが立ち上がるようになりました。


Xcode12でビルドしていた時は、

このバージョン不整合は無視されてようで、結果的に問題が起きていないように見えていただけ

なのかもしれません。

まとめ

こういう過去からの開発経緯が絡んでいたりする問題は、なかなかネット上に解決方法がなく、時間を浪費してしまうものですね。



かつ、Swiftはコンパイラ言語なので、

今回のように「Alamofireが参照できない」というような事実のみを開発者に対して出力し

、

理由を語ってくれないことも多い。



それだけに、PHPのようなLL言語に比べて

エンジニアが事象の原因を考える力が問われているな

と感じました。

Discuss on Twitter