シミュレーターで動くのに実機でクラッシュ — Rork Max アプリの原因特定と修正ガイド

Rork Max でネイティブアプリを生成して「シミュレーターでは問題なく動くのに、実機に入れたとたんクラッシュする」という経験をされた方は多いのではないでしょうか。

これは iOS 開発の世界で昔から繰り返されるトラブルのひとつです。AI でコードが自動生成されるようになった今も、残念ながらこの問題は変わらず起きます。むしろ、生成コードが膨大になるぶん、原因の特定に時間がかかることもあります。

ここではRork Max 利用者が実際によく遭遇するクラッシュパターンを5つに絞り、それぞれの原因と修正方法を具体的にご紹介します。

なぜシミュレーターと実機で挙動が異なるのか

まずは前提として、この差異が生まれる理由をご理解いただくと、問題解決の筋道が立てやすくなります。

CPU アーキテクチャの違いがもっとも根本的な原因のひとつです。Mac 上のシミュレーターは x86_64（Intel Mac）または arm64（Apple Silicon Mac）で動作しますが、iOS 実機は arm64 のみです。ライブラリが特定アーキテクチャ向けにビルドされていると、シミュレーターでは動いても実機で動かないケースが出てきます。

メモリの扱いも大きく異なります。 シミュレーターは Mac のメモリを自由に使えるため、数 GB のメモリを消費するコードも平然と動きます。一方、実機は搭載メモリが限られており、iOS の jetsam（メモリ管理）が容赦なくプロセスをキルします。

パーミッションとサンドボックスも実機だけに厳しく適用されます。Info.plist に使用説明文を書いていないカメラや位置情報へのアクセスは、シミュレーターでは見逃されることがありますが、実機では即座にクラッシュします。

よくある5つのクラッシュパターンと修正方法

パターン1: Info.plist のプライバシー使用説明文が不足している

最も多いのがこのケースです。カメラ・マイク・位置情報・フォトライブラリなどにアクセスするコードを Rork Max が生成した場合、対応する NSXxxUsageDescription が Info.plist に入っていないとアプリは即クラッシュします。

// Rork Max が生成するカメラアクセスコード例
import AVFoundation
 
func requestCameraAccess() {
    AVCaptureDevice.requestAccess(for: .video) { granted in
        // この処理の前にInfo.plistの記述が必須
    }
}

修正は Rork Max のプロジェクト設定（Info.plist に相当する部分）に以下を追加することです。

NSCameraUsageDescription = "プロフィール写真の撮影に使用します"
NSPhotoLibraryUsageDescription = "写真の選択と保存に使用します"
NSMicrophoneUsageDescription = "動画撮影時の音声収録に使用します"
NSLocationWhenInUseUsageDescription = "近くのスポットを表示するために使用します"

Rork Max のプロンプトに「カメラを使う機能を追加する際は、Info.plist のプライバシー説明文も一緒に追加してください」と明示すると、生成時に含めてもらいやすくなります。

パターン2: EAS Build の Entitlement 不足

プッシュ通知・App Groups・Sign in with Apple・HealthKit などの機能は、Entitlements ファイルへの記述が必要です。シミュレーターでは Entitlements が無くても動作するため、実機テストで初めて発覚するケースが多いです。

Rork Max の EAS Build 設定（app.json）を確認してください。

{
  "expo": {
    "ios": {
      "bundleIdentifier": "com.yourname.yourapp",
      "entitlements": {
        "aps-environment": "production",
        "com.apple.developer.associated-domains": ["applinks:yourapp.com"]
      }
    }
  }
}

特に aps-environment は development（TestFlight 用）と production（App Store 用）で正しく切り替える必要があります。EAS Build のプロファイル設定を見直してみてください。

パターン3: サードパーティライブラリのアーキテクチャ問題

Rork Max が npm パッケージを介してネイティブモジュールを取り込んだ場合、そのモジュールが arm64 実機向けにビルドされていないと動きません。

クラッシュログに Termination Reason: Namespace DYLD, Code 1 Library missing や image not found が出ていたら、このパターンを疑ってください。

# EAS Build ログでアーキテクチャエラーを確認する
eas build --platform ios --profile preview --local
 
# ビルド済み .ipa の中のバイナリアーキテクチャを確認
lipo -archs YourApp.app/YourApp
# → arm64 のみ表示されるのが正常

このエラーが出た場合、問題のあるライブラリを最新バージョンに更新するか、Rork Max のプロンプトで「React Native 0.73 以降対応のライブラリを使ってください」と指定して再生成するのが有効です。

