第2部 Web サービスの仕組み・第5章
Web と比べたスマホアプリの制約を、企画とリリースの判断に使える範囲で押さえる。
| 作り方 | 特徴 | 向いている場面 |
|---|---|---|
| ネイティブ（iOS は Swift、Android は Kotlin） | OS の機能を一番使える。iOS と Android で2回作る | 動きの速さ・OS の新機能が大事 |
| クロスプラットフォーム（Flutter・React Native など） | 1つのコードで両方に出せることが多い。OS の新機能への対応は少し遅れることがある | 両方を少ない人数で作りたい |
| Web（スマホのブラウザ・PWA） | 審査なしですぐ直せる。通知や端末の機能に制限がある | 更新が多い・まず試したい |
どの作り方かで、「iOS だけ先に出す」「OS の新機能に対応する」の工数が変わります。自分のプロダクトがどれで作られているかは最初に確かめておきます。
スマホアプリは App Store・Google Play の審査を通す必要があり、数時間〜数日かかることがあります。すぐに直して出し直せないので、サーバー側の Feature Flag で機能を止められる作りが特に大切です。
| 仕組み | 内容 |
|---|---|
| App Store の段階的リリース | 7日かけて配信の対象を少しずつ広げる。途中で一時停止できる |
| Google Play の段階的公開 | 公開する割合を自分で決めて広げ、問題があれば止められる |
| 戻せないこと | 一度入れた版は端末から戻せない。直した版を新しく出す |
| 強制アップデート | 古い版では使えないと案内する画面。使う条件を事前に決めておく |
| アプリ内課金 | デジタルの商品は、ストアの決済を使うルールと手数料がある。最新の規約を確かめる |
プッシュ通知は、アプリを開いていないときでも、サーバーからスマホの画面に知らせを出せる仕組みです。セールのお知らせ・発送の連絡・メッセージの着信など、利用者を呼び戻す強い手段ですが、利用者の許可がないと届かないうえに、断られると取り戻しにくいという制約があります。
そのため「いつ許可を聞くか」「許可されなかったときにどうするか」は、技術の話である前に仕様の話です。PdM がこの制約を知っておくと、通知に頼った施策の見込みを立てやすくなります。
プッシュ通知は、自社のサーバーから Apple の APNs や Google の FCM という配信サービスを通って端末に届きます。iOS では通知にユーザーの許可が要り、Android も 13 以降は許可が要ります。許可の画面は一度断られると、ユーザーが設定から戻さない限り出せません。
| OS の許可が要るもの | 仕様で考えること |
|---|---|
| 通知 | 最初の起動ですぐ聞かず、価値が伝わる場面で聞く |
| 位置情報 | 「使用中のみ」で足りるか。常に取る理由を説明できるか |
| カメラ・写真 | 使う直前に理由を添えて聞く |
| トラッキング（iOS の ATT） | 他社のアプリやサイトをまたいだ追跡には許可が要る。広告の効果の測り方に影響 |
許可されない前提で、通知がなくても使える流れ（アプリ内のお知らせ・メール）も用意しておきます。
下の「ブラウザで試す」の図では、アプリが通知の許可をもらって端末の宛先（デバイストークン）を受け取り、自社のサーバーに登録するところから始まります。そのあと、出来事が起きるとサーバーが Apple の APNs に送信を頼み、APNs から端末に届くまでを順に追えます。最初の「許可とデバイストークン」の手順がないと後の手順がすべて始まらない点と、APNs が「受け付けた」ことと「端末に届いた」ことは別の段階である点に注目してください。
ネットワーク図を読み込んでいます…
スマホは地下鉄やエレベーターで電波が切れます。そのときにどこまで使えるかは仕様で決めることです。全部をオフラインで使えるようにすると工数が大きく増えるので、場面を選びます。
| レベル | 例 | 工数 |
|---|---|---|
| エラーを分かりやすく出す | 「通信できません。再読み込み」 | 小 |
| 見るだけできる | 前に開いた記事・チケットを表示 | 中 |
| 操作も後で送る | メモや下書きを保存して、つながったら送る | 大（同期と食い違いの扱い） |
操作を後で送る場合、別の端末で同じデータを変えていたときにどちらを残すかのルールが必要です。
まず答えを見ずに声に出して答え、そのあと開いて比べる。
模範回答
大きく2つあります。1つ目は審査です。App Store や Google Play の審査を通す必要があり、すぐに直して出し直せないので、リリース日に余裕を持たせ、問題があればサーバー側のフラグで機能を止められるようにしておきます。
2つ目は古いバージョンが残ることです。アップデートしない人がいるので、API は古い版でも動くように後方互換を保つ必要があります。ストアの段階的な公開を使って少しずつ広げ、どうしても古い版を切る必要があるときは、強制アップデートの方針を事前に決めておきます。
深掘りされたら
見られているポイント審査・古いバージョン・後方互換・フラグでの停止
模範回答
私は、すぐに聞くのは避けたほうがよいと考えます。iOS では一度断られると、ユーザーが設定から戻さない限り許可の画面を出せないので、価値が分からないうちに聞くと断られやすく、取り返しがつきにくいからです。
例えば「注文の発送をお知らせします」のように通知の価値が伝わる場面で、理由を添えて聞く流れを提案します。そのうえで許可率を計測し、許可されない人にもアプリ内のお知らせやメールで届く設計にします。
深掘りされたら
見られているポイントOS の制約を体験の設計と数字に結びつけられるか