アプリ開発の言語選定｜Swift・Kotlin・Dartの分岐条件を実装視点で解説

言語の比較表を眺めるだけでは選定は終わりません。決め手になるのは文法の書き味や人気ランキングではなく、どこへ配布するか、OSのどの機能に触るか、誰が5年後まで保守するかという三つの制約でした。この記事では、iOSのSwift、AndroidのKotlin、クロスプラットフォームのDartとTypeScript、サーバー側のPythonを実装上の制約と調達コストから並べ直します。2026年8月時点の各バージョンとGoogle Playのtarget API要件を踏まえ、採用する条件と見送る条件を書き切りました。

まとめ：アプリ開発の言語選定を配布先・OS機能への依存度・保守体制の三点で絞る判断基準

先に結論を置きます。言語から考え始めると迷子になるため、順序を固定してください。第一に配布先。両ストアに出すのか、片方だけか、ブラウザで済ませるのか。第二にOS機能への依存度。BLE、カメラの低レベル制御、バックグラウンド実行、位置情報の常時取得のうちどれが必須か。第三に保守体制。5年間、誰が年2回のOS更新に追随するのか。この三点が決まれば選べる言語は1つか2つに絞られ、言語比較そのものが不要になります。

既定値も置きます。両OSに出す業務系アプリで、端末機能への依存が浅く画面数が30を超えないなら、Flutter（Dart）かReact Native（TypeScript）の単一コードベースが総コストで有利でした。BLE常時接続・カメラの低レベル制御・長時間のバックグラウンド処理のいずれかが必須要件に入った時点で、ネイティブ2本へ切り替える。境界の条件は後半に書きます。

言語選定が実質的に実行環境の選択になる構造｜配布先とランタイムの制約

アプリの言語は、Webのバックエンドのように自由には選べません。配布先のストアとOSが実行形式を決めており、言語はそこへ到達する経路として後から決まります。

iOSがSwift・AndroidがKotlinに収束した経緯｜公式SDKとの距離

両OSとも、公式SDKと開発ツールが特定の言語を第一級の扱いにしています。iOSはSwiftUIやSwift Concurrencyといった新しいAPIがSwift前提で追加され、Objective-Cから呼べない機能が増えました。AndroidもJetpack Composeの構文がKotlinの言語機能に依存しており、Javaからは書けません。

この差は「新機能が届くまでの時間差」として効きます。第二言語を選ぶとOS更新のたびに追随可否を確認する作業が発生し、5年運用ではその確認コストが積み上がる。特段の事情がなければ第一言語へ寄せる判断が無難でした。

クロスプラットフォームで選ぶのは言語ではなく描画方式という視点

クロスプラットフォームの比較を「DartとTypeScriptのどちらが書きやすいか」で始めると判断を誤ります。実際の差は描画方式にあり、言語はその方式に付いてくるだけだからです。

Flutterは自前の描画エンジンで画面全体を描きます。OSの標準部品を使わないため両OSで見た目が一致し、OS更新でUIが勝手に変わることもない。代わりにOSが新しいUI表現を出してもFlutter側の再実装を待ちます。React Nativeは逆にOSの標準部品を操作する方式で、OSらしい挙動が無料で手に入る反面、両OSの微妙な差を吸収する工数がかかります。

この表の右端が選定の実体です。左端の言語欄は、右端を決めた結果として自動的に埋まります。

Webアプリとして配布して足りる要件の見極め方｜TypeScriptの射程

ストア配布を前提にしない選択肢を先に潰すと、後の議論が短くなります。社内の業務ツール、帳票を見るだけの用途、月に数回しか開かないサービスなら、ブラウザで動くWebアプリで足りる。TypeScript一本で済み、審査待ちもバージョン分岐もありません。

境界線は三つです。プッシュ通知を確実に届けるか、オフラインで数時間使えるか、ホーム画面に常駐して毎日開かれるか。どれかが必須ならネイティブかクロスプラットフォームへ寄せ、該当しないならWebで足ります。仕組みと費用感の全体像はWebアプリ開発とは？仕組み・種類・開発言語から費用と外注判断まで発注者視点で解説に整理してあるため、判断材料として先に読むと絞り込みが速くなります。