パターン4: メモリ不足による強制終了（jetsam kill）

画像処理・機械学習モデル・大量のデータ読み込みをシミュレーターで試すと余裕で動くのに、実機（特に古い iPhone）では強制終了されるケースです。

クラッシュログに EXC_RESOURCE RESOURCE_TYPE_MEMORY や jetsam の文字が出ていれば確認です。

// 画像をメモリ上に全部展開してしまうコード（危険）
let images = urls.map { UIImage(contentsOfFile: $0.path) } // シミュレーターでは動く
 
// 推奨: 必要なときだけ読み込む
func loadImage(at url: URL) -> UIImage? {
    // ディスクから逐次読み込みにすることでメモリを節約
    return UIImage(contentsOfFile: url.path)
}

Rork Max に対して「メモリ効率を考慮して、画像は遅延読み込みにしてください」と指示すると、LazyVStack や AsyncImage を使ったコードを生成してもらえます。

パターン5: CoreML モデルが実機の Neural Engine に対応していない

AI 機能を含むアプリで CoreML を使う場合、モデルが特定の計算ユニット（Neural Engine）向けにコンパイルされていないと、実機でのパフォーマンスが著しく低下したり、場合によってはクラッシュしたりします。

// CoreML モデルのロード時に計算ユニットを明示する
let config = MLModelConfiguration()
config.computeUnits = .all // CPU・GPU・Neural Engine を状況に応じて自動選択
 
do {
    let model = try MyMLModel(configuration: config)
    // モデル使用
} catch {
    // エラーハンドリングを必ず実装する
    print("モデルのロードに失敗しました: \(error.localizedDescription)")
}

Rork Max に CoreML を使う機能を生成させる際は、「CoreML のモデルロード時にエラーハンドリングと計算ユニット設定を含めてください」と明示するとよいでしょう。

クラッシュログの読み方 — 原因の素早い特定

実機でクラッシュが起きたとき、原因を特定する最短ルートはクラッシュログを読むことです。

TestFlight 経由のクラッシュ: App Store Connect の「TestFlight」→「クラッシュ」タブに自動収集されます。

Xcode Organizer: デバイスを繋いで Xcode の「Window」→「Organizer」→「Crashes」を開くと、接続した実機のクラッシュログが確認できます。

見るべき主なフィールドは以下の2つです。

Exception Type: EXC_BAD_ACCESS (SIGSEGV)  ← メモリ参照エラー
Exception Type: EXC_CRASH (SIGABRT)       ← アサーション・フォース終了

Thread 0 Crashed:
0  libswiftCore.dylib    0x... swift_unknownObjectRetain  ← Swiftのメモリ管理問題
1  YourApp               0x... ContentView.body.getter    ← クラッシュした箇所

スタックトレースの一番上から順番に読んでいくと、クラッシュが起きた箇所がわかります。YourApp から始まる行（自分のコード）に注目するのが基本です。

シミュレーター依存を断ち切るための実機テスト習慣

根本的な解決策として、TestFlight を開発の早い段階から使うことをお勧めします。機能が完成してからまとめて実機テストするのではなく、1画面作ったら TestFlight に入れるというサイクルにすると、問題の発見が早く修正コストも小さく済みます。

Rork Max での開発フローとしては、プロンプトで機能を追加するたびに EAS Build を走らせて TestFlight 配布するのが理想的です。詳しいビルド〜配布の流れはRork Max TestFlight ガイドをご覧ください。

また、実機特有のバグが多い場合は、Rork Max ビルドエラー完全解決ガイドも合わせて参考にしていただければ、より広い範囲のトラブルに対応できます。

最初にやること — クラッシュ直後のチェックリスト

実機でクラッシュが発生したときに最初に確認すべきことをまとめます。

Info.plist に必要なプライバシー使用説明文がすべて記述されているか
Entitlements に使用している機能（プッシュ通知・Associated Domains 等）が含まれているか
クラッシュログの Exception Type を確認して原因を絞り込む
TestFlight で配布して複数の実機（特に古めのデバイス）で検証する
メモリ使用量が異常に多い処理がないか Xcode Instruments で確認する

シミュレーターと実機の差異は「なぜか動かない」ではなく、必ず理由があります。クラッシュログを手がかりにひとつずつ確認していくと、ほとんどのケースで解決できます。まずはクラッシュログを開いてみてください。