モバイルアプリに関する議論
はじめに
モバイルアプリと HTML5 は、現在最も注目されている 2 つのテクノロジーであり、多くの共通点があります。ウェブアプリはモバイル ブラウザで実行され、さまざまなモバイル プラットフォームでネイティブ アプリとして再パッケージ化することもできます。サポートするプラットフォームの幅広さとモバイル ブラウザの強力な機能により、デベロッパーは HTML5 を「一度書けばどこでも実行できる」ソリューションとして利用しています。しかし、本当に実現可能なのでしょうか？ネイティブを選択する魅力的な理由がまだ存在し、多くのデベロッパーが実際にそのルートを選択しています。この記事では、ネイティブとウェブのどちらを選択すべきかについて議論します。
機能の豊富さ
主張: ネイティブはより多くのことができる
モバイル機能は、アプリ自体のエクスペリエンスと、デバイスのエコシステムとの連携方法という 2 つの側面に分けることができます。たとえば、Android の場合、ウィジェットや通知などの機能がこれに該当します。ネイティブはどちらの側面でも優れています。
アプリのエクスペリエンスに関して言えば、ネイティブ アプリはより多くのことができます。スワイプ イベントやマルチタッチを簡単に取得できます（対応しているプラットフォームの場合）。 通常、Android の検索ボタンや音量調節ボタンなどのハードキーが押されたときに動作します。GPS やカメラなどのハードウェアにもアクセスできます。ユーザーの許可を得て、一部のプラットフォームではオペレーティング システムに無制限にアクセスできます。HTML5 でバッテリー残量を検出してみてください。
アプリ内エクスペリエンスだけではありません。Android などのオペレーティング システムでは、アプリがユーザーや他のアプリとやり取りするためのさまざまな方法が用意されています。ホームページにはアクティブなウィジェットがあります。デバイスのステータスバーに通知が表示されます。インテントを使用すると、アプリが一般的なサービスを提供していることを他のアプリに通知できます。
反論: ネイティブ機能は拡張可能であり、ウェブは追いついている
アプリ内機能の多くは、HTML5 アプリでは実現できないのは事実です。ウェブのスキルがどれほど優れていても、カメラ API がないサンドボックスにアプリが閉じ込められている場合、すぐに写真を撮ることはできません。 幸いなことに、サンドボックスに閉じ込められる必要はありません。ウェブアプリで写真を撮る必要がある場合は、ネイティブ アプリを作成できます。このアプリには、ユーザー インターフェースの大部分を提供するウェブビューが埋め込まれています。オープンソースの PhoneGap フレームワークは、ネイティブ機能をウェブサービスとして公開することで、このギャップを埋めています。ウェブビューは、標準のネットワーク API を使用してウェブサービスを呼び出します。このようなハイブリッド アプリを構築すると、ウィジェット、通知、インテントなどのプラットフォーム機能を利用することもできます。
ハイブリッド（ネイティブとウェブ）アプリの作成は、理想的なソリューションとは言えません。複雑さが増し、モバイル ブラウザからアクセスする従来のウェブサイトではなく、ネイティブ アプリとしてラップされたウェブアプリにのみ適用されます。しかし、長くは必要ないかもしれません。ウェブ標準は急速に進化しており、最新のモバイル ブラウザもそれに追いついています。たとえば、オフライン ストレージ、位置情報、キャンバス グラフィック、動画/音声の再生は、最新のスマートフォンで広くサポートされています。 カメラもサポートされ始めています。Android 3.1 以降では、ウェブ標準を使用して写真や動画を撮影できます。最新の iOS ブラウザでは、双方向ストリーミング用の WebSocket とデバイスの向きの検出がサポートされています。
全体として、モバイルは進化しています。ウェブも急速に進化しています。デスクトップ ブラウザだけでも、5 つの主要なブラウザ ベンダーが標準を進化させ、新機能を迅速に追加しています。これらの機能をモバイルに移植するのは簡単なプロセスではありませんが、多くはすでにモバイル ブラウザに搭載されています。
ネイティブは急速に進化していますが、ウェブはギャップを埋めています。
パフォーマンス
主張: ネイティブは高速に実行される
ネイティブ アプリには、ウェブ ランタイムのバリアはありません。ネイティブ アプリは、GPU アクセラレーションやマルチスレッドなどのパフォーマンス向上機能を活用できます。
反論: ウェブ ランタイムは現在非常に高速であり、ほとんどのアプリでは速度は必要ない
近年、ウェブは高速化しています。Chrome に搭載されている JavaScript エンジンである V8 は、リリース時にウェブ パフォーマンスの大きな発展を遂げましたが、それ以降も高速化しています。
グラフィック レンダリング エンジンもウェブを高速化し、ハードウェア アクセラレーションが開始されています。ハードウェア アクセラレーション キャンバスによる速度向上をご覧ください。
また、新しい Web Workers API により、マルチスレッドが可能になりました。最新のウェブ デベロッパーは、パフォーマンスが最適化されたライブラリや、十分に研究されたパフォーマンス最適化手法を利用することもできます。これらのほとんどはデスクトップ ウェブで始まりましたが、モバイルにも関連しています。モバイルに注目が集まっており、たとえば、パフォーマンスの専門家である Steve Souders は、モバイル パフォーマンス ツール専用のページを用意しています。
デスクトップの進歩はまだすべてのモバイル プラットフォームに反映されていませんが、その傾向は示されています。また、モバイルアプリの大部分は最先端の 3D ゲームではなく、ニュース、メール、時刻表、ソーシャル ネットワークなどの情報ベースのアプリであることも重要です。モバイルから GMail、Amazon、Twitter などのサイトにアクセスすると、モバイルウェブのパフォーマンスが十分であることがわかります。ゲームに関しては、基本的なゲームはすでに 2D キャンバスで実現可能であり、WebGL がモバイルに登場し始めています（Firefox 4 を参照）。WebGL が普及するまでは、WebGL アプリを OpenGL を活用できるネイティブ アプリにコンパイルするフレームワーク（ImpactJS など）が 増えています。
デベロッパー エクスペリエンス
主張: ネイティブは開発が容易
ネイティブ アプリは、複雑なアプリケーション開発向けに設計され、実績のある堅牢なプログラミング言語（Java、Objective C、C++ など）を使用します。API は、プラットフォームをサポートするためにゼロから設計されました。対象デバイスを忠実に再現するデスクトップ エミュレータでアプリを簡単にデバッグできます。
ウェブ開発が特に困難なのは、ブラウザとランタイムの多様性です。アプリを実行しても、機能 X が利用できるとは限りません。利用できるとしても、ブラウザはどのように実装するのでしょうか？標準は解釈の余地があります。
反論: ウェブは開発が容易な場合が多い（特に複数のデバイスをターゲットとする場合）
まず、コアテクノロジーに取り組みましょう。ウェブ標準は、ウェブがアプリではなくドキュメントを基本とする時代に考案されたものであり、JavaScript はわずか 10 日で構築、デプロイされました。 しかし、想像以上に優れた機能であることが判明しました。ウェブ デベロッパーは、優れた部分を活用し、悪い部分を制御する方法を学び、スケーラブルな設計のパターンを理解しました。さらに、標準は静的ではなく、HTML5、CSS3、EcmaScript Harmony などの取り組みにより、デベロッパー エクスペリエンスが向上しています。C++、Java、JavaScript のどれを好むかは宗教的な議論であり、レガシー コードベースによっても異なります。しかし、最近では JavaScript を有力な候補として含めることができます。
ブラウザ/ランタイムの断片化の裏側には、これらの環境がそもそも存在するという事実があります。Java で Android アプリを開発する場合、iOS をサポートするには Objective C に完全に移植する必要があります。ウェブアプリを一度開発すれば、Android、iOS、WebOS、BlackBerry、Windows Mobile などで実行できます。実際には、エクスペリエンスを正しく取得するには、プラットフォームごとに調整する必要があります。 ほとんどのモバイル オペレーティング システムでは、ネイティブでも同じことを行う必要があります。バージョンやデバイスが異なるためです。
幸いなことに、ウェブでは「断片化」は常にこのようになっており、それに対処するためのよく知られた手法があります。最も重要なのは、プログレッシブ エンハンスメントの原則です。デベロッパーはまず基本的なデバイスをターゲットとし、利用可能な場合はプラットフォーム固有の優れた機能を追加します。機能検出のマントラも役立ちます。最近では、 Modernizrなどのライブラリ サポートにより、レスポンシブ ウェブデザインをサポートしています。これらの手法を適切に使用することで、メーカーや OS に関係なく、古い「フィーチャー フォン」や、時計やテレビなどのフォーム ファクタなど、ほとんどのデバイスにリーチを拡大できます。Google IO 2011 でのマルチ UI デモをご覧ください。 共通のコードベースのロジックとマークアップを使用して、異なるフォーム ファクタ（フィーチャー フォン、スマートフォン、タブレット、デスクトップ、テレビ）をターゲットにしました。
ルック＆フィール
主張: ネイティブはプラットフォームのルック＆フィールに適合する
プラットフォームの定義機能の 1 つは、ルック＆フィールです。ユーザーは、コントロールが一貫して表示され、同じ方法で操作されることを期待しています。プラットフォームによって異なるイディオムがあります。たとえば、ユーザーが「長押し」（要素を数秒間タッチし続ける）した場合に何が起こるかなどです。 プラットフォームにはこのような標準的なイディオムがあり、1 つの HTML5 アプリですべてを満たすことはできません。
さらに、プラットフォームのルック＆フィールは、プラットフォームのネイティブ ソフトウェア ライブラリによって調整されます。このライブラリのウィジェットは、ユーザーが期待するルック＆フィールをカプセル化します。ネイティブ ツールキットを使用するだけで、期待されるルック＆フィールの多くを「無料で」利用できます。
反論: ウェブには独自のルック＆フィールがあり、最も重要なプラットフォームのウェブ インターフェースをカスタマイズすることもできる
前のセクションで説明したように、ウェブ開発の方法は、基本的な「ワンサイズですべてに対応」するバージョンを作成し、段階的に拡張することです。拡張は通常、機能に基づいて行われますが、最も重要なプラットフォームをターゲットにすることで拡張することもできます。これは「ブラウザ検出」の一種であり、ウェブ コミュニティではあまり好まれません。これは、利用可能なブラウザが非常に多いためです。ただし、2 つまたは 3 つのプラットフォームを非常に優先し、ネイティブの代替手段に対抗するために追加の労力を費やす場合は、この方法が適している可能性があります。
ベースライン バージョンに関しては、ウェブには独自のルック＆フィールがあり、デフォルトのブラウザとウェブ ランタイムによって確立された独自の「ウェブ ルック＆フィール」が各モバイル プラットフォームに存在すると言えます。「ウェブ ルック＆フィール」はユーザーにとって問題ないかもしれません。実際、デスクトップ ブラウジング エクスペリエンスや、ユーザーが使用している他のデバイスとの一貫性を高めることができます。さらに、ネイティブのルック＆フィールをあまりサポートしていないアプリも多くあります。これはゲームに当てはまります（お気に入りのモバイルゲームはモバイル OS のルック＆フィールに従っていますか？）。また、従来のアプリにも当てはまります。たとえば、選択したプラットフォームで人気のネイティブ Twitter クライアントを確認すると、さまざまなユーザー インターフェース メカニズムが動作していることがわかります。
見つけやすさ
主張: ネイティブ アプリは見つけやすい
Android の Market や Apple の App Store などのアプリ配信メカニズムは、近年非常に人気があり、モバイル業界全体の大きな推進力となっています。デベロッパーは、ネイティブ アプリをマーケットプレイスに送信できます。ユーザーは、ブラウジング、検索、おすすめの組み合わせでアプリを見つけることができます。それだけでなく、適切に作業を行っていれば、高い評価とコメントにより、ユーザーは重要なインストール ボタンを押すようになります。
反論: 実際には、ウェブアプリは見つけやすい
ウェブは、これまで作成された中で最も見つけやすいメディアと言えるでしょう。控えめな URL には、ウェブで公開されたすべてのもの（標準的なウェブサイトで公開されたアプリを含む）の一意の識別子があります（少なくとも理論上は）。検索エンジンを使用すると、そのコンテンツを簡単に見つけることができます。他のウェブサイトは、モバイル マーケットプレイスに似たウェブアプリのカタログなど、そのコンテンツにリンクできます。実際、個人はメールやソーシャル ネットワーク メッセージでリンクするだけで、ウェブアプリを友人と共有できます。リンクは SMS で送信することもできます。モバイル ユーザーはリンクをクリックして、デバイスのブラウザでアプリを起動できます。
ユーザーがアプリを評価してコメントできるマーケットプレイスはまだありませんが、それも変化しています。続きをご覧ください。
収益化
主張: ネイティブは収益化できる
「6 歳の子供が昼休みにアプリを作成し、1 つ 3 ドルで 10 億個販売する」。最近よく見かける見出しです。大小さまざまなデベロッパーが収益化のためにモバイル マーケットプレイスに注目しているのも不思議ではありません。モバイル プラットフォームでは、デベロッパーがアプリの料金を直接請求するためのいくつかの方法が用意されています。最も簡単なのは、まとめ払いで、アプリを永久に利用できるようにすることです。一部のプラットフォームでは、アプリ内決済と定期購入のメカニズムも提供されており、一貫した安全なメカニズムに緊密に統合されています。これらの新しい支払い方法により、デベロッパーはヒットしたアプリを長期的な収益源に変えることができます。
アプリの支払いに加えて、広告やスポンサーシップなどの従来のウェブモデルで収益化することもできます。
反論: ウェブでの収益化は常に可能であり、機会は増えている
ウェブは、収益化の機会が豊富でなければ、現代産業のエンジンにはなり得ません。直接的な「従量課金制」のメカニズムはまだ普及していませんが、定期購入型の「Software as a Service」ソリューションが実現可能になったニッチ市場はいくつかあります。例としては、Google Apps、37Signals の製品群、さまざまなメールサービスのプレミアム バージョンなどがあります。 さらに、ウェブアプリで収益を得る方法は直接支払いだけではありません。オンライン広告、アフィリエイト リンク、スポンサーシップ、他のプロダクトやサービスへのクロスプロモーションなどがあります。
とはいえ、ウェブ デベロッパーが記事の見出しを読んで、支払いに嫉妬するのは当然です。ネイティブ マーケットプレイスにウェブ URL を送信することはできません。ウェブ デベロッパーはどうすればよいでしょうか？ネイティブの「ラッパーアプリ」を作成します。ターゲットとするプラットフォームごとに、ウェブビューのみを含む空のネイティブ アプリを作成します。ウェブビューは、実際のアプリを埋め込む場所です。これらのアプリをさまざまなマーケットプレイスに送信します（収益が増えることを願っています）。現在、主要なマーケットプレイスには、数百、数千ものウェブアプリが存在します。その中には、ウェブアプリであることを知らずに利用しているものもあります。
欠点は、各プラットフォームへのクロスコンパイルの負担です。ここで、PhoneGap などの既存のフレームワークが役立ちます。 さらに、PhoneGap Build や Apparatio などのウェブサービスが開発されています。これらのウェブサイトをコード リポジトリに指定すると、Android アプリ、iOS アプリなどが表示され、それぞれのストアに送信できます。マシンにネイティブ SDK をインストールする必要はありません。これらのネイティブ アプリをすべて構築するために必要なのは、コードエディタとウェブブラウザだけです。
マーケットプレイスは、ネイティブでラップするオーバーヘッドなしで、ウェブアプリを直接サポートするようになるのでしょうか？まだ明らかではありません。Google は昨年 Chrome ウェブストアをリリースしました。これはデスクトップにのみ適用されますが、他のブラウザ ベンダーの関心を集めており、モバイル固有の試みを含むウェブアプリ カタログへのトレンドの一部となっています。 ウェブストアのコンセプトはまだ初期段階ですが、兆しは有望です。
まとめ
ここで勝者を宣言したいところですが、現時点では明確な勝者はいません。ネイティブに最適なアプリもあれば、ウェブに最適なアプリもあります。ウェブスタックは勢いがありますが、機能と実行品質の面では、ネイティブ アプリも急速に進化しています。ウェブテクノロジーがほとんどのモバイル OS でファーストクラスの市民になるまでは、ネイティブは常に重要な考慮事項となります。
この記事で説明した手法の 1 つにハイブリッド アプリがあります。これは、一部のデベロッパーにとって最適な妥協案となる可能性があります。可能な場合はウェブビューを使用し、不可能な場合はプラットフォーム固有のネイティブ コンポーネントを使用します。
ウェブを選択する場合は、ウェブ標準とプログレッシブ エンハンスメントの原則に注意してください。ウェブは、世界中のさまざまなデバイスやオペレーティング システムをターゲットとするテクノロジーです。「断片化」と呼ぶか「多様性」と呼ぶかにかかわらず、ウェブはそれを受け入れ、デベロッパーは既存のすべての先行技術を活用できます。