「動いてはいるが、機能追加のたびに 2 週間かかる」「Swift 5 と Kotlin の混在で、両プラットフォームを触れるエンジニアがいない」「iOS 26 の新機能を使うにも、SDK の依存関係が古すぎて手が入れられない」。5 年以上運用してきたモバイルアプリで、この 3 つのうちどれか 1 つでも心当たりがあるなら、そろそろリプレイスの選択肢を握っておくべきタイミングです。本記事は、iOS・Android のネイティブアプリを止めずに刷新するための進め方を、AI 駆動開発のクリエイティブスタジオが実案件ベースで整理した実務ガイドです。
結論: アプリ リプレイスも dual-stack 期間を軸にした段階移行が前提
先に結論を書きます。モバイルアプリのリプレイスは、旧アプリを全ユーザーで一斉に新アプリへ切り替える「一括置換」よりも、旧新のアプリを一定期間並行運用しながら少しずつ新側へ寄せていく段階移行のほうが、ほとんどのケースで安全です。この並行運用の期間を「dual-stack 期間」と呼びます。
理由は 3 つあります。1 つ目は、ストア公開型のアプリは Web システムと違い、ユーザー側の更新タイミングを開発側の意図どおりにはコントロールできないため、旧アプリのユーザーが一定期間残るのは避けようがないという点です。強制アップデートを組んでも、更新前のユーザーが数週間残るのは普通です。2 つ目は、ストア審査でリジェクトが発生した場合、切り戻しの選択肢が限られるという点です。3 つ目は、ネイティブアプリ特有の分析データ (アトリビューション、コンバージョン、リテンション) の連続性を保つには、新旧を並行運用しながらデータを寄せていく必要があるという点です。
注意
モバイルアプリは Web システムと違い、ユーザー側の更新タイミングを開発側の意図どおりにはコントロールできません。旧アプリのユーザーが一定期間残ることを前提に、dual-stack 期間を軸にした段階移行を計画するのが安全です。
段階移行の中身、つまり dual-stack 期間中の Feature Flag 設計、Remote Config での機能出し分け、ストア審査のリズム設計といったところが、アプリ リプレイスの実務の中核です。汎用のリプレイス手順は システムリプレイスの進め方完全ガイド にまとめていますが、本記事はモバイル固有の論点、つまりストア審査・SDK 依存・アトリビューションといったところを掘り下げます。
アプリのリプレイスが必要になるサイン
まずは「そろそろリプレイスの選択肢を握っておくべき」タイミングかどうかを、判断できるサインで確認します。次の 5 つのうち、2 つ以上が該当するようなら、着手時期を経営会議で議題に上げる段階に来ています。
- OS SDK の EOL が迫っている。iOS 26 や Android 15 で新機能を使いたいのに、既存アプリの最小サポート OS を上げると既存ユーザーの一定割合が切り落とされてしまう。あるいは Firebase・Push Notification など主要 SDK の最低要件が上がって、既存アプリの依存関係が持たなくなる。
- Swift や Kotlin の言語仕様変更に追従できていない。Swift 6 の Sendable、Kotlin K2 の型推論、といった新しい言語仕様に既存コードが対応できず、Xcode や Android Studio のアップデートで大量の警告が出るようになる。
- 開発者が離職して属人化した箇所が動かせない。既存の CoreData のスキーマ設計や Realm の使い方、独自の DI 設計を書いた開発者が離職し、後任がその領域を触るとバグが出るため、機能追加が止まっている。
- パフォーマンス劣化とクラッシュ率の悪化。RxSwift・RxJava の当時の書き方が今の Swift Concurrency や Kotlin Coroutines と噛み合わず、UI のもたつきやメモリリークが顕在化している。
- UI 表現の要求に応えられない。SwiftUI や Jetpack Compose の宣言型 UI で表現できる動きを、UIKit や View ベースの旧コードで実装するとコストが跳ね上がる。
これらは、リプレイスの初動を「保守撤退の通告が来てから」に置くと選択肢が狭まる、という点で メインフレーム リプレイスの進め方 と共通の構造です。相場を掴んで議論を始めるのは、少し早いくらいでちょうど良いフェーズです。
リプレイスの選択肢 4 系統と判断軸
アプリ リプレイスには、大きく次の 4 系統の選択肢があります。実務では 1 つに決めきるのではなく、機能領域ごとに方針を分けて組み合わせるのが普通です。
| 選択肢 | 主に変えるもの | 向く状況 |
|---|---|---|
| 現行スタック維持 | 最小限のリファクタリングと SDK 更新のみ | 短期的に機能追加を再開したい、フル刷新の予算がない |
| ネイティブ再構築 | Swift・Kotlin で SwiftUI・Jetpack Compose を軸に書き直し | ネイティブ体験と OS 機能の追従を最重視 |
| RN・Flutter 移行 | React Native や Flutter でクロスプラットフォーム化 | 2 プラットフォームの実装工数を圧縮したい |
| Web View 主体への切替 | Web View で UI を描画し、ネイティブ機能は最小限のブリッジ経由 | 更新頻度が高く、ストア審査を通さずに機能を出したい |
判断は 3 つの軸で行います。
**1 つ目は「UI 表現とネイティブ機能の要求水準」**です。カメラ・AR・位置情報の高精度活用・グラフィクスパフォーマンスといったネイティブ機能を深く使うアプリは、RN や Flutter でもブリッジ実装で対応できますが、ネイティブ再構築の方が総合的に楽な場合が多いです。逆に、UI の複雑さがフォーム中心・リスト中心で、機能の中心が API 呼び出しと表示であれば、RN・Flutter や Web View 主体の選択肢が現実的になります。
**2 つ目は「開発チームのスキルセットと採用可能性」**です。Swift・Kotlin エンジニアの採用が難しくなっている状況を踏まえると、TypeScript・Dart の人材市場を活用できる RN・Flutter は、中長期の採用面で利点があります。Web エンジニアが多い組織であれば、Web View 主体への切替でチームのスキルを揃える判断もあります。
**3 つ目は「更新頻度とストア審査回避の必要性」**です。1 週間に 1 回以上の機能アップデートを回したい業態 (EC・ニュース・金融) では、ストア審査の折り返し時間が業務のボトルネックになります。Web View 主体で UI と機能を配信する設計にすれば、審査を通さずに Web 側の更新で機能を出せます。
実務では 1 つに決めきりません。例えば「メインの UI は Flutter で書き直し、決済画面と AR カメラ機能だけネイティブモジュールを残す」といった組み合わせは、判断表の 3 つの軸を横断して現実解を作る典型例です。機能領域ごとに方針を分けると、一枚岩で見たときには非現実的だった総額と期間が、区画ごとには実行可能なラインに落ちてきます。
AI 駆動で Swift・Kotlin コードを読み解いて dual-stack 期間を設計する手順
アプリ リプレイスで時間を吸われるのが、既存の Swift・Kotlin コードから業務ロジックとデータフローを読み解くフェーズです。5 年前のプロジェクトでは、当時の Swift 3 や Kotlin 1.3 の書き方、その時期に流行っていたアーキテクチャ (VIPER・Redux・MVVM・Clean Architecture) の混在、独自の非同期処理 (RxSwift・RxJava・PromiseKit・Coroutines) の使い分け、といった歴史が積み重なっており、これを人手だけで詰めようとすると数ヶ月単位で消えていきます。
この工程は AI 駆動開発と特に相性が良い領域です。既存の Swift・Kotlin コードを Claude Code などの AI コーディングツールに読み込ませ、各画面の責務、データの流れ、非同期処理の複雑さ、外部 SDK の使い方を要約させると、人手だけで追うより短期間で全体像をつかめます。
具体的な進め方は次の 4 ステップです。
- 画面単位で分割して読ませる。ネイティブアプリは画面 (ViewController・Activity・Composable) が業務の単位に近いため、画面ごとに分割して AI に読ませると、責務の把握が早いです。全プロジェクトを一度に読ませると、精度が落ちる代わりに、抽象度の高い要約しか出てきません。
- 外部 SDK と依存関係のマトリクスを作る。Firebase・Sentry・Adjust・KeychainAccess といった SDK の使い方を洗い出し、それぞれが新側で必要かどうかを判定します。移行のタイミングで不要な SDK を落とせるのは、アプリ リプレイスの副次的な利点です。
- 非同期処理と状態管理のパターンを分類する。RxSwift・RxJava から Swift Concurrency・Kotlin Coroutines への書き換えは、機械的な変換だけでは終わらず、業務ロジックの理解が要ります。AI にパターンを分類させ、変換方針を機能領域ごとに決めます。
- 推定した業務ロジックを、新アプリ側のテストとして書き起こす。Espresso や XCUITest のような E2E テストと、ViewModel・Presenter 層の単体テストを、旧アプリの振る舞いから逆算して書きます。書き溜まったテストは、そのまま新アプリの生きた仕様書として残ります。
読み解きが進んだら、dual-stack 期間の設計に入ります。dual-stack 期間の中心は、Feature Flag と Remote Config による機能の出し分けです。旧アプリと新アプリの両方に Feature Flag を仕込み、Firebase Remote Config などのサーバー側で新アプリへ寄せていく割合を制御します。最初は社内テスターだけ、次に 5% のユーザー、次に 25%、といった形で対象を絞って広げます。問題が出たら Remote Config を戻すだけで即座に旧側へ復帰できるので、切り替えのリスクをかなり抑えられます。
FIXITdual-stack って、要するに新旧のアプリを一定期間ダウンロードしてもらうってこと？
実は多くの場合、そうではないんです。1 つのアプリの中に旧新の実装を両方入れて、Remote Config で出し分けます。
Hayateバイナリサイズは一時的に大きくなるんですけど、ユーザーには 1 本のアプリのアップデートに見えるので、体験が壊れないんですよ。
FIXITじゃあ、ストアには 1 本しか出さないってこと？
Hayate多くのケースはそうです。ただ、Bundle ID を変えたい場合や、大幅な UX の刷新をブランディングで見せたい場合は、別アプリとして出す判断もあります。
実案件の費用と期間レンジ
アプリ リプレイスの費用と期間は、対象アプリの機能領域数と外部 SDK の依存数で大きく動きます。実案件で見えているレンジはおおむね次のとおりです。
| 規模の目安 | 期間 | 費用レンジ (税抜) |
|---|---|---|
| 単一プラットフォーム (iOS または Android のみ)、機能領域 5〜8 | 4〜5 ヶ月 | 1,500 万〜2,500 万円 |
| 両プラットフォーム、機能領域 8〜15 | 5〜7 ヶ月 | 2,500 万〜4,500 万円 |
| 両プラットフォーム、機能領域 15 以上、複雑な SDK 依存 | 7 ヶ月以上 | 4,500 万円以上 |
費用と期間を左右するのは、対象アプリの画面数そのものよりも、次の変動要因です。
- 外部 SDK の依存数。Firebase・Sentry・Adjust・KeychainAccess・独自 SDK など、依存が多いほど新側での互換確認が増えます。
- アトリビューションと分析データの引き継ぎ要件。広告成果を継続して計測する必要があるほど、初回起動時のユーザー識別と履歴突合の設計が複雑になります。
- In-App Purchase の設計。定期購読や消費型 IAP を含むアプリは、新側での価格設定・レシート検証・過去購入者の状態復元まで含めた設計が必要で、ここが最も工数を吸います。
- ストア審査の折り返し。新規パーミッションや IAP の変更を含むリリースでは、リジェクトから再提出までの折り返しが工程に乗ります。
AI 駆動開発を取り入れると、これらのうち特に既存 Swift・Kotlin コードの読み解きと、新側での再実装 (SwiftUI・Jetpack Compose・Flutter への書き換え) の工数を圧縮できます。実案件の感触では、従来開発と比べて期間がおおむね半分から 3 分の 2 程度に短縮できることが多いです。ただし、ストア審査の折り返しや IAP の設計はそのまま残るため、費用が期間と同じ比率で下がるわけではありません。
失敗しやすい 3 パターンと回避策
アプリ リプレイスが頓挫する原因は、ほとんどが次の 3 パターンのどれかに集約されます。
**1 つ目は「完全リライトからの即置換」**です。旧アプリを一切触らずに新アプリを別プロジェクトで開発し、完成したタイミングで旧アプリを新アプリに置き換える方針を取ると、切り替え当日までユーザーテストができず、リリース直後に致命的なバグが顕在化しがちです。dual-stack 期間を最初から設計に組み込み、旧アプリのバイナリに新側の実装を仕込んで少しずつ寄せていく進め方が回避策になります。
**2 つ目は「ドキュメント整備を先行させて実装が進まない」**です。旧アプリの仕様書を先に整備してから新側の実装に入る計画を立てると、設計書が完成しないまま予算と期間を消費してしまうことがよくあります。仕様書を整備するのではなく、業務ルールを新側のテストとして書き起こしていく進め方に切り替えると、テストが生きた仕様書として残り、無駄がなくなります。
**3 つ目は「iOS だけ先行して Android を放置」**です。iOS を先に新側で書き直したものの、Android 側の開発リソースを確保できずに 1 年以上放置される、というのはアプリ リプレイスで最も頻度の高い失敗パターンです。回避策は 2 つあります。1 つは、両プラットフォーム同時進行を最初から計画に組む方針。もう 1 つは、Android から先に着手する方針。Kotlin の言語仕様の変化 (K2 コンパイラ、Kotlin Multiplatform) が Swift より速いため、Android を先に整理したほうが、後発の iOS 側でも設計の再利用が効くケースがあります。詳しくは FAQ の 1 つ目で扱っています。
アプリ リプレイスのご相談
アプリ リプレイスは、進め方の前半、特に既存 Swift・Kotlin コードの読み解きと dual-stack 期間の設計で勝負が決まります。「新アプリの企画は動き始めたが、旧アプリの分析データを止めたくない」「iOS と Android のどちらから着手するか判断したい」という状況こそ、AI 駆動開発で読み解きと再実装を加速できる領域です。FIXIT ではネイティブアプリのリプレイスの無料相談を承っています。現状の課題や対象アプリの規模が固まっていない段階でも構いません。まずは システム刷新・リプレイスのサービス内容 をご覧いただき、お問い合わせ からお気軽にご相談ください。