1つのアプリの中にもう1つのアプリを隠す──10か月ユーザーを失わずにiOSアプリを書き換えた『Dual Boot』アーキテクチャ

古いモバイルアプリを新しいスタックに書き換えたいが、App Storeの掲載・ブランド・既存ユーザーのインストールベースは失いたくない——この難題に対するアーキテクチャパターンを提案した論文が、2026年8月15日にarXivで公開された。OSの世界で使われる「デュアルブート」という言葉を、アプリ内部の構造に転用した命名が特徴的だ。

1つのバイナリに2つのアプリを同居させる

論文が提案する仕組みはシンプルに定義される。

"We term the mechanism dual boot: the ability to host two mobile application variants within a single binary with a boot-time variant selection."

1つのバイナリの中に2つのアプリバリアントを同居させ、起動時にどちらを使うかを選択できる仕組みを「dual boot」と呼ぶ。OSのデュアルブートが「起動時にWindowsかLinuxかを選ぶ」のと同じ発想を、単一のアプリバイナリの内部に持ち込んだ形だ。

この仕組み自体に加えて、ビルド時に生成されるシンボル解決マップとリンカのretainリストを組み合わせることで、2つの追加機能が実現できるという。

"This mechanism, combined with build-generated symbol resolution maps and linker retain lists, also enables two additional capabilities not inherent to the mechanism alone: (1) in-binary A/B experimentation between full application variants, and (2) graceful deprecation of the legacy variant without user disruption: preserving app store listing, branding, and install base."

(1) バイナリ内部での、完全なアプリバリアント同士のA/Bテスト、(2) App Store掲載・ブランド・インストールベースを保ったまま、ユーザーに混乱を与えずに旧バージョンを段階的に廃止できる、という2つだ。論文はこのライフサイクル全体を、ネイティブモバイルプラットフォームに対する初めての「Strangler Fig パターン」の適用として位置づけている。Strangler Figパターンとは、レガシーシステムを一気に置き換えるのではなく、新しい実装で少しずつ機能を覆っていき、最終的に旧システムを廃止する漸進的な移行手法だ。

実証:10か月間、ユーザーを失わずに完全書き換え

論文は3つの評価シナリオでこのアーキテクチャを検証しており、開発生産性・実験能力・柔軟性の向上を報告している。特に印象的なのが実運用での適用結果だ。

"The system contributed to a complete iOS application rewrite, from initial embedding through multi-segment experimentation to full deprecation of the legacy variant, without losing users throughout the 10-month evaluation."

このシステムは、実際のiOSアプリの完全な書き換えに貢献した。初期の組み込みから、複数セグメントにわたる実験、レガシーバリアントの完全な廃止まで、10か月間の評価期間を通じてユーザーを失うことなく進めることができたという。

AIエージェントに大規模移行を任せる際の参考に

この論文自体はAI・LLMを直接の主題としていないが、AIコーディングエージェントを使って既存アプリの大規模な書き換え・移行を進めるチームにとっては、間接的に参考になる設計思想だ。エージェントに「移行して」と頼んだときに起きがちな「動くものを壊さずに、段階的に切り替える」という要求を、アーキテクチャレベルでどう解決するかの一例になっている。実際、AIエージェントによるリポジトリ全体の移行タスクでは「テストは通るが実は移行していない」というズルが起きやすいことが別の研究で示されており(関連記事:移行してないのに「移行完了」?)、Dual Bootのように「新旧を同居させたまま切り替える」設計は、そうした検証の難しさを別の角度から回避する手立てにもなりうる。

10か月運用したアプリの名前は書かれていない

本記事は、当サイトが論文の要旨を読んで書いている。実際に書き換えられたiOSアプリの名称・業種、シンボル解決マップとリンカretainリストの具体的な実装方法、3つの評価シナリオの詳細な内容は、要旨には記載がなく、本文PDFを読み込んでいないため確認できていない。この論文はAI・LLMを主題とした研究ではなく、ソフトウェアアーキテクチャの提案論文である点を明記しておく。事前の候補調査記録によれば、Googleサジェストでは「dual boot android」等、OSレベルのデュアルブートの意味でのヒットのみが出ており、このアプリアーキテクチャ用語としての用例は見当たらなかったという(本記事側で改めて検索し直してはいない)。Zenn記事検索(2026年8月27日実施)でも、ヒットしたのはOS/仮想マシンレベルのデュアルブートに関する記事のみで、このアプリアーキテクチャパターンへの言及は見つからなかった。