React Native 0.86 iOSクラウド構築ガイド

React Native 0.86 iOSクラウド構築ガイド

React Native 0.86は2026年6月11日に正式リリースされ、公式発表ではユーザー向けの破壊的変更を含まないリリースと説明されています。(React Native公式リリース情報)

React Native 0.86 iOSクラウド構築の結論

勝者は「ローカルでコードを書き、遠隔MacでiOSネイティブ工程を実行する構成」です。 WindowsやLinuxではJavaScript、TypeScript、Git操作を続け、Xcode、CocoaPods、iOSシミュレーター、Archive、署名、App Store Connectへのアップロードだけを遠隔Macへ分けます。

すべての作業を遠隔Macへ移す必要はありません。React Native 0.86では、先にツールチェーンとロックファイルを固定し、その後にDebug、Release Archive、署名、アップロードの順で確認すると、失敗箇所を切り分けやすくなります。

最終更新日：2026年8月15日。React Native 0.86の公式発表、環境設定文書、Appleの配布およびApp Store Connect文書を確認しています。

この構成が合う開発者

WindowsやLinuxでReact Nativeアプリを書いており、手元にMacがない独立開発者が対象です。

自作のネイティブモジュール、複雑なPod設定、Xcodeプロジェクトの直接編集を含むチームにも向いています。リリース前だけでなく、継続的なiOSビルド環境を用意したい小規模チームにも適しています。

ローカル開発と遠隔Macの境界

React NativeのJavaScriptやTypeScript編集は、必ずしもMac上で行う必要はありません。一方、公式ドキュメントは、ネイティブコードを含むiOSアプリのビルドにはMacが必要だと説明しています。(React Nativeの実機実行ガイド)

実務では次のように分けます。

  • Windows／Linux側：エディター、TypeScript、JavaScript、Git、Issue対応、Androidビルド
  • 遠隔Mac側：Xcode、Command Line Tools、CocoaPods、iOSシミュレーター、実機署名
  • リリース工程：Release Archive、Validate、Export、App Store Connectへのアップロード

Framework中心でネイティブ設定が少ないプロジェクトなら、遠隔Macの利用頻度を抑えられる場合があります。しかし、独自のネイティブモジュール、Podのビルド設定、Entitlements、複数ターゲットを扱う場合は、ファイル操作だけでは足りません。Mac上のXcodeを直接操作できる権限が必要です。

開始前に、次の項目をリポジトリとApple Developer側で確認します。

  • 対象ブランチとコミット
  • package.jsonと採用中のロックファイル
  • Gemfile、Podfile、Podfile.lock
  • Bundle IDとApp Store Connectのアプリレコード
  • Team ID、署名方式、配布対象
  • 環境変数と秘密情報の保管場所

決定ツール：遠隔Macの使い方を分ける条件

次のチェックリストで、短期利用と常駐ビルド環境を分けます。該当する項目が複数ある場合は、単発の接続よりも、環境の持続性と再接続性を優先します。

  • [ ] JavaScriptやTypeScriptの編集が中心で、iOSのArchiveはリリース前だけ
    → 必要な期間だけ遠隔Macを使います。
  • [ ] ネイティブモジュールやPod設定を頻繁に変更する
    → VNCでXcodeを操作でき、SSHで同じコマンドを再実行できる環境を選びます。
  • [ ] 週に複数回Releaseビルドを作る
    → 作業ディレクトリ、依存関係、署名設定を保持できる常駐構成を優先します。
  • [ ] App Store Connectへのアップロードを自動化したい
    → APIキーや証明書を安全に保管でき、SSH経由で再現可能なビルドを組みます。
  • [ ] 物理iPhoneを頻繁にUSB接続する
    → 遠隔Macだけで完結すると決めず、実機接続方式を事前に確認します。
  • [ ] 依存関係を毎回手作業で入れ直している
    → ロックファイル、ツール一覧、セットアップコマンドを記録し、環境再構築の手順を先に作ります。

判断の目安は明確です。 上のチェックが0〜1個で、リリース前だけArchiveするなら短期の遠隔Macが候補です。2個以上に該当し、継続的な署名やビルドを行うなら、常時利用できる構成へ進みます。物理端末の接続が中心なら、遠隔Macだけで完結させず、手元の検証端末と役割を分けます。

最初の1時間：ツールチェーンの固定

