🍻

iOSDC Japan 2020 に「Webとネイティブアプリの付き合い方を改めて考える」というタイトルで登壇しました

2020/09/26に公開

2020/9/19〜21 に行われた iOSDC Japan 2020 でPWAやWebの話をしました。
リアルタイムでご覧いただいたみなさま、また開催後にタイムシフトやアーカイブでご覧いただいたみなさま、ありがとうございました。

この記事は「Webとネイティブアプリの付き合い方を改めて考える」に関する補足&感想記事です。
プロポーザルやスライドと合わせてご覧ください。

プロポーザル: https://fortee.jp/iosdc-japan-2020/proposal/d996c43a-834b-4bfe-b15a-67457725da02

発表内容の補足

動画の冒頭で、せっかくWebに関するトークので、どんな方が聞いているのかなと思い(コメント書き込みへのハードルを下げる意味も込めて)、簡単なアンケートを取ってみました。

あなたはどんな人ですか

アンケート結果

技術選定に近いトークテーマだったこともあってiOSエンジニアの方のほか、テックリードや何でも屋フルスタックエンジニアの方など、様々な方がいらっしゃっていたのが印象的でした。結構バックエンドの方もiOSDCに参加されているんですね……!

Web, PWA, ネイティブアプリ, App Clips のできることできないこと

発表の前半は、この表を埋めながらiOSにおけるWeb、PWAの簡単な紹介、App Clipsの紹介を行う形にしました。各技術の概要とこの表の内容がある程度把握できていれば、正直技術選定そのものはケースバイケースだとは思っています。

クロスプラットフォーム

この表に入れられておらず、また質問を多くいただいたのが、クロスプラットフォームやWebViewを活用したいわゆる「ガワアプリ」に関する内容です。
クロスプラットフォームとしては、昨今だとFlutterが一番人気なイメージです。ほかにもKotlin Multiplatform MobileReact NativeCapacitorなどが有名どころでしょうか。日本の接触確認アプリで使われたのはXamarinでした。

これらクロスプラットフォームは、大きく2つに分けることができます。

WebViewタイプ

  • プラットフォーム側で生成したWebViewの中で、開発者が作成したHTMLやJavaScriptを実行して動作させる仕組み
  • 画面構成まで含めてWebの知識だけでAppStoreに提出できるアプリを作成できる
  • 上記で挙げた例ではCapacitorがこれにあたる
  • Cordova (PhoneGap) など、以前のクロスプラットフォームといえばこのタイプだった

ネイティブ変換タイプ

  • 別の言語(JavaScript, Kotlin, Dart …)でロジックとUIを記述し、SwiftやObj-Cのコードにビルド時に変換する仕組み
  • このビューを出すにはこのクラス、といった対応するパーツを組み合わせて実装する
  • Flutterなど、最近のクロスプラットフォームにはこちらが多い印象

私個人としてWebViewタイプのプラットフォームでアプリをリリースしたことはあるのですが、ネイティブに変換する系のプラットフォームはまだ触れたことがなく、知らないのに考察もできないなと思って発表からは除外していたのでした。

知っている限りでクロスプラットフォームに関する特徴を挙げてみると、以下のようになります。(本格的に触れたことがないため、事実と異なる点がありましたらぜひご指摘ください……)

  • 最終的にネイティブアプリの形でのリリースとなるため、Swift等での実装と機能面での差はない
    • WebViewタイプの場合はどうしても標準UIのようなリッチなアニメーションなどの実装が難しいが、変換されるタイプの場合はUI面のギャップも埋めやすい
  • ただ、OSの機能の呼び出しはプラットフォーム側で用意されているブリッジの仕組みを使うことになるはずなので、最新機能などはプラットフォーム側の対応待ちになるケースもある
    • 特にOSの新機能などにいち早く追従したい場合、Swiftの方が強いことは多い
  • OSごとにUIやできることに違いがあるので、差異が出る部分はどうしても共通化が難しくなる
    • またはどちらかに寄せて実装した場合、もう一方のOSではどうしても使いづらくなる
  • ネイティブ用しか提供されていないOSSやSDKを使いたい場合、自分でブリッジする必要がある
    • ライブラリなどは各プラットフォームでも力を入れているものの、ネイティブと比べるとどうしても規模は小さく見える
    • 広告SDKなどはネイティブのみ対応していることも多い

