✍️ 필사 모드: クロスプラットフォームモバイル開発 2026 — React Native New Architecture / Flutter / KMP / Tauri / Lynx 徹底比較

プロローグ — 2026 年、五強の時代

2018 年のモバイルクロスプラットフォームは二強だった。React Native と Flutter。Cordova や Ionic が WebView 系のニッチを埋め、NativeScript は端に座っていた。

2026 年 5 月、風景はまるで違う。

• React Native は 0.76 から New Architecture(Fabric + TurboModules + Hermes)が既定になった。2026 年後半に React Native 1.0 が予告されている。
• Expo は事実上の RN 標準だ。SDK 52、Expo Router 4、EAS Build と EAS Update がなければ「RN をやっている」と言いづらい空気になった。
• Flutter 3.27 は全プラットフォームで Impeller レンダラを既定に有効化した。Skia 時代のジャンクは過去の話。
• Compose Multiplatform 1.7 + KMP 2.1 — iOS が正式 stable。Jetpack Compose を iOS でそのまま動かす時代になった。
• Tauri 2 Mobile が beta に入った。Rust とシステム WebView の組み合わせで 30MB 未満のバンドルを狙う。
• Lynx — 2025 年 3 月に ByteDance がオープンソース化した新フレームワーク。TikTok・Lark・Douyin が社内で使っていたものだ。

五強である。その横で Capacitor 7、.NET MAUI、NativeScript が自分の席を守る。

本稿は 2026 年のモバイルクロスプラットフォーム地図を — 5 つのモデルから、韓国・日本企業の実例まで — 一息にまとめる。

1. 2026 年のクロスプラットフォーム地図 — 五強

まず五強を一つの表に並べる。数値は npm、pub.dev、Maven Central のダウンロード数および GitHub スター(2026 年 5 月時点)。

隣の三候補。

覚えておく一行: 「レンダリングモデルはそのまま性格である」。システム WebView は速く作れ、native render は一貫し、独自レンダラはピクセルまで制御する。

2. モバイルクロスプラットフォームの 4 モデル(今や 5 つ)

クロスプラットフォームは結局 「ネイティブ UI をどう描くか」 の問題に行き着く。5 つの道。

1) WebView モデル — Capacitor / Cordova / Tauri Mobile

iOS の WKWebView と Android の WebView の上に Web アプリを載せる。カメラ・Bluetooth・プッシュなどの OS 機能はネイティブプラグインが JS ブリッジで公開する。

• 利点 — Web 開発者がそのままモバイルを作れる。バンドルが小さい。ホットアップデートが自由(ストア回避は別途のポリシー問題)。
• 欠点 — 60fps のインタラクションが難しい。iOS WKWebView のメモリ・キーボードの癖。App Store が「ただの WebView ラッパー」を拒否する例が増えた。

2) Native Bridge モデル — React Native(旧アーキテクチャ)/ NativeScript

JS エンジンが別途動き、ネイティブ UI(UIView / View)は別に存在する。両者を JSON メッセージキュー でつなぐ。

• 利点 — UI は本物のネイティブコンポーネント、つまり OS アップデートに自動で追随する。
• 欠点 — ブリッジが非同期 + シリアライズなので大きなリストやアニメーションでジャンク。New Architecture がこれを解く。

3) Native Render モデル — React Native New Architecture / .NET MAUI

JS は依然として別途動くが、JSI(JavaScript Interface)で 同期呼び出し が可能になり、Fabric が C++ レイヤーでネイティブビューツリーを直接構築する。

• 利点 — 本物のネイティブコンポーネント + 同期呼び出し + concurrent rendering。
• 欠点 — マイグレーションコスト。旧アーキテクチャ向けのライブラリが一部残っている。

4) 独自レンダラモデル — Flutter / Compose Multiplatform(iOS)

OS のネイティブ UI を使わない。Skia / Impeller のようなグラフィックスライブラリですべてのピクセルを自前で描く。iOS のボタンも Android のボタンもすべて Flutter が描くボタンだ。

• 利点 — ピクセル単位の一貫性。一つのコードがすべての OS で同じに見える。
• 欠点 — OS の UI 進化(Material You アップデート、Dynamic Type、アクセシビリティ)を自前で追わなくてはならない。

