Bitcode: 中間バイトコードとコンパイルの仕組み

iOS開発におけるBitcodeとは

Bitcodeは、LLVMコンパイラインフラストラクチャによって生成されるプログラムの中間表現（Intermediate Representation, IR）です。AppleはXcode 7とiOS 9から、watchOSアプリケーションでは必須、iOSとtvOSではオプションとしてBitcodeサポートを導入しました。Xcode 14以降、watchOSを除くすべてのプラットフォームでこの要件は廃止されました。

Bitcodeの歴史

中間コード表現の概念は、2000年代からイリノイ大学でクリス・ラトナーが創設したLLVMプロジェクトの一部として存在しています。Appleは2011年にLLVMをXcodeに適応させ、2015年にBitcodeをApp Storeに再提出せずにアプリケーションを更新する方法として発表しました。この技術はWWDC 2015のセッション「What's New in Xcode」で発表されました。

Bitcodeとマシンコードの違い

マシンコードは、特定のプロセッサ（arm64、armv7、x86_64）向けのバイナリ命令です。Bitcodeはハードウェアに依存しない形式で保存され、App Storeが単一のソース表現から異なるアーキテクチャ向けに最適化されたバイナリファイルを生成できるようにします。この重要な違いが、この技術のすべての利点を定義しています。

Bitcodeは実行可能ファイルではありません。これは開発者がプロジェクトメタデータとともにApp Storeに送信するバイナリ形式のLLVM IRです。アプリストアは再コンパイルプロセスを実行し、各ターゲットプラットフォームとオペレーティングシステムバージョンにコードを適応させます。

iOSコンパイルにおけるBitcodeの動作

Bitcode生成プロセスは、SwiftまたはObjective-CのソースコードをLLVM IRに変換するコンパイラフロントエンドから始まります。リンク段階で、XcodeはIRを.bc（Bitcode）形式ファイルにパッケージ化し、.xcarchiveとともにApp Storeに送信されます。App Storeは自社側で再コンパイルプロセスを実行します。

LLVM段階と中間コード生成

LLVMインフラストラクチャは3つの部分で構成されています：フロントエンド（C/ObjC用Clang、Swift用Swift Frontend）、Middle-Endオプティマイザ、バックエンド（マシンコードジェネレータ）。Bitcodeはアセンブリ命令の生成に進むことなく、最初の2つの段階の結果です。Middle-Endはプラットフォームに依存しない最適化（デッドコード削除、インライン化、定数折りたたみ）を実行します。

// Swiftソースコードの例
func calculateSum(a: Int, b: Int) -> Int {
    return a + b
}

// コンパイル後のLLVM IR（簡略版）
; define i32 @calculateSum(i32 %a, i32 %b)
; %result = add i32 %a, %b
; ret i32 %result

IR生成後、コンパイラは表現レベルで一連の最適化（デッドコード削除、関数インライン化、定数折りたたみ）を実行します。これらの最適化はアーキテクチャに依存せず、Bitcodeに保持されます。App Storeでの再コンパイル時に、特定のプロセッサ向けの命令並べ替えなどのアーキテクチャ依存の最適化が追加されます。

App Storeでの再コンパイル

App Store ConnectはBitcodeを含むアーカイブを受け取り、独自のコンパイルインフラストラクチャを実行します。システムはユーザーのデバイスのターゲットアーキテクチャを判別し、マシンコードを生成して、特定のプロセッサ特性にさらに最適化します。arm64e（A12+およびMシリーズプロセッサ）では、追加のセキュリティ最適化が適用されます。

このプロセスはApp Thinningと呼ばれます — デバイスのアーキテクチャに必要なリソースとコードのみをそのデバイスに配信する技術です。A17 Proプロセッサを搭載したiPhoneユーザーは、古いアーキテクチャ向けの不要な命令なしで、arm64e向けに最適化されたバイナリファイルを受け取ります。これによりダウンロード時間が短縮され、デバイスの容量を節約できます。

Bitcodeを使用する利点

Bitcodeは、iOSアプリケーション開発者にいくつかの重要な利点を提供します。主な利点は、App Storeにアップデートを再提出することなく、新しいAppleプロセッサ向けに自動最適化されることです。これは、armv7からarm64への移行など、新しいアーキテクチャへの移行時に特に重要です。

新しいアーキテクチャ向けの最適化

Appleが新しいアーキテクチャのプロセッサをリリースすると、Bitcodeとともに送信されたアプリケーションは自動的にそのアーキテクチャ向けに再コンパイルされます。開発者はプロジェクトを再ビルドしてアップデートを公開する必要はありません — App Storeがユーザーが最初にダウンロードする際に自社側でこれを行います。これは、長期間にわたって維持されるアプリケーションにとって特に重要です。

バイナリファイルサイズの削減

