#なぜ今日これを選んだか

自分のアプリ（FORGE・可動域の記録アプリ）はSwiftUIで書いていて、カメラや姿勢推定などOS固有の機能が中心にある。「クロスプラットフォームで1本にまとめる」誘惑とどう付き合うかは避けて通れない。実際に移行した会社が理由と数字を出しているので、判断の材料として読んだ。

#要点

• 通話処理はもともとほぼ全部Swift/Kotlinにあり、Flutterは主にWebViewのUIラッパーだった。FlutterとNativeの間のPlatform Channelsは約50件あり、着信イベントがOS・Native・Flutterを行き来して問題の切り分けが難しかった
• PoCでは、Androidのコールドスタート（起動〜初期画面表示）の中央値が192.5msから49.6msになった。ただし差のすべてがPlatform Channels由来ではないと記事自身が断っている
• 移行を後押ししたのはAIコーディングの進化。2つのOSで別々に書くコストが下がり、Nativeは公式ドキュメントが豊富でAIとの相性もいい。一方、リリース・運用・OSごとの設計のコストは増える

#自分にとっての示唆

技術選定は一度決めたら終わりではなく、「その選択を支えていた前提が今も成り立つか」を問い続けるもの、という主張が刺さった。可動域アプリはVision/カメラというOSの中心機能が本体なので、Nativeで書いている今の選択は筋が通っている。Androidが必要になった時も、境界を50件抱えるより、AIに手伝わせてKotlinで別に書く方が安い可能性がある。明日からは、可動域アプリで「OSの機能に近いところ」と「計算だけのところ」を分けて書き、計算部分はプラットフォームに依存しない純粋な関数として保つ。どちらに転んでも作り直しが小さくて済む。

原文を読む →