5) デュアルスレッド + 独自レンダラ — Lynx

ByteDance の新モデル。JS スレッド(メインビジネスロジック)とは別に UI スレッドを持ち、最初のフレームを同期で描く。RN の Fabric に似ているが、メインスレッドを空けることにより積極的だ。

覚えておく一行: 「WebView は速く作れ、Native Render は一貫し、独自レンダラはピクセルまで制御する」。

3. React Native New Architecture — 0.76 から既定

2024 年 10 月の 0.76 リリースが転換点だった。New Architecture が既定で有効化 され、それ以降のすべての新規プロジェクトは自動で Fabric + TurboModules + Hermes のセットアップになる。

3 つの部品の役割を分けて見る。

Hermes — JS エンジン

Facebook が作った JS エンジン。RN 0.70 から既定で、2026 年現在では事実上 RN の標準エンジン。

• AOT バイトコード — ビルド時に JS を Hermes バイトコードへコンパイル。起動が速い。
• メモリ使用量が V8 / JSC より低い。
• デバッガ — Chrome DevTools が直接 Hermes に接続できる。

JSC(JavaScriptCore)は互換のため残っているが、新規プロジェクトの推奨は Hermes。V8 は Android のみオプションで利用可能(バンドルが大きくなる)。

JSI — JavaScript Interface

JS とネイティブをつなぐ 新しい橋。要点は二つ。

• ブリッジではなく C++ HostObject — JS から見えるオブジェクトの正体は C++ メモリだ。
• 同期呼び出し が可能 — 以前はすべての呼び出しが非同期 JSON メッセージだった。

// JSI 上で同期に動く呼び出し (TurboModule)
import { NativeModules } from 'react-native'
const { CryptoModule } = NativeModules

// 以前: 常に非同期
// const hash = await CryptoModule.sha256(input)

// 現在(TurboModule + JSI): 同期可能
const hash = CryptoModule.sha256Sync(input)

TurboModules — ネイティブモジュールインターフェース

CodegenSchema で TypeScript 型から C++ / Java / Obj-C インターフェースを自動生成する。旧 NativeModules のランタイム動的ディスパッチがコンパイル時 type-safe へと変わった。

// specs/NativeCrypto.ts
import type { TurboModule } from 'react-native'
import { TurboModuleRegistry } from 'react-native'

export interface Spec extends TurboModule {
  sha256(input: string): string
  randomBytes(length: number): string
}

export default TurboModuleRegistry.getEnforcing\<Spec\>('Crypto')

この 1 ファイルから Android(Java / Kotlin)と iOS(Obj-C / Swift)のインターフェースコードが自動生成される。

Fabric — 新 UI マネージャ

C++ レイヤーが React ツリーを受け取り、ネイティブビューツリーを直接構築する。

• Concurrent rendering — React 18 の Suspense と startTransition が RN でちゃんと動く。
• Shadow tree 同期 — レイアウト計算が一つのツリーで完結する(以前は JS、Shadow、Native が別々に持っていた)。
• Synchronous events — スクロールとタッチがメインスレッドで同期処理され、ジャンクが減る。

マイグレーションチェックリスト

# 0.76+ の新規プロジェクト
npx @react-native-community/cli@latest init MyApp  # New Arch が自動で有効

# 既存プロジェクトのマイグレーション
# 1. RN 0.76+ へアップグレード
npx react-native upgrade

# 2. iOS の Podfile
# RCT_NEW_ARCH_ENABLED=1 npx pod-install

# 3. Android の gradle.properties
# newArchEnabled=true

# 4. 非対応ライブラリの点検
npx react-native doctor

4. Expo SDK 52 + Expo Router 4 — 事実上の標準

「bare RN で始める」という話は 2026 年にはほとんど聞かない。Expo が RN の標準セットアップ になった。理由は三つ。

1. EAS Build — ローカル Xcode 不要のクラウドビルド。iOS 証明書とプロビジョニングまで管理。
2. EAS Update — JS・画像・小さなアセットの OTA アップデート。App Store 回避ではなく「バグ修正を早く届ける」ためのもの。
3. Expo Router 4 — ファイルベースのルーティングがネイティブアプリにそのまま。Next.js の app/ ディレクトリがモバイルに来た感覚。

