Rork でアプリの形が見えてきて、いざ手元の Mac で iOS プロジェクトを開こうとすると、ターミナルに真っ赤なエラーが流れる——多くの人がここで一度詰まります。原因のほとんどは Rork ではなく、ローカルの Ruby・CocoaPods・Xcode の組み合わせ問題です。M1 以降の Apple Silicon Mac が当たり前になってから、この層のトラブルは目に見えて増えました。
私自身、Rork で書き出したプロジェクトを複数の Mac に持ち込む過程で、毎回違うパターンの pod install 失敗に遭遇してきました。原因のパターンは限られていて、しかも対処は驚くほど機械的に決まります。ここでは私が実際にハマってきた順に5つのパターンを並べていきます。
なぜ Rork プロジェクトで pod install がよく止まるのか
Rork は React Native + Expo ベースのコードを生成します。ローカルでビルドする際は npx expo prebuild などでネイティブプロジェクト（ios/ ディレクトリ）を作り、その中で CocoaPods が依存ライブラリを引っ張ってきます。つまり Rork 自体ではなく、pod install が走る瞬間にホスト環境の歪みが一気に表面化するわけです。
特に問題が出やすいのは次の3つの軸です。Ruby のインストール方法（システム Ruby か rbenv か asdf か）、CocoaPods のバージョン、Xcode コマンドラインツールのパス。どれか一つがずれているだけで、何も触っていないのに突然ビルドが通らなくなります。
パターン1：Apple Silicon Mac で ffi gem がロードできない
最も遭遇率が高いのがこれです。エラーメッセージは大抵こんな形をしています。
LoadError - dlopen(.../ffi_c.bundle, 0x0009):
tried: '.../ffi_c.bundle' (mach-o file, but is an incompatible architecture
(have 'x86_64', need 'arm64'))
原因は、Ruby のバイナリが x86_64 でビルドされているのに、pod install は arm64 で動こうとしていることです。Rosetta 2 環境で一度インストールしたものが残っているケースもあります。
対処は二つあります。一つは Rosetta を使わずに arm64 ネイティブで動かす方法です。
# 現在のアーキテクチャを確認
arch
# arm64 と表示されることを確認
# ffi を arm64 で再インストール
sudo gem uninstall ffi
sudo arch -arm64 gem install ffi
# CocoaPods 自体も arm64 で入れ直す
sudo arch -arm64 gem install cocoapodsもう一つは、Rosetta 環境を明示的に使う方法です。これは古い CocoaPods で書かれた Podfile を扱うときに有効です。
# Rosetta 経由で pod install
arch -x86_64 pod install判断の基準としては、新規プロジェクトなら arm64 ネイティブで揃える、既存の古いプロジェクトを引き継いだ場合だけ Rosetta フォールバックを検討する、という順番がおすすめです。混在させると後から原因切り分けが難しくなります。
パターン2：システム Ruby と rbenv/asdf の Ruby が衝突している
macOS には初期状態でシステム Ruby（/usr/bin/ruby）が入っています。一方で Homebrew や rbenv、asdf 経由でも Ruby を入れている人が多く、gem install cocoapods がどの Ruby に対して動いたのか分からなくなりがちです。
確認は次のコマンドで一発です。
which ruby
which gem
which pod
ruby -v期待する出力は、たとえば rbenv を使っているなら次のようになります。
/Users/yourname/.rbenv/shims/ruby
/Users/yourname/.rbenv/shims/gem
/Users/yourname/.rbenv/shims/pod
ruby 3.2.2 (2023-03-30 revision e51014f9c0) [arm64-darwin23]
pod のパスが /usr/local/bin/pod や /opt/homebrew/bin/pod なのに、ruby だけ rbenv のパスが返ってくる場合は不整合です。pod を入れた Ruby と、現在シェルが参照する Ruby がずれています。
対処は、現在のシェルが指している Ruby に対して cocoapods を入れ直すことです。
# rbenv を使っている場合
rbenv local 3.2.2 # プロジェクトに固定
gem install cocoapods
rbenv rehash
pod --versionRuby のバージョンは Rork のテンプレートが想定するものに合わせるのが無難です。Expo SDK 50 以降は Ruby 3.2 系で安定しています。逆にシステム Ruby（macOS 標準）の 2.6.10 を直接使うのは、警告が大量に出るので避けたほうが快適です。
パターン3：CocoaPods のバージョンが新しすぎて Podfile を解釈できない
最近 gem install cocoapods を打つと、何も指定しなければ最新版（執筆時点で 1.16 系）が入ります。一方で Rork が生成する Podfile は、Expo SDK のテンプレートに付随する形で 1.14 や 1.15 系を想定して書かれていることが多く、まれに次のような警告が出ます。
[!] CDN: trunk Repo update failed - 28 error(s):
CDN: trunk URL couldn't be downloaded ...
これはネットワークエラーに見えますが、実際は CocoaPods Specs リポジトリの更新で詰まっているケースが多いです。次の順序で潰していきます。
# 1. CocoaPods のキャッシュをクリア
pod cache clean --all
# 2. Specs リポジトリを最新化
pod repo update
# 3. それでもダメならローカル Specs を一度消す
rm -rf ~/.cocoapods/repos/trunk
pod setupそれでも解決しない場合、CocoaPods のバージョンを Expo の推奨に合わせて落とすのが確実です。
sudo gem uninstall cocoapods
sudo gem install cocoapods -v 1.15.2
pod --version # 1.15.2 と出ることを確認「最新が常に正しい」と考えがちですが、React Native / Expo 周辺は CocoaPods のメジャーアップに対する追従がワンテンポ遅れることがあります。テンプレートが想定しているバージョンに合わせるほうが、結果的に時間を節約できます。
パターン4：Xcode のコマンドラインツールが指している場所が違う
pod install の途中で次のようなエラーが出る場合、Xcode のパス設定が原因です。
xcrun: error: SDK "iphoneos" cannot be located
xcrun: error: unable to lookup item 'PlatformPath' in SDK 'iphoneos'
新しい Xcode に入れ替えた直後や、Command Line Tools 単体だけが入っている状態でよく起きます。xcode-select で参照先を Xcode 本体に向け直します。
# 現在のパスを確認
xcode-select -p
# /Library/Developer/CommandLineTools のような出力が返ってきたらズレている
sudo xcode-select -s /Applications/Xcode.app/Contents/Developer
# 確認
xcode-select -p
# /Applications/Xcode.app/Contents/Developer に変わっていればOK加えて、Xcode を起動して一度ライセンスに同意していないと、コマンドラインから Xcode の機能を呼び出した瞬間に止まります。
sudo xcodebuild -license acceptこのあたりは「Mac を新しく買い替えた」「macOS をアップグレードした」「Xcode をベータ版に変えた」のいずれかで再発しやすいので、ローカルビルドが急に通らなくなったら真っ先に疑う場所です。
パターン5：Hermes・Folly のコンパイル中に C++ エラーで落ちる
pod install 自体は通っても、その直後の xcodebuild 段階で Hermes や RCT-Folly のコンパイルが失敗するケースがあります。エラーメッセージは膨大ですが、根本原因はだいたい次のどれかに収束します。
第一に、ios/Podfile の Hermes 有効化フラグと、app.json / app.config.js の設定が食い違っているケース。Expo が New Architecture を有効にしようとしている一方、Podfile 側で :hermes_enabled => true が伝わっていないと不整合が起きます。Rork が出力する app.json を見て、"newArchEnabled" の値を確認してください。
第二に、Xcode 16 以降と古い Folly の組み合わせで C++17 関連のエラーが出るケース。これは React Native のバージョンを 0.74 以上に上げるか、Podfile の post_install フックで CLANG_CXX_LANGUAGE_STANDARD を c++17 に固定することで回避できます。
最終手段として、ios/ ディレクトリを一度捨てて作り直すのが最も確実です。
# プロジェクトルートで
rm -rf ios
rm -rf node_modules
npm install # または yarn / bun install
# Expo の prebuild で iOS プロジェクトを再生成
npx expo prebuild -p ios --clean
cd ios
pod installexpo prebuild --clean は破壊的なので、ios/ 配下に手書きで加えた変更がある場合は事前にバックアップを取ってください。一方で「いつの間にか Podfile を書き換えていて、何が原因か分からない」という状態になっているなら、思い切って作り直したほうが結果的に早いです。
デバッグの順序を固定しておくと迷わない
エラーが出るたびに行き当たりばったりで対処していると、毎回同じ場所でハマります。私は次の順序を固定して、上から潰すようにしています。
最初に arch と which ruby / pod を確認して環境の整合性を見る、次に pod --version と xcode-select -p で外部要因を確認する、それでも分からなければ ios/ を一度作り直す。この順序なら、ほとんどのケースで30分以内に切り分けが終わります。
Rork 自体は AI でアプリを作れる優秀なツールですが、生成された後のローカルビルドは結局 React Native の世界です。CocoaPods 周りの基礎知識を一度押さえておくと、Rork に限らず他の React Native プロジェクトでも同じパターンで対処できます。
関連する内容として、Rork React Native ビルドエラー完全解決ガイド 2026 や Rork EAS Build CI/CD パイプラインを GitHub Actions で構築する も合わせて読むと、ローカル/クラウド両方のビルド戦略が見えてきます。
まずは手元の Mac で arch と which pod を実行して、自分の環境がどのパターンに当たるかを確認してみてください。原因さえ特定できれば、対処自体は5分で終わるはずです。