この記事は Akerun Advent Calendar 2022 - Qiita の22日目の記事です。
本年度2回目の出番となります、Web開発グループの小森です。主にiOSアプリケーションの開発を担当しています。
前回以下のような記事を書きました。
本記事は、前回記事とは違い少し技術寄りなことを書こうと思います。
Xcode14からのbitcode
Xcode13系で開発していた時までbitcodeを含めた実行バイナリを生成し、それをAppleに提出することができました。 しかしXcode14にて不要になり、Appleに提出するバイナリにbitcodeを含められなくなったようです。*1
Akerunアプリでもbitcodeを含めてバイナリを生成していたことと、bitcodeそのものの理解がやや曖昧だったため、周辺知識を整理してみました。
bitcodeとは何か
こちら*2にある通り、コンパイルされたプログラムの中間表現です。
具体的にはLLVMが使用するテキストベースの中間表現であるLLVM IR のバイナリ表現のことで、LLVM IR ⇄ bitcode の双方向に変換が可能です。LLVMは、特定のCPUアーキテクチャに依存することはなく独立しているので、LLVM IR によって複数のCPUアーキテクチャ向けのバイナリが生成できます。
bitcodeで何ができそうか
互換性のないCPUアーキテクチャのスマホに同様のアプリケーション（バイナリ）を展開する必要がある場合、開発者がそれに対して特別作業することなく、Apple側でそのCPUに対応するバイナリを準備することが可能になると思われます。
大まかなイメージとしては図のようなものです。
なかなか便利な仕組みですが、32bit cpu である唯一のデバイスが64bitに移行したことで、将来的なことを見据える必要性が薄れ*3、その影響でbitcodeが役目を終えたように思われます。
bitcodeについて、なんとなく存在理由がわかったところで、次はbitcodeが不要になったことで開発者側として気にした方が良さそうな、App Store Connect上で作成される dSYM(デバックシンボル)についても補足します。
App Store Connect上でdSYMが生成されなくなる
App Store Connect上でdSYM(デバッグシンボル)をダウンロードして、それをFirebase Crashlyticsにアップロードすることは、多くのiOSエンジニアの方が経験済みだと思います。
bitcodeが不要になると、App Store Connect上で新しいdSYMが吐き出されることがなくなったので、リリースビルド(アーカイブ)時に一緒に生成されたdSYMをFirebase Crashlyticsにアップロードすることになりそうです。App Store Connect上にいちいち吐き出されるまで待つ必要が無くなったことは嬉しいです。
bitcodeをオンにしていた場合、バイナリをAppleに提出した際に再コンパイルされ、その影響でビルドUUIDが異なるバイナリとdSYMが生成されます。そのためアーカイブ時点で作成したdSYMとビルドUUIDの整合性がとれずCrashlyticsにログが上がってこない状況が発生する可能性があります。
以上を図でまとめると以下のようなイメージとなります。
参考: https://developer.apple.com/documentation/xcode/building-your-app-to-include-debugging-information
最後に
bitcodeをoffにして Apple に提出することは今後ないので、上記のようにまで整理する必要性はないかもしれません。しかしLLVMやdSYM, CPUなど普段見ないレイヤも踏まえながら思考整理しつつ、Appleがなぜbitcodeを含めようとしたのかほんのりわかったような気がしてよかったです。
株式会社フォトシンスでは、一緒にプロダクトを成長させる様々なレイヤのエンジニアを募集しています。 hrmos.co
Akerun Proにご興味のある方はこちらから akerun.com