Expo Router 4 — ファイルベースルーティング

app/
├── _layout.tsx              # ルートレイアウト (Tab/Stack)
├── (tabs)/
│   ├── _layout.tsx          # タブレイアウト
│   ├── index.tsx            # /
│   ├── feed.tsx             # /feed
│   └── profile.tsx          # /profile
├── post/
│   └── [id].tsx             # /post/123 (動的ルート)
├── modal.tsx                # /modal (ネイティブモーダル)
└── +not-found.tsx           # 404

// app/_layout.tsx
import { Stack } from 'expo-router'

export default function RootLayout() {
  return (
    <Stack>
      <Stack.Screen name="(tabs)" options={{ headerShown: false }} />
      <Stack.Screen name="modal" options={{ presentation: 'modal' }} />
    </Stack>
  )
}

// app/post/[id].tsx
import { useLocalSearchParams } from 'expo-router'
import { Text, View } from 'react-native'

export default function PostScreen() {
  const { id } = useLocalSearchParams\<{ id: string }\>()
  return (
    <View>
      <Text>Post {id}</Text>
    </View>
  )
}

要点は二つ。

• タイプセーフリンク — expo-router がルートの型を自動生成する。誤ったルートはコンパイル時にエラー。
• ディープリンクが無料 — /post/123 という URL がそのままアプリ内で動作する。Web、iOS、Android が同じルートツリーを見る。

EAS Build — クラウドビルド

// eas.json
{
  "cli": { "version": ">= 13.0.0" },
  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal"
    },
    "preview": {
      "distribution": "internal",
      "ios": { "simulator": false }
    },
    "production": {
      "autoIncrement": true
    }
  },
  "submit": {
    "production": {}
  }
}

eas build --platform ios --profile production
eas submit --platform ios --latest

この 2 行で App Store まで届く。Xcode は一度も開かない。

EAS Update — OTA

# コードだけの小さな変更
eas update --branch production --message "Fix login crash"

ネイティブモジュールに触れない変更なら、ストアレビューなしでユーザーに届く。App Store ガイドラインを守る限りは合法だ(主要機能の変更や UI の全面リニューアルは正式ビルドを推奨)。

5. Flutter 3.27 + Impeller — 独自レンダラ戦略

Flutter は最初から違う道を歩いた。OS のネイティブ UI を使わない。 Skia(現在は Impeller)ですべてのピクセルを自前で描く。

Impeller — Skia を置き換えた新レンダラ

2024 年までは Skia + GPU シェーダコンパイルという 2 段階のせいで最初のフレームにジャンクがあった。Impeller はその問題を解いた新しいレンダラだ。

• シェーダの事前コンパイル — ビルド時に GPU シェーダを全部コンパイルして同梱する。ランタイムコンパイルのジャンクが消えた。
• Metal(iOS)/ Vulkan(Android) バックエンドを既定で使う。OpenGL ES はフォールバック。
• Flutter 3.27 から iOS と Android の両方で既定。

Material You 3 + Cupertino

import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        colorSchemeSeed: const Color(0xFF6750A4),
        useMaterial3: true,
        brightness: Brightness.light,
      ),
      darkTheme: ThemeData(
        colorSchemeSeed: const Color(0xFF6750A4),
        useMaterial3: true,
        brightness: Brightness.dark,
      ),
      home: const HomeScreen(),
    );
  }
}

class HomeScreen extends StatelessWidget {
  const HomeScreen({super.key});

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: const Text('Hello Flutter 3.27')),
      body: const Center(child: Text('Material You 3 + Impeller')),
      floatingActionButton: FloatingActionButton(
        onPressed: () {},
        child: const Icon(Icons.add),
      ),
    );
  }
}

useMaterial3: true と colorSchemeSeed の 1 行で Material You のカラーシステムが自動で適用される。ライト・ダーク・トーンマッピング・アクセシビリティコントラストまで自動。

独自レンダラというアイデンティティ

利害を明確にする。

