ネイティブアプリの緩やかな死とSPAのメリデメ比較

2019/03/05

タイトルは半分釣りですが、半分本気でそう考えています。

現在SPAでWebアプリを作る仕事をしていますが、遠くない未来、ネイティブアプリの時代は終わって、SPAで作られたWebアプリが主流になると思っています。

今回はネイティブアプリに変わるかもしれないSPAについて、具体的にどんなものか、ネイティブアプリと比較した場合のメリデメ等も考えていきたいと思います。

SPAとは何か?

SPAとは、SinglePageApplication(シングルページアプリケーション)の略称で、JavaScriptを使って、単一のページでコンテンツの切り替えを行う、Webアプリケーションを作る為の手法です。

このポートフォリオサイトも、SPAで作っています。

非同期通信を使って、ブラウザによるページ遷移を行わずに、コンテンツを切り替える事ができます。

裏側のHTMLはheadとCSSとJavaScriptしか存在せず、JavaScriptがDOMの切り替えを行なっています。

Pjaxと何が違うの?

少し話が脱線してしまいますが、非同期通信が出来るjQueryライブラリに、Pjaxというものがあります。

Pjaxは、URLを変更すると非同期でコンテンツを入れ替えてくれるライブラリで、SPAとは違い遷移先にページが存在しています(HTMLがある)。

SPAの場合、実際には遷移先にページが存在しておらず、JavaScriptでDOMとURLを動的に切り替えて、リクエストがあった差分のみを描画しています。

アプリ開発の現状

SPAは、非同期通信による滑らかな挙動、豊富なライブラリ、安全な認証等、ネイティブアプリと比較しても遜色ない環境が揃っていますが、まだ広く普及しているとは言い難いと思います。

裏側の管理画面や、単一ページをSPAで開発しているケースはありますが、アプリケーションそのものをSPAで開発しているプロダクトは、まだそう多くはないのではないでしょうか?

エンジニア的なコストはあまり詳しくはないですが、AWSやモジュール設計、セキュリティやパフォーマンスを意識した要件定義、およびコーディングが出来る人はそう多くありません。

デザイナー的にも、通常のWebアプリと同等の設計、つまりPC・タブレット・スマホ毎に設計が必要だったり、参考サイトやノウハウが少ない中での設計、ネイティブアプリと比べて足りないものを別のアプローチで補わないといけなかったりするので、要件定義や設計手法が手探りになる事が多いです。

SPAの代表的なプロダクト

Slack
IT業界でよく使われているコミュニケーションツール。
SPAで作る事によって、ブラウザとデスクトップアプリで同じ画面を使う事が出来ている。
APIと連携して通知が送れるのも、SPAで作成されているから。
Figma
比較的新しいプロトタイピングツール。
こちらもSPAで作る事によって、ブラウザとデスクトップアプリで同じ画面を使う事が出来ている。
データバインディングを使う事によって、複数人での共同編集も可能にしている。
Twitter
ツイートの更新がリアルタイムで表示されるのは、SPAだからこそ出来る事。
GoogleMap
データバインディングの特徴を活かし、URLを変える事なく画面の切り替えを行なっている。

SPAのメリット

ネイティブアプリと比較して、運用コストが低い

運用コストが低いというより、ネイティブアプリの運用コストが高すぎるのかもしれません。

後述する様にクロスプラットフォームである為、デバイスによって言語が違うということはありません。全てJavaScriptで動作するので、Webブラウザがあればすぐ使う事ができます。

デザインも、iOS・Androidで別に用意するという必要性はなく、またブラウザで動くアプリケーションなので、PCで使用する事も可能です。

ストアによる審査がない

Webアプリケーションなので、ネイティブアプリと違いストアによる審査が必要ありません。

プロダクトが完成したら、サーバーにプッシュして、デプロイするだけですぐに反映されます。リジェクトされる心配はありません。

また、ストアに支払う登録料も維持費も必要ありませんし、ストアによる高い決済手数料を気にする必要もありません。

ネイティブアプリに近い挙動を実現できる

SPAはJavaScriptを使って非同期によるページ遷移を行うので、ネイティブアプリに近い挙動を実現できます。

ネイティブアプリと完全に同じ事は出来ませんが、非同期による滑らかな体験は、従来のWebアプリケーションには無かった強力な武器となります。

データバインディングが出来るので、ネイティブアプリの様に、URLを変えずにタップしたら要素だけ変える、という様な事も可能です。

クロスプラットフォームである

