HTML5、ネイティブおよびハイブリッドモバイルアプリのアプローチの長所と短所は何ですか？

モバイルアプリケーションを開発したい。最近、Telerik Forumの記事を読みました。この記事では、3種類のモバイルアプリケーションを比較していますが、どちらを選択すればよいかわかりません。以下は、さまざまなモバイルデザインの選択の長所と短所を説明する画像です。

これらの設計の選択を決定するために、図にリストされている各アーキテクチャの選択の長所と短所をよりよく理解したいと思います。各アーキテクチャアプローチの長所と短所は何ですか？

私はこの問題を考慮して多くの時間を費やしたモバイル開発者です。

なぜ聞くのですか？

ほとんどの場合、次の方法でアプリ開発コストを削減したいと考えています。

• 既存のHTML5 / Javascript開発スキルを使用する
• 複数のアプリをゼロから作成せずに複数のプラットフォームをターゲットにする
• 将来的に複数のコードベースを維持する必要がない

理由には以下も含まれます。

• HTML5 / Javascript開発は、ネイティブプラットフォーム開発よりも「簡単」だと認識されています
• 開発者プログラムの登録料の支払いを避ける
• アプリストアのコンテンツ制限の回避（ギャンブルなど）
• 開発ハードウェア（iPhone開発用Macなど）の購入の回避

定義

前述の3つのアプローチのそれぞれが意味することを正確に確立しましょう。

ネイティブ
デバイスにインストールされるアプリ。通常はアプリストアからインストールされます（サイドロードされることもあります）。この説明の目的上、ネイティブアプリのUIは通常、フルスクリーンWebビューのみで構成されていません。

モバイルWeb
これは実際にはどのWebページでもかまいませんが、この説明では、ネイティブアプリのルックアンドフィールを模倣しようとする単一ページのWebアプリを考えてみましょう。これはネイティブアプリではなく、デバイスのブラウザーで実行されます。

ハイブリッド
ハイブリッドアプリinstanceofネイティブアプリ。

ほとんどの人は、おそらくハイブリッドアプリを単一ページのモバイルWebアプリ（ネイティブアプリのルックアンドフィールを模倣している可能性が高い）として理解していますが、ネイティブサービス（Phonegapなど）にアクセスできるネイティブアプリとしてパッケージ化されています。

しかし、実際にはPhonegapモデルと完全ネイティブの間にスペクトルがあります。これについては後で説明します。

モバイルウェブ

技術
的な制限まず、モバイルWebアプリに関するいくつかの技術的な制限を挙げましょう。これは、あなたがしていることに応じて、それ自体が契約を破る可能性があります。

• HTML /キャンバスUIのみ
• 特定のデバイスイベントおよびサービスへのアクセスなし（これらは広く文書化されています）
• アプリストアにリストできない（発見性に影響する）
• iOSでフルスクリーンになり、ホーム画面アイコンを持つことができますが、これはほとんどのユーザーにとっては珍しくて馴染みのないエクスペリエンスです

上記のすべてに対応できる場合は、単一ページのネイティブスタイルWebアプリの課題について詳しく読んでください。ただし、このセクションは、FTアプリを参照しないと完全ではありません。

フィナンシャル・タイムズ紙
ザ・FTのWebアプリはアプリのこのスタイルの有名な例です。 これは、英国ガーディアン紙の興味深い機能です。

それは確かにエンジニアリングの驚くべき偉業です。現時点ではまだiOSでのみ利用可能であることに注意してください-これは、高度なクロスブラウザ開発の課題を解決することが実際に非常に難しいことを発見していることを教えてくれます。

単一ページのネイティブスタイルのWebアプリ

このセクションは、モバイルWebアプリとPhonegapスタイルのアプリの両方に適用されます。

Webアプリ内のネイティブスタイルのルックアンドフィールは、通常、使用するUIコンポーネントのスイートを提供するSencha Touchなどのフレームワークで実現されます。