• 利点 — Android・iOS・Web・デスクトップがピクセル単位で同一。デザイナーのピクセルパーフェクトが実際に動く。
• 欠点 — OS の UI 進化(iOS Dynamic Island のような)に自前で対応する必要がある。アクセシビリティも OS への委譲ではなく自前実装。

Flutter の道は 「OS と違う道を行ってでも一貫性を守る」 だ。ゲーム・メディア・ブランド色が強いアプリに合い、OS のルック&フィールをそのまま追うべきアプリには違和感が出るかもしれない。

6. Compose Multiplatform 1.7 / KMP 2.1 — iOS 正式 stable

2024 年までは Compose Multiplatform の iOS は「alpha」だった。2025 年 Q2 に 1.6 で beta、2026 年 Q1 に 1.7 で stable。意味するところは大きい。

Jetpack Compose で書いたコードが iOS でそのまま動く。

KMP — 共有の自由度

Kotlin Multiplatform の核は 「共有範囲を自由に選べる」。3 つの選択。

1. ロジックだけ共有 — ネットワーク・DB・ドメインを KMP、UI は SwiftUI(iOS)と Compose(Android)。最も保守的で、最も多く使われるパターン。
2. ロジック + UI の一部 — 共通画面は Compose Multiplatform、プラットフォーム特化画面はネイティブのまま。
3. すべて共有 — 100% Compose Multiplatform。Flutter のような独自レンダラ(iOS は Skiko = Skia for Kotlin)。

// shared/src/commonMain/kotlin/UserRepository.kt
class UserRepository(private val api: UserApi, private val db: UserDb) {
    suspend fun getUser(id: String): User {
        return db.findById(id) ?: api.fetch(id).also { db.insert(it) }
    }
}

// shared/src/commonMain/kotlin/App.kt
@Composable
fun App() {
    MaterialTheme {
        var name by remember { mutableStateOf("World") }
        Column {
            TextField(value = name, onValueChange = { name = it })
            Text("Hello, $name!")
        }
    }
}

// iOS アプリ側からの呼び出し
import shared
import SwiftUI

struct ContentView: View {
    var body: some View {
        ComposeView()  // Compose UI を SwiftUI に埋め込む
    }
}

KMP 2.1 の新しさ

• K2 コンパイラ が既定 — コンパイル速度が約 2 倍。
• expect/actual がさらに安定し、プラットフォーム特化実装がきれい。
• Native ターゲット が Apple Silicon ビルドをさらに高速化。

Compose Multiplatform iOS — 現在地

• iOS Stable — プロダクション推奨。
• Skiko レンダリング — Skia ベース(Flutter の Skia と同じライブラリ、別の統合)。
• アクセシビリティ — VoiceOver 対応が 1.7 で大幅に改善(まだ SwiftUI と 100% 同等ではない)。
• テキスト入力 — iOS のキーボードと IME が安定してきたが、韓国語 IME に時折ぎこちなさがある。

覚えておく一行: 「KMP は logic から始めて段階的に UI まで伸ばす道を与える」。

7. Tauri 2 Mobile — Rust + システム WebView の新しい挑戦

Tauri はデスクトップ(Windows / macOS / Linux)で Electron の代替として定着した。30MB 未満のバンドル、1/5 のメモリ が売りだった。2024 ～ 2025 年に Mobile が alpha → beta へ進んだ。

構造 — Rust コア + システム WebView

• iOS — WKWebView の上に Web フロント(React / Vue / Svelte / Solid)。
• Android — WebView(Chromium)の上に同じフロント。
• Rust コア — ネイティブ機能を Rust で書き、IPC で公開する。

// src-tauri/src/lib.rs
#[tauri::command]
fn greet(name: &str) -> String {
    format!("Hello, {}!", name)
}

#[cfg_attr(mobile, tauri::mobile_entry_point)]
pub fn run() {
    tauri::Builder::default()
        .invoke_handler(tauri::generate_handler![greet])
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
}

// フロント(React)側
import { invoke } from '@tauri-apps/api/core'

const greeting = await invoke\<string\>('greet', { name: 'YJ' })

Tauri 2 Mobile の強みと弱み

