Swift 7年書いてきたけど React Native に賭けてみようと思う

• この記事は2025年12月時点の情報に基づいています
• この記事は生成AIを活用して執筆しています
• 本記事での React Native は Expo を前提としています
• 本記事の内容は私個人の観測・体験に基づく主観であり、統計データに基づくものではありません
• Flutter も React Native もまだ半年程度の経験であり、長年使い込んだ上での評価ではない点にご留意ください
• 本記事では便宜上「Swift」「Flutter」「React Native」と表記していますが、厳密には Swift/SwiftUI、Dart/Flutter、TypeScript/React Native のように言語とフレームワークの組み合わせを指しています（わかりやすさを優先し簡略化しています）

はじめに

エンジニア歴9年、Swift歴7年、フリーランス歴5年の私が、Swift → Flutter → React Native とモバイル開発技術を渡り歩いてきた経験をもとに、なぜ React Native に賭けてみることにしたのかをお話しします。

各技術の使用期間は以下の通りです。

• Swift: 2018年〜2024年（約7年）
• Flutter: 2025年前半（約半年）
• React Native: 2025年後半〜（約半年）

それぞれの技術に良さがあり、どれも魅力のある技術です。以下では、私が個人的に見立てる今後の開発トレンド（少数エンジニア × Web・バックエンド・ネイティブアプリのモノレポ × 生成AI） と、その判断理由を整理します。

---

私の技術遍歴

Swift 時代（2018年〜2024年）

私のモバイル開発キャリアは Swift から始まり、メイン技術として業務に携わってきました。

Swift は言語として非常に好みで、開発体験もシンプルさという点ではかなり高い水準だと感じていました。

Flutter 時代（2025年前半）

2024年末、フリーランス市場での Swift 案件が減少していたタイミングで、Flutter のリードエンジニアから誘いがありました。もともと一度 Flutter を経験してみたかったこともあり、案件に参画しました。

正直、Dart という言語に慣れてしまえば、Flutter に対してネガティブに感じることはほとんどなく、全体としてやりやすいと感じました。

なぜ Swift に戻らなかったか

Flutter の案件が一区切りついた2025年6月ごろ、もう一度 Swift に戻ろうと考えました。それまでフリーランスとして活動する中で、巨大企業である Apple が牽引してくれることを期待しており、Swift に乗っかっていれば大きくは外さないだろうと思っていました。

しかしながら、生成AIによるコード開発の本格化に伴い、状況は大きく変わっていると感じました。

当時流行していた生成AI系の SDK は TypeScript や Python での公開が中心で、Swift Package Manager 版は後回しにされがちでした。Swift を続けていると取り残されるかもしれないという不安がありました。

さらに、フリーランス市場の Swift 案件も減少傾向にあり、Swift があと数年後も同じように使われ続けるか不透明だと感じました。

また、Apple が生成AI分野で出遅れていると感じたため、このまま Swift に依存し続けることはリスクだと判断して、モバイルエンジニアとして Swift / Flutter / React Native のどれを軸にするかを検討し直すことにしました。

---

今後の開発トレンド予測

少数エンジニアでモノレポ開発する時代

• 開発エンジニアの数は減少傾向にあり、一人でカバーする範囲が広くなる（究極的には、一人のエンジニアがプロダクト全体を担う時代が来ると考えています）
• コーディングエージェントを活用した開発が増えていく
• Web・バックエンド・ネイティブアプリを一つのモノレポで管理することが、トークン効率と開発効率の両面で相性が良い

TypeScript 統一がスタンダードに

このような時代に選択される言語は、TypeScript 統一が有力な選択肢の一つになっていくのではないかと考えています。

• バックエンドも TypeScript（Node.js/Bun）
• Web も TypeScript（React）
• ネイティブアプリも TypeScript（React Native）

言語が揃うと開発・レビューの文脈が統一され、採用面でも TypeScript が書けるエンジニアを一人雇えばプロダクト全体をカバーできるため、生成AI時代に TypeScript を軸にすることは合理的だと考えています。

Swift/Kotlin よりもクロスプラットフォームを選ぶ理由

iOS と Android 両方に対応するアプリを開発する場合、Swift/Kotlin でそれぞれ作るか、クロスプラットフォームで統一するかという選択肢があります。

私は、両方を作る前提なら最初からクロスプラットフォームを選ぶ価値は高まりやすいと考えています。Flutter や React Native も成熟してきており、パフォーマンスや実現できることにおいてネイティブとの差はほとんどなくなってきています。

