バックエンドエンジニアがモバイルアプリならではの領域を聞いてみた【株式会社ライトコード】

はじめに

普段バックエンドを開発している服部です。

以前アプリ向けのAPI開発にも携わっていたので、サーバー側の障害対応やAPI設計の勘所はある程度分かっているつもりです。

ただ、審査フローやアプリ側の防御策、リリース周りの独特な事情など、アプリ開発者ならではの領域については断片的な知識しかありません。

そこで今回は、弊社のモバイルアプリエンジニアのこーさんに、アプリ側の視点から色々教えてもらいつつ、バックエンド側の実践もお伝えしながら、両者の視点をすり合わせてみました！

登場人物
服部（聞き手）：バックエンドエンジニア。アプリ開発は未経験。
こーさん（話し手）：モバイルアプリエンジニア。iOS/Android両方のリリース経験あり。バックエンドも少し経験あり。

1. iOSとAndroid、申請ってどう違うの？

服部

本日はよろしくお願いします！

早速なのですが、僕らバックエンドはデプロイすれば即リリースできますよね。一方でアプリには「審査」があると聞いています。よく「iOSの審査は厳しい」と耳にするのですが、実際のところどうなのでしょうか？

こーさん

よろしくお願いします。

まず流れから言うと、iOSはApp Store Connect、AndroidはGoogle Play Consoleにビルドをアップロードして審査に提出し、審査が通ればリリース可能になります。ここは両OSでほぼ同じですね。

服部

なるほど、工程自体は大きく変わらないんですね。違いが出るのはどこなのでしょうか？

こーさん

審査期間ですね。おっしゃる通りiOSの方が審査が厳格な傾向があるので、期間は長くなりやすいです。今でこそiOSでも1日程度で終わりますが、昔は1週間ほどかかっていました。

服部

1週間ですか！　その期間も開発スケジュールに組み込む必要があるということですよね…？

こーさん

そうなんです。審査期間を前提としたスケジュールになるので、Webフロントに比べて納期が短くなったり、ユーザーの要望がアプリに反映されるまで時間がかかったり、もどかしい部分は多かったですね。

服部

逆に、Androidは比較的緩やかなのでしょうか？

こーさん

昔はiOSに比べてリリースのハードルが低かったんですが、実は最近厳しくなっていて。

2023年11月中旬以降に作成された個人アカウントでアプリをリリースする場合、「12名のテスターによる14日間のクローズドテスト」が必須になったんですよ（※2026年7月時点の要件です）。

服部

12名を14日間ですか…。個人開発だと、テスターを集めるだけでも大変そうですね。

こーさん

かなり厳しい条件ですよね。おそらくストア内のアプリの質を高めるための施策だと思うんですが、「さくっと何かリリースしたい」個人開発者には痛手で…。

そのおかげ（？）でテスター募集のDiscordサーバーが立ち上がったり、クローズドテスト請負みたいな新しいビジネスモデルが誕生しているのは皮肉な話です（笑）

服部

需要のあるところにビジネスが生まれるんですね（笑）。ちなみに審査は人が行っているのでしょうか？　それとも機械による自動チェックなのでしょうか？

こーさん

iOSもAndroidも、人力レビューと自動レビューの両方で審査されています。レビューフロー自体は公開されていないのであくまで体感ですが、iOSの方が人力レビューを重視している印象ですね。

服部

人が担当されているということは、判断のブレもありそうですね。

こーさん

まさにそれで、一定のマニュアルはあると思うんですが、重視する項目がレビュワーによってかなり差があるみたいなんです。リジェクトされた後にビルドを取り下げて出し直したらすんなり通ったり、その逆もあったり（笑）

一方Androidは、自動レビューで問題なければ数時間で審査が終わることも多いので、あまり人的リソースを割いている感じはしないですね。

服部

「レビュワーガチャ」というやつですね（笑）。実際にリジェクトされたご経験で、印象に残っているものはありますか？

こーさん

苦い思い出があります…。

2022年頃に担当していたBtoBの特定業種向けアプリの話なんですが、「利用者が窓口にアカウント作成を依頼 → バックエンドチームがアカウントを発行 → 利用者へ連絡」というアカウント発行フローだったんです。

なのでレビュワーがアプリの中身を確認できるよう、レビュー用アカウントを添えてAppleに審査を依頼していました。

服部

BtoBだとよくある構成ですね。それがどうしてリジェクトに…？

こーさん

ある日、軽微な修正を含んだ定期リリースを審査に出したんです。いつも通り難なくパスすると思っていたら、まさかのリジェクト。「レビュワーガチャ外したかなw」と呑気にレビュワーノートを見たら、「アカウント削除の導線がないのでリジェクトします」と書いてあって。

服部

えっ、それまでは問題なく通っていたのにですか？

こーさん

ちょうどその時期から「アカウント削除導線の必須化」が明確にルール化されたんですよ…。ルール化自体は把握していたんですが、施行時期を1年勘違いしていたという凡ミスで…。結局プロジェクト全体を巻き込んで、急遽アカウント削除対応を行うことになりました。

非常に苦い思い出ですが、「ポリシーの変更や施行時期には常にアンテナを張らないといけない」といういい教訓になりましたね。

服部

なるほど…。リリース段階で突然のタスク追加はかなりしんどいですね…。

この章のポイント

・申請のフロー自体はiOS/Androidでほぼ同じ。差が出るのは審査期間で、人力レビュー重視のiOSの方が長くなりやすい
・審査期間を織り込んでリリーススケジュールを組む必要がある
・ストアポリシーの変更内容と施行時期には常にアンテナを張る（アカウント削除導線のリジェクト事例）

2. 障害が起きたとき、アプリはどうする？

服部

今のお話を伺って思ったのですが、リリースに審査が挟まるということは、障害対応も大変ではないですか？

Webなら前のバージョンにロールバックすれば比較的短時間で復旧できますが、アプリはユーザーの端末にインストールされている訳で…。

例えばサーバー側で障害が起きた時、僕らバックエンドは原因調査や修正に集中することになりますが、その間アプリ側ではどんなフォールバック対応をされているのでしょうか？

こーさん

大前提として、サーバー側で障害が起こるとアプリ側でできることはないんです。

しかもiOSもAndroidも、一度公開したアプリは公開を中止しても、既にインストール済みのユーザーは再ダウンロードできるポリシーなので、「配布を止める」こともできません。

服部

止めることすらできないんですね…。

こーさん

だからこそ、いかに事前にフェイルセーフを仕込んでおくかが重要になります。

よく取る手法としては、あらかじめメンテナンスモードのUIをアプリに仕込んでおいて、503エラー（Service Unavailable）をネットワーク層でフックして表示させる、というものですね。ユーザーへの被害を最小限に抑えられます。

逆にお聞きしたいんですが、アプリ側で不具合があった場合に「特定のバージョンからのリクエストは弾く」みたいな緊急対応フローって、バックエンド側で意識したりしてますか？

服部

特定のバージョンを弾く、という対応はしていなかったですね。

ただ、以前アプリのWebViewをネイティブにリプレイスする際に、バックエンド側でABテストを実施して、AがWebView・Bがネイティブになるように設定していました。

もしネイティブ画面で何かしら問題があった際は、ABテストの管理画面上で即座にAに切り替えてWebViewに遷移させることで、ユーザーへの影響を最小限にする、という対応は行なっていました。

こーさん

まさにそういう仕組みがバックエンド側にあると心強いですね。実はアプリ側にも似た考え方の手法があるので、後ほどお話しします。

…