• 強み — Android で 6 ～ 8MB のバンドル、セキュリティ(自動 CSP と権限マニフェスト)、Rust バックエンド(高速 IO、暗号、DB アクセス)。
• 弱み — UI 性能は結局システム WebView 次第。60fps のゲームや複雑なアニメーションには不向き。iOS 17 以前の互換性に一部の癖。

誰が使っているか

2026 年現在、Tauri Mobile は prosumer ツール — セキュアキーマネージャ、ローカルノートアプリ、開発者ユーティリティ — での採用が増えている。TikTok 級のコンシューマアプリではまだ稀。

8. Capacitor 7 vs Cordova — Web ファーストの現在

Web ファーストモバイルの 2 強だった。Cordova は 2024 年にメジャー更新が事実上停止 し、Apache Cordova プロジェクトは retire トラックに入った。Web ファーストの座は事実上 Capacitor 7 (Ionic チームが作る)が占めた。

Capacitor 7 の要点

• iOS の WKWebView と Android の Chromium WebView の上に Web アプリ。
• Capacitor Plugins — カメラ・Bluetooth・プッシュ・ファイルなどのネイティブ機能を JS API として公開。
• Ionic Framework が上に乗る UI キット(必須ではない。React / Vue / Angular のどれでも可)。

// Capacitor のカメラ利用
import { Camera, CameraResultType } from '@capacitor/camera'

const takePhoto = async () => {
  const photo = await Camera.getPhoto({
    quality: 90,
    allowEditing: false,
    resultType: CameraResultType.Uri,
  })
  return photo.webPath
}

# 基本セットアップ
npm install @capacitor/core @capacitor/cli
npx cap init
npx cap add ios
npx cap add android
npm run build
npx cap copy
npx cap open ios

誰が使っているか

• PWA を素早くアプリ化 — 既存の React / Vue アプリがあり、1 ～ 2 週間でストア掲載が必要なとき。
• エンタープライズの LOB アプリ — 社内ツール。性能要求が低く、素早いデプロイが重要なとき。
• ハイブリッド EC — チェックアウトだけネイティブ、その他は Web。

App Store が「ただの WebView ラッパー」を拒否する事例が増えたので、Capacitor を使うときは 「ハイブリッドの価値」 — ネイティブ機能の積極利用、オフライン動作、アプリらしいインタラクション — を見せる必要がある。

9. Lynx(ByteDance)— TikTok の社内フレームワークのオープンソース化

2025 年 3 月、ByteDance が Lynx をオープンソースとして公開した。社内で TikTok・Lark・Douyin といった巨大アプリが使っていたクロスプラットフォームフレームワークだ。意味は大きい。

なぜ新フレームワークなのか

RN と Flutter があるのになぜ? ByteDance の公式説明をざっくり言えば。

• メインスレッドの保護 — TikTok のような無限スクロール・短い動画アプリでは、最初のフレームを同期で描くことが核となる。RN の Fabric も良いが、もっと積極的にメインスレッドを空けたかった。
• デュアルスレッドモデル — メインスレッド(UI 同期レンダリング)とバックグラウンドスレッド(JS ロジック)を分離。最初のフレームが同期で描かれる。
• PrimJS — Lynx 専用の JS エンジン(QuickJS ベースのフォーク)。Hermes に似た AOT バイトコード方式。

Lynx の 1 行コード

import { View, Text, Image } from '@lynx-js/react'

export default function App() {
  return (
    <View style={{ padding: 20 }}>
      <Text style={{ fontSize: 24 }}>Hello Lynx</Text>
      <Image src="https://example.com/cat.jpg" style={{ width: 100, height: 100 }} />
    </View>
  )
}

表面上は RN とほぼ同じ JSX とコンポーネントモデル。違いは内部にある。

何が違うか

• 最初のフレームを同期で — List が最初に描かれるとき、メインスレッドで同期にレイアウトとペイント。
• Atomic CSS — Tailwind に似た atomic CSS が一級市民。ビルド時に事前処理。
• Rust コア — 一部の critical path が Rust で書き直されている。

誰のためのツールか

