ReactとReact Nativeの違いを描画・部品・スタイル・画面遷移の4層で比較【2026年8月時点】

ReactとReact Nativeは名前が似ており、どちらもコンポーネントとHooksで画面を組み立てる点は共通です。ところが実際に移植へ着手すると、divが書けない、CSSファイルを読み込めない、URLが無いという壁に順番にぶつかります。この記事では両者が共有する層と入れ替わる層を切り分け、描画・部品・スタイル・画面遷移の4点で何が変わるのかを実装の解像度で並べ、既存アプリをモバイルへ移す際の書き換え量を見積もる手順まで示します。

まとめ：ReactとReact Nativeの違いは層の境界で切り分ける

結論を先に書きます。両者は別々の製品ではなく、共通のreactパッケージの上に別々の描画先を載せた組み合わせです。境界はreactとreact-domの間にあり、これより上の状態管理・Hooks・コンポーネントの分割方針はほぼそのまま持ち運べる。境界より下、つまり画面に出す部分は総入れ替えになります。

入れ替わるのは4か所です。描画先がDOMからネイティブのビュー階層へ移り、divやspanがViewとTextへ置き換わり、CSSファイルがJavaScriptのオブジェクトになり、URLの履歴管理が画面スタックの管理へ変わる。4か所は独立しておらず、CSSが消えればメディアクエリによる画面幅の分岐も同時に書き直しです。

見積もりの目安も示します。状態とロジックが全体の4割を占めるアプリなら、その4割は流用できる計算です。残る6割のうち画面の組み立ては要素名の置換で済む一方、スタイルと画面遷移は作り直す前提で見ておくと崩れません。

共通しているのはreactパッケージまでで画面を描く層から先が入れ替わる

同じ再調整エンジンとHooksを使い描画先だけを差し替える構造

reactというパッケージが担うのは、状態が変わったときに画面の何をどう更新するかを計算する部分です。Hooks、Context、Suspenseの制御はこの層にあります。React Nativeのアプリでも、npmから入れるreactは公開元も版番号もWeb向けと同一で、2026年8月18日時点の最新版は2026年7月21日公開の19.2.8でした。

計算結果を画面へ反映する担当が、いわゆるレンダラです。Webではreact-domが、モバイルではreact-nativeに同梱されたレンダラがその役目を負う。同じ計算結果を受け取り、片方はDOMを書き換え、もう片方はネイティブのビューを操作します。

react-domとreact-nativeが担うホスト側の役割の違い

レンダラの仕事は、要素の生成、属性の反映、子要素の並べ替え、そして破棄です。react-domはこれをDOM APIで行い、react-nativeは同じ仕事をiOSのUIViewやAndroidのViewGroupの生成という形で行います。公式ドキュメントはこの仕組みで作られる部品をplatform-backed componentsと呼び、実行時にネイティブのビューが作られるため見た目も操作感もほかのアプリと同じになる、と説明しています。

帰結が1つあります。ホストが違う以上、ホスト固有の型はコードを跨げません。HTMLElementを引数に取る処理、ref経由でscrollTopを触る処理、getBoundingClientRectで座標を測る処理は動かない。逆に言えば、ホスト固有の型に触れていない関数は無条件で持ち運べる。移行量を測る最初の物差しがこれになります。

版番号が別々の系統で進むため公式の対応表で組み合わせを決める

版番号の付け方も別系統です。Reactは19.2.8のように三桁で進む一方、React Nativeは0.87.0のように先頭が0のまま二桁目が上がります。0.87.0は2026年8月11日、0.86.0は2026年6月9日、0.85.0は2026年4月7日の公開で、おおむね2か月間隔。実務で効くのは、どのReactと組み合わせるかを自分で決められない点です。各版は同梱レンダラが対応するReactの系統を固定しており、Web側の感覚で最新へ上げると起動しません。ネイティブ側の内部構造そのものはReact Nativeとは？仕組みとNew Architectureの構造・採用判断で層ごとに整理しています。

描画層の違いはDOMツリーかネイティブのビュー階層かという点にある

次は画面が実際に作られる場所です。ここが変わると、レイアウトの計算主体とブラウザAPIの可否も同時に変わります。

ブラウザのDOM要素に対しUIViewとViewGroupが生成される

Webでは、書いたJSXがDOMのツリーになり、それをブラウザが解釈して描画します。React NativeではJSXがネイティブのビュー階層になり、iOSではUIViewの入れ子、AndroidではViewGroupとその子ビューの入れ子ができる。要素検証の手順は使えず、XcodeやAndroid Studioの階層表示で確認する形になります。

