SECTION 01
技術スタック選びは2つの質問で決まる
アプリ開発の技術スタック選びで一番多い失敗は、比較表を眺めて悩み続けることです。Swift、Kotlin、Dart/Flutter、JavaScript/React Native、C#/Unity……並べるほど決められなくなります。
ここで大事なのは、「言語」と「フレームワーク」と「ゲームエンジン」は別物だという点です。たとえばFlutterはDart言語で書くフレームワーク、React NativeはJavaScriptで書くフレームワーク、UnityはC#で書くゲームエンジンです。記事中では混乱を避けるため、言語とフレームワーク／エンジンを分けて表記していきます。
実は、たった2つの質問に答えるだけで候補は一気に絞れます。質問①は「iOSだけ作るのか、Androidも作るのか、両方に出すのか」。質問②は「Web系の開発経験があるか、プログラミング自体が初めてか」です。
質問①で対象プラットフォームが決まれば、使える技術スタックは半分以下になります。質問②で残った候補から自分に合う1つが決まります。
この判断チャートをベースに、以降のセクションでは目的別の選び方と、選んだ後に起きがちな落とし穴まで掘り下げていきます。技術スタックを決めるのに何日もかける必要はありません。
SECTION 02
目的別・逆引き早見表：作りたいもの→選ぶ技術スタック
「何を作りたいか」が決まっていれば、技術スタックはほぼ自動的に決まります。迷う原因の多くは、目的が曖昧なまま選択肢を比較しているからです。
目的別の対応は次のとおりです。
- iOSアプリだけ出したい → Swift（言語）
- Androidアプリだけ出したい → Kotlin（言語）
- iOS・Android両方に出したい → 代表的な候補としてJavaScript/React Native（言語+フレームワーク）、Dart/Flutter（言語+フレームワーク）、Kotlin Multiplatform（言語+フレームワーク）などがあります
- Webアプリ・業務システム → JavaScript / TypeScript、またはPython
- 3Dゲーム → Unity（C#／ゲームエンジン）またはUnreal Engine（C++／ゲームエンジン）
ここで押さえておきたいのが、言語・フレームワーク・エンジンの区別です。「Flutterを学ぶ」と言っても、実際に習得するのはDart言語とFlutterフレームワークの両方です。React Nativeならば、JavaScript言語とReact Nativeフレームワークの両方を学ぶことになります。
個人開発で最初の1本を出すなら、この早見表から1つ選んでそのまま突き進むのが最短ルートです。比較検討に時間を使うより、手を動かして実機で動くものを見た方が圧倒的に学びが大きくなります。
どれにも当てはまらない場合は、次のセクションの「ネイティブかクロスプラットフォームか」の判断から入ると整理しやすくなります。作りたいものが曖昧なうちは技術スタックを決めない、が鉄則です。
SECTION 03
ネイティブ vs クロスプラットフォーム、どちらを選ぶか
ネイティブ開発とは、iOS向けにはSwift、Android向けにはKotlinといった、各OSの公式言語で作る方法です。クロスプラットフォーム開発は、React NativeやFlutter、Kotlin Multiplatformのように1つのコードベースからiOS・Android両方に出せる方法です。
よく「ネイティブの方が速い」と言われますが、性能差の大きさはアプリの種類や使い方によって変わります。フォーム入力やリスト表示が中心のアプリでは差を感じにくい一方、描画負荷が高い処理、起動時間、スクロールの滑らかさ、ネイティブAPIとの深い連携が求められる場面では差が出ることがあります（JetBrains公式ガイドでも、性能はツールや用途に依存するとされています）。
開発速度だけでなく、運用・保守コストまで含めて考えることが大事です。ネイティブで両OSに出すと、同じ機能を2回作り、バグ修正も2回、OSアップデート対応も2回になります。個人開発でこの負荷を抱え続けるのはかなりしんどいです。
判断の軸を整理すると次のようになります。
- 1人で両OSに出したい → クロスプラットフォームが現実的
- 片方のOSだけでいい → ネイティブの方がシンプル
- OS固有の機能を深く使う → ネイティブが有利
- 素早くリリースして反応を見たい → クロスプラットフォーム向き
個人開発なら「1つのコードで2プラットフォーム」の恩恵が特に大きいと感じています。重複実装を減らせることで、機能追加やバグ修正に使える時間を確保しやすくなります。ただし、テスト・ストア申請・OS差分対応などの工数は残るため、保守コストがそのまま半減するわけではない点には注意が必要です。
SECTION 04
FlutterでWebViewを先に出して全部作り直しになった話
クロスプラットフォームを選んでも、やり方を間違えると逆にコストが膨らみます。これは筆者自身の経験ですが、あるサービスのスマホアプリを作るとき、最初はSwiftとKotlinで両OSに出していたのをFlutterにリプレイスしました。
さらに工数を減らそうとして、「まずWebViewベースで素早くリリースして、順次ネイティブUIに作り変えよう」という作戦を取りました。これが完全に裏目に出ました。
WebViewベースのアプリは操作感がどうしてもWebそのものになるので、ユーザーがアクティブに使ってくれませんでした。結果、フルリニューアルすることになり、最初からきちんと作った方がトータルのコストは低かったという結論です。
特にすでにWebサービスとして上手くいっている場合、アプリ版に中途半端なものを出すと既存ユーザーの印象を損ねます。「まず出す」は大事ですが、「中途半端に出す」とは違います。クロスプラットフォームを選ぶなら、最初からアプリとしてちゃんと作ることをおすすめします。
SECTION 05
Web出身エンジニアがスマホアプリを作るならReact Nativeを推す理由
Web開発の経験がある人がスマホアプリに初挑戦するなら、React/JavaScript経験者にとっては学習コストを抑えやすい選択肢がReact Nativeです。JavaScriptとReactの知識がそのまま使えるため、新しく覚えることがフレームワーク固有のAPIだけで済みます。
開発体験も大きなポイントです。Expo GoはExpoが提供する試作用のサンドボックスアプリで、コードを保存した瞬間に実機でプレビューできます（Expo公式ドキュメント）。素早く動作を確認しながら開発を進められるのが魅力です。
ただし、Expo Goはあくまでプロトタイピングや学習向けのツールです。長期運用やカスタムネイティブモジュールが必要なプロジェクトでは、development build（Expoの本格的なビルド環境）への移行を検討してください。
AIコーディングツールとの相性も見逃せません。React Nativeなら自分が使い慣れたエディタで書けるので、AIアシスタント系のツールと組み合わせやすい環境が作れます。SwiftだとXcodeが基本になるため、この柔軟さは得にくいです。
React Nativeを推す理由をまとめると次のとおりです。
- 既存のWeb知識がそのまま活きる（React/JavaScript経験が前提）
- Expo Goで素早くプロトタイプ確認、本格開発はdevelopment buildへ移行
- エディタを選ばないのでAIツールとの連携がしやすい
- 将来Androidにも同じコードベースでリリースできる
もちろんFlutterも優れた選択肢です。Dartという新しい言語を覚えるコストは加わりますが、UIの表現力やホットリロードの快適さに魅力を感じる人も多いです。また、Kotlin Multiplatformのように既存のKotlin資産を活かせる選択肢もあります。Web出身で手元にJavaScriptの経験があるなら、その資産を活かせるReact Nativeから始めるのは合理的な判断の一つです。
SECTION 06
クロスプラットフォームでも両OSテストは必須という教訓
これも筆者の実体験ですが、React Nativeで作ったアプリで片方のOSだけでテストしていて痛い目に遭ったことがあります。集中支援アプリを開発したとき、自分のメイン端末がAndroidだったので、長時間の動作テストもAndroid中心で完了させていました。
ところがiPhoneで長時間使うと、省電力機能の影響なのか動画が停止して画面が真っ暗になったり、音楽が止まるバグが出ていました。自分では気づかないまま公開してしまい、App Storeで低評価レビューがつきました。
「1つのコードで両OSに出せる」は開発時の話であって、動作確認も1回で済むわけではありません。OSごとにメモリ管理やバックグラウンド処理の挙動が違うので、両方の実機で同等にテストする必要があります。
この失敗以降は、リリース前にTestFlightとGoogle Playのクローズドテストで両OSのユーザーに事前確認してもらう運用に変えました。クロスプラットフォームを選ぶなら、テストのコストも織り込んで計画することが大切です。
SECTION 07
初心者が最初に選ぶべき技術スタックと、挫折しない判断基準
プログラミング初心者がアプリ開発の技術スタックを選ぶとき、重要な判断軸の一つは「ググったときに日本語情報が多いかどうか」です。エラーが出たときに日本語で検索して解決策がすぐ見つかるかどうかで、挫折率が大きく変わります。
ただし、これだけで決まるわけではありません。OS制約、教材の品質、環境構築の容易さ、公式ドキュメントの充実度なども大きな判断材料になります。複数の軸を総合的に見て選ぶのがおすすめです。
初心者の技術スタック選びで押さえたいポイントはこちらです。
- 日本語の情報量が多い技術を選ぶ（エラー解決のスピードに直結します）
- 環境構築が簡単かどうかを確認する（始める前に挫折するパターンが多いです）
- 公式ドキュメントやチュートリアルの質も確認する
- Windows環境ならiOS開発にはMacが必要という制約を知っておく
- Pythonでもモバイル開発は可能ですが、主流のネイティブ開発スタックではなく、対応ライブラリや情報量に制約があるため初心者の第一候補にはしにくいです（BeeWareなどのプロジェクトは存在します）
Pythonでのアプリ開発がどこまで現実的かという質問もよくありますが、Webアプリやデスクトップツールなら十分に使えます。iOSやAndroidのスマホアプリについては、ツールは存在するものの主流とは言えず、日本語の情報や事例が限られるため、現時点では制約が多い選択肢です。
Windows環境で始める場合は、Android向けの開発はそのままできますが、iOS向けにはMacが必須になります。まずはAndroidアプリから始めて、iOS対応はMacを入手してからという順番でも問題ありません。
SECTION 08
技術スタックの前にプラットフォームを選べ：toCならアプリも有力な選択肢
「何の技術で作るか」の前に、「どこに出すか」を先に決めると迷いが一気に消えます。Web開発出身だとつい「Webで作ろう」と考えがちですが、toC（一般ユーザー向け）のサービスではスマホアプリも有力な選択肢になります。
App StoreやGoogle Playにはストア検索という発見経路があり、ユーザーがキーワード検索からアプリを見つけてダウンロードする導線が用意されています（Apple公式: Discovery on the App Store）。ただし、これがWebより有利かどうかは商材の特性、想定する獲得チャネル、ユーザーの利用頻度などの条件によって変わります。
筆者の経験では、特に宣伝をしていなくてもストア検索からダウンロードされてサブスクが発生したケースがありました。一方、Webはカテゴリによっては検索流入が強力な場合もあります。どちらが有利かは一概には言えないため、自分のサービスの特性に合わせて判断してください。
プラットフォームが決まれば技術スタックの選択肢も絞られます。
- スマホアプリ × Web出身 → JavaScript/React Native
- スマホアプリ × iOSだけでいい → Swift
- スマホアプリ × Androidだけでいい → Kotlin
- Webサービス → JavaScript / TypeScript
- 業務ツール・自動化 → Python
SECTION 09
「最初は簡単な技術で作って後で乗り換える」は現実的か
「まずPythonで試作して、上手くいったらSwiftで作り直す」といった段階的なアプローチは、移行コストが想像以上に高くなるケースが多いです。UIのロジック、データ構造、API連携をすべてゼロから書き直すことになるため、実質的に新規開発と変わりません。
移行コストが比較的低いケースもあります。バックエンド（サーバー側）は言語を変えてもフロント側に影響が少ないため、最初はPythonで動かしておいて後からGoやRustに切り替えるのは現実的です。
ただし、スマホアプリの場合は事情が違います。
- SwiftからReact Nativeへの移行 → UIもロジックも全書き直し
- Flutter（Dart）からSwift+Kotlinへの移行 → 2つの言語で再実装
- React Native（JavaScript）からFlutter（Dart）への移行 → 言語とフレームワーク両方の書き換え
個人開発で1本目のアプリを出すなら、「最初から本命の技術スタックで作る」方が結局は速いです。「後で乗り換えればいい」と思って始めた技術に慣れてしまい、結局そのまま使い続けるパターンも多いからです。
技術の習得コストを気にする人は多いですが、それよりも「何を作るか」の方が先に来ます。言語やフレームワークで差がつくのではなく、何を誰のために作るかで差がつくのです。
SECTION 10
迷っている時間で1画面作れる。まず手を動かそう
ここまで読んで、まだ迷っているなら冒頭の2つの質問に戻ってください。「iOSだけ？Android も？両方？」と「Web経験あり？初めて？」——この2つで答えは出ます。
完璧な選択を求めるより、「今の自分で最短で動くものが出せる技術スタック」を選ぶことをおすすめします。動くものを出してユーザーの反応を見る方が、比較表を眺めるよりはるかに価値のある学びになります。
最後にもう一度、判断の要点を整理します。
- iOS専用 → Swift（言語）
- Android専用 → Kotlin（言語）
- 両OS × Web経験あり → JavaScript/React Native（言語+フレームワーク）
- 両OS × 新しい言語でもOK → Dart/Flutter（言語+フレームワーク）やKotlin Multiplatformも選択肢
- Webアプリ → JavaScript / TypeScript
- 3Dゲーム → Unity（C#／ゲームエンジン）
技術スタックは道具です。道具選びに時間をかけすぎて、作るべきものを作れないのが一番もったいない結果です。この記事を閉じたら、選んだ技術のチュートリアルを1つ開いて、最初の1画面を作ってみてください。