両OSに対応することはできるものの、使いこなすために両OSのネイティブアプリ開発の知識が必要になることも多く、必要とされるスキルが多いというのが個人的な印象です。両OSのアプリストアに同時にアプリを配信できるメリットは大きいですが、その分細かい要件に対応するための学習コスト(またはプラットフォームを使いこなせるエンジニアの人数)がリスクになるのかなと思います。

Webにはないアプリのメリットとは

このトークでは「Webでできることも結構あるよ」というのが大きいテーマとなっていますが、Webでもアプリでも提供できるサービスを「あえてネイティブアプリで出す」ことのメリットについても質問を受けました。

トークで触れた内容とも被りますが、いくつか挙げてみます。

ホーム画面からのリテンション

トーク中には「Webでもホーム画面に追加できる」とお話しましたが、実際にiPhoneでWebページをホーム画面に追加するという行動はあまりユーザーに浸透していません[1]。ホーム画面に並んでいるのは(AppStoreからダウンロードした)アプリであるという認識の方が強いでしょう。iOS14になってホーム画面の考え方もかなり変わりましたが、Appライブラリも含めて、ホーム画面からのリテンションを考えるならネイティブアプリに軍配が上がると言えそうです[2]

ユーザー層の違い

トーク中でも触れていますが、Webを活用するユーザーとAppStoreからアプリをダウンロードするユーザーでは、若干ユーザー層が異なります。AppStoreをよく使うユーザー層にリーチしたい場合、ネイティブアプリで展開するメリットは大きいと思います。AppStore上の各種特集やストーリーで取り上げられた場合、ユーザー数を伸ばすことができるというのもネイティブアプリのメリットだと思います。

ネイティブアプリならではの操作感やユーザーの慣れ

iOSの場合、ネイティブアプリのUIはHuman Interface Guidelineに沿った形になることが多いです。ダウンロードしたばかりのアプリでもそれほど混乱せずに使うことができるのは、ナビゲーションバーやタブバーの使い方、左上の戻るボタン、右上の完了ボタンなど、各アプリがガイドラインに沿って一貫したUIを構築しているためと言えるでしょう。ガイドラインに沿った開発がしやすいように、開発者へのサポート[3]も手厚くなっています。

Webの場合このような制約がない変わりに、ユーザーは初見の画面に対して操作方法を学ぶところから始めなければいけません。ユーザーが使いやすいUIを提供することはWebであってもネイティブであっても大切なことですが、Webの場合はそのようなサポートがない分、より慎重な設計が求められると思います。

また、たとえネイティブに寄せたUI設計をしたとしても、その操作感をネイティブアプリと同等に引き上げるのはそう簡単ではないと思います。手軽にリッチな操作感を提供できるのは、ネイティブアプリの特権と言えると思います。

ネイティブアプリにしかできない機能

これもトーク中に触れていますが、WebKitではサポートされていない機能を使ったサービスを提供する場合、ネイティブアプリの選択肢を取らざるを得ないケースがあります。

プッシュ通知についても(これはAppleの方針なのか)iOS14時点ではWebでの利用がサポートされていません。特にプッシュ通知はリテンション施策の中で話題に上がることも多いと思いますが、Webを利用しているユーザーに通知を送るには、メールなど別の手段をとる必要があります。

セキュリティ面でのメリット