ByteDance が自社アプリ(TikTok 級)のために作った。つまり 巨大トラフィック + 無限スクロール + 短い動画 に特化しているということだ。一般的な SaaS・EC・生産性アプリでは RN / Flutter が依然として安全な選択。

オープンソース化の本当の意味は 「RN / Flutter では届かないケースがある」 という公的な認知と、TikTok 級のノウハウの外部流出 だ。2026 年後半 ～ 2027 年に誰が続くかが見どころ。

10. .NET MAUI / NativeScript — その他のオプション

五強の他に二つの選択肢が自分の席を守る。

.NET MAUI — Microsoft の答え

Xamarin.Forms の後継。C# + XAML で iOS・Android・Windows・macOS を 1 つのコードベースから。

<!-- MainPage.xaml -->
<ContentPage xmlns="http://schemas.microsoft.com/dotnet/2021/maui">
  <VerticalStackLayout>
    <Label Text="Hello, MAUI!" FontSize="32" />
    <Button x:Name="CounterBtn" Text="Click me" Clicked="OnCounterClicked" />
  </VerticalStackLayout>
</ContentPage>

• 強み — Visual Studio 統合、.NET 陣営のライブラリそのまま、エンタープライズの SSO / Active Directory を 1 行で。
• 弱み — モバイルファーストの設計ではなく、Xamarin の遺産が残る。コミュニティの勢いは RN / Flutter に及ばない。

NativeScript — 生存中

Telerik 時代から生き残った。TypeScript / Vue / Svelte / Angular で本物のネイティブ UI(UIView / View)を直接扱う。

• 強み — JS から iOS と Android の API をほぼそのまま呼び出せる(ブリッジコードなしで)。
• 弱み — コミュニティが小さい。RN の New Architecture 以降、差別化が薄くなった。

2026 年 5 月時点で NativeScript は 「RN 以前の時代へのノスタルジー」 が主な理由で使われている。新規プロジェクトなら RN / Flutter / KMP が先に検討される。

11. どのフレームワークを選ぶか — 意思決定マトリックス

五強と二つの追加オプションをチーム・プロダクト・デザイン・バンドルサイズで並べる。

チーム軸

プロダクト軸

デザイン軸

バンドルサイズ軸

バンドルサイズは 空アプリ 基準だ。実アプリは画像・フォント・ライブラリで 2 ～ 3 倍に膨らむ。100MB を超えると App Store の cellular ダウンロード制限に引っかかり 4G / 5G での自動ダウンロードができなくなる。

12. 韓国・日本のモバイルエコシステム — 実際は何を使っているか

理論の表は意思決定の出発点で、現実は別物だ。韓国と日本の大手企業が 2026 年 5 月時点で実際に何を使っているかをまとめる(公開された採用ページ、技術ブログ、カンファレンス発表ベース)。

韓国

• Kakao — Android は Kotlin + Jetpack Compose、iOS は Swift + SwiftUI。一部の社内ツールや新規サービスで KMP(logic だけ共有) の事例が増えている。RN は社内ツールやイベント系のミニアプリ。
• Naver — 同じ方向性。コアアプリはネイティブ(Swift / Kotlin)、検証段階のサービスで RN / Flutter の採用ページが出る。
• Coupang — RN 採用が最も積極的。検索やリスト画面の一部が RN で動いていることが知られている。Hermes 上で動作。
• Toss — メインは iOS Swift と Android Kotlin。一部の社内・運用ツールで RN。
• Daangn (Karrot) — Flutter の採用が最も目立つ。一部のサービス(中古 + 地域コミュニティ)で Flutter を採用。
• Baemin (Woowa Brothers) — ネイティブ中心。一部の新規実験で Flutter。

日本

• メルカリ(Mercari) — Android チームが KMP の事例をカンファレンスで何度も共有。iOS は Swift、Android は Kotlin がメインで、共有はビジネスロジックだけを KMP に切り出すパターン。
• CyberAgent — 子会社が多くスタックは多様。AbemaTV は RN / Flutter の履歴なしのネイティブ。一部の子会社で Flutter。
• DeNA — ゲーム・エンタメは Unity やネイティブ。一般アプリは Swift + Kotlin。
• LINEヤフー(LINE Yahoo Japan) — LINE アプリ本体はネイティブ。一部のミニアプリやキャンペーンページで WebView。
• PayPay — ネイティブ中心。RN / Flutter の痕跡は少ない。
• freee / SmartHR / Money Forward — SaaS 陣営。モバイルアプリは RN と Flutter が混在し、新規プロジェクトで Flutter 採用が増えている。