このようなフレームワークは、非常に単純なUIには適しています。ただし、柔軟性に欠けます。Senchaを使用してネイティブアプリのデザインを実装することはできません。フレームワークが対応できるものにデザインを適合させる必要があります。

これらのフレームワークが苦しむ主な方法は、プラットフォーム独自のUIの複雑さをエミュレートしようとすることです。iPhoneでリストの最後までスクロールしたときに得られる素敵で小さなバウンス効果はありますか？フレームワークは、Javascriptでそれをエミュレートする必要があります。完全に再作成することは不可能であり、スローダウンする傾向があり、ユーザーはアプリの「不気味な谷」に閉じ込められますが、これはネイティブのように見えますが、明らかにそうではなく、非技術的ユーザーは正確な理由に指を置くことができません。

「HTML5 / Javascriptは簡単」という神話

Webブラウザー内のデバイスの断片化はis延しており、最も基本的なHTMLおよびCSSを超えると、期待どおりに機能しないことがわかります。UIの厄介な問題を解決するのに、ネイティブで2回行うよりも多くの時間を費やすことに気付くかもしれません。ネイティブに移行する場合、ネイティブアプリのWebビューはデバイスブラウザーとは異なり、独自のフラグメンテーションの問題があることに注意してください。

アプリの機能がより複雑になると、Javascriptをクリーンで保守可能な状態に保つために、基本的なjqueryスキル以上のものが必要になることがわかります。

とはいえ、このアプローチを使用すると、シンプルで機能的なアプリを非常に迅速に作成することができます。しかし、アプリがそれを実行しているときは明らかです。

さらにスペクトルに沿って

そのため、Phonegapスタイルのアプリが提供できるよりも優れたUXが必要です。私たちは何ができる？

非UIコードを共有する

複数のネイティブプラットフォーム間でビジネスロジックを共有するために利用できるさまざまな手法があります。GoogleはJavaをObjective-Cに変換するJ2ObjCを開始しました。コードを注意深くファクタリングすることで、JavaライブラリをAndroidとiOSの両方で使用できます。

CalatravaやKirinなどのライブラリを使用すると、Javascript（およびJavascriptにコンパイルできるもの）で記述されたコードベースをネイティブコードから操作できます。免責事項：キリンを作成したFuture Platformsで働いています。GWTを使用してJavaから生成されたJavascriptを使用してiOSで使用し、JavaコードもAndroidでネイティブに実行することで、大成功を収めました。

必要に応じてWebビューを使用...

フルスクリーンWebビューには、画面の遷移を模倣してエフェクトをバウンスできるようにするために多くの作業が必要です。ただし、ネイティブアプリchrome内のWebビューは、ネイティブと区別できません。

ネイティブアプリとWebビューが通信するための標準的で十分に文書化された方法があります。

リストとテーブルはこの方法で特にうまく機能しますが、テキスト入力はネイティブで最も適切に処理されるものの例です（キーボードを完全に制御するため）。

要約すれば

最適なアプローチは、アプリの複雑さと、満足できるUIの洗練度によって異なります。

私のモットー：できる限りウェブビューを使用しますが、ユーザーに伝えられないようにしてください。

最初にこの調査をチェックして、何が起こっているかを確認してください！

3つのタイプの比較： モバイルアプリケーション開発オプションについて

ネイティブとhypridの比較：

HTML5とネイティブ

HTML5対ネイティブアプリ：どちらを選択しますか？

これは本当に良いです： HTML5 vネイティブアプリ：モバイル戦略の重要な考慮事項

コメント：

• あなたはそれらの1つに行くことができますあなたが持っているもの（スキル）とあなたが得ることができるものに依存します（ルックアンドフィール、パフォーマンス、機能性、...）
• すべてのモバイルアプリ開発者は、最初のバージョンと将来のバージョンのために開発するアプリケーションについて明確なビジョン/要件を持っている必要があります！彼が使用するオプションが何らかの点で彼を制限しないことを確実にするためだけです。
• 3つの方法を実際に体験し、同時に最新のものであることほど素晴らしいことはありません。これにより、正しい判断を下す感覚と能力が得られます。