iOSネイティブを選ぶ判断材料｜Swift 6系の並行性チェックと移行コスト

iOSをネイティブで作るなら言語はSwiftで確定しますが、選定の実務はそこから先です。Swift 6系で言語仕様が厳しくなり、既存資産の扱いと移行工数が見積り項目として立ちました。

Swift 6系の厳格な並行性検査が既存コード全体へ及ぼす改修量

Swift 6系では、データ競合を招く書き方をコンパイラが検査して弾きます。実行時に稀に起きていた不具合が、ビルド時のエラーとして表面化する形です。品質面では前進ですが、既存プロジェクトをSwift 6モードへ切り替えると警告とエラーが数百件単位で出ます。

言語モードを段階的に上げる経路が用意されています。まずSwift 5モードのまま並行性の警告だけを有効にし、モジュール単位で潰してから言語モードを上げる。新規開発なら最初からSwift 6モードで始めるほうが安上がりでした。既存アプリの改修案件で「Swiftだから工数は変わらない」と見積もると、この移行分が丸ごと抜け落ちます。

Objective-C資産を残したまま進める条件｜相互運用の境界線

10年選手のiOSアプリには、Objective-Cで書かれた層がまだ残っています。全面書き直しを前提にする必要はありません。両者は相互に呼び出せるため、境界の引き方さえ決めれば共存は成立します。

分け方は、画面とUIロジックをSwiftへ移し、安定して動く低レベル層（暗号処理、独自プロトコルの通信、古いC言語ライブラリのラッパ）をObjective-Cのまま据え置く形です。Swift 6.3では@c属性が入り、Swift側の関数をC言語やC++から直接呼べます。ただし並行性検査はObjective-C由来の型に十分効かず、共存部分が検査対象外になる点を見積りへ織り込んでください。

Swift 6.3のAndroid向けSDKを選定材料に入れてよい範囲

2026年3月24日リリースのSwift 6.3で、Swift SDK for Androidの公式リリースが始まりました。SwiftでAndroid向けのネイティブコードを書ける経路が公式に用意され、「SwiftだけでiOSとAndroidの両方を作る」構想が理屈の上では立ちます。

現時点の選定材料としては、採用しない判断を勧めます。UI層の共有までは想定されておらず、ロジック層をSwiftで共有しAndroidのUIはKotlinで書く構成になるためです。同じことはKotlin Multiplatformが2023年から安定版で提供しており、Androidの公式ツールチェーンとつながる分そちらが有利でした。既存のSwift資産をAndroidへ持ち出す場合の選択肢として、2027年以降に再評価すれば足ります。

Androidネイティブを選ぶ判断材料｜Kotlin 2.4系とAPI 36要件

Androidも言語はKotlinで実質確定します。判断が要るのは既存Java資産の扱いと、ストア要件へ追随する速度のほうです。

Kotlin 2.4系を前提にする理由とJava資産の混在運用の限界

Kotlinは2.4.0が2026年6月3日の言語リリース、2.4.10が同年7月14日のバグフィックスリリースという版で動いています。K2コンパイラ前提の世代で、Jetpack Composeを含む主要ライブラリはKotlinの言語機能に依存する形で書かれ、JavaからComposeのUIを書く経路はありません。

既存のJavaコードはモジュールとして残せます。混在の限界が出るのはUI層で、画面を作り直す場面ではKotlinへ移す判断が避けられません。KotlinとJavaのどちらを選ぶか、既存資産をどこまで移すかという一段細かい判断はAndroidアプリ開発の言語はKotlinとJavaのどちらか？選定基準と環境まで解説に切り出してあります。本記事は横断の選定に絞るため、ここでは踏み込みません。

2026年8月31日のtarget API 36要件が言語選定に効く場面

Google Playは2026年8月31日以降、新規アプリとアップデートにAndroid 16（API 36）以上を求めます。Wear OSとAndroid Automotive OSはAPI 35以上、Android TVとAndroid XRはAPI 34以上と別基準です。既存アプリはAPI 35以上なら端末の新規ユーザーへ配信できますが、API 34以下では自身のターゲット以下のOSを積む端末にしか届きません。延長申請は2026年11月1日まで。