App ThinningをBitcodeと組み合わせることで、インストールされるアプリケーションサイズを15〜40%削減できます。App Storeは特定のデバイスに必要なマシン命令のみを生成し、他のアーキテクチャや異なるiOSバージョン向けのコードを排除します。実際には、新しいiPhoneのユーザーはコンパクトなバイナリファイルを受け取ることになります。

Apple WWDC 2015 Session 102によると、BitcodeとApp Thinningを使用することで、すべてのアーキテクチャを含むユニバーサルバイナリファイルと比較して、ダウンロードされるアプリケーションサイズを平均25%削減できます。100 MBのアプリケーションの場合、ユーザーのデバイスで最大40 MBの節約になります。

• 自動適応 — 開発者がプロジェクトを再ビルドすることなく新しいプロセッサに対応
• ダウンロード時間の短縮 — ユーザーのデバイスでのアプリケーションダウンロード時間
• 配布の簡素化 — すべてのアーキテクチャに1つのアーカイブ、1つのメタデータセット
• 将来の互換性 — 未発売のAppleプロセッサでもアプリケーションが動作

XcodeプロジェクトでBitcodeを有効にする方法

Bitcode設定はXcodeのビルド設定で行います。Enable BitcodeパラメータはBuild Settingsにあり、新しいプロジェクトではデフォルトで有効ですが、開発者はデバッグ時やBitcodeをサポートしていないサードパーティライブラリを使用する際に無効にできます。

Build Settingsによる設定

// Build Settings -> Apple Clang - Code Generation
// Enable Bitcode = YES

// または個別ターゲットのInfo.plist経由
@property (nonatomic, assign) BOOL enableBitcode;
- (void)configureBuildSettings {
    // 設定でのBitcodeステータスの確認
    if (self.enableBitcode) {
        NSLog(@"Bitcode is enabled for this target");
    } else {
        NSLog(@"Bitcode is disabled");
    }
}

アーカイブにBitcodeが含まれているか確認するには、Xcode Organizer経由で.xcarchiveファイルを開くか、ターミナルでotool -lコマンドを実行します。バイナリファイルに__LLVMセクションが存在すれば、Bitcodeが有効で正しくパッケージ化されていることを確認できます。セクションがない場合、ビルド中にBitcodeが生成されませんでした。

ターミナルでの確認

# アーカイブ内のBitcode存在確認
otool -l YourApp.app/YourApp | grep __LLVM

# 出力: __LLVMセクションがある場合 — Bitcodeが存在
# 出力が空の場合 — Bitcodeが有効でないか生成されていない

# sizeコマンドを使用して確認することも可能
size -m -l YourApp.app/YourApp | grep __LLVM

CocoaPodsやSPMを介してサードパーティライブラリを使用する場合、すべての依存関係がBitcodeでビルドされていることを確認してください。1つでもBitcodeをサポートしていないライブラリがあると、Xcodeはアーカイブ時にリンクエラーを生成します。CocoaPodsの場合は、サブスペックでbitcode_enabledフラグを確認するか、enable_bitcode付きのuse_frameworks!を使用してください。

Bitcodeの制限と注意点

BitcodeはすべてのタイプのiOSプロジェクトに対する万能な解決策ではありません。この技術には制限があり、開発者はビルド設定でオプションを有効にする前に考慮する必要があります。これらの制限を理解することで、アーカイブや公開時の問題を回避できます。

ライブラリの互換性

すべてのサードパーティライブラリがBitcodeをサポートしているわけではありません。ライブラリがBitcodeなしのコンパイル済みバイナリファイルとしてのみ配布されている場合、オプションを有効にしたプロジェクトはビルドできません。この場合、開発者はBitcodeを無効にするか、ベンダーにBitcode対応バージョンをリクエストする必要があります。これは特に、更新されなくなった古いライブラリに関連します。

デバッグとクラッシュレポート

Bitcodeでビルドされたアプリケーションからのクラッシュレポートは追加の処理が必要です。再コンパイルされたコードのシンボル（dSYM）はApp Storeによって生成され、Xcode Organizerを介してダウンロードできます。対応するdSYMファイルをロードしないと、クラッシュレポートのコールスタックが読み取れなくなり、問題の診断が困難になります。

• dSYMアップロード — 再コンパイル後にApp Storeからクラッシュログをデコードするために必須
• アーカイブサイズ — Bitcodeを含む.xcarchiveは開発者のディスク容量をより多く消費
• ビルド時間 — Bitcode生成によりプロジェクトのコンパイル段階が約10〜15%増加
• macOS — BitcodeはmacOSアプリケーションおよびwatchOSアプリケーションではサポートされない
• レガシープロジェクト — 大規模プロジェクトの移行にはすべての依存関係の更新が必要になる可能性

iOS 17およびXcode 15の時点で、AppleはApp Storeへの公開にBitcodeの必須有効化を要求していません。ただし、watchOSアプリケーションについては、BitcodeはApp Store Connectポリシーレベルで必須要件のままです。開発者は、すべての依存関係がサポートしている場合、新しいプロジェクトでBitcodeを有効にすることをお勧めします。