電話のハードウェアにアクセスする必要がある場合は、ネイティブアプリを作成する必要があります（HTML5では、GPSなどのデバイスのハードウェアコンポーネントの一部にアクセスできます）。

Web開発に慣れている場合は、ネイティブアプリを作成する必要がない限り、これに固執する必要があります。

知っておくべきことは、すべての異なる画面サイズ（垂直および水平方向を含む）を念頭に置いておく必要があるということです。OSのさまざまなバージョンを念頭に置く必要があります（これはAndroid向けです）。これらはモバイルデバイスであるため、ユーザーが電話に出て電話に出る可能性があり、デスクトップやサーバーの計算能力もありません。

消費者向けアプリを作成するとき、私にとって、その成功の最も重要なことは、アプリのユーザーの受け入れと認識です。そのため、学習、トレーニング、およびWORAの損失（どこでも実行できる書き込み）に関連する追加コストにもかかわらず、ネイティブアプリを優先する4つの理由は次のとおりです。

1. アプリの高速起動
2. スムーズなスクロール
3. 他のOSやアプリとより一貫して連携する一貫性のあるアプリUI
4. より高速なアプリUI応答

他の何よりも欲しいのは、アプリが喉の渇きの市場で成功するのに役立つ優れたユーザーエクスペリエンスです。もちろん、例外は特にスキルセットの不足、時間と予算の不足です。アプリは、これらのことをあまり気にしないビジネスユーザーの限られたセットを対象とする場合があります。

FacebookがIOSとAndroid用のネイティブアプリを支持してアプリ戦略を捨てたのは、これらと同様の理由です：

読んでください：

マーク・ザッカーバーグ：最大の間違いはHTML5にあまりにも多く賭けていた http://techcrunch.com/2012/09/11/mark-zuckerberg-our-biggest-mistake-with-mobile-was-betting-too-much-on- html5 /

Facebookが新しいiOSアプリでモバイルWebを捨ててネイティブになった理由 http://readwrite.com/2012/08/23/how-facebook-ditched-the-mobile-web-went-native-with-its-new- ios-app＃awesm =〜o9jDrRefxdgnpS

お役に立てれば。

以下では、この問題に対する私の現在のスタンスは、ハイブリッドは、アプリを探索し、顧客からのフィードバックをすばやく繰り返し、機能セットを安定させるために開始するのに適しているということです。その後、仕様に従ってアプリをネイティブに書き換え、エクスペリエンスを向上させます。

モバイルWebはまったく別の目的で使用されるため、除外しました。アプリストアに参加したい場合は、Native / Hybridが最適です。展開を簡素化し、経験と技術的能力を犠牲にしたい場合は、モバイルWebを使用してください。

Pro / Cons Native：

• 利点：デバイスエクスペリエンスの残りの部分に適合し、不思議な谷の問題はありません。
• 利点：ほとんどの場合、スムーズで一貫したUIエクスペリエンスが提供され、遅延やスタッターは発生しません。
• 利点：技術的な制限はほとんどなく、デバイスを十分に活用できます。
• Pro：ネイティブツールは、アプリストアの検証に準拠しています。
• 利点：ネイティブフレームワークには、プラットフォームバージョンごとの微調整が含まれており、微調整にかかる時間が短縮されます。
• 欠点：ビルドが長持ちするため、ビルドに時間がかかります。
• 欠点：見つけるのが難しく、高価なポリグロット開発者が必要です。
• 短所：各デバイスプラットフォームAPI（iOS / Android /など）を理解する必要があります。
• 短所：急な学習曲線。
• 短所：プラットフォームごとに異なるツールセット。

賛否両論のハイブリッド：