これが言語選定に効くのは、クロスプラットフォームを選んだときです。targetSdkを上げるにはフレームワーク側の対応版が要り、使っているプラグイン群がその版に追随していなければビルドが通りません。ネイティブなら自社の判断だけで上げられる作業が、依存関係の待ち時間に化ける。この遅れをクロスプラットフォーム採用のリスクとして見積りへ明示してください。Android全体の作り方と外注時の進め方はAndroidアプリ開発とは？できること・開発の流れ・iOSとの違いと外注の進め方にまとまっています。

クロスプラットフォーム採用の条件｜Flutter系とReact Native系の差

単一コードベースで両OSに出す選択肢は、2026年時点で二つに収束しています。どちらも成熟していますが、向く要件が明確に分かれます。

Flutter（Dart）を選ぶ条件｜描画を自前で持つ設計の代償

Flutterの最新安定版は3.47.0です。言語はDartで、画面は自前の描画エンジンが全ピクセルを描きます。採用条件は明快で、デザインを両OSで1ミリ単位まで揃えたい場合、独自のブランド表現をUI全体へ貫きたい場合に向く。OSのバージョン差でレイアウトが崩れる問題も原理的に起きません。

代償は三つ。OSが新しいUI表現や標準部品を出したときFlutter側の実装を待つ。アクセシビリティ機能や日本語入力の挙動がOS標準部品と微妙に違う場面が残る。そしてDartの人材がTypeScriptやKotlinに比べて薄い。三つ目は後半で扱います。

React Nativeを選ぶ条件｜新アーキテクチャ既定化後の前提

React Nativeは0.87系が最新の安定版です（2026年8月時点）。長く課題だったJavaScriptとネイティブ間の通信方式は新アーキテクチャで置き換えられ、0.76以降は既定になりました。旧アーキテクチャは非推奨に移っています。「橋渡し層が遅い」という数年前の評価をそのまま選定へ持ち込むと判断を誤ります。

採用条件は人材と資産の側にあります。WebフロントエンドをReactとTypeScriptで作っているなら、型定義・状態管理・テストの作法をそのまま持ち込める。同じ人が両方を触れる体制になり、採用も容易でした。Web側の資産が無くモバイル単体で新規に作るなら、選ぶ理由は弱くなります。

ロジックだけを共有する折衷案｜UIをネイティブに残す構成の条件

単一コードベースか2本立てかの二択に見えますが、中間があります。Kotlin Multiplatformで通信・データ保存・業務ロジックだけを共有し、UIはSwiftとKotlinで別々に書く構成です。仕組み自体は1.9.20から安定版で提供されています。

効くのは、UIの作り込みが競争力の源泉で、かつ業務ロジックが複雑な場合。金融系の計算処理、オフライン同期、複雑な権限判定が両OSで完全一致すべきときに有効でした。画面が単純なフォームと一覧の繰り返しなら共有量が少なく、ビルド構成の複雑さだけが増える。判断基準は「ロジック層のコード量がUI層を上回るか」で置きます。

サーバー側とAI連携で言語が分かれる境界｜Pythonを置く位置

アプリ開発の言語選定を調べると、候補としてPythonが挙がる資料に行き当たります。実装の観点では、Pythonは端末側ではなくサーバー側へ置く言語です。

アプリ本体にPythonを使わない理由｜配布形態と実行環境の制約

iOSとAndroidの実行環境には、Pythonのインタプリタが標準で入っていません。端末で動かすにはインタプリタと標準ライブラリを同梱することになり、サイズが数十MB単位で膨らみます。起動時間も伸び、OSのUIフレームワークへは間接的にしか触れません。

枠組み自体は存在し、学習用途や社内の小さな道具なら成立します。ただし業務で配布し5年保守する候補には入れないでください。端末側はSwift・Kotlin・Dart・TypeScriptの4択です。

推論やデータ処理をPythonへ寄せる分界点｜APIで切る設計

