【はじめてのアプリ開発・番外編】Webビュー？ネイティブ？それぞれのメリット・デメリットを解説

Webビューアプリというのは、アプリの中でWebページを表示させているアプリを指します。アプリで箱だけ作って、中身はWebページを参照するので「アプリ内ブラウザ」と言ったりしますね。

一方、ネイティブアプリは、コンテンツの中身も含めて各OSに対応する言語で開発したアプリです。

その前に、「そもそもアプリで作る必要があるのか？」ということから考えるようにしています。確かに、アプリはWebサイトに比べてできることが多いですが、当然コストも高くなります。

クライアント様が提供したい価値や体験は、本当にアプリでなければ実現できないのか？という点は、最初に議論するところです。

アプリをつくることがゴールになってしまっているケースは、意外と多いですね。

アプリはインストールしないと中身が覗けません。ユーザーにアプリをインストールさせる障壁は高いですし、アプリのみのサービスは認知・拡散が苦手分野なんです。

特に記事メディア型のサービスの場合は、記事の拡散やバズで認知が伸びていきますから、せっかくバズっても受け皿がアプリしかないと、取りこぼしが多くなります。リリース後の認知拡大のフェーズで苦戦してしまうんですね。

そういう場合に、僕らから提案させていただくのがWebビューアプリです。まず、Webでメディアを構築して、それを参照するWebビューアプリをつくれば、Webサイトの発信力や拡散性、アプリならではのプッシュ通知機能など、両方のいいところを使えます。

コスト的にもWeb構築のコスト＋αでできますから、メリットが大きいですね。

Webサイトをすでにお持ちであれば、そのWebサイトを閲覧するWebビューアプリのみを構築すればいい。前回の記事で通常５～6か月の開発期間と言いましたが、こういうケースなら１～2か月でリリースに漕ぎつけられることもあります。

ネイティブアプリはネイティブアプリで、起動や動作処理が速い、というメリットがあります。

アニメーションなどの表現の幅も、Webビューに比べると広いですね。また、OS側と密接に連携する機能を実装するような場合も、ネイティブでなければ実現できないものもあります。

Webビュー、ネイティブそれぞれに強みがあるので、クライアント様の提供したい価値に合わせて判断をしていくことになります。そのときにやはり重要なのは、「ユーザー目線」だと思っています。

スムーズな操作感が、サービスの提供価値と切り離せない、と判断すればネイティブをお勧めしますし、記事の閲覧などがメインのプロダクトなら、操作感よりも、常に新しいコンテンツが提供される更新性の高さが重要ですから、Webビューの方が向いている。ケースバイケースで判断しています。

補足すると、ネイティブアプリだと、コードを一行変更するだけ、例えば、アプリに埋め込まれた文字を一文字修正するだけでも、それを反映するためにアプリのアップデートが必要になります。

実際のアプリ修正作業に加えて、アプリストアへの申請や審査も必要になりますから、反映に時間もかかります。Webビューなら、Webサイト側のHTMLを変更するだけで、当然アプリにも反映されます。

更新性の高いものや、クライアント様側で自由に変えたいコンテンツの場合は、Webビューで作って、管理画面からHTMLを編集できるような作りをご提案するケースが多いですね。

クライアント様とお話する中で、少し誤解があるのかなと思うのは、ネイティブで作ったからといって劇的にユーザー体験が上がるわけではないということです。

「良いユーザー体験を提供したいから、ぜひネイティブで」と言われることもあるのですが、それはWebビューでも実現可能なことだったりします。

ネイティブならヌルヌル動く、というのはもう何年も前の話ですね。いまではパフォーマンスの差はごくわずかです。それよりは、デザイン面が大きいかなと思いますね。ネイティブで作るとOSレベルでデザインされたコンポーネントを使うので、デザインの統一感が出やすい。

一方、Webビューアプリでは、アプリの中からWebサイトを覗くわけですが、Webサイト側がアプリで見ることを想定せずにデザインされていると、ごちゃごちゃして見えるということはあります。

「アプリを作ったけど、デザインがイマイチだから作り直してほしい」というご依頼をいただくことがあるのですが、こういったことが原因のケースが多いです。

逆にWebビューは、運用段階でも自由に画面を作れるメリットもあるので、一概に何が正解というのはなくて、ユーザー体験や運用面、コストなどを総合的に考える必要があります。本当にご要望は1件１件、千差万別なので、オーダーメイドでご提案することになりますね。

ちょっと脇道に逸れますが、狭義の「ネイティブアプリ」は、iOSならObjective-CやSwift、AndroidならJavaやKotlinなどの言語で開発したものを指し、iPhone用とAndroid用で別々に開発する必要があります。

PIVOTは、これらの対応ももちろん可能ですが、いまはFlutterで開発することが多いです。前回の記事でもご紹介しましたが、Flutterだと、iOS用とAndroid用を１つのソースコードで作れるので、コスト面でもスケジュール面でもメリットが大きいためです。

Flutterは、ここ数年で爆発的に普及した新進気鋭のフレームワークですが、歴史が浅い分、不安を感じられる方もいらっしゃいますね。

「コストメリットは魅力だけど、やっぱり怖い…」というような。そんな漠然とした不安でも、ぶつけていただけたら、できるだけ解消できるようなご提案をさせていただきます。

例えば、特定の機能だけSwiftやKotlinで作って、土台はFlutterを使う、ということも可能ですし、お互いにとってベストな方法を探れたらと思っています。

どんな方法がもっともやりたいことに合致するのかの判断は、ご担当者様では難しいことも多いと思います。

我々は、ひとつの方法に固執せず、メリットもデメリットも明示してフラットに判断しますので、クライアント様側も先入観を一旦捨ててご相談いただけると、議論が進みやすいのかなと思います。

議論を深めていく中で、自然とクライアント様とのコンセンサスが取れていきますし、同じ方向を向いてプロジェクトを進めていけると思います。