レイアウト計算がブラウザエンジンからYogaへ移ることの影響

Webのレイアウトはブラウザのレイアウトエンジンが行います。React NativeではYogaというC++実装のエンジンが同じ役目を担い、計算結果に従ってネイティブのビューへ座標と大きさが渡される。Yogaが実装するのはflexboxの範囲に限られ、gridやfloat、positionのstickyは持ちません。

単位の扱いも変わります。px・rem・em・vw・vhはそのまま渡せず、数値が密度非依存の値として解釈される。パーセント指定は幅と高さなど一部でしか受け付けず、画面幅で分岐するならuseWindowDimensionsの実測値を使います。

windowとdocumentが無い前提で代替のAPIに置き換える

ブラウザのグローバルオブジェクトは存在しません。documentもlocalStorageも無く、windowは変数として一応あるものの中身は別物です。置き換えが要る代表例を挙げます。

• localStorageやsessionStorage：非同期ストレージへ置き換える。2026年8月18日時点でasync-storageの最新版は3.1.1。同期で読めなくなるため、読み出し側の関数が非同期になります
• DOM操作による測定：onLayoutやmeasure系で、描画後に座標と寸法を受け取る形へ書き換える
• alertやconfirm：AlertのAPIに置き換える。戻り値は待てず、コールバックで受けます
• Cookieとセッション：自動送信が無いため、トークンを保存して自分でヘッダへ載せる設計にする

一方でfetchとWebSocketは実装されており、通信まわりはほぼそのまま動きます。手が止まりやすいのは通信ではなく、上に挙げた画面と端末に寄った部分です。

部品の違いはdivとspanが消えViewとTextに置き換わる点

主要な要素の対応関係を公式のコア部品表で一つずつ照らし合わせる

公式ドキュメントは、コア部品とネイティブのビュー、Webでの相当要素を並べた対応表を示しています。移植の初手はこの表に沿った置換になります。

表に無い要素は、対応物が無いか別の考え方で組み直します。ulとliは意味を持たなくなるため、件数の多い一覧はFlatListのような仮想化部品へ置き換える。tableに相当する部品も無く、Viewの入れ子とflexboxで桁を揃えます。

文字列は必ずTextの内側に置くという制約が生む書き換えの量

Webではdivの中に直接文字を書いても表示されます。React Nativeでは文字列をText以外の部品の直下に置けず、置けば実行時に落ちる。単純な制約に見えて、実際の移植ではここが一番手数を食います。

// React（react-dom）
<div className="card" onClick={open}>
  残り3件
</div>

// React Native
<Pressable style={s.card} onPress={open}>
  <Text>残り3件</Text>
</Pressable>

条件分岐で文字列を返す箇所、テンプレートリテラルを直接埋める箇所、三項演算子で空文字を返す箇所がすべて対象です。文字を含むJSXの行数が、そのまま作業量の目安になります。

onClickではなくPressableのonPressで操作を受ける

イベント名も変わります。onClickはonPressになり、onMouseEnterに相当するものは無く、onPressInとonPressOutで押下の開始と終了を取る。ホバーという状態が指の操作に無いため、ホバーで補助情報を出す設計は長押しや情報アイコンへの置き換えになります。

タッチの伝わり方も別です。Webのイベントは親へ伝播しますが、React Nativeはどのビューが操作を受け持つかを決める仕組みで動きます。公式ドキュメントはさらに、タッチの反応領域が親ビューの境界を越えない点と、Androidで負のmarginが効かない点を明示しています。親からはみ出させた要素は、見た目を再現できても押せない領域が残る点に注意してください。

スタイルの違いはCSSファイルが消えJavaScriptの値になる

キャメルケースのオブジェクトとStyleSheet.createの位置

公式ドキュメントの説明は簡潔で、プロパティ名と値はおおむねCSSと同じだが名前はキャメルケースで書く、というものです。background-colorはbackgroundColorになり、単位は付けず数値を渡します。