サービスの起動経路が限られているため、通信内容を見られづらく、攻撃者からの攻撃を受けづらいというのもネイティブアプリのメリットの一つかもしれません。もっとも、これはサービスの表面がインターネット上に出ていないから攻撃を受けるリスクが一つ減るというだけの話であり、アプリが裏でやりとりしているAPIがアクセス可能な状態であることには変わりありませんから、セキュリティ面で手を抜いて良いという話ではありません。アプリの仕組みそのものの脆弱性を突いた攻撃もありますので「セキュリティ面でメリットがあるから」という理由だけでネイティブアプリを採用するのはやめた方が良いような気がします。

スピーカーとしての感想など

きっかけ

今回は、iOSのネイティブアプリ開発に関する発表が多いiOSDCでは珍しくWebの話をしました。サービス提供にあたって、最近ではいろいろな選択肢が取れるようになってきたので一度整理したいなと思っていたのと、App Clipsの立ち位置を整理しておきたいな、と思ったのがプロポーザルを出したきっかけでした。

また、業務でiOS開発に触れる機会が減ってしまって話すネタが見つからなかったこと、また業務の中でPWAについて調査をする機会があったこともきっかけの一つです。今回の発表も、そこで調査をした内容を一部ベースにして作成しています。

事前収録

今回のiOSDCは事前収録でした。最初は収録の枠を取ったことを忘れていて収録用のZoomに入れず、結果としてforteeの収録システムのバグを踏んでしまうなどいろいろありましたが、なんとか無事に収録することができました。

噛んでしまった箇所があったり、後半の展開をもう少し練り直した方がいいかなと思ったりもして、再収録をしようか迷いましたが、悩んでいるうちに収録期間が過ぎてしまったのが若干の後悔です。妻が寝ている真夜中に収録をするわけにもいかず、夜中の枠が取れなかったというのもあるかもしれません。

ニコニコ生放送

当日はコアスタッフとして、配信会場でトーク配信の補助をしていましたが、自分のトークの間はスタッフ業を離れ、自分の放送を見ていました。他のスピーカーの方も同様のようですが、事前収録なのに直前はものすごく緊張していました。事前収録だったため、直前の悪あがきが全くできなかったのも緊張した要因の一つかもしれません。

また、iOSDCで久しぶりにニコニコを利用しましたが、思わぬところ[4]でコメントの反応があったり、最後に拍手の弾幕をいただいたりと、とても楽しく過ごせました。参加者の方がとても温かく、ありがたい限りです。

Discord

これについてはまず謝らねばなりません。コアスタッフとしての配信担当がTrack Dだったのですが、私のトークはTrack Bで行われていました。そのせいで頭が混乱してしまったのでしょう、最初パブリックビューイング会場を間違え、Track Dのチャンネルで独り言を呟いておりました。大変お恥ずかしい限りです、その場に居合わせたみなさま、大変失礼いたしました……。

Ask the Speakerについては、多くの方にご参加いただき、質問もたくさんいただけて非常にありがたかったです。この補足記事のほとんども、コメントやAsk the Speakerでいただいた質問をもとに作成させていただきました。ありがとうございました。

さいごに

今回は初のオンライン開催でしたが、オフラインと変わらずとはいかないものの、オンラインならではの楽しみ方をさせていただけたのかなと思っています。オンラインでの登壇は初めての経験でしたが、最後まで楽しく過ごすことができました。来年もまたみなさんと技術のお話ができるように、また頑張ろうと思います。ご参加いただいたみなさま、ありがとうございました。

脚注
  1. 私の場合、iPhoneでは開きっぱなしのタブから探すことが多く、ブックマーク機能すら使わなくなりました…… ↩︎

  2. ホーム画面に追加したブックマークはAppライブラリには入れられないため、ホーム画面をカスタマイズしたいユーザーと「ホーム画面に追加」は相性が悪いとも言えます ↩︎

  3. UIKitなど、豊富なAPIが提供されています ↩︎

  4. 多くのコメントをいただいた背景のカーテンですが、これはニトリで買ったような気がします(数年前に買ったのですが、今調べても出てこないので、終売したのかもしれません……)。ハリネズミが可愛いので私も気に入っています ↩︎

Discussion