• プロ：複数のデバイスプラットフォームをターゲットとする単一のコードベース。
• Pro：迅速な開発サイクル、優れたレイアウトの柔軟性、プロトタイピングとMVPに最適。
• プロ：快適な学習曲線、多くのドキュメント、あなたを助けるフレームワーク。
• Pro：単一の開発ツールセット。Chromeデバッガーツールは優れています。
• プロ：複数のデバイスプラットフォームを対象とする1つのコードベース。
• プロ：多くの開発者が利用でき、簡単に習得できます。
• 欠点：デバイスエクスペリエンスと一貫性を保つために、さまざまなプラットフォームに合わせてUIを調整するには、適切なUIフレームワークが必要です。Kendo UI、Sencha Touchなどのソリューションがあります。
• 短所：メモリと計算の使用について非常に意識する必要があります。一部のCSS、javascriptループはアプリの速度を著しく低下させる可能性があります。デバイス上でデバッグできるツールはあまりありません。
• 短所：まだ成熟しておらず、状況は突然変わる可能性がありますが、ツールは改善されています。

自分でモバイル開発者であるため、最悪の事態はオフラインアクセスです。ユーザーを単にオンラインにするだけで、多くのアプリで動作するはずですが、すべてではありません。

他の大きな悪い面は、遅さです。リモートデータの解析に必要な時間には、かなりの時間がかかります。はい、ロード中にデータをプリフェッチできますが、他のすべての場合、速度低下を避けることはできません。

そのようなアプリはネイティブアプリよりもアプリを終了させることがわかりました。私のクライアントにはもうお勧めしません。

ハイブリッドアプリの大きな問題は、フレームワークの断片化です。対象のネイティブモバイルプラットフォーム（通常はAndroidとiOSの2つだけ）よりも明らかに多くのフレームワーク（Ionic、Xamarin、React Nativeなど）があります。これらのフレームワークは競合し、出現し、衰退します。そのため、現在のチームを生涯維持するつもりであっても、ハイブリッドに移行してもプラットフォームからプラットフォームにジャンプすることはありません。

GoogleとAppleは、エディター、デバッガー、テストフレームワーク、リファクタリングツール、およびプラットフォーム用に開発するその他の手段の提供とサポートに最善を尽くしています。したがって、「ハイブリッドアプリを開発し、お気に入りのエディターで編集し、ブラウザーで開くのは簡単です」という典型的な言い回しを合理的な予約で受け取ります。XamarinとReact Nativeは、SwiftやJava / Androidと同じ開発プラットフォームであり、「hello world」は短く見えるかもしれませんが、最終的には適切な学習に相当する時間がかかるはずです。

いずれにせよ、ネイティブコンポーネントが必要になった場合（たとえば、既存のサードパーティライブラリを統合する必要がある場合）、2つではなく3つのフレームワークになります：iOS、Android、およびハイブリッドフレームワークが最上部にあり、最終的にはより複雑なアーキテクチャで。そのようなアプリのデバッグ、クロスレイヤーコール間のステップ実行、すべてのレイヤーのログ記録、コードの同期の維持は、複雑な場合もあります。

「アプリはすべてのプラットフォームでまったく同じに見える」と言う人もいます。それは本当に良いことですか？AndroidアプリはAndroidアプリのように見え、iOSアプリはiOSアプリのように見えなければなりません。

新機能はどうですか？ウェアラブル？Androidプラットフォームで提供されるインスタントアプリ 外部ディスプレイに追加データを表示していますか？ハイブリッドアプリは多くのネイティブ機能をサポートするようになりましたが、本当にすべてをサポートしていますか？いつでも、すぐに？

最後に、パフォーマンスとユーザーエクスペリエンスだけでなく、セキュリティもネイティブアプリ側にある可能性があります。ハイブリッドフレームワークは、独自のバグ（セキュリティバグを含む）を持つ可能性のある間接化のレイヤーを追加します。

上記のすべてをまとめて、選択の可能性の下で、私は間違いなく、iOS用とAndroid用の2つのネイティブアプリを選ぶか、プラットフォームのアプリ開発に一切煩わされることなく、単にモバイルバージョンのウェブサイトを設計します。