// Web: card.css
.card { background-color: #fff; padding: 16px; }

// React Native
const s = StyleSheet.create({
  card: { backgroundColor: '#fff', padding: 16 },
});

StyleSheet.createは、スタイル定義を1か所へまとめる入れ物です。styleには配列も渡せて後ろが優先されるため、条件付きのスタイルはこの配列で表現します。

flexboxの既定値が4点ずれるため画面が縦方向に崩れる理由

移植で最初に見た目が壊れる原因はここです。公式ドキュメントは、flexboxはWebとほぼ同じに動くが既定値が違うと注意しており、差は次の4点になります。

影響が大きいのは1つ目と3つ目です。横並びを期待した箇所がすべて縦積みになり、はみ出しても縮まないため画面外へ流れる。移植ではflexDirectionのrowを明示し、flexShrinkを1で指定し直す作業が機械的に発生します。flexの複合値もflexGrowとflexBasisへ分解してください。

カスケードとメディアクエリが無い前提でどう書き分けるかの判断

クラス名によるスタイルの共有と、親から子への継承は存在しません。文字色やフォントサイズをbodyへ書いて全体へ効かせる設計は成り立たず、Textごとに指定するか、スタイル済みのTextを自作して使い回します。公式ドキュメントも、styleプロパティを受け取る部品を作って子へ渡す形を紹介しています。

疑似クラスとメディアクエリも不在です。hoverやfocusは状態変数で管理し、画面幅の分岐はuseWindowDimensionsの値で行う。クラス名でスタイルを書ける仕組みを別途入れる選択肢もあり、詳しくはNativeWindとは？Tailwind CSSをReact Nativeで使うための統合ライブラリで扱っています。2026年8月18日時点の最新版は4.2.6。ただし導入してもカスケードと継承は戻らず、記法が近づくだけです。

画面遷移の違いはURL履歴の管理か画面スタックの管理かにある

4層目は画面の切り替えです。記法の違いというより、何を管理対象にするかという設計の違いになります。

React RouterはURLとHistory APIを前提に画面を決める

Web側のルーターは、現在のURLを唯一の状態として画面を決めます。パスを変えれば画面が変わり、戻るボタンは履歴を1つ戻り、URLを共有すれば同じ画面が開く。2026年8月18日時点でreact-routerの最新版は8.3.0、旧来のパッケージ名であるreact-router-domは7.18.2で並行して公開されています。設定の書き方はReact Routerのmeta・title設定と基本ルーティングで扱っています。

React Nativeではネイティブの画面スタックを積み上げる

モバイル側にURLバーはありません。管理するのは画面の積み重なりそのもので、React Navigationが標準的な選択肢です。2026年8月18日時点で本体パッケージは7.3.16、ネイティブの画面遷移を使うnative-stackは7.18.8。画面を開くとスタックへ積み、戻ると1つ取り出す。iOSの横スワイプやAndroidの戻るボタンはこのスタックへ直結します。

設計上の違いは3つあります。第一に、画面は積まれたまま残るため、戻ったときに前の画面の状態が生きている点。マウントし直される前提の初期化処理は、再び前面へ出たことを検知する仕組みへ移します。第二に、タブとスタックを入れ子にでき、どの階層に戻るかを設計で決める点。第三に、遷移がネイティブのアニメーションで行われ、描画コストが端末性能に左右される点。外部リンクから特定画面を開く場合も、1つのリンクを複数画面へ展開する設計が要ります。

既存Reactアプリの移行量をファイル種別ごとの書き換え率で測る

ここまでの層の話を見積もりへ落とします。全体を一律に何割と置くより、ファイルの役割ごとに扱いを決めるほうが実測に近づきます。

既存コードをそのまま動く層と書き換える層と作り直す層に分ける

手元のリポジトリをファイル単位で次の6分類へ割り振り、行数を数えます。

この分類で数えると見積もりの精度が上がります。状態とロジック、通信と型の行が多いほど移行は軽く、スタイルと画面遷移の比率が高いほど重くなる。UIライブラリに強く依存しているなら、それがモバイルへ対応しているかを先に確認し、対応していなければその画面はすべて作り直す層へ移します。

見積もりから漏れやすいビルド環境と実機確認とストア審査の工数

コードの書き換え量だけでは実際の期間と合いません。Web開発には無かった工程が3つ加わるためです。

• ビルド環境：iOS側はmacOSとXcode、Android側はJDKとAndroid SDKが要ります。ネイティブ依存を含むライブラリを入れるたびに設定ファイルへ手が入る。負担を減らす選択肢がExpoで、役割と範囲はExpo（React Native）とは？Expo Go・開発ビルド・EASの役割と採用判断で整理しています
• 実機確認：iOSとAndroidの両方で、複数の画面サイズとOS版を確かめます。カメラや通知など端末機能はシミュレータで再現しきれません
• ストア審査：公開までの待ち時間が入り、差し戻されれば修正して再提出です。リリース日から逆算した計画が要ります

この3工程は初回リリースだけでなく、版上げのたびに発生します。安定版が2か月おきに出ている以上、年に数回は追随が入る前提で運用費を組むほうが破綻しない。社内に知見が無いなら、初回の環境構築と審査対応を外部と組む方法もあります。当社ではFlutter / React Nativeによるクロスプラットフォーム開発として、既存Webアプリのモバイル展開から運用フェーズの版追随までを請け負っています。

react-native-webで1つのコードを両方へ出す条件と限界

変換の向きはWebからではなくネイティブ側からWebへ向かう

react-native-webは、公式ドキュメントの言葉を借りればReact DOMとReact Nativeの互換層です。React Native向けに書いたコードを、React DOMでブラウザに描画する。ViewやText、Image、TextInput、ScrollViewといったコア部品を備え、JavaScriptで書いたスタイルをCSSへ変換して出力します。2026年8月18日時点の最新版は0.21.2です。

押さえるべきは向きです。既存のWebコードがモバイルで動くのではなく、React Nativeの書き方へ統一したコードがWebでも動くようになります。divをViewへ、文字列をTextへ、CSSをオブジェクトへ書き換える作業は先に済ませる必要がある。書き換えたあとにWeb版を維持できる、という位置づけです。

採用してよい条件と分けて作ったほうが早い場面をそれぞれ切り分ける

採用してよいのは3条件がそろう場合です。第一に、Web版とモバイル版で画面構成と操作の流れをほぼ同じにしてよいこと。第二に、開発要員が1チームで、双方のUIを別々に維持する余力が無いこと。第三に、Web側で検索からの集客を狙わないこと。ログイン後の業務画面や社内向けツールは、この3つを満たしやすい対象です。

分けて作ったほうが早いのは、逆の条件が1つでも当てはまる場合です。Web版が検索からの流入を前提にしている、Web版でだけ表示する情報量が多い、Web側に大量のコンポーネント資産がある、といった状況では、両方の要求を1つのコードへ押し込む調整コストが別々に書くコストを上回る。迷うときは、WebとモバイルでUIが同じになる画面の比率を数え、7割を下回るなら状態とロジックだけを共有して画面は分けてください。

よくある質問

ReactができればReact Nativeもすぐ書けますか？

状態管理とコンポーネント設計の知識はそのまま通用しますが、画面を出す部分は学び直しになります。部品名の対応、スタイルの記法とflexboxの既定値、画面遷移の考え方、ビルドと実機確認の手順の4点です。つまずくのは文法ではなく、CSSファイルが無いことと戻るボタンの挙動になります。

React NativeはWebViewでHTMLを表示しているのですか？

違います。JSXから作られるのはネイティブのビューで、iOSではUIView、AndroidではViewGroupが生成され、HTMLは介在しません。WebViewを部品として使えますが、それは外部のWebページを埋め込む機能で、通常の画面はネイティブのビューで構成されます。

Web版のCSSをそのままReact Nativeへ持ち込めますか？

持ち込めません。CSSファイルという概念が無く、スタイルはJavaScriptのオブジェクトとして書きます。プロパティ名はキャメルケースで、単位の無い数値を渡す。gridやfloat、疑似クラス、メディアクエリは無く、カスケードと継承も働きません。値の対応表を作って変換し、レイアウトは組み直す前提で見積もってください。

ReactとReact Nativeでコードをどれくらい共有できますか？

共有できるのは、画面に触れない層です。状態管理、業務ロジック、通信処理、型定義、検証ルールはほぼそのまま持ち運べる一方、画面の組み立てとスタイルと画面遷移は共有できません。この境界を前提に共有層を別パッケージへ切り出すと、両方の版を並行して保守しやすくなります。

ReactとReact Nativeのどちらから学ぶべきですか？

Reactから入るほうが遠回りになりません。Hooksとコンポーネント設計はどちらでも使う土台であり、Web側は実行環境の準備が軽く試行の回転も速いためです。React Nativeから始めると、言語の理解とビルド環境の整備を同時に進めることになり、原因の切り分けが難しくなります。

関連記事

• React Nativeとは？仕組みとNew Architectureの構造・採用判断を実装目線で解説：ネイティブ側の内部構造を層ごとに確認できます
• Expo（React Native）とは？Expo Go・開発ビルド・EASの役割と採用判断：工数が読みにくいビルド環境の全体像が分かります
• FlutterとReact Nativeの違いと選び方｜2026年の判断基準：モバイル側の選択肢を横並びで比較できます
• React Nativeはオワコンか？離れの実態を更新頻度・案件数・採用状況で検証：採用前に継続性を数値で確かめる判断材料です
• React Routerのmeta・title設定と基本ルーティング｜v8対応入門：Web側のルーター設定を確認できます