「LLM が進化したら、どの言語でも同じだろう」という意見もあるかもしれません。しかし、仮にそうなったとしても、次の点は残ると考えています：

• わざわざ Swift と Kotlin で2つのコードを生成する必要があるか？ → 出力トークン量が倍近くになる
• 一人のエンジニアが Swift と Kotlin を両方管理するなら、同じようなアーキテクチャに揃えたい
• しかし実際には、Swift らしさや Kotlin らしさを活かした書き方ができず、どっちつかずになりやすい
• 結局、2つの異なるコードベースを維持することになり、認知コスト・修正コストが高くなりやすい

どの技術を選んでも追加の言語習得は必要

生成AIで開発効率が上がり、一人が見る範囲が広がったことで、Swift エンジニアが Kotlin も見る（逆もしかり）ことが現実的な選択肢になりつつあります。

つまり、Swift を選んでも Kotlin の習得が、React Native を選んでも TypeScript の習得が必要になり、追加の言語学習は避けづらいということです。どちらを選んでも学習コストは大きく変わらないと考えています。

もちろん、React Native は Web 技術ベースなので、Web の React エンジニアがモバイル開発に参入しやすく、競争相手は増えます。ただ、ネイティブモジュールの組み込みやストアリリースの経験など、ネイティブ開発を経験してきた人には一定の優位性があります。過度に悲観する必要はないと考えています。

生成AI開発環境の差

React Native (Expo) は VSCode で開発できるため、生成AI拡張の恩恵を受けやすいと感じています。

また、Expo は Web ビルドに対応しているため、モバイルアプリしか作らない場合でも、開発中は Web として動作確認でき、Web 系の MCP（Playwright など）を活用できます。

---

なぜ React Native に賭けてみることにしたのか

上記のトレンド予測を踏まえ、私が React Native を選んだ理由は以下の通りです：

1. 少数エンジニアでモノレポ開発する時代に向いていそう
2. TypeScript 統一で Web・バックエンド・ネイティブアプリを一貫して開発できる
3. Web を取り巻くエコシステムの成長が早く、その恩恵を受けやすい
4. 生成AI開発（Vibe Coding）との親和性が高い（VSCode 拡張機能 + Web 開発の MCP エコシステムの恩恵）
5. 世界的に見ると React Native に勢いがある（日本では Flutter が優勢だが、世界的には React Native の採用が増えており、その潮流は日本にも影響すると考えている）
6. Apple/Swift だけに技術的に依存するリスクを下げられる

React Native にも依存関係の複雑さなどの課題はありますが、今後の開発トレンドを考えると挑戦する価値はあると感じており、現在は React Native エンジニアとして案件に参画しています。

---

補足1：各技術を触った感想

Swift

良い点:

• 言語として非常に好み（Associated Value を持てる Enum、強力な型システムなど）
• SwiftUI + Combine の双方向データバインディングでのUI実装はとても洗練されている
• ビルトインコンポーネントが充実しており、別途ライブラリを探す手間が少ない

課題:

• iOS/Android 別開発のコスト問題
• 生成AI時代の開発体験が良くない（Xcode 依存であること）
• 日本のフリーランス市場での案件が減少傾向

Flutter

良い点:

• クロスプラットフォームで iOS/Android 両対応できる
• VSCode で開発できる
• 初心者でも取り組みやすい（ドキュメントが手厚く、使うライブラリも限られていて迷わない）
• Riverpod による状態管理が強力
• マテリアルデザインを適応させやすい
• 日本のフリーランス市場での案件が多い

課題:

• Dart エコシステムの充実度（Swift/TypeScript と比べると）
• Web 版の同時開発が難しい（技術的には可能だが、実用レベルではまだ課題がある）

React Native（Expo）

良い点:

• クロスプラットフォームで iOS/Android 両対応できる
• VSCode で開発できる
• Next.js と Expo でコードを共通化でき、Web アプリとネイティブアプリを同時に開発できる
• Web/TypeScript エコシステム（TanStack Query、Storybook、Playwright など）をそのまま活用できる
• tRPC/oRPC などでフロントエンドとバックエンド間の型安全な API 通信を実現でき、モノレポでの TypeScript 統一開発との相性が非常に良い
• New Architecture によってパフォーマンスも向上しており、Swift/Kotlin/Flutter と比べても遜色ないレベルに到達している（Discord のモバイルアプリは React Native で動いている）
• Expo Modules を使えば、いざというときに Swift/Kotlin のネイティブコードを組み込める

課題:

