ネイティブ vs クロスプラットフォームのモバイル開発：アプリの開発手法の選び方

このガイドは、チームへのブリーフィングや見積もりの比較を行う前に、アプリの開発手法を決定しなければならないファウンダー、プロダクトオーナー、CTOを対象としています。モバイルプロダクト開発ガイドでは、ディスカバリーからスケールまでの全工程（バックエンドとストアリリースを含む）を網羅していますが、このページでは1つの意思決定に絞り、より深く掘り下げます。

このガイドの内容

• 2択ではなく4つの選択肢
• 各手法の比較
• 手法を決定する6つの問い
• 初回リリース以降の総所有コスト
• 後から手法を切り替える
• AI機能と手法の選択
• セキュリティとストアのルールはすべての手法に適用される
• Netbase JSCはどのようにアプリを開発しますか？
• 存在する納品実績と存在しないもの
• このガイドの限界は何ですか？
• よくある質問
• 次のステップ

2択ではなく4つの選択肢

この問いはネイティブかクロスプラットフォームかという形で語られることが多いですが、実際には4つの選択肢から選ぶことになります。

• 2つのネイティブアプリ。 iOS向けのSwiftアプリと、Android向けのKotlinアプリをそれぞれのプラットフォーム固有のツールとUIコンポーネントで開発します。
• 1つのクロスプラットフォームコードベース。 1つのアプリを一度書いて両プラットフォームで動作させます。React Nativeは「JavaScriptで記述し、ネイティブコードでレンダリングする」と自己説明しており、画面はプラットフォーム固有のUIコンポーネントを使用します。Flutterは「単一のコードベース」からマルチプラットフォームアプリを構築し、独自のインターフェースを描画します。
• 共有ロジック＋ネイティブ画面。 ビジネスロジック、ネットワーク処理、データ管理を一度書く一方で、各プラットフォームは独自のインターフェースを維持します。Kotlin Multiplatformでは、インターフェースを共有するレベルと並んで、共有レベルの1つとしてこれを説明しています。
• モバイルWebまたはプログレッシブウェブアプリ（PWA）。 ホーム画面にインストールでき、ブラウザの制約内でオフライン動作も可能なレスポンシブウェブサイトです。web.devでは、これらを「Webで構築・デプロイされる」アプリ体験として説明しています。

各手法はある製品にとっては最適な答えです。製品要件を整理する前に、習慣やフレームワーク論争から1つを選んでしまうことが誤りです。

各手法の比較

ネイティブ画面と共有ロジックの組み合わせは、インターフェースとデバイスアクセスの面ではネイティブ列に相当し、ビジネスロジックはクロスプラットフォーム列に近づきます。ロジックの重複は減りますが、2つのインターフェースは依然として開発が必要です。

初回リリース以降の総所有コスト

初回リリースの見積もりは手法間の単純な比較が難しく、ローンチ後にコストが変化するからです。

• 2つのネイティブアプリは開発コストが高く、その後の機能追加作業もおおよそ倍になりますが、プラットフォームの更新がサードパーティのレイヤーを壊すリスクは最も低くなります。
• クロスプラットフォームは機能開発の重複作業のほとんどを省けますが、フレームワークのアップグレード、プラグインの保守、ネイティブ修正が時折発生します。毎年その時間を計画に入れておきましょう。
• 共有ロジックはビジネスロジックとテストの重複を省けます。これはバグが多い部分でもありますが、インターフェースの作業は倍のままです。
• モバイルWebは運用コストが最も低いですが、本来アプリが必要だった場合は機能、ユーザー継続率、ストアでの露出を失うことになります。

Netbase JSCはモバイルアプリの個別タイムラインを公開していません。SaaS MVPの標準的な範囲は8〜12週間であり、独自バックエンドを持ち両プラットフォームに対応するモバイルプロダクトは、既存APIを使用するシングルプラットフォームアプリよりも範囲の上位に位置します。SaaS MVPアーキテクチャと納品ロードマップでは、その初回リリーススコープがどのように固定されるかを説明しています。これらは標準的な範囲であり、見積もりではありません。

後から手法を切り替える

手法は永続的なものではありませんが、切り替えには時間がかかります。

