申請ボタンを押す前日の夜、手元の更新通知がずらりと並んでいるのを見て、「どうせなら全部最新にしてから出そう」と考えたことが、私にもあります。
その判断で出したリリースのあと、古い Android 端末だけがクラッシュしている報告が届きました。手元の端末では一度も起きず、原因は、更新したライブラリが古い OS の前提を一つ外していたことでした（経緯は別の記事に書きました）。上げたこと自体より、何を、どの順で確かめてから上げたのかを持っていなかったことが、いちばんの失敗だったのだと思います。
最初にお伝えしたいのは、結論です。申請前の確認は「新しいものから」ではなく、ストアや SDK が決めているものから確かめます。ここからは、個人開発の壁紙アプリ（Dolice 名義）で線引きし直した順番を、画面とコマンドの両方で書き残してまいります。Rork で生成したプロジェクトでも同じ見方が使えます。
手順1：ストアに出ている版と、手元の版を並べる
最初に見るのは、ライブラリではありません。「いま出ている版」と「これから出す版」の差です。
App Store Connect と Google Play Console を開き、公開中のバージョン番号を控えます。次に、手元のプロジェクトの package.json と app.json（または app.config.ts）にある version を見ます。ここで番号が同じままなら、申請そのものが通りません。
このとき一緒に、前回の申請から何を触ったかを思い出しておきます。更新の記録が git にあれば、git log --oneline で前回のタグ以降を眺めるだけで足ります。触っていない部分は、確認の対象から外せるからです。
手順2：SDK が決めている版とのずれを、機械に出させる
Expo を使うプロジェクトでは、「この SDK なら、このパッケージはこの版」と決まっているものが多くあります。人が目で追うより、コマンドに聞くほうが確実です。
npx expo install --check
npx expo-doctor1 行目は、SDK が想定する版とずれているパッケージを一覧にします。2 行目は、設定やネイティブ側の整合をまとめて点検します。どちらもファイルを書き換えないので、前日の夜に安心して回せます。
表示された指摘は、すべて直す必要はありません。ただ、赤い行が出たら、その行を読まずに申請しないと決めています。この一線だけは守っています。なお、expo-doctor が見ていない領域もあります。ストア提出の基準については、別の記事で中身を読んで確かめました。
手順3：期限や要件がある依存だけ、先に読む
次に見るのは、「上げなければ申請できなくなるもの」です。代表は 2 つあります。
| 対象 | どこで決まるか | 見る場所 |
|---|---|---|
| Android の対象 API レベル | Google Play の要件 | Play Console の通知と公式ヘルプ |
| iOS のビルドに使う Xcode / SDK | Apple の提出要件 | App Store Connect からのお知らせ |
ここは「上げたいから上げる」のではなく、「上げないと出せない」ものです。期限と要件を先に確定させておくと、残りのライブラリは上げない選択肢を持てるようになります。対象 API レベルまわりの具体的な見方は、実効 targetSdkVersion の点検にまとめてあります。
手順4：npm outdated は、メジャー番号が変わったものだけ拾う
ここでようやく、更新通知の山に向き合います。
npm outdated出力には Current（いま入っている版）、Wanted（package.json の範囲で上げられる版）、Latest（最新の版）が並びます。全部を見ると手が止まるので、Latest の最初の数字が Current と違うものだけを拾います。メジャー番号が変わっているものは、挙動が変わる可能性がある、という約束事だからです。
拾ったものについては、公式の変更履歴（CHANGELOG やリリースノート）の「Breaking」にあたる箇所だけ読みます。全文を読む必要はありません。自分のアプリが使っている機能に触れていなければ、今回は上げません。
Firebase を CocoaPods から Swift Package Manager へ移したときも、同じ姿勢でした。移行の記録は別の記事に残してあります。一度に移さず、小さく試してから本線へ入れる、という順番です。
手順5：上げないと決めたものを、一行で書き残す
最後の手順が、いちばん効いています。上げなかったライブラリと、その理由を、メモに一行ずつ残します。
expo-image：Latest はメジャーが一つ先。今回の画面は旧版の挙動のまま。次回の機能追加のときに検討する。
こう書いておくと、次の申請で同じ迷いをやり直さずに済みます。のちに不具合が出たときも、「上げた側」と「上げなかった側」を切り分けられます。上げる理由と同じ重さで、上げない理由を残します。これが私の線引きです。
次のアクションを一つだけ
次の申請の前に、まず npx expo install --check を一度だけ回してみていただければと思います。結果が空なら、そのまま安心して手順3へ進めます。
もし上げたあとで「手元では動くのに、一部の端末だけ起動しない」という報告が届いたら、起動の経路に載せてはいけないものが混ざっている可能性があります。その見分け方は、起動しない設計を直した記録の中で書いています。
私自身、確認の順番を決めてから、申請前夜の迷いはかなり減りました。同じ課題に向き合っている方の、前夜が少しでも落ち着いたものになれば幸いです。
関連：Rork Max Android アプリが古い OS バージョンだけクラッシュする原因と Java 8 デシュガリング修正／expo-doctor は API レベル 36 を見ていません／Firebase を CocoaPods から SPM へ移した記録／チュートリアルの画像が欠けただけで、アプリごと立ち上がらなくなる設計でした