• Expo の依存関係が複雑で、ライブラリのアップデートが大変になりやすく、メンテナンスコストが上がりやすい
• まだ成熟しきっていない分野も多く、依存ライブラリも多いため、何かとバグを踏みやすい
• Swift/Kotlin/Flutter エンジニアだと Node.js/TypeScript 周りでつまずくポイントが多い（npm/pnpm/yarn/bun、package.json、tsconfig など）
• ライブラリの選択肢が膨大で、ベストプラクティスが定まっておらず、選定に迷いやすい
• Expo Modules で Swift/Kotlin のネイティブコードを組み込む際の開発体験が良くない（ホットリロードが効かない、デバッグしづらいなど）
• 日本で採用されている案件がまだ少ない

比較表

※ 以下は私個人の経験に基づく主観的な評価です。
※ Swift にも Skip/Scade 等のクロスプラットフォームフレームワークが存在しますが、私自身は使用経験がないため評価できていません。

観点	Swift	Flutter	React Native
クロスプラットフォーム対応	?	◎	◎
サーバーサイドとの言語統一	△	△	◎
生成AI時代のDX	△	○	◎
Web 版の同時開発	✕	△	◎
ライブラリの豊富さ	○	△	◎
学習コスト（Web経験者）	△	○	◎
学習コスト（初心者）	○	◎	△
メンテナンスコストの低さ	◎	○	△
パフォーマンスの良さ	◎	◎	○
言語の好み	◎	○	○
案件数（フリーランス）	△	◎	△

それぞれを選ぶべきケース

• Swift/Kotlin
  • iOS または Android 単体のアプリをすぐ作りたい場合
  • 安定性とパフォーマンスを重視する場合
  • Swift/Kotlin 専用 SDK などネイティブコードを多く組み込む必要がある場合
• Flutter
  • 少ないコストでクロスプラットフォーム開発を始めたい場合
  • 未経験者や初心者が多いチームの場合
  • 学習コストの低さを重視する場合
• React Native（Expo）
  • ネイティブアプリと Web アプリを同時に開発したい場合
  • サーバーサイドと言語を統一したい場合
  • Web エンジニア経験が多いチームの場合
  • 生成AI時代の開発体験を重視する場合
  • Web/TypeScript エコシステム（TanStack Query、Playwright、Storybook など）を活用したい場合

---

補足2：Kotlin Multiplatform という選択肢について（2026年1月追記）

筆者は KMP の実務経験がないため、以下は調査に基づいた意見となります。

TypeScript 統一と同様の発想で、Kotlin Multiplatform（KMP） で言語を統一するという選択肢もあります。Kotlin は Java から派生した言語であり、バックエンドフレームワーク（Ktor、Spring Boot など）も存在するため、React Native が TypeScript で統一できるように、Kotlin でも Web・バックエンド・モバイルを統一することが可能です。

KMPの2つのアプローチ

KMP には大きく分けて2つのアプローチがあります。

1. UI共通化型（Compose Multiplatform）: UI層まで Compose Multiplatform で統一する
2. ビジネスロジック共通化型: ビジネスロジックまでを Kotlin で共通化し、UI層は Swift/Kotlin でそれぞれ書く

このうち、React Native や Flutter と比較対象になるのは 1. UI共通化型 です。

Compose Multiplatform より React Native を選ぶ理由

UI共通化型として Compose Multiplatform を選ぶか React Native を選ぶかという観点では、現時点では以下の4点で React Native の方が優勢だと考えています。

1. ライブラリ・SDKの選択肢

   • React Native: 純粋な JavaScript/TypeScript ライブラリをそのまま使えるため、npm エコシステムの恩恵を受けられる
   • KMP: Kotlin 対応ライブラリであっても KMP 対応されているとは限らない

   KMP の共有コード部分では Kotlin/Native でもコンパイルできる KMP 対応ライブラリを使う必要があり、ライブラリの選択肢が狭まる可能性があります。

   具体例：

   • Stripe: React Native には公式 SDK があるが、KMP には公式 SDK がない
   • Firebase: React Native Firebase（GitHub Star 約1.2万）と Firebase Kotlin SDK（GitHub Star 約1,600）では成熟度に差がある

   KMP 非対応のライブラリや SDK を使いたい場合は、結局プラットフォームごとに実装を分ける必要があり、共通化のメリットが薄れる可能性があります。

2. エコシステムの人気度（GitHub Star数、2026年1月時点）

   • Flutter: 約17.5万
   • React Native: 約12.5万
   • Kotlin（言語全体）: 約5.2万

   Flutter と React Native は10万を超える Star を獲得していますが、Kotlin は言語全体のリポジトリでも約5万程度です。KMP 単体で見ればさらに限定的なコミュニティ規模と考えられます。