• モバイルWebからアプリへ。 一般的な移行パスです。バックエンドとAPIを最初からモバイル向けに設計しておけば、アプリは書き直しではなく新しいクライアントとなります。
• クロスプラットフォームからネイティブへ。 通常は画面ごとに行い、デバイス機能を最も必要とする画面から始めます。インターフェースとビジネスロジックの明確な分離が実現を可能にします。
• 2つのネイティブアプリから共有ロジックへ。 ロジック、ネットワーク処理、データを1モジュールずつ移行します。インターフェースはそのまま維持されます。

どの手法を選ぶにしても、WebサイトとアプリとパートナーシステムのためにAPIを1つに統一し、アプリストアのアカウントを自社名義で管理し、サポートする最小アプリバージョンを記録しておきましょう。バックエンド側についてはモバイルアプリのバックエンド・API・オフライン同期で、ローンチ後のパッチ・セキュリティ・リリースのリズムについてはモバイルアプリの保守・セキュリティ・リリース運用で説明しています。

セキュリティとストアのルールはすべての手法に適用される

セキュリティはフレームワークよりも、その周辺の開発プラクティスに依存します。OWASP Mobile Application Security Verification Standard（MASVS）は、ストレージと暗号化からネットワーク通信と耐障害性まで管理策をグループ化しており、ネイティブとクロスプラットフォームのアプリいずれにも適用されます。AppleのApp Review GuidelinesとGoogle Playのポリシーは、開発手法にかかわらず、各ストアのすべてのアプリに適用されます。Netbase JSCのセキュリティプラクティスは、セキュアコードレビューとバージョン管理、転送中のTLSと保存時のAES暗号化、ロールベースアクセス制御と管理ダッシュボードのMFAをカバーしています。

Netbase JSCはどのようにアプリを開発しますか？

Netbase JSCはReact Nativeでクロスプラットフォームアプリを開発し、機能が要求する場合はネイティブを選択します。React Nativeの開発者は長年にわたって採用してきた役職の1つです。3〜30名のチームは、ビジネスアナリスト、プロジェクトマネージャー、ソリューションアーキテクト、開発者、QA、UI/UXデザイナーで構成され、ディスカバリー後通常1〜2週間以内に作業を開始します。Netbase JSCのプロジェクトのほとんどはディスカバリー後に合意された請負契約で納品され、カスタム開発においてはクライアントがそのために作成されたIPを所有します。モバイルアプリ開発サービスではエンゲージメントの詳細を、フロントエンド・モバイルテクノロジーページではより広いスタックを説明しており、再利用可能なビルディングブロックが製品に適合する場合はモバイルプロダクトアクセラレーターが出発点となります。Netbase JSCの受賞歴には、Top Mobile App Developers 2020、Clutchのバッジがあります。

存在する納品実績と存在しないもの

• 存在するもの。 Dey Pageの実績では、iOSとAndroid向けの1つのReact Nativeコードベースと、Webディレクトリのバックエンドをベースにしたコンシューマーモードとビジネスオーナーモードの両方を説明しています。RB Marketplaceの実績では、Android向けにマーケットプレイスAPIを使用した顧客向けショッピングアプリを説明しており、iOSは拡張スコープに含まれています。
• 存在しないもの。 いずれの実績もダウンロード数、評価、使用状況、パフォーマンス、コストの数値を公開しておらず、RB Marketplaceの実績はフレームワーク名を記載していないため、いずれも一方の手法がより安価または高速であることの証拠として提示しているわけではありません。同一製品のネイティブとクロスプラットフォームの両方を比較した実績はありません。

このガイドの限界は何ですか？

• フレームワークに関する記述は、アクセス日時点での各フレームワーク自身のドキュメントに基づいています。フレームワークは急速に変化するため、決定前に最新バージョンを確認してください。
• ここでのコスト比較は方向性を示すものです。公表されているコスト削減率はソースと手法によって異なり、いずれもNetbase JSCの数値として使用していません。
• この基準はビジネス・コマース・コンテンツ系アプリに適しています。ゲームやハードウェア製品には独自の分析が必要です。

次のステップ

アプリが実現すべき機能、必要なプラットフォーム、接続すべきシステムをご共有ください。ソリューションレビューを予約し、手法を一緒に評価します。モバイルアプリ開発のページもご覧いただけますし、Netbase JSCのインサイトも参照できます。

関連サービスとソリューション