ネイティブかクロスプラットフォームか：判断の基準

新しいアプリを開発するとき、最初に直面する技術的な問いのひとつが、プラットフォームごとに2本作るか、クロスプラットフォームフレームワークで1本作るかという点です。どちらの立場にも根強い意見があります。私たちは最初から特定の選択肢を推すことはしません。まずはプロダクトと、それを運用・保守するチームについていくつかの質問から始めます。

選択肢

ネイティブ開発とは、iOSアプリをSwiftで、AndroidアプリをKotlinで、それぞれ独自のツールとインターフェースフレームワークを使って構築することを意味します。React NativeやFlutterのようなクロスプラットフォームフレームワークでは、1つのコードベースを両方で動かせます。Kotlin Multiplatformはその中間に位置します。ビジネスロジックを共通化し、インターフェースは共有することも、プラットフォームごとにネイティブで書くこともできます。

ネイティブがコストに見合う場合

高度なカメラや音声処理、ウィジェットやウォッチ向けアプリ、システム機能へのディープリンク、負荷の高いグラフィックスなど、プラットフォームに深く依存するアプリではネイティブ開発が適しています。また、各プラットフォームに完全に馴染む操作感を持たせたい場合や、最新のOS機能をいち早く取り入れたい場合にも有効です。デメリットは2つのコードベースが必要になることで、通常はより多くの人員や期間、あるいはその両方が求められます。

クロスプラットフォームが強みを発揮する場合

画面、フォーム、リスト、ネットワーク通信がアプリの大半を占める場合は、クロスプラットフォームが理にかなっています。多くのビジネス向けアプリがこれに当てはまります。1つのコードベースなら、構築とテストを行う機能セットも1つで済み、両プラットフォームを同時にリリースできます。チームがすでにWeb向けにTypeScriptを書いているなら、React Nativeを使うことでそのスキルとコードの一部を再活用できます。

アプリだけでなくチームも見据える

最適な技術とは、リリース後にチームが維持管理できるものです。アプリを社内チームに引き継ぐ予定なら、彼らがすでに熟知している技術や、採用しやすい技術で構築しましょう。チームの誰も理解していないフレームワークは、ドキュメントに載っていない問題が起きた途端にリスクへと変わります。

ネイティブ側の作業も考慮しておく

クロスプラットフォームであっても、プラットフォーム固有のコードが完全に不要になることは稀です。プッシュ通知、アプリ内課金、バックグラウンドタスク、一部のデバイス機能には依然としてネイティブの設定が必要ですし、各ストアには固有のリリース手順があります。どのクロスプラットフォームプロジェクトでも、ある程度のネイティブ作業を見込んでおき、チーム内にそれに対応できる人を確保しておく必要があります。

ビジネスロジックの移植性を保つ

どちらのアプローチを選ぶにしても、料金体系、権限、計算などのプロダクトのルールは画面表示から切り離し、必要に応じてサーバー側に配置しましょう。これにより、テストが容易になり、プラットフォーム間の一貫性が保たれ、将来アプローチを変更することになった場合の手間も大幅に抑えられます。

まとめ

プラットフォームへの依存度が高いアプリならネイティブを、画面やデータ通信が中心ならクロスプラットフォームを選びましょう。どちらにしても、チームが今後何年も保守していける技術を選択することが大切です。どちらを選ぶかよりも、適切に作り上げることの方が重要です。