一方、画像認識や自然言語処理をアプリへ載せる案件ではPythonが必ず登場します。モデルの学習と推論のエコシステムがPythonへ集まっているためです。端末側とPython側をHTTPのAPIで切り、端末はリクエストとレスポンスだけを扱います。

分界点の基準は二つです。応答に1秒以上かかってよく通信断で業務が止まらないなら、サーバー側でPythonへ寄せる。カメラ映像へリアルタイムに重ねる、圏外でも動かす、といった要件があれば端末側で推論し、OS側の推論フレームワークをSwiftやKotlinから呼びます。

言語選定で抜け落ちやすい調達コスト｜人材確保と保守年数の見積り

ここからが独自の観点です。5年運用の総コストを分けるのは、言語の性能や書き味ではなく人材の調達しやすさとOS更新への追随工数でした。選定会議でこの二つが議題に上がらないまま決まる案件が多すぎます。

5年運用を前提にした総コストの見積り方｜OS更新への追随工数

初期開発費だけで比較すると、単一コードベースが常に勝ちます。実際に効くのはリリース後に毎年発生する追随工数のほうです。両OSとも年1回のメジャー更新があり、Google Playのtarget API要件は毎年8月末に切り上がります。

• OS更新への追随：ネイティブは各OSで数人日、クロスプラットフォームは更新待ちを含めて読む
• フレームワークの更新：Flutter・React Nativeとも年数回の更新があり、破壊的変更の吸収工数が立つ
• 依存プラグインの寿命：個人メンテナのものが放置された場合、自前で引き取る工数が突発的に出る

三つ目が実務で最も痛い項目でした。クロスプラットフォームの見積りでは、使うプラグインの直近1年のコミット状況と代替の有無を先に調べてください。工程全体の切り分けはアプリ開発の流れとは？企画から保守まで7工程で発注側が決めることを解説に整理しています。

採用市場から逆算した現実的な選択肢｜求人母数と単価の非対称性

技術的に優れていても、書ける人を継続的に確保できなければ選定は失敗します。日本の受託開発の現場感覚では、TypeScriptが最も母数が厚く、次いでKotlinとSwift、Dartが最も薄い並びでした。Dartはほぼモバイル専業で、Web・サーバーからの流入が少ないためです。

この非対称性は内製と外注で意味が変わります。外注で作り切って保守も委託するなら、Dartの薄さは発注側の問題になりません。内製へ切り替える構想があるなら、社内で採用しやすい言語を先に選ぶほうが安全でした。保守を引き取る主体が未定の案件では、TypeScriptかKotlinへ寄せます。

見送るべき場面の言い切り｜クロス対応とネイティブ2本の損益分岐

選定記事は両論併記で終わりがちなので、条件を付けて言い切ります。当てはまる場合、その選択肢は検討対象から外してください。

クロスプラットフォームを見送る具体条件｜端末機能への依存の深さ

次の要件が一つでも必須に入るなら、クロスプラットフォームは見送ります。BLE機器と常時接続する。カメラの露出・フォーカス・フレームレートを自分で制御する。バックグラウンドで数十分以上の処理を継続する。OSのウィジェットやウォッチアプリを本体と連携させる。決済端末やICカードリーダーのSDKを組み込む。

いずれもOS固有のAPIを直接叩く領域で、フレームワークの抽象化が届かないためです。結局SwiftとKotlinでプラグインを自作することになり、言語を1つに減らした利益が消えたうえ、境界をまたいでデバッグする難易度だけが残ります。「プラグインがあるから大丈夫」と返ってきたら、最終更新日と対応OSバージョンを必ず確認してください。

ネイティブ2本を見送る具体条件｜画面数と改修頻度から見た分岐

逆に、次の条件が揃うならネイティブ2本立ては過剰です。画面数が30以下。端末機能への依存が通知と写真選択の範囲に収まる。企画側が月1回以上の頻度で画面を変えたがる。予算が2,000万円を下回る。