React Nativeの公式環境ガイドは、Node、Watchman、Xcode、CocoaPodsなどをiOS開発に必要な構成として案内しています。現在のガイドではNode 22.11.0以上が例示されていますが、React Native 0.86のプロジェクトでは、プロジェクト設定と公式テンプレートを優先して確認します。(React Nativeの環境設定ガイド)

遠隔Macへ接続したら、最初に実行結果を保存します。

xcode-select -p
xcodebuild -version
node --version
npm --version
ruby --version
pod --version
git --version

出力例は固定値ではなく、次のように記録します。

Xcode: <プロジェクトで承認したバージョン>
Node: <プロジェクトで確認したバージョン>
Ruby: <Gemfileに対応するバージョン>
CocoaPods: <bundle exec pod --version の結果>

Xcodeの場所が不明な場合は、活動中の開発者ディレクトリを明示します。

sudo xcode-select --switch /Applications/Xcode.app
sudo xcodebuild -license

Nodeの場所が対話シェルとSSHで変わる場合は、React Nativeプロジェクトの.xcode.envにあるNODE_BINARYを確認します。GUIから成功しても、SSHやCIに近い非対話シェルで失敗する原因になりやすい部分です。

Gitの作者情報、作業ディレクトリ、Xcodeの選択状態を記録しておくと、遠隔Macを再構築する際に差分を追えます。ここでバージョンを曖昧にしたまま先へ進むと、後のArchive失敗が依存関係なのか署名なのか判別しにくくなります。

初回同期：ソースと依存関係の分離

プロジェクトはGitから取得します。ローカルで生成された依存関係やビルド成果物を、そのまま遠隔Macへコピーしません。

git clone <REPOSITORY_URL> <PROJECT_DIR>
cd <PROJECT_DIR>

git checkout <BRANCH_OR_COMMIT>
git status

次に、実際に存在するロックファイルだけを使います。

npm ci
# または、プロジェクトの指定に従って
yarn install --immutable
# または
pnpm install --frozen-lockfile

iOS側では、Gemfileがある場合にRuby依存関係を固定します。

bundle install
cd ios
bundle exec pod install

React Nativeの安定版テンプレートでも、GemfileとPodfileを使い、Ruby依存関係とCocoaPods依存関係を構成する流れが案内されています。Xcodeの世代によってCocoaPodsやxcodeprojの指定が変わる場合があるため、手元のPodfileを一般論で置き換えないでください。(React Nativeの既存iOSプロジェクト統合ガイド)

コピーを避ける代表例は次のとおりです。

  • node_modules
  • ios/Pods
  • DerivedData
  • 一時的なビルド成果物
  • 個人の証明書、秘密鍵、APIキー
  • ローカル絶対パスを含む設定ファイル

Podfile、ビルドスクリプト、.xcode.envに、開発者のホームディレクトリやWindowsのドライブ文字が残っていないか確認します。pod installが成功しても、Xcodeプロジェクトが遠隔Macのパスを参照していればArchiveで失敗します。

初回Debug：実行経路の分解

最初のビルドは配布用ではなく、Debug経路の確認に限定します。Metro、JavaScript依存関係、ネイティブモジュール、コード生成、リソース、シミュレーターの順に確認します。

cd <PROJECT_DIR>
npx react-native start

別のSSHセッションで実行します。

npx react-native run-ios --simulator "<SIMULATOR_NAME>"

Xcodeを使う場合は、ios/<PROJECT>.xcworkspaceを開きます。CocoaPodsを利用するプロジェクトで.xcodeprojだけを開くと、Pods統合を反映できません。

遠隔Macの操作は二つに分けます。

  • VNC：XcodeのSigning設定、Scheme、シミュレーター、ログ画面の確認
  • SSH：依存関係の復元、Pod操作、ビルドコマンド、ログ保存

同じ作業体験として扱わないことが重要です。GUI操作は状態を見やすく、SSHは同じコマンドを再実行しやすいからです。

失敗時は、次の4段階でログを保存します。

  1. 依存関係の解決
  2. ソースのコンパイル
  3. ライブラリのリンク
  4. シミュレーターまたは実機での起動

キャッシュ削除を繰り返す前に、最初に失敗したターゲット、使用されたパス、Releaseとの差分を確認します。Debugが動いても、署名やRelease固有の設定が正しいとは限りません。

Release Archiveと署名