SPAはブラウザで動くので、デバイスを選ばないクロスプラットフォームです。これもSPAの強力な武器となります。

基本的にネイティブアプリは、iOS / Androidで言語も開発チームも異なるので、チームは同じでも同時進行で開発する事はあまりないかと思います。

もちろん、ブラウザによる細かい挙動や仕様を考慮する必要性はありますが、iOS / Androidで同じプロダクトを別で作ることに比べたら、コストは微々たるものです。

豊富な開発環境

今ではネイティブアプリで使える環境が、SPAを使えばWebアプリケーションでも使える様になってきています。

例えば、このサイトでも認証で使われているFirebase Authenticationは、ネイティブアプリでもWebでも使う事が出来ます。

SPAのデメリット

プッシュ通知が使えない

現状SPAの一番の課題になっているのは、このプッシュ通知が使えない事ではないでしょうか?

一応、WebPushという技術を使えば限定的に使う事はできますが、それでもiOS/Safariではサポートされておりませんので、必然的にiPhoneでは使えない事になります。

プッシュ通知が欲しい場合は、別のアプローチを試みる必要があります。

デザイナー・エンジニア共に経験者が少ない

SPAはまだ現状のアプリケーションの主流になりきれていないので、デザイナー・エンジニア共に経験者が少ないのが現状です。

業務ページ、単一ページをSPAで作成される事はあっても、プロダクトそのものにSPAが使われているケースは、国内ではまだ多くありません。

高度なJavaScriptの技術が必要

正確にいうとデメリットではありませんが、SPAは今までサーバーサイドで行なっていた処理を、JavaScriptを使ってクライアントサイドで実行するので、必然的に高いJavaScriptの技術が必要になります。

SEO対策に注意が必要

現在はそうでもありませんが、SPAは裏側にHTMLが存在せず、JavaScriptを使って動的にDOMを切り替えるので、ほとんどがクローリングの対象外です。この問題を解決する為には、別途SEO対策をする必要があります。

ただ、このポートフォリオサイトで使われているNuxt.jsであれば、modeを変更するだけで簡単にSEOで必要な要素を書き出してくれるので、現在ではあまり心配する必要はないかもしれません。

初期表示に時間がかかる

初期ページで必要なものを全て読み込む性質上、初期表示に時間がかかる事が多いです。

アナリティクスの設定が独特

慣れの問題なのですが、SPAでGoogleアナリティクスを導入する場合、公式から出ているライブラリを導入して、別途設定をする必要がある為、ネットによくある普通のサイトにアナリティクスを設定するやり方は、通用しない事がほとんどです。

また、通信が発生しない都合上通常のやり方ではイベントトラッキングが出来ないので、トラッキングさせるには、別途特殊な設定が必要だったりもします。

ジェスチャーが使えない

まだまだJavaScriptでは、ネイティブアプリの様な豊富なジェスチャーは使えないのが現状です。

ですが、ほとんどのジェスチャーはボタンアクションでサポート出来るので、あまり困る事もないですが。

ネイティブアプリのメリット

SPAのメリデメと反するものが多いですが、整理する為に改めて書いてみます。

プッシュ通知が使える

SPAと比較して、一番のメリットはこれではないでしょうか。

ネイティブアプリはプッシュ通知によるアプローチが出来るので、アプリはインストールしたけど使っていない様な休眠ユーザーを掘り起こしたり、PRしたいものを効率的にアプローチする事が出来ます。

ホーム画面に追加してもらえる

SPAとネイティブアプリで挙動が変わらないのであれば、インストールしてもらう事で生まれるメリットは、これではないでしょうか。

SPAでもホーム画面にアイコンを追加してもらう事は出来ますが、Androidはホーム画面にアイコンを追加する画面を出せるのでいいですが、iOSの場合はまだサポートされていませんので、ホーム画面に追加する場合、Safariから自分でやってもらうしか方法がありません。

ノウハウが豊富

ストアにネイティブアプリが豊富にあるので、参考事例を探すのに困る事はありません。

ジェスチャーが使える

ボタンアクションで賄えますが、表現が豊富であればアプローチできる幅が広がるので、ジェスチャーを使えるのは魅力的だと思います。

PCのデザインを作らなくていい

ネイティブアプリの場合スマホで動くので、PCのデザインを作らなくて良いのは、工数が一つ減ることになります。

マシンスペックをフル活用できる

ネイティブアプリは端末に直接インストールするので、マシンスペックをフル活用したアプリを作る事が可能です。

