ネイティブとPWA：挑戦者ではなく、選択肢！
公開: 2022-03-10「ネイティブ」と「ウェブ」の間の亀裂が実際にどこから始まったのかを正確に知ることは困難です。 これは、Flashの初期の頃から表面のすぐ下でかき回されていたもののひとつであり、モバイルプラットフォームの台頭とともに最近になってようやく噴火したように感じます。 とにかく、開発者はこの「大きな溝」を横切って、自分たちの側を強化しようとして、お互いに侮辱を働きかけています。
私はその戦いには興味がありません。 確かに、私は「ウェブの男」ですが、それは私がネイティブ開発の魅力を見ることができないという意味ではありません。 私はソフトウェア開発者でもあります。 何よりも、私は実用主義者です。 私は、すべてのプロジェクトが異なり、それぞれに対する私たちのアプローチは、プロジェクトのニーズと目標に合わせて調整する必要があることを認識しています。
プログレッシブウェブアプリ（PWA）がネイティブ開発の領域に侵入しているので、今は一歩下がって、製品を構築するためのこれら2つのアプローチを検討する良い機会かもしれないと思いました。 私の希望は、私たち全員が、私たちが作成する製品に最適なものを見つけることを期待して、各アプローチの長所を明確に理解できるようになることです。
連射比較
ほぼ最初から、Webベースのエクスペリエンスは、デスクトップソフトウェア（元の「ネイティブアプリ」）からインタラクティブCD-ROM、Flash、そして最近ではモバイルアプリまであらゆるものと比較されてきました。 何度も死亡宣告されたにもかかわらず、ウェブは存続しました。 多くの場合、それはその疑惑の殺人者（RIPフラッシュ）よりも長生きしました。
この点でのWebの主な強みの1つは、その適応性です。 インターネット接続があればどこにでも行くことができ、新しい機能を獲得し続けています。 すべてのプログラミング言語は進化しているので、それは予想外ではありませんが、時間の経過とともに、Webの拡大する境界線は、従来のソフトウェアの領域に侵入し続けています。
しかし、歴史的にWebが不足している分野のひとつは、パフォーマンスの領域にあります。 インストールされたソフトウェアは、Webでは不可能な方法で基盤となるオペレーティングシステムに結び付けることができます。 それらはホストの共通語で書かれており、ハードウェアに直接アクセスできるか、よく言われるように「金属に近い」ものです。 ほとんどの場合、その上の1つ以上の抽象化レイヤーを操作するWebは、パフォーマンスに関して競争するのに苦労していました。 パフォーマンスのギャップは時間の経過とともに縮小しますが、少なくともWebがハードウェアのピンから直接信号を解釈できるようになるまで、ネイティブコードはWebコードよりも高速に実行され続ける可能性があります。
パフォーマンスの利点と相まって、ネイティブ開発では、NFC、Bluetooth、近接センサー、環境光センサーなどのデバイス機能へのアクセスがはるかに多くなります（以前は）。 Webも着実にこれらの機能にアクセスできるようになっていますが、Webがそれらを利用する前にネイティブAPIを開発する必要があり、ブラウザー全体での標準化には時間がかかるため、常にネイティブに遅れをとっています。
さらに、ネイティブコードは、名簿やカレンダーなどのOSレベルの機能にフックできます。 プッシュ通知も大きなものでしたが、Service Workerにより、Webでもその機能を利用できるようになりました。 最近、ウェブ上でも同様に支払い処理が改善されています。 おそらく、名簿とカレンダーへのアクセスも最終的にはWebに登場するでしょう。
しばらくの間ServiceWorkersに戻りますが、この最近のWeb開発者のツールボックスへの追加には、他にも多くのトリックがあります。 まず第一に、それはWebが以前にAppCacheで持っていたよりもはるかに堅牢なキャッシングシステムを提供します。 Service Workerを使用して、オフラインリクエストの管理、特定のリソースのキャッシュ、ユーザーがサイトを開いていないときのリモートサーバーとのデータの同期などを行うことができます。 おそらく他のどの単一テクノロジーよりも、ServiceWorkerはWebがよりアプリのようなエクスペリエンスを提供できるようにしました。
サービスワーカーは、PWAの3つの技術的な要の1つです。 もう1つは、Webアプリマニフェストです。 少し退屈に聞こえるかもしれませんが、Web App Manifestは、Webサイトが自分自身をアプリとして宣伝できるという点で、実際には非常に強力なツールです。 この比較的単純なJSONファイル形式は、説明するWebサイトに関する豊富な情報を提供し、PWA対応のブラウザーとオペレーティングシステムがネイティブソフトウェアであるかのようにサイトをインストールできるようにします。
一部のアプリストアは、マニフェストを使用して関連するエントリを入力し、PWAのインデックス作成を開始しています。 ユーザーの観点から見ると、アプリストアのPWAは、それらを取り巻くネイティブアプリと何ら変わりはありません。 これらはインストール可能、インストール不可であり、基盤となるオペレーティングシステムのアプリ管理ツールに設定を公開することもできます。 また、PWAはWeb上に存在するため、使用するためにユーザーが明示的にインストールする必要がないことにも注意してください。
ウェブ上とウェブの両方にいるということは、PWAが常に最新であることも意味します。 ユーザーは、新しい機能にアクセスするために新しいものを積極的にダウンロードする必要はありません。 また、新しいコンテンツや機能が公開された場合でも、ほとんどのネイティブアプリの場合のように、ユーザーがPWA全体を再ダウンロードする必要はほとんどありません。 どちらかといえば、彼らはいくつかの新しいアセットといくつかの新しいHTMLを取得する可能性があり、それはかなり瞬時に発生し、アプリストアは必要ありません。 もちろん、アプリストアが提供する検出と配布のオプションはまだあるので、実際には両方の長所があります。
アプリストアに参加することで、PWAは、発見、配布、および現金化の点でネイティブアプリと同等の立場に立つことができます。 実際、PWAは検索エンジンを介して検出可能であり、URLに存在するため、アプリよりも無限に共有可能であるため、ネイティブを介してWebをボールトすることさえあります。 適切に構築されている場合、PWAはブラウザ、プラットフォーム、およびデバイス間で相互運用することもできます。 PWA機能はプログレッシブエンハンスメントであるため、PWAはServiceWorkerなどの機能をサポートしないブラウザーでも機能します。
Webはまた、非常に成熟したアクセシビリティサポートを提供し、プロジェクトを最も多くのユーザーが使用できるようにすることを比較的簡単にします。 複雑なインターフェースはプログラミングに関してはもう少し注意が必要ですが、セマンティックHTMLによって提供されるアクセシビリティの利点は、特にテキストが多い、情報を提供する、または単純なフォームベースの製品に関しては、ベースラインのアクセシビリティをaplombで処理します。 対照的に、ほとんどの場合、アクセシビリティAPIを認識し、ネイティブコードに組み込む必要があります。
開発に関しては、開発経験に関して明確な勝者はいないと思います。 すべての言語にはファンがいて、開発者ツールについても同じことが言えます。 あなたは好きなものが好きで、あなたが知っていて情熱を持っているツールや言語でより効率的になる傾向があります。 Webもネイティブ開発も、そこには明確な利点はありません。
ただし、ネイティブ開発が優れているのは、SDK（ソフトウェア開発キット）を使用して構築されたUIの一貫したレベルの品質を確保することです。 ほとんどのネイティブSDKは、パフォーマンス、設計、機能などをテストするためのツールを提供します。 また、ボイラープレートコード、設計システム、およびネイティブソフトウェア製品の全体的な水準を上げるのに役立つその他のツールも含まれています。 もちろん、Webにも同様のツールがありますが、それらはWeb全体に散在しており、人々がWebサイトを構築するために使用するさまざまな開発環境のすべてに共通しているわけではありません。 質の高いWebエクスペリエンスを定義し、それらを構築するためのツールを提供する単一のエンティティはありません（多くの人が試しましたが）。
製品の開発に人員を配置することになると、Web用に構築する方法を知っている人を雇うのは間違いなく簡単です。 私が入力すると、プログラミング言語インデックスは現在JavaScriptを最も人気のある言語としてランク付けしており、そのすぐ後ろにJavaがあります。 C＃は5位、HTMLは7位、CSSは9位、Swiftは15位です。 このインデックスは、GitHubのパブリックリポジトリで変更された行を持つStack Overflowタグを相互参照するため、一粒の塩で解釈する必要がありますが、多くの人々がWebテクノロジーを知っている（そして使用している）ことをかなり明確に示しています。 反対に、才能のあるネイティブ開発者を見つけて採用するのは難しい場合があります。なぜなら、彼らの数は少なく、需要が高いからです。
才能が不足しているということは、ネイティブ開発により多くのお金を払うことになる可能性が高いことを意味します。 プロジェクトはそれぞれ明らかに異なり、機能や要件も異なりますが、平均的な開発コストを比較してみるとわかりやすくなります。 Comentumは、適度なサイズのWebアプリの構築は10,000米ドル未満から150,000米ドルの範囲であることを示唆しています。 ネイティブエンドでは、Appsterは、中規模のモバイルアプリプロジェクトの構築にかかる費用は110,000〜305,000米ドルと見積もっています。 ネイティブプロジェクトの開発には、Webプロジェクトの約2倍の費用がかかる可能性が高いと想定するのはおそらく安全です。 そして、それはプラットフォームごとです。 ネイティブアプリも通常、開発に時間がかかります。
PWAを構築せずにWebテクノロジーを使用してネイティブソフトウェアを構築するためのオプションがあることは注目に値します。 React Native、PhoneGap、Ionic、Appcelerator Titaniumなどのフレームワークを使用すると、HTML、CSS、JavaScriptからネイティブコードを生成できます。 これらのツールのいずれかを使用すると、ネイティブ開発者のチームを雇う場合と比較して、人件費と開発コストを削減できますが、デバイス機能へのアクセスに関しては、プロジェクトはフレームワークが実装したものに限定されます。 それに応じて計画します。
アプリが開発されたら、その1つまたは複数のアプリの継続的なメンテナンスコストも考慮する必要があります。 Clutchが実施した調査に応じて、Dom＆Tomは、製品の初期価格の1年目は50％、2年目は25％、その後は毎年15〜25％の予算を立てることを推奨しています。
Webとネイティブ開発の比較と対比を適切に把握したら、プロジェクトに関連する長所と短所の評価を開始できます。 いくつかのトレードオフを行う必要がある可能性があり、それは予想されることです。 万能の解決策はありません。 そして、もしあったとしても、それは誰にもうまく適合しません。
ネイティブとPWAの開発の違いに焦点を当てるために、いくつかの架空のプロジェクトを実行してみましょう。
プロジェクト＃1：既存のネイティブアプリ
ネイティブアプリを構築するプロセスをすでに完了しているとしましょう。 すべてが順調に進んでいれば、コースを変更する理由はありません。 本当に正当な理由がない限り、PWAに切り替えるために既存の作業をすべて破棄しないでください。 PWAへの切り替えを検討する必要があるシナリオは1つしか考えられません。それは、新しいOSのサポートを組み合わせることです。 それでも、アプリのニーズがWebだけで満たされる場合にのみ本当に意味があります。
製品に新しいプラットフォームのサポートを追加する場合、それらのニーズを満たすためのコストに関して、プロジェクトのニーズと目標を評価する絶好の機会が作成されます。 Webが問題を解決できない場合は、ネイティブを使用してください。 ただし、一時停止して次のことを検討してください。PWAを使用して新しいプラットフォームのサポートを追加すると、将来的に追加のプラットフォーム（Webを含む）をサポートできるようになり、PWAが追加されたら既存のネイティブアプリケーションを置き換えることもできます。徹底的にテストされています。
既存のネイティブアプリをPWAに置き換えることが考えられない場合は、次のことを検討してください。スターバックスとTwitterはすでにこのアイデアを模索しています。
アプリをネイティブに保つ必要がある特定の理由がある場合でも、特定のアプリ機能をWebに「アウトソーシング」することを検討する価値があります。 数年前、私は大手金融サービス会社のプロジェクトに取り組んでいました。彼らは、通常のアプリストアよりも迅速にセキュリティ機能を展開できるようにするために、ネイティブアプリのログインフローをウェブに移動することを選択しました。承認プロセスにより、彼らは達成することができました。 おそらくあなたのプロジェクトには、ウェブがあなたのネイティブアプリが満たす力を与えることができるのと同様のニーズがあります。
プロジェクト＃2：既存のクロスプラットフォームアプリ
クロスプラットフォームで動作する既存のアプリをお持ちの場合は、そのアプリの継続的な開発とメンテナンスに多額の資金を投入している可能性があります。 また、各ネイティブプラットフォームには独自の開発タイムラインがある傾向があるため、アプリ内機能の相違も見られる可能性があります。 たとえば、小売業者Targetのアプリでは、現在、ユーザーはiOSでショッピングリストを管理できますが、Androidバージョンにはその機能がありません。 多くの点で、これはWebサイトの「デスクトップ」バージョンと「モバイル」バージョンの間に時々見られる相違に似ています。
Webがすでにクロスプラットフォームミックスの一部である場合は、そこでの投資を倍増し、ネイティブアプリをPWAに置き換えることを検討する良い機会を提供します。 ソナーや灯台などのツールは、既存のサイトがPWA化のためにどれだけ準備されているかについての洞察を提供し、また、何に取り組む必要があるかを教えてくれます。 そこから、WebサイトをPWAに変えるのは比較的簡単です。 数分でサイトをPWAにアップグレードするのに役立つ無料のツールもあります。 ただし、そうでない場合は、プラットフォーム間の機能の相違が非常に深刻になるか、さらに別のネイティブプラットフォーム（またはWeb）をミックスに追加することを検討している場合を除いて、この動きをするインセンティブはあまりありません。
プロジェクト＃3：新しいクロスプラットフォーム製品
複数のプラットフォームを対象とした新しいプロジェクトを開始する場合は、PWAとして1つの場所でプロジェクトを作成および維持することは、間違いなくテーブルにあるはずです。 予算とスタッフによっては、予算を最も伸ばす可能性があります。 ただし、製品でハードウェアまたは基盤となるOSに直接接続する必要がある場合でも、ネイティブにする必要がある場合があります。 ただし、そのルートに進む前に、すべての要件のリストを作成してから、Webで何ができるか（そして何ができないか）を確認してください。 複数のブラウザでもサポートを確認してください。
プロジェクト＃4：新しいハイパーフォーカス製品
新しい製品を構築していて、その製品の全体的な目的の一部が特定のプラットフォームとの深いつながりである場合は、必ず、そのプラットフォーム用に構築してください。 たとえば、製品がAppleのMessagesプラットフォームまたはHomeKitとの統合に依存している場合は、必ず、SwiftでiOSおよび/またはmacOS用にビルドしてください。 製品がウィジェットを介してユーザーのニーズを最もよく満たす場合、またはカスタムランチャーを構築する場合は、Androidを構築するのが最善であり、Javaを使用する必要があります。
ただし、すべてのネイティブ機能が壁に囲まれた庭園であるとは限りません。 AmazonのAlexa、AppleのSiri、およびGoogleアシスタントはすべて、アプリと統合するためにネイティブコード（またはJSON API）を必要としますが、興味深いことに、MicrosoftのCortanaは、HTMLのheadからリンクされたXMLファイルのみを使用してPWAを音声対応にします。 おそらく他の人が彼らの先導に従うでしょう。
PWAまたはネイティブ？ 選択はあなた次第です
ウェブとネイティブはそれぞれ提供するものがたくさんあります。 どちらがいいかと聞かれたら、「状況次第」と答えるだけです。 私は回避的でも非コミット的でもありません。 プロジェクトに最適なものを判断することは、プロジェクトの特定のニーズに完全に依存します。 それはあなたが構築しているもの、それを構築することを任されている既存のチームまたはあなたがそうするために雇う必要があるチームの構成、そしてあなたが一緒に働かなければならない予算を考慮に入れる必要があります。 多くの場合、Webはプロジェクトの目標を達成するために必要なすべてを提供しますが、常に例外があります。 Webが提供する可能性を探求したい場合は、この記事の最後にいくつかのリソースを含めました。
ソフトウェア開発へのさまざまなアプローチ、またはさまざまなフレームワーク、ライブラリ、言語、設計システムなどを比較検討するときに実行できる最も重要なことは、目前のプロジェクトに関連するオプションを検討することです。 あなたの研究をして、あなたの選択肢を比較検討してください。 そして、巧妙なマーケティング、セクシーなデモ、または熱狂的なファンボーイによって、自分自身が何らかの形で動揺することを許可しないでください。 これも含めて。
PWA関連のリソース
- PWAビルダー
役立つ推奨事項とレシピを備えた3ステップのWebサイトからPWAへの作成ツール。 また、PWAをWindows、Android、およびiOS用のインストール可能なネイティブアプリに変えることもできます。 - プログレッシブWebアプリのプログレッシブロードマップ
Jason Grigsbyは、彼のチームが数か月の間にPWAの側面をWebサイトに組み込み始めた方法について説明し、さまざまな機能を少しずつ追加する方法をうまく示しました。 - はい、そのWebプロジェクトはPWAである必要があります
あなたが本当に書いた、PWAのUXの機会（およびリスク）の概要。 - MDNのプログレッシブウェブアプリ
高品質のPWAの特徴について知っておく必要のあるすべての技術的な要素のハブ。 - Webが今日できること
デバイス、OS、およびブラウザがサポートするAPIを確認してください。 あなたが見つけたものはあなたを驚かせるかもしれません。 - 使ってもいいですか
すべての主要なブラウザーで使用可能なAPIと機能、およびそのサポートが実際に使用しているブラウザーと比較してどのように測定されるかについての最も信頼のおけるデータベース。 また、特定の機能の下位互換性を確認するために、過去の優れたビューを提供することもできます。