Debug確認後に、配布用のArchiveへ進みます。Appleは、配布前にXcodeでArchiveを作成し、OrganizerからValidateやDistribute Appを実行する手順を案内しています。(AppleのXcode配布ガイド)

コマンドラインで確認する場合は、プロジェクトのSchemeとワークスペースを明示します。

xcodebuild \
  -workspace ios/<PROJECT>.xcworkspace \
  -scheme <SCHEME> \
  -configuration Release \
  -sdk iphoneos \
  -archivePath <ARCHIVE_PATH>/<APP>.xcarchive \
  archive

ここで使う値は、実際のプロジェクトのものに置き換えます。Team ID、Bundle ID、証明書名、秘密鍵のパスワードをコマンドへ直接書き込まないでください。

Archive後は、次の順に状態を分けます。

  • Archiveが作成された
  • ArchiveのValidateが通った
  • IPAのExportが成功した
  • App Store Connectへのアップロードが完了した
  • Apple側の処理が完了した
  • App Storeの審査へ提出した

Archive成功を「公開完了」と扱ってはいけません。Appleの説明でも、アップロードしたビルドは処理後にApp Store Connectへ表示されます。(App Store Connectのビルド管理ガイド)

Bundle IDはアプリを識別する重要な値です。Appleは、最初のビルドをアップロードした後はBundle IDを変更できないと説明しているため、App Store ConnectのアプリレコードとXcodeの設定を先に突き合わせます。(Appleの配布準備ガイド)

App Store Connectアップロード

XcodeのOrganizerからアップロードする場合は、Archiveを選び、Distribute AppからApp Store Connect向けの配布を選択します。AppleはXcode、Transporter、App Store Connect APIなど複数のアップロード方法を案内しています。

APIキーを使う場合の概念例は次のとおりです。

export ASC_KEY_ID="<API_KEY_ID>"
export ASC_ISSUER_ID="<ISSUER_ID>"
export ASC_PRIVATE_KEY="<SECURE_KEY_PATH>"

実際の秘密鍵は、シェル履歴、Git、共有メモ、スクリーンショットへ残しません。Apple Developer側では、アカウントの役割とApp Store Connectの権限を必要最小限に設定します。

アップロード後は、処理状態、警告、エラーを確認します。App Store Connectでは、処理完了前のビルドをアプリのバージョンへ選択できません。処理後に対象ビルドを選び、輸出コンプライアンスなどの追加項目を確認してから審査提出へ進みます。(App Store Connectでビルドを選択する手順)

構築後の一週間：再現性の確認

初回Archiveが成功しただけでは、常用できるiOSビルド環境とはいえません。次の作業を同じ遠隔Macで繰り返します。

  • 依存関係を削除した状態からの冷起動ビルド
  • 既存のDerivedDataを使った増分ビルド
  • VNC接続を切った後のSSH再接続
  • サインアウト後のXcode署名確認
  • 同じArchiveコマンドの再実行
  • アップロード後のApp Store Connect処理確認

各回で、使用したコミット、ツールバージョン、実行コマンド、最初のエラー、生成されたArchiveの場所を保存します。環境の持続性、ディスク使用量、ログ保存期間は、契約する遠隔Macの構成や運用条件によって異なるため、実際の提供条件で確認します。

React Native iOS構築を継続するなら、SFTPMACのMacレンタル料金と利用条件を確認し、利用期間、SSH接続、GUI操作、環境保持の条件を照合します。単発のArchiveだけなら短期利用、頻繁なテストやリリースなら常時利用を候補にします。

現在の構成と遠隔Macの選択

WindowsやLinuxだけで進める構成は、iOSネイティブビルド、Xcodeの署名設定、シミュレーター操作、App Store Connectへの配布を自動的に解決してくれません。Macを都度借りる方法では、環境の初期化、依存関係の再取得、証明書の再設定が隠れた負担になります。

一方、SFTPMACの遠隔Macなら、必要な期間だけmacOS環境を確保し、VNCでXcodeを操作しながらSSHで再現可能なコマンドを実行する構成を検討できます。初回Archive後に、発表前だけ使うのか、継続的なiOSビルドへ移行するのかを決めるのが現実的です。

まずはSFTPMACのMac環境案内を確認し、React Native 0.86の利用期間、署名作業、SSH接続、常時稼働の必要性が合うプランかを照合してください。長期の重いビルドを毎日続ける場合や、物理端末を常時接続する場合は、自前のMacや別の構成も含めて比較するのが適切です。

関連記事