なので、加速度センサーを利用したアプリ、ゲーム、カメラを利用する事を前提としたアプリの場合、ネイティブアプリの方が良いです。

ネイティブアプリのデメリット

運用コストがとてもかかる

これがネイティブアプリの一番のデメリットだと思います。

SPAが登場する以前は致し方なかったですが、SPAが出てきた今、Webアプリケーションとネイティブアプリの差異は、プッシュ通知以外ほぼ無いと言っても良いかもしれません。

そうなるとSPAと比較して、プラットフォームが異なるiOS/Androidでアプリを開発するのは、運用コストがもの凄くかかってきます。

正確な数値が測れない

アプリの場合、KPIを設定しても正確な数値が測りにくいです。

個人的に「運用コストがとてもかかる」のは、実装コストでもデザインコストでもなく、この計測コストだと思っています。

実装コストもデザインコストも、資金があれば人に頼めば解決しますが、計測コストのずれは本質的な問題なので、お金で解決できません。

アプリの場合、Webから遷移したユーザーの動向は追えないので、以下の様な問題が発生します。

KPIがWebからアプリのダウンロード数を伸ばす場合

よくあるアプリへダウンロードするボタンを置く場合。

アプリダウンロード数(CV) / ボタンのトラッキング数 * 100 = CVR

という事になりますが、イベントを発火させたユーザーが、アプリをダウンロードしたのかは計測出来ないので、CVRを測ることは出来ません。

この「イベントを発火させたユーザー」というのがとても大事で、アプリのダウンロードには様々な遠因があり、仮に施策を実施後にダウンロード数が伸びても、イベントトラッキングの数値を元にCVRを計測しないと、「偶然かもしれない」という不安が拭えないのです。

確実な数値で効果を計測出来ないと言う事は、事例として蓄積しないので、CVRを測るための指針にはならないのです。

結果が全てなのに、自分たちがやっている事が本当に結果が出ているのか計測出来ないというのは、とてももどかしいものがあります。

インストールに時間がかかる

SPAの場合ネットに繋がないと使えませんが、裏を返せばそれは、インストールしなくてもページさえ開けば、すぐ使えるということです。

ネイティブアプリの場合インストールしないと使えないので、蓋を開けるまでどの様なアプリか分かりません。

よく分からないアプリを開く為に、わざわざインストールするでしょうか?

Webと違ってネイティブアプリの場合、広告を出してもその後「使ってもらう」為の工夫が必要なのです。

ストアの審査がある

ストアによる審査があるので、ネイティブアプリの場合本番に反映されるのが遅いです。

バージョン管理が大変

あまり詳しくは無いですが、アプリの場合バージョンを上げていかないとリジェクトされて更新が出来なくなるので、定期的にバージョンを上げていかないといけません。

SPAならサーバーにプッシュすればいいだけですが、アプリはそうもいかないみたいです。

ではどう住み分けしていくか?

ではWebとアプリはどう住み分けしていけばいいのか?

Webで完結するビジネスモデルならWebで

やりたい事をヒアリングしていくと、「それって本当にアプリでやった方がいいのかな?」と思う事があります。

「何となくアプリにしたいんだよね」という理由なら、ネイティブアプリはコストがかかるので、Webで高速にリリースしてく方が良いと思います。

マシンスペックを使いたいならネイティブアプリ

ネイティブアプリの良いところは、やはりマシンスペックを思う存分に使える事だと思います。

各種センサーを利用したアプリ、GPUとCPUを酷使するゲーム、カメラアプリ等々。

SPAの場合ライブラリーが対応してくれるまで待たないといけないので、やりたい事と比較して、最新鋭のテクノロジーを活用したいなら、ネイティブアプリが良いと思います。

Webとアプリは完全に切り離す

Webとアプリは完全に切り分け、具体的な効果の計測、それぞれの出来ること・出来ないこと、メリット・デメリットを完全に切り分け、具体的に定量的な数値を計り、改善を繰り返していく事が大事だと思います。

Webで出したらアプリは出さない!アプリはWebサイトは作らず広告だけでPRする!

が理想だと思います。

まとめ

まとめますと、運用コストがめちゃくちゃかかるネイティブアプリより、今ならSPAで開発する方が遥かに効率的では?ということです。

SPAも開発コストがかかるので、ブログの様な直帰率が高いサービスにはオーバースペックかもしれませんが、滞在時間が長いアプリケーションにはとても適しています。

お問い合わせはこちら