こんにちは！
この記事では、macOS Tahoe 26.0.1 の開発環境で Ruby 3.4 系を Homebrew から入れた直後に ruby -v が無言で固まり、CPU 使用率 0% のまま沈黙し続けてしまった──そんな状態から bundle install や pod install まで復旧させた記録をまとめます🔥
原因は単なる設定ミスではなく、macOS 26 (Tahoe) の Gatekeeper が Homebrew ビルドの Ruby を「未署名の実行ファイル」と誤認して実行を握り潰していたことでした。Ruby プロセスが沈黙したのは、 Gatekeeper が dyld 初期化段階で拒否を返し、実行がほとんど進まなかったためだったようです。
React Native（Expo ではない）iOS プロジェクトで hermes-engine のインストールが止まったり、Gatekeeper が容赦なくブロックしてきた人の参考になれば嬉しいです。
環境
- macOS: Tahoe 26.0.1 (arm64)
- Ruby (Homebrew): 3.4.7
- Bundler: 2.7.2
- CocoaPods: 1.15.2
- React Native: 0.76 系（Hermes 使用）
プロジェクトのルートは /Users/you/workspace/sample-rn-app です。
どんな問題だったのか？
最初は pod install が Installing hermes-engine (0.82.1) ... で固まるところからスタート。「Ruby が古いのでは？」と思って Homebrew で Ruby 3.4.7 を入れ直したところ、今度は ruby -v すら戻ってこず CPU 0% のまま沈黙。無反応のプロセスを強制終了せざるを得ない最悪のループに突入しました。
結果的に以下の二重苦が発生：
- Gatekeeper が Homebrew Ruby の実行を拒否し、プロセスが即座に沈黙
-
bundle installが古い Bundler (1.17.2) を無理矢理インストール → Ruby 3 系で消えたString#untaintを呼んでクラッシュ
トラブルシュートの道筋
Gatekeeper が沈黙を引き起こした背景（技術ノート）
- macOS 25〜26（Sequoia〜Tahoe）では Gatekeeper の「実行時検証キャッシュ」の挙動が変わり、
xattrを消しても拒否キャッシュが残るケースが出ています。spctl --assessではrejectedなのにxattrは空、という矛盾はこの仕様変更が原因です。 - Homebrew は Apple の Developer ID 署名を付けずに自前ビルドを配布しているため、Gatekeeper から見ると Ruby は「未署名で怪しい実行ファイル」。Python や Node.js でも同様のブロックが報告されています。
- Apple Silicon 世代の macOS ではセキュリティが強化されており、「brew install しただけで Gatekeeper に止められる」のは珍しくありません。今回の沈黙もこの流れの一環でした。
この章では、実際にどう切り分けて復旧したかを手順付きで整理します。
1. Gatekeeper にブロックされているのを確認する（再現確認）
まずは Gatekeeper が拒否して固まっていないか確かめる
which ruby
/opt/homebrew/opt/ruby/bin/ruby
spctl --assess --type execute --verbose /opt/homebrew/opt/ruby/bin/ruby
# => rejected
/usr/bin/log show --last 1m --predicate 'process == "syspolicyd"' | tail
# Unable to initialize qtn_proc: 3 が連発
xattr -p com.apple.quarantine ... では「そんな属性は無い」と言われるのに、spctl では rejected。つまり Gatekeeper 側のキャッシュが残っていて、実行許可が出ていない状態でした。Ruby プロセスは起動直後にブロックされ、CPU 0% のまま固まっていたわけです。
2. Quarantine 属性を根こそぎ削除する（キャッシュ掃除）
Gatekeeper の検疫属性とキャッシュを一斉クリア
sudo xattr -dr com.apple.quarantine /opt/homebrew/Cellar/ruby/3.4.7
sudo xattr -dr com.apple.quarantine /opt/homebrew/bin
sudo xattr -dr com.apple.quarantine /opt/homebrew/lib
sudo killall -HUP syspolicyd
syspolicyd を再起動してキャッシュをリセットするのがポイント。
3. 一時的に Gatekeeper を OFF にして Ruby を起動（動作確認）
Gatekeeper を一時無効化して Ruby が起動するか検証
sudo spctl --master-disable
export PATH="/opt/homebrew/opt/ruby/bin:$PATH"
hash -r
ruby -v
# => ruby 3.4.7 ... が表示されれば勝ち
spctl --master-disable は macOS 15 では「システム設定で確認してね」と言われるので、設定 > プライバシーとセキュリティ の一番下にある Gatekeeper の許可ダイアログで OFF を許可します。Ruby プロセスが即座に沈黙する症状がこれで収まるか確認しましょう。
4. Ruby が動くようになったら Gatekeeper を戻す（再有効化）
最後に Gatekeeper をもとに戻す
sudo spctl --master-enable
/usr/sbin/spctl --status
# => assessments enabled
ruby -v
Bundler 1.x が Ruby 3.x をクラッシュさせる問題
Gatekeeperを突破しても bundle install で次のエラーが出ました：
Bundler 1.x が Ruby 3 系でクラッシュするログ
Bundler 2.7.2 is running, but your lockfile was generated with 1.17.2.
Installing bundler 1.17.2 and restarting using that version.
...
undefined method 'untaint' for an instance of String (NoMethodError)
Ruby 3 系では String#untaint が削除されているので、Bundler 1.17 系はもう動きません。Bundler 1.x は RubyGems の旧 taint/untrust モデルに依存しているため、Ruby 3 以降ではクラッシュしてしまいます。以下のようにロックファイルを Bundler 2 系に更新して解決しました。
Bundler を 2 系に更新し、Ruby バージョンもロックファイルに反映
cd /Users/you/workspace/sample-rn-app
bundle _2.7.2_ update --bundler
bundle update --ruby
bundle install
これで Gemfile.lock の末尾が下記のように更新されます：
Gemfile.lock の末尾がこう変わる
RUBY VERSION
ruby 3.4.7p58
BUNDLED WITH
2.7.2
CocoaPods の再インストール
Bundler が整ったところで、Pods をクリーンにやり直します。
Pods を削除して再インストール
cd /Users/you/workspace/sample-rn-app/ios
rm -rf Pods Podfile.lock
bundle exec pod install --no-repo-update --verbose
hermes-engine のコピーや Privacy Manifest の集約なども含め、約 26 秒で全工程が完走しました。
最後にはお決まりの注意が出ます：
Xcode では .xcworkspace を使うように注意される
[!] Please close any current Xcode sessions and use `SampleRNApp.xcworkspace` for this project from now on.
✅ まとめ（学び）
- 🧱 Homebrew で入れた Ruby がレスポンスせず CPU 0% で沈黙したら Gatekeeper の rejection をまず疑う
- 🌀
sudo xattr -dr ...に加えてsudo killall -HUP syspolicydでキャッシュを忘れずに消す - 🔐 Gatekeeper を一時的に OFF → Ruby 動作確認 → すぐ ON に戻すのが安全ルート
- ⚠️ Bundler 1.x は Ruby 3 系の taint/untrust 廃止に非対応で、確実にクラッシュする
- 📌
bundle update --rubyでGemfile.lockの Ruby バージョンも合わせると後々トラブル減少 - 🚀 React Native 0.76 + Hermes の
pod installは 70 以上の依存が入り、正常完走で 20 秒台 - 🤝 「macOS 側の仕様変更に起因する落とし穴」を踏み抜いたログとして、同じ症状に困る開発者の助けになる
おまけ：最終チェックコマンド
/usr/sbin/spctl --status
# assessments enabled
which ruby
# /opt/homebrew/opt/ruby/bin/ruby
ruby -v
# ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +PRISM [arm64-darwin25]
bundle install
# Bundle complete!
cd ios && bundle exec pod install --no-repo-update --verbose
# Pod installation complete!
筆者より
macOS 26 (Tahoe) 以降では、Apple 公認署名のないバイナリに対して syspolicyd が QTN キャッシュを持続的に参照し、xattr が空でも拒否する挙動が見られます。今回のトラブルはこの仕様変更が引き金でした。
私はこれのために1週間ほど苦しみました。。
同じように Gatekeeper × Ruby × CocoaPods の三重苦にハマっている人の助けになれば嬉しいです。
🔮 CocoaPods のこれから
React Native 公式もアナウンスしているとおり、CocoaPods は将来的にアーカイブ予定で、新しい依存管理手段（Expo の npx expo run:ios や Community CLI の yarn ios）へ移行が進んでいます。現時点では既存プロジェクトの互換性確保に欠かせませんが、長期的には Swift Package Manager など代替手段への移行計画を立てておくと安心です。