二つの市場に共通するパターン

• コアアプリは依然としてネイティブ — スーパーアプリ級(KakaoTalk、LINE、PayCo)はほぼ全部 Swift + Kotlin。
• 新規・実験的サービスで RN / Flutter — 新規ドメイン、ミニアプリ、社内ツール。
• KMP が静かに増えている — UI まで踏み込まずビジネスロジックの共有から始めるパターン。メルカリと Kakao の事例が代表的。
• Compose Multiplatform の本格採用はまだ保守的 — iOS stable が 2026 年 Q1 のため、本格的な採用は 2026 年後半 ～ 2027 年に見えてくるだろう。

含意

大企業は 「リスク < コード共有の利益」 のときだけクロスプラットフォームを使う。中核ユーザー体験がかかったアプリではネイティブを維持し、新機能・実験・社内ツール でクロスプラットフォームを検証する。KMP の logic-only 共有はその検証への最も安全な入り口だ。

まとめ — チェックリストとアンチパターン

意思決定チェックリスト

1. チームの主力言語は何か?(TS / Dart / Kotlin / Swift / C#)
2. UI 基準は OS 標準か、ブランドのピクセルパーフェクトか?
3. 主要画面は 60fps の動画と複雑なアニメーションか、フォームとリスト中心か?
4. バンドルサイズの上限はあるか?(App Store の cellular キャップは 200MB)
5. App Store / Play Store のレビュー速度と OTA アップデートのバランスは?
6. 既存の Web 資産はあるか?(Capacitor / Tauri の価値)
7. セキュリティ要件は?(Tauri の Rust バックエンド、または RN のセキュリティライブラリ)
8. 5 年後のコード保守者は誰か?

アンチパターン 10 個

1. RN 0.76+ で New Architecture を無効化 したまま運用する(不要な非対称)。
2. Expo で始めておきながら eject して後悔。
3. Flutter で iOS のネイティブルック&フィールを真似ようとして 時間を浪費。
4. KMP の UI 共有 を stable 到達前(2025 年以前)にプロダクション導入した先行事例を踏襲してしまう。
5. Capacitor の上に 60fps のゲームアニメーションを押し込もうとする。
6. Tauri Mobile を TikTok 級コンシューマアプリ に適用しようとする。
7. Lynx を 社内ツール のような小さなアプリに導入する(過剰なツール)。
8. JS エンジンを JSC に固定 したまま Hermes 移行をしない。
9. EAS Update を 主要 UI の全面リニューアル に使い、App Store ガイドライン違反のリスクを冒す。
10. .NET MAUI を モバイルファーストデザイン のアプリに選んでデスクトップパターンを強要する。

次回予告

候補: React Native New Architecture のマイグレーション実践 — 0.74 → 0.76 段階別ガイド、KMP logic-only 共有で SwiftUI / Compose を両方生かす、Flutter Impeller のシェーダデバッグ — ジャンクを潰す方法。

「クロスプラットフォームは、一つのコードで二つの OS を同時に作る魔法ではなく、どのコストをどこへ移すかという交渉である。」

— クロスプラットフォームモバイル開発 2026、了。

参考 / References

• React Native 公式
• React Native 0.76 New Architecture ブログ
• Hermes エンジン
• Expo 公式
• Expo SDK 52 リリースノート
• Expo Router ドキュメント
• EAS Build ドキュメント
• Flutter 公式
• Flutter Impeller レンダラ
• Material You 3 ガイド
• Kotlin Multiplatform 公式
• Compose Multiplatform 公式
• Tauri 公式
• Tauri 2 Mobile ガイド
• Capacitor 公式
• Ionic Framework
• Lynx 公式サイト
• Lynx GitHub
• .NET MAUI 公式
• NativeScript 公式
• メルカリ Engineering ブログ(KMP 事例)
• Kakao Tech ブログ