携帯／モバイルアプリでは、iOSとAndroidの両方にどう無理なく対応するかが、多くの担当者が最初にぶつかる悩みです。両OSの技術形態と言語の選び方が、開発コストと将来の運用負荷を左右します。
事例は、どの技術形態・言語を選び、なぜそう判断したかという視点で見ていきます。
なお、アプリ開発の全体像をまだ把握していない方は、まず携帯/モバイルアプリ開発の完全ガイドから読むことをおすすめします。
スマホアプリ開発の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「スマホアプリ開発の完全ガイドブック」で詳しく解説しています。
▼開発を相談する前に読みたい無料ホワイトペーパー
・スマホアプリ開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
両OS対応の実現方法と事例
携帯／モバイルアプリの事例を「両OS対応の実現方法」という観点で見ると、大きく二つのアプローチに分かれます。
一つは、FlutterやReact Nativeといったクロスプラットフォーム技術で、単一のコードから両OSを生成するアプローチです。もう一つは、iOS向けにSwift、Android向けにKotlinをそれぞれ書く別々開発のアプローチです。
どちらを選んだかは、そのサービスがアプリに求める性能とコスト、そして組織の採用体制によって決まっています。
クロスプラットフォームで両OSを一本化した事例
クロスプラットフォームを採用した事例の最大の狙いは、iOSとAndroidで二重に発生する開発・保守コストの圧縮です。
SwiftとKotlinで別々に作ると、同じ画面を二度実装し、二つのコードベースを維持し続ける必要があります。これに対しFlutterなら、UIのロジックを一本化して両OSに同時に展開できます。
新機能を追加するときも一度の実装で両OSに反映でき、そのぶん保守工数が構造的に下がります。これが、この形態を採用する決め手になっています。
ただし、性能には明確なトレードオフがあります。学術的なベンチマークでは、iOSでカメラ起動時間がネイティブ平均5.85msに対し、Flutterは平均247.87msと大きな遅延が報告されています（出典：アムステルダム自由大学等の修士論文）。
アプリ容量も、iOSのネイティブ1.3MBに対しFlutterは28.5MBと約22倍になります。事例を読むときは、こうした性能差が自社サービスの体験を損なわない範囲かを必ず確認することが大切です。
逆に、カメラや高速描画を多用しないサービスであれば、コスト圧縮のメリットが性能差を上回ると判断できます。
- 体験の要：カメラや高速描画が、サービスの価値を左右する場面があるか
- 発注の目的：コスト削減と性能の確保のどちらを優先する案件か
ネイティブ別々開発で性能を優先した事例
性能やOS深部の機能活用を最優先する事例では、iOSをSwift、AndroidをKotlinで別々に開発する道を選んでいます。
高速なカメラ起動、滑らかなアニメーション、OSの最新機能への即時対応が求められるサービスでは、ネイティブ別々開発のほうが体験品質を担保しやすいためです。
現場のエンジニアからは、「ネイティブのエラーの方がデバッグしやすい」「大企業ではObjective-CやJavaが今も最強」といった声も上がっています（出典：Reddit）。
ネイティブ別々開発のコストは、当然ながらクロスプラットフォームより重くなります。SwiftとKotlinそれぞれにエンジニアが必要で、言語別の年収はKotlinが約873万円、Swiftが約868万円とほぼ同水準です。
両OSをそろえると人件費がほぼ倍になります（出典：ぷらすわん調べ等）。それでもネイティブを選ぶのは、性能と安定性が事業の競争力に直結するケースです。
両OS対応をどう実現するかは、結局「性能をどこまで妥協できるか」と「二重コストを許容できるか」のバランスで決まります。
この判断は、メリットとデメリットの観点とも深く関わります。関連記事もあわせてご覧ください。
- 優先する機能：OSの深部の機能や描画の速さを、どの程度まで求めるか
- 人件費：両OSぶんの開発体制を抱える余裕があるか
ネイティブからハイブリッド統合へ移行した事例
両OS対応の事例で特に学びが深いのが、すでにネイティブで作り込んだアプリを、クロスプラットフォームへ部分的に移行する「ハイブリッド統合」のケースです。
全面的に作り直すのではなく、UIなど一本化しやすい部分だけをクロスプラットフォーム化します。認証やセキュリティといったコア部分は、ネイティブのまま残します。
この折衷こそが、大規模アプリの現実的な両OS戦略として注目されています。
ING銀行「InsideBusiness App」のFlutter移行事例
もっとも示唆に富むのが、ING Wholesale Bankingの法人向け銀行アプリ「InsideBusiness App」の事例です。
月間4.2万人を超える法人ユーザーが利用するこのアプリは、もともとiOSとAndroidをネイティブで別々に開発していました。そこで、両OSのUI開発・保守コストを圧縮するため、Flutterへの移行を進めました（出典：アムステルダム自由大学等の修士論文）。
注目したいのは、アプリ全体をFlutterに置き換えなかった点です。認証で使うmTokenなどのコアセキュリティはネイティブSDKを継続し、UI層だけをFlutterに統合しました。
この移行ではトレードオフも生じました。アプリサイズは、iOSで40.1MBから79MBへ、Androidで29.2MBから141MBへと肥大化しています（出典：同修士論文）。
それでもINGがこの選択を成功と評価したのは、容量の増加よりも、両OSのUIを一本のコードで維持できる保守性の向上を重視したからです。
銀行アプリという高いセキュリティ要件を満たしながら両OSの開発効率を上げるには、「コアはネイティブ、UIはクロスプラットフォーム」というハイブリッド統合が最適解になり得ます。
この事例は、両OS対応を白黒で割り切らない柔軟さの大切さを教えてくれます。
- コア部分：ネイティブに残す範囲を、どこで線引きするか
- 移行の範囲：UIやロジックのうち、どの層から寄せるか
BMWがKMPで段階統合した事例
もう一つの示唆的な事例が、BMWの車載システムにおけるKMP（Kotlin Multiplatform）の段階統合です。KMPは、ビジネスロジックなどの共通部分をKotlinで一本化しつつ、UIは各OSのネイティブに任せられる技術です。
Flutterとは異なるアプローチで両OS対応を実現します。BMWは、このKMPをいきなり全面採用するのではなく、全体工数の約20%に抑えて段階的に統合することに成功しました（出典：リサーチノート記載のKMP事例）。
BMWの事例から学べるのは、新しいクロスプラットフォーム技術を導入する際の「リスクの抑え方」です。
既存のネイティブ資産は一気に置き換えず、共通化の効果が高いロジック層から少しずつKMPへ寄せていきます。こうすれば、移行が失敗しても影響範囲が限定され、効果を確かめながら範囲を広げられます。
INGのUI一本化とBMWのロジック一本化は、いずれも「全面移行のリスクを避けつつ両OSの効率を上げる」という点で共通しています。
両OS対応の移行は、一括ではなく段階で進めるのが成功の定石だと言えます。
- 移行の起点：既存のネイティブ資産のうち、どの層から寄せるか
- 影響の確認：移行を広げる前に、どの効果を見て判断するか
国内クロスプラットフォーム採用とAI駆動開発の事例
両OS対応のクロスプラットフォーム採用は、海外の大企業だけの話ではありません。
国内でも有名サービスがFlutterで両OSを一本化しています。さらに近年は、AI駆動開発を組み合わせて開発コストそのものを圧縮する事例も生まれています。
国内有名サービスのFlutter採用事例
国内でFlutterを採用して両OSに展開しているサービスは、すでに幅広い業種に広がっています。
具体的には、メルカリのスポットワークサービス「ハロ」、回転寿司チェーンのスシロー、旅行予約のじゃらん、就活サービスのマイナビ2025などが挙げられます。ほかにも、アパレルのユニクロ、サイバーエージェントの公営競技サービスWINTICKET、DeNAの音声配信Pococha（Voice Pococha）があります（出典：リサーチノート記載の国内Flutter採用アプリ）。
これだけ多様なサービスが採用していることは、Flutterによる両OS一本化が実用段階にあることを示しています。
これらのサービスに共通するのは、両OSで同じ体験をスピーディーに提供したいというニーズです。アパレルや飲食、旅行といった分野では、キャンペーンや新機能を両OSに同時に投入できるかどうかが集客に直結します。
Flutterで一本化すれば、iOSとAndroidで機能の提供時期がずれる事態を避けられます。
riplaの知見では、エンジニアの採用難易度はReact Native、Swift／Kotlin、Flutter、KMPの順に難しくなります。
Flutterエンジニアの採用は、2026年時点でも容易ではないため、両OS一本化のメリットを受けつつ、退職時のリカバリーを経営リスクとして織り込んでおくことが欠かせません。
- 採用ルート：Flutterエンジニアを探す経路を、開発の開始前に確保できるか
- 社内の知見：エンジニアが替わっても、開発の仕組みを引き継げる記録が残るか
AI駆動開発でコストを3分の1に圧縮した事例
両OS対応のコストを根本から変える可能性を示したのが、AI駆動開発の事例です。
ぷらすわん合同会社では、市場相場で700〜1500万円、工数にして13〜18人月かかる規模の案件に取り組みました。Claude Code等のAIによるコード自動生成と発注体制の工夫によって、実質8人月・500万円まで圧縮しています（出典：ぷらすわん合同会社）。
クロスプラットフォームで両OSのコードを一本化したうえで、その実装をAIが支援することで、人月そのものを削減したのです。
この事例で見逃せないのが、発注体制の工夫です。一社にまとめて発注するのではなく、「フリーランス＋小規模専門会社」へ分割発注することで、中間マージンを抑えています。
発注先別の人月単価は、フリーランスが60〜80万円、中小開発会社が80〜120万円、大手SIerが150〜300万円と大きな開きがあります（出典：ぷらすわん調べ）。
この差を踏まえて発注先を組み合わせること自体が、コスト削減の打ち手になります。AIによる生産性向上と、両OS一本化、そして賢い発注設計が重なると、従来の常識を超えるコスト圧縮が実現します。
両OS対応の費用を考えるうえで、この三点セットは今後の主流になっていくでしょう。
- 分割の単位：工程ごとに、どの規模の会社へ任せるかの線引き
- AIの使いどころ：コード自動生成をどの範囲の実装に当てるかという判断
失敗から軌道修正した両OS対応の事例
事例の価値は成功談だけにあるのではありません。むしろ、発注側がもっとも学べるのは「なぜ技術選定でつまずいたのか」「どう立て直したのか」というリアルな経験です。
両OS対応の技術形態を見誤ると、せっかくの一本化が裏目に出ることもあります。そこで、クロスプラットフォームの限界からネイティブへ回帰した事例と、段階移行で堅実に立て直した進め方を見ていきます。
クロスプラットフォームからネイティブへ回帰した事例
クロスプラットフォームは、どんな場面でも最適とは限りません。現場のエンジニアからは、「クロスプラットフォームで限界にぶつかり、ネイティブへ回帰する人もいる」という声が上がっています（出典：Reddit）。
両OSを一本化したものの、OSごとの細かな挙動の差への対応、ネイティブ特有の機能の実装、複雑なバグの調査などで、かえって工数がかさんでしまうケースがあります。
「ネイティブのエラーの方がデバッグしやすい」という指摘も、こうした回帰の背景を物語っています。
この回帰事例が示す教訓は、「コスト圧縮だけを理由にクロスプラットフォームを選ぶと、後で性能や保守の壁にぶつかる」ということです。
前述のとおり、カメラ起動でネイティブ5.85msに対しFlutter247.87ms、容量で約22倍という性能差は、サービスの性質によっては大きな痛手になり得ます。
両OS対応の技術選定は、開発初期のコストだけでなく、リリース後に求められる性能と保守性まで見据えて決める必要があります。
技術形態の選定で起きやすい失敗や注意点の詳細は、後述の関連記事もあわせてご覧ください。
- 工数の見積もり：OSごとの差異やバグ調査にかかる工数を、初期の見積もりに含めているか
- 性能の要件：リリース後に求める性能を、技術選定の前に言葉にしておくこと
段階移行で立て直したripla流の事例
技術選定の失敗を避けるために、riplaが一次情報として整理しているのが「ネイティブ化の移行シグナル3条件」です。
これは、ラクスルやLINEヤフー出身のメンバーの実体験に基づく判断基準です。最初から両OSのネイティブアプリに数千万円を投じるのではなく、MVP期はWeb/PWAで最速に検証することを起点にしています。
Web/PWAであれば、iOSとAndroidの区別を意識せず、一つのコードで両OSのユーザーに最速で価値を届けられます。
- MVP期：最速の検証に使う時期
- 移行の判断：3つのシグナルが揃ったところで、ネイティブ化に進む段取り
1. デイリーアクティブユーザーが増えていること
2. プッシュ通知でのリエンゲージメントが重要になってきたこと
3. カメラなどブラウザの制約では実現できない機能への強い要望が出てきたこと
この3つが重なったタイミングこそ、ネイティブ化の明確なシグナルだとしています。逆に言えば、これらが揃う前に高額なネイティブ開発へ進むのは、過剰投資のリスクが高いということです。
この段階移行の考え方は、前述したINGやBMWの「一括ではなく段階で移行する」という成功パターンと根底で一致しています。Web/PWAで両OSのユーザーを検証し、シグナルが揃った部分からネイティブ化する流れも、その延長にあります。
riplaはフルスクラッチ受託と国内開発、そして元事業会社出身の知見をもって、この「成長段階から逆算した両OS設計と段階移行」を一貫して重視しています。
事例は華やかな技術選定ではなく、「なぜそのタイミングでその形態を選んだのか」という視点で読むことが、失敗を避ける最大の近道です。
まとめ
携帯／モバイルアプリの事例を「iOSとAndroidの両OS対応」という観点で振り返ると、成功も失敗からの回復も、結局は「二者択一ではなく、組み合わせと段階移行で技術形態を選ぶ」という一点にまとまります。
クロスプラットフォームは両OSの開発・保守コストを一本化できる一方で、カメラ起動5.85ms対247.87ms、容量約22倍という性能差を抱えます。
INGのハイブリッド統合はコアをネイティブに、UIをFlutterに分けました。BMWのKMPは、ロジック層から段階的に統合しています。
国内ではメルカリ ハロやユニクロがFlutterで両OSを一本化し、AI駆動開発は700〜1500万円の案件を500万円に圧縮しました。
コスト圧縮だけを理由にした一本化は、ネイティブ回帰という手戻りを招くことも事例が示しています。
事例を読むときに大切なのは、「どの技術が優れているか」ではなく、「なぜそのタイミングでその形態を選んだのか」という視点です。
自社サービスの性能要件と成長段階に照らして、まずWeb/PWAで両OSのユーザーを検証します。移行シグナル3条件が揃ったところで、必要な部分からネイティブ化するのが進め方です。
この段階的な進め方こそが、両OS対応の堅実な成功パターンです。
riplaはフルスクラッチ受託と国内開発、元事業会社出身の知見を組み合わせ、成長段階から逆算した両OS設計と、現場に定着するアプリづくりを一貫して支援します。
全体像の確認には、あらためて完全ガイドをご活用ください。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。