WindowsだけでReact Native 0.87のアプリ開発を続けられますか？

はい。JavaScriptまたはTypeScriptの編集、Metroによる開発、業務ロジックの単体テスト、Android向けの作業はWindowsで継続できます。ただし、Apple向けSimulator、Xcodeを使うビルド、ネイティブ依存関係の確認、署名と提出はMac側の工程です。開発全体をWindowsだけで完結させることはできません。

React Native 0.87でMacが必要になる工程はどこですか？

Macが必要になる代表的な工程は、iOS Simulatorでの画面確認、SwiftまたはObjective-Cを含むネイティブモジュールの検証、CocoaPodsなどの依存関係を含むXcodeビルド、Archive、署名、配布用ファイルの作成です。コードの大部分を書けることと、Apple向け成果物を納品できることは別の判定にしてください。

リモートMacでReact NativeのSimulatorを実用的に動かせますか？

実用性は、リモートデスクトップの画面品質、入力遅延、接続の安定性、Mac側の空き容量に左右されます。Simulatorを操作する作業はグラフィカルな接続で行い、依存関係の導入やビルドはSSHで分ける構成が扱いやすいです。最終的な端末互換性は実機でも確認してください。

手元にMacがない状態で署名済みアプリを納品するには何が必要ですか？

Mac上でXcodeのArchiveとエクスポートを実行し、署名証明書、秘密鍵、Team ID、Bundle Identifier、配布用トークンを用意します。これらを通常の開発アカウントと同じ権限で共有するのは避け、専用アカウントと保管場所を分けてください。インストール可能な成果物、署名検証結果、実行記録を納品証跡にします。

React Native開発ではMacをレンタルするべきですか、それとも購入すべきですか？

短期案件、低頻度のApple端末確認、リリース前のArchiveが中心なら、まずリモートMacで実プロジェクトの閉ループを確認する判断が合理的です。毎日Simulatorを操作する、実機を常時接続する、低遅延の画面調整が多い場合は本体購入を検討してください。チームでは日常開発とMac CIを分ける混合構成が候補になります。

React Native 0.87 Macなしでどう開発する？2026年の納品方法

WindowsまたはLinuxを主な開発環境にしている場合でも、JavaScriptやTypeScriptの実装とAndroid開発は従来の環境で継続できます。一方、Simulator、Xcodeビルド、Apple向け署名と納品はMacへ分離する必要があります。本稿では、React Native 0.87の開発工程を場面ごとに分け、遠隔利用、本体購入、混合構成を選ぶ基準まで整理します。

Windowsでは業務コードもAndroidビルドも正常なのに、最初のApple向け成果物を作る段階で処理が止まります。

最短の解決策は、JavaScriptとTypeScriptの開発をWindowsまたはLinuxに残し、Simulator、ネイティブ依存関係、Xcodeビルド、署名、納品だけをMacへ分離することです。React Native 0.87 Macなしでどう開発するかを考えるなら、遠隔利用から始め、実案件のArchiveまで通るかを確認してください。

最終更新：2026年9月20日。React Native公式資料とApple公式の提出要件を同日に確認しています。

この判断が必要な開発者

この記事は、WindowsまたはLinuxを主力機にしているReact Native開発者が、ローカル作業とMac作業の境界を決めるためのものです。Apple向けCIを設計するDevOps担当者はMacノードの責任範囲を整理でき、技術責任者は購入、レンタル、混合構成を実際の作業量で比較できます。

React Native 0.87は2026年8月11日の公式リリースで扱われているバージョンです。公式環境資料でもApple向け開発にはXcodeが必要とされているため、「コードを書ける環境」と「Apple向けに納品できる環境」を同じものとして扱わないでください。React Native 0.87の公式リリースノートと公式の環境構築要件が判断の基準になります。

作業場所を先に分ける

まず、WindowsまたはLinuxに残せる作業を明確にします。エディター、JavaScriptまたはTypeScriptの実装、Metroの起動、業務ロジックの単体テスト、Android向けの確認は、Apple固有のツールチェーンを使わない限り主力環境で進められます。

ただし、次の失敗は典型的です。

