twilio

Flutter やめました。電話アプリを Native にした理由 はじめに こんにちは。株式会社IVRyで Engineering Managerをしています。tsutou です。 アイブリーのモバイルアプリのユースケースは、電話の転送を受けたり、着信を折り返して発信したりすることがメインです。 体験としては、アイブリーの対話型音声AIで、一次対応を自動化しながら、忙しい最中でも人が出ないといけない電話に応答する体験が、そのままエンドユーザーの体験になります。 note.com そんな中で、このアプリで進めていた Flutter Exit というプロジェクトが今月に完了しました。 Flutterで構築していたアプリを、iOSは Swift / SwiftUI 、Android は Kotlin / Jetpack Compose によるフル Native 構成へ移行し、2026年10月に両OSとも全ユーザーへの展開を終えています。 この記事では、なぜ Flutter をやめることにしたのか について経緯や意思決定を含めて書きたいと思っています。 apps.apple.com play.google.com Flutter 導入時の判断 Flutter導入当時は採用戦略の一部と、「クロスプラットフォームで UI を共有し、少人数で iOS/Android を同時に開発する」という合理的な判断でした。 導入当時は LLM も今ほど隆盛を極めておらず、限られたエンジニアリングリソースで出来るだけ早く iOS と Android の両方にアプリを提供するという課題がありました。 当時の採用戦略も踏まえれば、 Dart で書いたコードを両OSで共有でき、機能や仕様を揃えやすく、 Hot Reload でUIの変更をすぐ確かめられる Flutter は、当時はとても合理的な選択肢でした。 また、OS 標準の通話機能や利用する 通話SDK との連携には、Native側の実装が必要だったため、内部のSDK として通話部分は切り離され、Native な内製 SDK で作られておりました。外部公開も見据えてこの設計になっていたのは当時の判断としてとても助かりました。 現在の前提変化 今回の Flutter Exit には、大きく2つの目的がありました。 ひとつは、アイブリーの中核機能である音声通話の品質・安定性を高める こと。もうひとつは、アーキテクチャをシンプルにする ことで、今後の開発生産性と保守性を高めることです。 Flutterを導入した当時は、少人数で2つのプラットフォームを開発できることに大きな合理性がありました。しかし、プロダクトの成長に伴ってOS固有の機能を扱う重要性が増し、Flutter と Native の境界を維持することによる複雑性も無視できなくなっていました。 一方で、AIコーディングツールの進化によって、Swift / Kotlin それぞれで実装・保守することのコストも変わり始めています。 移行を決意した背景 こうした変化を踏まえ、私たちは Flutter Exit を決断しました。その理由を3つの観点から紹介します。 通話とOSの距離 Flutter 時代と Native 時代のアーキテクチャ比較 中核機能である音声通話処理のほぼ全ては Kotlin/Swift で実装されており、Flutter は UI (WebView) のラッパーとして機能していました。 そんな中で、アイブリーアプリはほぼ WebView で構成されているため、Flutterで UI Components を共通化するメリットも十分に享受できておらず、Flutterの各種ライブラリ、特に WebViewを中心に音声通話にも影響を及ぼす事象がいくつか発生してしまっていました。 voice-quickstart-android#641 flutter#175099 Native と Flutter のオーバーヘッド Flutter 時代と Native 時代の着信イベントフロー比較 Flutter と Native の間には、Platform Channels による呼び出しやコールバックが合計 50弱 ありました。着信イベントはOS・Native・Flutterの間を行き来し、問題が起きると、どの層に原因があるのかを切り分ける必要がありました。 特にAndroidでは、アプリが終了した状態で着信を受ける際に Headless な Flutter Engine を1つのコードで通常の Flutter Engine とは別で起動・管理する構成があり、OSのライフサイクルや相互の Flutter Engine の状態と合わせた細かな制御が求められました。 zenn.dev 移行前のPoCでは、Android cold-start 時の「アプリ起動〜初期画面表示までの時間」の中央値が 192.5ms から 49.6ms (約74%の短縮、約3.9倍の高速化) になりました。 アイブリーアプリは起動速度が、着信応答の速度にそのまま繋がるため、開発効率だけでなくユーザー体験にも改善をもたらすインサイトが見えました。その他にも着信通知受信 → 着信UI表示までの時間など、通話における色々なパスで改善のインサイトが見られました。 ただし、これはPoCでの比較であり、もちろん差のすべてを Platform Channels だけに帰するものではありません。それでも、通話体験に関わる経路をシンプルにする意義を確かめる材料になりました。 AI コーディングツールの進化 これまでは、SwiftとKotlinでそれぞれ実装する開発コストが大きな懸念でした。しかし、Claude Code や Devin など、AIコーディングツールの進化によって、定型的な UI や API 連携の実装コストを下げられるようになりました。 Anthropicも、既存コードを仕様として参照でき、テストによって移行結果を検証しやすい大規模なコードマイグレーションは、AIエージェントと特に相性のよい領域だと紹介しています。 claude.com 実際に PoC では、既存のネイティブ通話コードには手を加えず、 Dart -> Swift / Kotlin へのコード移行に限れば わずか2〜3日で、iOS / Android ともに、電話をかけ、受けて転送といったアイブリーアプリの基本的な体験が成立するところまで到達 しました。もちろん、これは移行全体が数日で終わったという意味ではありません。品質検証やリリースには別の時間が必要です。 また、Nativeに寄せることで、人間の開発者だけでなく、AIコーディングツールにとっても扱いやすいアーキテクチャになると考えました。 Swift / Kotlin は公式ドキュメントやWeb上の技術情報が豊富であり、OS標準の開発ツールを直接利用できます。加えて、Platform Channels や Flutter Engine をまたぐ複雑な状態・イベント処理が不要になり、追うべきコードや依存関係も減らせます。 AIによって実装コストが下がることに加えて、AIが理解・変更する対象そのものをシンプルにできる点も、今回の意思決定を後押ししました。 expo.dev もちろんいいことばかりではなく、 CodingはAIで圧縮できますが、リリース作業や運用だったり OS ごとのルール設計など純増してしまうコストは一定存在します。デザインなども今後は OS ごとに最適なデザインを考えていく必要があるでしょう。 最後に 今回のFlutter Exitは、Flutter という技術そのものを否定するものではありません。導入時には合理的だった選択も、プロダクトの中核機能に及ぼす作用について考え続け、技術環境や前提条件の変化が時代と共に変われば再考する必要があります。 近年では、Notion がWebView中心の構成から Native へ移行してモバイル体験の改善に取り組み、ShopifyもAIコーディングツールの進化を背景に React Native から Native への回帰を発表しています。 notion.com shopify.engineering 技術選定においては、その選択を支えていた前提が、今も成り立っているかを問い続けること が大切だと感じます。 今回の開発や検証をを具体的にどう進めていったかについては、また別のメンバーの記事でご紹介したいと思っております。 また、Android側の進め方は、DroidKaigi 2026のポスターセッション 「FlutterからAndroidネイティブへ: Agentic Codingを活用したフルリライトの戦略と実践」 でも発表しています。 We are hiring! IVRyでは「イベントや最新ニュース、募集ポジションの情報を受け取りたい」「会社について詳しく話を聞いてみたい」といった方に向けて、キャリア登録やカジュアル面談の機会をご用意しています。ご興味をお持ちいただけた方は、ぜひ以下のページよりご登録・お申し込みください。 herp.careers ivry-jp.notion.site