モバイルアプリに関する議論
はじめに
今最も注目されているテクノロジーはモバイルアプリと HTML5 ですが、ウェブアプリはモバイル ブラウザで実行されます。また、さまざまなモバイル プラットフォームでネイティブ アプリとして再パッケージ化することもできます。幅広いプラットフォームに対応していることと、その優れたモバイル ブラウザ技術を組み合わせることで、デベロッパーは「1 つ書けば何個でも実行できる」ソリューションとして HTML5 に注目し始めています。しかし、それは本当に可能でしょうか？ネイティブ化にはやはり説得力のある理由があり、多くのデベロッパーが実際にネイティブ化を目指しています。この記事では、ネイティブとウェブについて議論します。
機能の拡充
ポイント: ネイティブでできること
モバイル機能は、アプリ自体のエクスペリエンスと、アプリがデバイスのエコシステムと連携する方法（たとえば Android の場合）の 2 つの側面に分けることができます。これは、ウィジェットや通知などの機能です。ネイティブ広告は両方の点で優れています。
アプリのエクスペリエンスに関して言えば、ネイティブ アプリではできることが多くなります。スワイプ イベントやマルチタッチは、プラットフォームに対応しているプラットフォームでも簡単に確認できます。通常、Android の検索ボタンや音量コントロールなど、ハードキーが押されても動作します。GPS やカメラなどのハードウェアにもアクセスできます。一部のプラットフォームでは、ユーザーの許可があればオペレーティング システムへの無制限のアクセスが提供されます。HTML5 を使用してバッテリー残量を検出してみましょう。
しかし、これはアプリ内エクスペリエンス以上のものです。Android のようなオペレーティング システムでは、アプリがユーザーと、実際には他のアプリとやり取りするためのさまざまな方法を提供しています。ホームページにアクティブなウィジェットがある。デバイスのステータスバーに表示される通知があります。また、インテントを使用して、他のアプリで必要となる可能性のある一般的なサービスを提供することをアプリが宣言できます。
対抗: ネイティブ機能を拡張できるのに、ウェブが追いつく
確かに、アプリ内機能の多くは HTML5 アプリでは手の届かないものです。どんなに Web-fu スキルが高まっても、カメラ API のないサンドボックスに縛られたアプリは、すぐには撮れません。幸いなことに、そのサンドボックス内にいる必要はありません。ウェブアプリで写真を撮影する必要がある場合は、ウェブビューが埋め込まれたネイティブ アプリを作成できます。このアプリは、ユーザー インターフェースの大部分を占有します。オープンソースの PhoneGap フレームワークはこのように動作します。ウェブビューが標準のネットワーキング API を使用して呼び出すネイティブ機能をウェブサービスとして公開することで、ギャップを埋めます。このようなハイブリッド アプリを作成すると、ウィジェット、通知、インテントなどのプラットフォーム機能に接続することもできます。
ネイティブ + ウェブのハイブリッド アプリにすることは、理想的なソリューションとは言えません。これは複雑さが増し、モバイル ブラウザからアクセスする従来のウェブサイトではなく、ネイティブ アプリとしてラップされたウェブアプリにのみ適用されます。ただし、その必要がない場合もあります。ウェブ標準は急速に進化しており、最新のモバイル ブラウザもそれに追いついています。たとえば、オフライン ストレージ、位置情報、キャンバス グラフィック、動画/オーディオの再生などが、最新のスマープトーンで幅広くサポートされています。カメラのサポートも開始しています。Android 3.1 以降では、ウェブ標準を使用して写真や動画をキャプチャできます。また、最新の iOS ブラウザは、WebSocket による双方向ストリーミングとデバイスの向きの検出をサポートしています。
全般的に、モバイルは進化を続けています。しかし、ウェブも進化し、急速に進化しています。デスクトップ ブラウザだけでも、主要ブラウザ ベンダー 5 社が標準を進化させ、急速に機能を追加しています。これらの機能をモバイルに移植するのは簡単なプロセスではありませんが、その多くはモバイル ブラウザにすでに実装されています。
ネイティブ広告は目まぐるしく変化するターゲットですが、ウェブによってそのギャップが縮まっています。
パフォーマンス
ポイント: ネイティブの動作が高速
ネイティブ アプリにウェブ ランタイムの障壁はありません。これらは金属の近くで動作し、GPU アクセラレーションやマルチ スレッディングなどのパフォーマンス ブースターを活用できます。
カウンタポイント: 現在のウェブ ランタイムは大幅に高速化しており、ほとんどのアプリにその速度が必要ではない
ここ数年でウェブは高速化されています。Chrome に付属の JavaScript エンジンである V8 は、リリース当初はウェブ パフォーマンスの面で大きな発展を遂げましたが、その後はさらに高速化が進みました。
グラフィック レンダリング エンジンによってウェブも高速化され、今ではハードウェア アクセラレーションが行われ始めています。ハードウェア アクセラレーション キャンバスによって提供される速度バンプを見てみましょう。
さらに、新しい Web Workers API を使用すると、マルチスレッド化が可能になります。最新のウェブ デベロッパーは、さまざまなパフォーマンスが最適化されたライブラリや、十分に調査されたパフォーマンス最適化手法を呼び出すことができます。その大部分は PC ウェブで始まりましたが、今もモバイルにも関係しており、モバイルへの関心も高まっています。たとえば、パフォーマンスの達人である Steve Souders は、モバイル パフォーマンス ツールに特化したページを公開しています。
パソコンの進歩がすべてのモバイル プラットフォームに浸透しているわけではありませんが、トレンドは着実に進んでいることを示しています。また、モバイルアプリの大半は最先端の 3D ゲームではなく、ニュース、メール、時刻表、ソーシャル ネットワークなど、基本的に情報に基づいたものです。Gmail、Amazon、Twitter など、モバイルからいくつかのサイトにアクセスすると、モバイル ウェブ パフォーマンスが十分以上であることを確認できます。ゲームに関しては、基本的なゲームは 2D キャンバスですでに可能になっており、WebGL がモバイルでも利用可能になりつつあります。Firefox 4 をご覧ください。広く利用されるまで、WebGL アプリを OpenGL を利用できるネイティブ アプリにコンパイルするフレームワーク ファミリーは増え続けています（例: ImpactJS）。
デベロッパー エクスペリエンス
ポイント: ネイティブの方が開発しやすい
ネイティブ アプリは、Java、Objective C、C++ などの堅牢なプログラミング言語を使用しており、複雑なアプリケーション開発用に設計され、確かな実績があります。API は、手元のプラットフォームをサポートするようにゼロから設計されています。対象デバイスを近づけたデスクトップ エミュレータでアプリを簡単にデバッグできます。
ウェブ開発が特に難しいのは、ブラウザとランタイムの多様さです。アプリが実行されたときに、機能 X が利用可能になるとは限りません。たとえそうだとしても ブラウザはどのようにして実装するのでしょうか解釈を受け入れやすい基準があります。
カウンターポイント: ウェブは開発が容易なことが多い（特に複数のデバイスをターゲットにしている場合）
まずはコア テクノロジーに取り組みましょう。実際にウェブ標準が考案されたのは、ウェブがアプリではなくドキュメントの基本であり、JavaScript がわずか 10 日で構築、デプロイされていた時代に考案されました。ところが、ウェブ デベロッパーは予想以上に優れた機能を持つことがわかりました。ウェブ デベロッパーは、優れた部分を活用し、不適切な部分を手放し、スケーラブルな設計のためのパターンを理解しています。さらに、その標準は定着せず、HTML5、CSS3、EcmaScript Harmony などのあらゆる取り組みが、デベロッパーのエクスペリエンス向上につながっています。C++、Java、JavaScript のどれが良いかは、宗教的な議論の問題です。また、以前のコードベースによっても異なります。しかし最近では JavaScript を 本格的な競争相手として検討できます
ブラウザやランタイムの断片化の反面、これらの環境はすべてそもそも存在するということです。Java で Android アプリを開発すると、iOS をサポートする Objective C へのフルポートに直面します。一度開発したウェブアプリは、WebOS、BlackBerry、Windows Mobile は言うまでもなく、Android と iOS で動作します。実際に体験するには、プラットフォームごとに 微調整を行う必要がありますただし、ネイティブで行う必要があります。ほとんどのモバイル オペレーティング システムには、さまざまなバージョンやデバイスがあります。
幸いなことに、ウェブではこのように「断片化」が起こり続けており、対処するためのよく知られた手法があります。最も重要な点は、プログレッシブ エンハンスメントの原則に従い、デベロッパーはまず基本的なデバイスをターゲットにし、利用可能な場合はプラットフォーム固有の優れたレイヤを追加することを推奨することです。機能検出の信条も役に立ちます。最近では、Modernizr などのライブラリ サポートによってレスポンシブ ウェブ デザインをサポートしています。これらの技術をうまく活用すると、メーカーや OS に関係なく、ほとんどのデバイス（旧式の「フィーチャー フォン」も含む）にまでリーチを広げることができます。Google IO 2011 のマルチ UI デモをご覧ください。このデモでは、ロジックとマークアップの共通のコードベースを使用して、異なるフォーム ファクタ（フィーチャー フォン、スマートフォン、タブレット、デスクトップ、テレビ）をターゲットにしています。
デザイン
ポイント: プラットフォームのデザインにネイティブでフィットする
あらゆるプラットフォームを特徴付ける特徴の 1 つは、そのデザインです。ユーザーは、コントロールが一貫して表示され、同じように操作されることを期待するようになります。特定のイディオムはプラットフォームによって異なります。たとえば、ユーザーが「長押し」（要素を数秒間タップし続ける）するとどうなるでしょうか。プラフォームには、こうしたことを表す標準的なイディオムがあり、単一の HTML5 アプリでそのすべてを満たすことはできません。
さらに、プラットフォームのネイティブ ソフトウェア ライブラリによって、プラットフォームのデザインがオーケストレートされます。このライブラリのウィジェットは、ユーザーが期待するデザインをカプセル化しています。ネイティブ ツールキットを使用するだけで、想定される多くのデザインを「無料で」実現できます。
対抗: ウェブには独自のデザインがあります。また、最も重視するプラットフォームに合わせてウェブ インターフェースをカスタマイズすることもできます。
前のセクションで説明したように、ウェブ開発の手法では、基本的な「画一的な」バージョンを書き、徐々に拡張していきます。通常、拡張機能は機能に基づいて行われますが、重要なプラットフォームをターゲットとして拡張することもできます。これは一種の「ブラウザ検出」であり、多くのブラウザが存在するため、ウェブ コミュニティから頻繁には非難されることがあります。ただし、優先度が非常に高いプラットフォームを 2 つまたは 3 つ表示し、ネイティブの代替手法と比較するために余分な労力を費やしても構わない場合は、この方法が最適です。
ベースライン バージョンに限り、ウェブには独自のデザインがあり、各モバイル プラットフォームには、デフォルトのブラウザとウェブ ランタイムによって確立された独自の「ウェブのデザイン」もあります。「ウェブのデザイン」はユーザーにとっては適切かもしれませんが、実際は、デスクトップのブラウジング エクスペリエンスや、ユーザーが使用する可能性のある他のデバイスのエクスペリエンスとの整合性を高めることができます。さらに、ネイティブのデザインにあまり対応していない、成功を収めているアプリも数多くあります。これは間違いなくゲームに当てはまります（お気に入りのモバイルゲームはモバイル OS のデザインに合っているか）。また、一般的なアプリにも当てはまります。たとえば、選択したプラットフォームで人気のあるネイティブ Twitter クライアントをチェックしたり、さまざまなユーザー インターフェース メカニズムを実際に確認したりできます。
見つけやすさ
ポイント: ネイティブ アプリは見つけやすい
Android のマーケットや Apple の App Store のようなアプリ配信メカニズムは、近年非常に人気があり、モバイル業界全体の原動力となっています。どのデベロッパーもネイティブ アプリをマーケットプレイスに提出できます。マーケットプレイスでは、ユーザーは閲覧、検索、おすすめを組み合わせてアプリを見つけることができます。それだけでなく、適切に対処すれば、高評価やコメントの高表示で、ユーザーに重要なインストール ボタンを押すよう促すことができます。
カウンタポイント: 実際、ウェブアプリの方が見つけやすい
ウェブはおそらく、これまでで最も見つけやすいメディアです。シンプルな URL では、（理論的には）ウェブで公開されているすべてのもの（標準的なウェブサイトで公開されているアプリを含む）に対して、（少なくとも）一意の識別子があります。検索エンジンを使用すると、モバイル マーケットプレイスに似たウェブアプリのカタログなど、コンテンツや他のウェブサイトがリンクできるコンテンツを簡単に見つけることができます。実際に、メールやソーシャル ネットワーク メッセージでウェブアプリへのリンクを設定するだけで、誰でもウェブアプリを友人と共有できます。リンクを SMS で送信することもでき、モバイル ユーザーはリンクをクリックしてデバイスのブラウザでアプリを起動できます。
ユーザーがアプリを評価したりコメントしたりできるマーケットプレイスはまだありませんが、それも変化しつつあります。続きを読む
収益化
ポイント: ネイティブ広告は収益化できる
「6 歳の少年が昼休みにアプリを作成し、1 千万本を 1 本 3 ドルで販売しています」。最近はこのような見出しが頻繁に出てきます。あらゆる規模のデベロッパーが収益化をモバイル マーケットプレイスに期待しているのは当然のことです。モバイル プラットフォームには、デベロッパーがアプリを直接請求する方法がいくつかあります。最も簡単な方法は、アプリを永遠にロック解除できる 1 回限りの支払いです。一部のプラットフォームでは、アプリ内決済と定期購入のメカニズムも提供されています。これらは、一貫した安全なメカニズムに緊密に統合されています。こうした新しい支払い方法により、デベロッパーは大ヒットしたアプリを長期的な収益源に変えることができます。
アプリの支払いに加えて、広告やスポンサーシップなどの従来のウェブモデルで収益化することもできます。
カウンターポイント: これまでウェブでの収益化は可能でしたが、そのチャンスは拡大しています
実現する機会が十分でなければ、ウェブは現代産業の原動力にはなれません。直接的な「従量課金」メカニズムはまだ発展していませんが、サブスクリプションベースの「Software as a Service」ソリューションが実際に実現可能なニッチはさまざまです。たとえば、Google アプリ、37Signals のサービス、各種メールサービスのプレミアム バージョンなどです。また、ウェブアプリで収益を得る方法は直接支払いだけではありません。オンライン広告、アフィリエイトリンク、 スポンサーシップ、他の商品やサービスとの相互プロモーション
そうは言っても、ウェブ デベロッパーが見出しを読んで、支払いにちょっとした欲求を抱くのは、まったく合理的です。ネイティブ マーケットプレイスにウェブ URL を送信することはできないため、ウェブ デベロッパーはどうすればよいでしょうか。ネイティブの「ラッパーアプリ」を作成します。ターゲットとするプラットフォームごとに、ウェブビューのみを含む空のネイティブ アプリを作成します。ウェブビューは、実際のアプリを埋め込む場所です。次に、これらのアプリをさまざまなマーケットプレイスに送信するだけです（そして収益が得られるのを待つだけです）。今日のメインのマーケットプレイスには、おそらく数千とは言わないまでも数百のウェブ駆動型アプリが存在しますが、その中には驚くほど巧妙に同化されていて、Google のウェブアプリすらまったく知られていないものもあります。
デメリットは、各プラットフォームに対してクロスコンパイルを行う必要があることです。ここで、PhoneGap のような既存のフレームワークが役立ちます。さらに、PhoneGap Build や Apparatio などのウェブサービスも開発中です。これらのウェブサイトをコード リポジトリを指すと、Android アプリや iOS アプリなどがポップされ、それぞれのストアに送信できるようになります。マシンにネイティブ SDK をインストールする必要はなく、コードエディタとウェブブラウザだけで、これらのネイティブ アプリを構築できました。
マーケットプレイスでは、ウェブアプリをネイティブにラップするオーバーヘッドを発生させることなく、ウェブアプリを直接サポートするか。まだはっきりしていません。Google が昨年導入した Chrome ウェブストアは、デスクトップ限定ですが、このストアは他のブラウザ ベンダーからも関心を集めており、モバイルに特化した試みを含め、ウェブアプリ カタログへの全体的なトレンドの一端を担っています。ウェブストアという概念はまだ始まったばかりですが、その標識は将来性のあるものです。
まとめ
ここで勝者を宣言したくはありませんが、現時点では明確な勝者がありません。ネイティブに向いているアプリもあれば、ウェブに向いているアプリもあります。おそらくウェブスタックの勢いは増していますが、機能と実行品質の観点からも、ネイティブ アプリも急速に進んでいます。そして、大多数のモバイル OS でウェブ テクノロジーが最優先される時期が来ない限り、ネイティブは常に重要な考慮事項となります。
この記事で紹介する手法の 1 つがハイブリッド アプリです。これは、可能な場合にはウェブビューを使用し、そうでない場合はプラットフォーム固有のネイティブ コンポーネントなど、一部のデベロッパーにとっては最適な妥協点となる可能性があります。
ウェブパスを選択する場合は、ウェブ標準とプログレッシブ エンハンスメントの原則に留意してください。ウェブは、さまざまなデバイスやオペレーティング システムをターゲットにできるテクノロジーです。これを「断片化」とか「多様性」と呼ぶにしても、ウェブは受け入れ、デベロッパーは世の中のあらゆる技術の恩恵を受けることができます。