JavaScriptの変更は動くが、iOSプロジェクト生成後にXcodeビルドで止まる
Androidでは通る依存関係が、Apple向けネイティブモジュールで失敗する
Simulatorの画面確認をしないまま、実機または配布用成果物へ進む
CIでビルドは完了しても、署名、Archive、エクスポートの段階で止まる

したがって、判定を3つに分けます。JavaScript層の成功、ネイティブプロジェクト生成の成功、XcodeによるApple向けビルドの成功です。1つ目だけを確認して「Apple版も完成した」と判断するのは危険です。

React Native 0.87 Macなし開発でMacへ移す工程

第一段階：画面とSimulatorを確認する

XcodeはApple向けSDK、ビルド、Simulator、実機実行を担います。Simulatorの操作にはリモートデスクトップなどのグラフィカルな接続を使い、依存関係の導入やビルドログの取得にはSSHを使うと、作業を分けやすくなります。

遠隔のMacを使う場合は、最初に次の2経路を別々に確認してください。

グラフィカルなセッションでログインし、Simulatorを起動できる
SSHで同じMacへ入り、リポジトリのコマンドを実行できる
同じユーザーの作業ディレクトリを両方の経路から確認できる
画面接続が切れた後も、ビルドログと終了コードを取得できる

Simulatorは開発時の検証には有効ですが、実機のカメラ、プッシュ通知、Bluetooth、画面性能、署名状態まで再現するものではありません。Apple公式の Simulatorと実機でアプリを実行する説明でも、実行対象ごとの扱いが分けられています。

第二段階：ネイティブ依存関係を再現する

SwiftまたはObjective-Cの変更、ネイティブモジュールの追加、CocoaPodsを含む依存関係の導入がある場合は、Mac上で新しい作業ディレクトリを作ってください。既存のキャッシュや開発者固有の設定を残したままでは、再現性を判定できません。

確認手順は次の通りです。

<REPOSITORY_URL> からクリーンなディレクトリへクローンする
<NODE_VERSION>、パッケージマネージャー、React Native 0.87の依存関係を固定する
npm install またはプロジェクトで指定された導入コマンドを実行する
iOS側の依存関係を導入する
<SCHEME_NAME> を指定してXcodeまたはCLIでビルドする
Simulatorテストを実行し、ログと終了コードを保存する

React Native 0.87ではSwift Package Managerの経路を試す場合でも、プロジェクトの既定経路や既存依存関係との整合性を先に確認してください。この記事ではCocoaPodsとSwift Package Managerの優劣を決めるのではなく、どちらを使う場合もMac上で同じコミットを再現できるかを判定します。

注意：React NativeのJavaScriptテストが成功しても、Xcodeのコンパイル、リンク、署名が成功したことにはなりません。各段階のログを別ファイルで保存し、判定を混ぜないでください。

第三段階：Xcodeの世代とCIを固定する

Xcode 27を使うプロジェクトでは、Macノードに実際に導入されたXcodeのバージョン、SDK、Command Line Toolsを記録してください。Xcode 27を指定したからといって、CI上の別ノードが同じ環境になるわけではありません。Appleの要件変更やプロジェクトの指定を、導入前に公式ページで再確認します。

Appleは2026年4月28日以降、App Store Connectへ提出するアプリについて、Xcode 26以降と対応SDKでのビルドを求める予定を公式に案内しています。Appleの提出要件を確認し、Xcode 27の扱いを未確認の噂や予定だけで決めないでください。

CIでは、タスクを次のように分けます。

共通ノード：静的解析、JavaScriptテスト、依存関係の検査、Android処理
Macノード：iOS依存関係、Simulatorテスト、Xcodeビルド、Archive
保護された公開工程：署名、エクスポート、提出用ファイルの作成

Macノードには専用の <CI_USER> を用意し、リポジトリ、DerivedData、依存関係キャッシュをジョブ単位で整理します。ジョブ終了後に作業ディレクトリを消去できるか、再起動後にRunnerが戻るか、同じコミットから同じ成果物を作れるかを確認してください。

Archiveと署名を納品の合格条件にする

ビルドが通っただけでは、Apple向け納品は完了していません。Archive、エクスポート、署名検証、インストール確認、提出記録までを一つの閉ループとして扱います。

