Rork Max SwiftUI アプリのクラッシュログが読めない：dSYM アップロード設定の落とし穴

Relaxing Healing の iOS アップデートを準備していたとき、Firebase Crashlytics のダッシュボードを見て困惑しました。クラッシュレポートが全て「Unsymbolicated」になっていて、関数名の代わりに 0x0000000100234a40 のような16進数アドレスが並んでいました。エラーが出ているのは分かる。でも何が起きているのかが、全く読めない状態です。

累計5,000万DL超のアプリ群を個人で運営してきた中で、クラッシュ調査のつまずきポイントはいくつかパターンがあります。その中でも「ログは届いているのに読めない」というこの状態は、Rork Max で SwiftUI 開発を始めたばかりの方が特に陥りやすいと感じています。

Unsymbolicated クラッシュとは何か

アプリが本番環境でクラッシュすると、iOS はスタックトレース（どの処理順でエラーが起きたか）を記録します。ただし、その記録は元々「機械が読む形式」 — つまり関数名ではなくメモリアドレスで書かれています。

この生のアドレスを人間が読める関数名に変換する処理を「Symbolication（シンボリケーション）」といいます。この変換に必要なのが dSYM ファイルです。dSYM ファイルにはアドレスと関数名のマッピングが格納されており、Crashlytics がこれを使ってログを翻訳してくれます。

dSYM が Crashlytics に届いていないと、ログは届いても読めない状態になります。

原因：ビルド設定とアップロードスクリプトの抜け

Rork Max で生成したプロジェクトは、Xcode のビルド設定がデフォルトのままになっていることがあります。この状態だと以下の2点が機能しておらず、dSYM が生成・アップロードされません。

問題1: Debug Information Format の設定不足

Xcode の Release ビルドで DWARF が選択されていると、dSYM ファイル自体が生成されません。DWARF with dSYM File に変更する必要があります。

問題2: dSYM アップロードスクリプトが未設定

Firebase Crashlytics SDK は、ビルド完了時に自動で dSYM ファイルを Crashlytics のサーバーにアップロードするスクリプトを提供しています。このスクリプトがビルドフェーズに追加されていないと、dSYM は生成されても届きません。

修正手順：Xcode の Debug Information Format を変更する

まず Xcode でプロジェクトを開き、ターゲットの Build Settings を確認します。

プロジェクトナビゲーターでターゲット名を選択
「Build Settings」タブを開く
検索欄に「Debug Information Format」と入力
Release の値が DWARF になっていたら、DWARF with dSYM File に変更

// 変更前（dSYMが生成されない）
Debug Information Format (Release): DWARF

// 変更後（dSYMが正しく生成される）
Debug Information Format (Release): DWARF with dSYM File

Debug ビルドは DWARF のままで問題ありません。Release のみを変更します。

修正手順：dSYM アップロードスクリプトを Build Phase に追加する

次に、Crashlytics への自動アップロードスクリプトを設定します。

Xcode でターゲットの「Build Phases」タブを開く
左上の「+」ボタンをクリックし「New Run Script Phase」を選択
以下のスクリプトを貼り付ける

CocoaPods を使っている場合:

# Firebase Crashlytics dSYM 自動アップロード
"${PODS_ROOT}/FirebaseCrashlytics/run"

Swift Package Manager（SPM）を使っている場合:

# SPM 経由の場合（パスが異なる）
"${BUILD_DIR%Build/*}SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/run"

Input Files に以下を追加することも推奨されています（アップロードの確実性が上がります）:

${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}/Contents/Resources/DWARF/${TARGET_NAME}
$(SRCROOT)/$(BUILT_PRODUCTS_DIR)/$(INFOPLIST_PATH)

スクリプトを「Link Binary with Libraries」フェーズの後に配置することを確認してください。

Rork Max プロジェクト特有の注意点

Rork Max が生成したプロジェクトでは、Firebase を追加する際に CocoaPods と SPM のどちらを使うかで対応が変わります。2026年以降は CocoaPods の配信が停止される予定のため、SPM での設定を推奨します。

2026年5月時点で私が Relaxing Healing に対して実施した手順は SPM 版です。CocoaPods を使っているプロジェクトでは、まず SPM 移行を行ってからスクリプトのパスを更新するとスムーズです。

また、Rork Max が生成するコードには Xcode Cloud や EAS Build など CI/CD 経由でのビルドが前提になっているケースもあります。CI 環境でもこのスクリプトが実行されるよう、ビルド構成が Release になっているかを確認してください。

# EAS Build 設定の確認ポイント
# eas.json の production プロファイルが release ビルドであることを確認
{
  "build": {
    "production": {
      "ios": {
        "buildConfiguration": "Release"  // ここが Release であること
      }
    }
  }
}

効果の確認方法

設定後に本番ビルドをリリースしたら、Crashlytics ダッシュボードでシンボリケーションが有効になっているか確認します。

確認の流れ:

Firebase Console → Crashlytics → 対象アプリを選択
「Issues」リストでクラッシュを開く
スタックトレースに関数名（例: ContentView.body.getter）が表示されていれば成功

アドレスがそのまま表示されている場合は、まだ dSYM が届いていない状態です。ビルドの Release 設定と Run Script フェーズを再確認してください。

なお、過去の古いビルドのクラッシュはさかのぼってシンボリケーションできません。設定後の新しいビルドから有効になります。

設定作業は一度だけ行えばよく、以降は自動でアップロードされます。Rork Max で生成したプロジェクトを App Store に出す前に、この設定を必ず確認しておくことを個人的に推奨しています。同じアプリを長く運用するほど、クラッシュ調査のスピードが収益に直結してきます。

よくある追加の問題：Bitcode と dSYM

Rork Max プロジェクトで Enable Bitcode がオンになっている場合、Xcode がビットコードを再コンパイルするタイミングで App Store Connect 上に新しい dSYM が生成されます。この場合、Crashlytics に届く dSYM はビルド時のものとは別になるため、手動でダウンロードしてアップロードする手順が必要になります。

確認方法は以下の通りです。

App Store Connect にログイン
該当アプリ → 「アクティビティ」タブ → ビルドを選択
「...」ボタンから「dSYM をダウンロード」が表示されていれば Bitcode が有効
ダウンロードした dSYM は Firebase Console の「アプリ設定」→「dSYM を手動アップロード」から送信

最近のプロジェクトでは Bitcode が廃止される方向にあり（Apple が Xcode 14 以降でデフォルト無効にしました）、新規の Rork Max プロジェクトなら基本的に手動アップロードは不要です。ただし古いプロジェクトを引き継いでいる場合は念のため確認することをお勧めします。

実際のクラッシュ調査で役立ったこと

私がアプリ群のクラッシュ調査を行う際に実感するのは、クラッシュレートが下がる前にまず「読める環境を作る」ことが先決だということです。dSYM の設定を後回しにすると、何十件のレポートが届いていても手がかりが一切つかめない状態が続きます。

Crashlytics が正常に機能するようになってから分かるのは、「全体の80%は同一のクラッシュ」という現実です。シンボリケーションが通った状態で見ると、スタックトレースの上位2〜3行を見ただけで原因が特定できることがほとんどです。逆に言えば、それまでの期間は問題の所在すら分からなかったことになります。

今回の設定は10分もあれば完了します。Rork Max で SwiftUI アプリをビルドしたら、リリース前にまずこの設定を確認する習慣をつけると、後の調査作業が格段に楽になります。お読みいただきありがとうございました。