3. 採用実績

   • React Native:
     • Facebook、Instagram、Shopify、Discord、Microsoft Office、Amazon Shopping、PlayStation App など多数
   • KMP:
     • Compose Multiplatform（UI共通化）:
       • Bitkey by Block、Markaz、Wrike、Feres、BiliBili、Instabee など
     • ビジネスロジック共通化のみ:
       • Duolingo、Google Docs、McDonald's、X（旧Twitter）、Cash App、Forbes、9GAG、Netflix など

   React Native は多数の大規模アプリで採用されています。KMP の採用事例も増えてきていますが、Compose Multiplatform（UI共通化）を使っている事例はまだ限定的で、多くはビジネスロジック共通化のみにとどまっているようです。

4. 採用市場

   • TypeScript: Web エンジニアの母数が大きく、採用しやすい。案件数も多い傾向
   • Kotlin: 採用市場はそれほど大きくない。ただし、Javaエンジニアまで広げれば母数は大きく、Kotlin の習得も短期間で可能

   TypeScript は Web エンジニアの母数が大きいため、採用面でも有利になる傾向があります。一方、Kotlin の採用市場はそれほど大きくありませんが、Javaエンジニアまで広げれば母数は大きく、Javaができる人は Kotlin を短期間で習得できる傾向があります。キャリアの観点では、TypeScript の方が案件が多い傾向にありますが、Java/Kotlin も安定した需要があります。

   ただし、Web の React が書ければ React Native も比較的スムーズに書ける可能性がある一方で、サーバーサイドの Java/Kotlin が書けてもモバイル UI（Jetpack Compose など）の実装には別途学習が必要と考えられます。この点で、React Native は Web エンジニアの参入障壁が低く、採用面で有利に働く可能性があると考えています。

以上の理由から、UI共通化型として Compose Multiplatform を選ぶよりも、React Native や Flutter を選ぶ方が現時点では安心感があると考えています。

ビジネスロジック共通化型をおすすめしない理由

一方、2. のビジネスロジック共通化型については、以下の理由からあまりおすすめしていません。

• BFF での共通化も選択肢: ビジネスロジックは BFF サーバーを立ててサーバー側で共通化した方がテストしやすく、Web などへのマルチプラットフォーム展開にも対応しやすいと考えている
• 共通化したいクライアントコードは既に自動生成されることが多い: API は OpenAPI や gRPC で定義され、クライアントからのサーバーへのリクエストコードは自動生成されることが多いため、共通化したいコードの多くはすでにKMPを使わなくても実質的に共通化されている場合が多い
• 本当にやりたいこと: 個人的には、一番やりたい共通化は iOS/Android をワンソースで書くことであって、中間レイヤーを共通化することではないと感じている

そのため、ビジネスロジックのみを共通化するアプローチを選ぶよりも、UI 層まで統一できる React Native や Flutter を選ぶ方が、やりたいことに直結すると考えています。

KMP を採用した方がいいケース

ここまで否定的な意見が多くなりましたが、KMP が適しているケースもあります。

• Java/Kotlinエコシステムを活用したい場合: Kotlin は Java との相互運用性が高く、Javaのコード・ライブラリを透過的に利用できる。Apache Lucene などのJava/Kotlin専用SDKが必要な場合や、Ktor・Spring Boot などのバックエンドフレームワークを使っている場合、KMPを採用することでフルスタック Kotlin という選択肢もある
• Java/Kotlin エンジニアが確保しやすい環境: Javaエンジニアは Kotlin を短期間で習得でき、採用もしやすい。すでに Java/Kotlin エンジニアが多いチームや、Javaエンジニアを潤沢に確保できる環境であれば、学習コストを抑えて導入できる
• 段階的にクロスプラットフォーム化したい場合: 既存のネイティブアプリに少しずつ KMP を導入していくアプローチが取りやすい
• ネイティブ UI を維持したい場合: SwiftUI や Jetpack Compose を活かしつつ、ビジネスロジックだけを共通化したい場合
• オフライン処理など複雑なクライアントロジックがある場合: BFF に寄せられないロジックが多い場合は、クライアント側での共通化にメリットがある

これらのケースに該当する場合は、KMP も有力な選択肢として検討する価値があると思います。

---

おわりに

以上が私がReact Native に賭けてみることにした判断理由になります。今後は実際に React Native で開発を続けながら、この選択が正しかったのかを検証していきたいと思います。