第四段階：公開権限を分離する

<BUNDLE_IDENTIFIER>、<TEAM_ID>、<CERTIFICATE_NAME>、<PROFILE_NAME>、<TOKEN_NAME> は、実際の値を記事や共有ログへ書かず、保護された変数として管理します。通常の開発セッションに配布用の秘密鍵を置いたままにせず、公開用ジョブだけが参照できる権限へ分離してください。

合格条件は次の4点です。

Archiveが完了し、失敗理由をログで追える
指定した署名IDとTeam IDが一致している
エクスポートした成果物を指定端末へインストールできる
誰が、どのコミットから、どのMacノードで作ったかを記録できる

Archiveと配布の操作は、Appleの Archiveおよびベータ配布・リリース手順と配布前のプロジェクト設定に沿って確認します。

遠隔利用、本体購入、混合構成の比較

最初から購入を決めるのではなく、実案件で「Simulator操作の頻度」「実機接続」「Archiveの頻度」「CI常駐」の4点を測ってください。価格や性能だけでなく、作業の復旧性と権限管理も選択条件になります。

構成	向いている作業	強み	注意点	判断
Windows/Linux＋リモートMac	低頻度のApple確認、短期案件、Archive	主力環境を変えずにMac工程だけ追加できます	画面遅延、接続断、実機接続の制約を検証する必要があります	まず試す候補
ローカルMac	毎日のSimulator操作、実機連携、UI調整	入力と画面確認が安定しやすく、周辺機器を直接扱えます	購入後の利用率、保守、遊休期間を見積もる必要があります	高頻度開発向け
混合構成	チームCI、定期ビルド、複数開発者	日常コードとApple向け実行層を分離できます	Macノードの更新、キャッシュ、秘密情報の管理が必要です	チーム納品向け

VPSMACの Macノードの選択肢を見る場合も、先に実プロジェクトでクローン、依存関係導入、Simulator、Archiveを順番に確認してください。地域を選ぶ必要がある場合は、東京のMacノード案内のように、接続経路と利用条件を確認してから判断します。

よくある判断をFAQで整理する

上の工程を実施すると、WindowsやLinuxを捨てる必要はないことが分かります。必要なのは、Apple固有の検証と公開権限をMac側へ寄せ、各段階の証拠を残す設計です。

第五段階：1つのコミットで閉ループを確認する

候補の構成を決める前に、実際の <COMMIT_SHA> を選び、次の順番で実行します。

WindowsまたはLinuxでJavaScript層のテストを通す
Macへクリーンクローンする
依存関係を導入し、ネイティブプロジェクトを生成する
Simulatorで主要画面を確認する
Xcodeビルドとテストを実行する
Archiveとエクスポートを行う
署名結果とインストール結果を記録する
Macを再起動し、同じ工程を再実行する

この結果、画面操作だけが不安定なら遠隔デスクトップの改善またはローカルMacを検討します。ビルドや署名が不安定なら、先にツールチェーン固定、アカウント分離、キャッシュ消去、ログ保存を直してください。構成を変える前に失敗箇所を分けることが重要です。

現在の環境とMac構成をどう選ぶか

WindowsまたはLinuxだけで進める構成は、Apple向けSimulator、Xcode SDK、ネイティブ依存関係、署名を同じ環境で検証できません。共有Macを無計画に使う方法も、アカウント権限、作業ディレクトリ、秘密鍵、ツールチェーンの混在が障害になります。

そのため、低頻度のApple確認や短期の納品であれば、まずVPSMACのリモートMacで1つのReact Native 0.87プロジェクトを閉ループ検証する方法が現実的です。毎日グラフィカルな調整を行う場合は本体購入を、チームで継続的に成果物を作る場合はローカル開発とMac CIを組み合わせる構成を検討してください。

今週は、実案件のコミットを1つ選び、クリーンクローン、依存関係導入、Simulatorテスト、Archive、再起動後の再実行までを記録してください。その結果をもとに、短期レンタルを続けるか、ローカルMacを購入するか、Mac実行層をCIとして常設するかを決めるのが安全です。