特に三つ目が効きます。改修頻度が高いプロダクトでは、同じ変更を2つのコードベースへ入れて2回テストする往復が積み上がり、差が半年で見えました。この条件でネイティブ2本を選ぶと、機能追加の速度が競合に追いつけません。要件の切り分けから相談したい場合は、ネイティブアプリ開発の実績を確認したうえで、要件定義の段階から技術選定を含めて依頼する進め方が確実です。iOS側の作り方と費用感の総論はiOSアプリ開発とは？特徴・Swiftでの作り方・費用と外注判断を発注者視点で解説が扱っています。

言語を変える書き直しが正当化される条件｜移行判断の三つの関門

運用中のアプリで言語を変える判断は、原則として見送りが正解です。書き直しは機能追加を止め、既存の不具合修正の履歴も失う。それでも移行が正当化されるのは、次の三つの関門を全て通過したときだけでした。

1. 現行の言語やフレームワークが公式に更新を終え、ストア要件へ追随できない見込みが立っている
2. 書き直し中の半年から1年、機能追加を止めても事業計画が破綻しない
3. 移行後の言語で保守できる体制が、契約または採用によって確保済みである

一つでも欠けるなら、既存コードのまま延命する方針を選んでください。延命策は、UI層だけを置き換える部分移行と、新機能のみ別画面として新技術で作り既存へ埋め込む手法の二つです。全面書き直しを提案されたら、この三点を満たす根拠を必ず確認してください。

よくある質問

アプリ開発の言語選定でよく寄せられる質問に、実装の前提を添えて答えます。

アプリ開発の言語は何から決めればよいですか？

言語から決めないでください。順序は、配布先（両OSかブラウザか）、OS機能への依存度（BLE・カメラ制御・バックグラウンド実行の要否）、保守体制（5年間誰が触るか）の三つです。この三点が確定すれば技術は1つか2つに絞られ、言語は結果として決まります。

Swiftだけを覚えればアプリ開発はできますか？

iOS向けに限れば成立します。Swift 6.3でSwift SDK for Androidの公式リリースも始まりましたが、ロジック層をSwiftで共有しAndroidのUIはKotlinで書く前提です。SwiftのみでAndroidアプリを完成させる構成は、2026年8月時点で実務の選択肢に入りません。両OSを1言語で作るならDartかTypeScriptが確実です。

FlutterとReact Nativeはどちらが将来性がありますか？

将来性という軸では判断できません。どちらも大手が開発を継続し、Flutterは3.47系、React Nativeは0.87系が最新の安定版です。判断軸は自社の資産にあります。WebをReactとTypeScriptで作っているならReact Native、デザインを両OSで完全に揃えたいならFlutter。この二つで実務の分岐はほぼ尽きます。

Pythonでスマホアプリを作ることはできますか？

技術的には可能ですが、業務で5年配布する候補には入れないでください。実行環境にPythonのインタプリタが標準で入っておらず、同梱するとアプリサイズと起動時間が犠牲になります。出番はサーバー側で、推論やデータ処理を担当させ端末とはHTTPのAPIで切る構成が実務の形です。

途中から開発言語を変更することはできますか？

可能ですが、原則として見送ります。判断してよいのは、現行技術が更新を終えてストア要件へ追随できない、書き直し期間中に機能追加を止めても事業が回る、移行後の保守体制が確保済み、という三条件を全て満たすときだけです。満たさない場合は部分移行などの延命策を先に検討してください。

関連記事

• Androidアプリ開発の言語はKotlinとJavaのどちらか？選定基準と環境まで解説：Android内の移行判断と環境構築の詳細です。
• アプリ開発の流れとは？企画から保守まで7工程で発注側が決めることを解説：技術選定を挟む工程全体の地図です。
• iOSアプリ開発とは？特徴・Swiftでの作り方・費用と外注判断を発注者視点で解説：iOS側の費用感と外注判断の材料。
• Androidアプリ開発とは？できること・開発の流れ・iOSとの違いと外注の進め方：Android側の総論と進め方の解説。
• Webアプリ開発とは？仕組み・種類・開発言語から費用と外注判断まで発注者視点で解説：ストア配布を回避する選択肢の詳細。
• アプリ開発会社の選び方は？依頼先の見極め方と見積比較の判断基準を解説：技術選定を任せる相手の見極め方。