◉RORK LABJP
●GPT-6.1 SOL — Added to Rork's model menu (09-29) with Low, Medium and High effort; included on Pro and Max●SONNET 5.5 — Claude Sonnet 5.5 is selectable: strong at UI design and faster than Sonnet 5 (09-28)●SONNET 4.5 — Retires on the Claude API on 11/30, 35 days left. If your app calls it, check the migration target●SDK 58 ISSUE — Early reports include Android widgets not refreshing on a schedule and Stripe linking statically●OBSERVE — EAS Observe now records native crashes too (SDK 57.0.21 or later, 10/07)●NEW — My App Open Ad Only Showed When the App…●GPT-6.1 SOL — Added to Rork's model menu (09-29) with Low, Medium and High effort; included on Pro and Max●SONNET 5.5 — Claude Sonnet 5.5 is selectable: strong at UI design and faster than Sonnet 5 (09-28)●SONNET 4.5 — Retires on the Claude API on 11/30, 35 days left. If your app calls it, check the migration target●SDK 58 ISSUE — Early reports include Android widgets not refreshing on a schedule and Stripe linking statically●OBSERVE — EAS Observe now records native crashes too (SDK 57.0.21 or later, 10/07)●NEW — My App Open Ad Only Showed When the App…
Articles/Business
⟐ Business/2026-10-26Beginner

The Night Before You Submit: Which Dependencies to Check First, in Five Steps Anyone Can Follow

Upgrading every library the night before submission is how crashes that only hit old devices slip into a release. Here is the order I settled on in my own wallpaper apps: check what the stores decide first, and write down what you chose not to upgrade.

Store submissionDependencies4expo-doctornpm outdatedPre-release checksBeginner9

The night before a submission, looking at a long list of available updates, I have thought more than once: "I might as well bring everything up to date before I ship."

One release made that way was followed by crash reports from older Android devices only. Nothing went wrong on my own phone. An upgraded library had dropped an assumption that old OS versions relied on (I wrote up the details in a separate article). Looking back, the upgrade itself was not the real mistake. The mistake was that I had no order for what to check before upgrading.

Let me give you the conclusion first. Check what the stores and the SDK dictate before you look at what is merely new. This article lays out the order I use as an indie developer shipping wallpaper apps under Dolice, with the screens and commands. The same view works for projects generated by Rork.

Step 1: Put the store version next to your local version

Start with the versions, not the libraries. Open App Store Connect and Google Play Console and note the version currently live. Then open package.json and app.json (or app.config.ts) and read the version field. If the numbers match, the submission cannot go through.

While you are there, recall what you touched since the last release. If you use git, git log --oneline from the last tag is enough. Anything you did not touch can be left out of today's checks.

Step 2: Let a command show you where you drifted from the SDK

Each Expo SDK expects specific versions of many packages. A command is more reliable than your eyes here.

npx expo install --check
npx expo-doctor

The first lists packages whose versions differ from what the SDK expects. The second checks configuration and native-side consistency. Neither rewrites your files, so they are safe to run the night before.

You do not have to fix every finding. But I keep one rule: if a line is flagged, I do not submit without reading it. Also note that expo-doctor does not cover everything; I opened it up and looked at what it actually checks in a separate article.

Step 3: Read the dependencies that carry deadlines first

Next come the things that can block submission if you do not upgrade.

ItemDecided byWhere to look
Android target API levelGoogle Play requirementsPlay Console notices and the official help page
Xcode / SDK used to build for iOSApple's submission requirementsAnnouncements in App Store Connect

These are not "upgrade because I want to" items but "cannot ship without it" items. Once the deadlines are settled, everything else can honestly stay where it is. For how to inspect the Android side, see this audit of the effective targetSdkVersion.

Step 4: With npm outdated, pick up only the major-version jumps

Now you can face the pile of update notices.

npm outdated

The output shows Current (installed), Wanted (the newest version your package.json range allows), and Latest. Reading everything stalls you, so I pick only the rows where the first number of Latest differs from Current. A changed major number is the convention for "behavior may have changed."

For those rows, read only the breaking-changes part of the changelog. If your app does not use the affected feature, skip the upgrade this time.

I took the same posture when moving Firebase from CocoaPods to Swift Package Manager: try it small first, then bring it onto the main line. The record is here.

Step 5: Write one line for everything you chose not to upgrade

The last step is the one that pays off most. Keep a note with each skipped library and the reason.

expo-image: Latest is one major ahead. Current screens rely on the old behavior. Revisit when adding the next feature.

With this in place, you do not repeat the same hesitation at the next submission. And if something breaks later, you can tell the upgraded side from the untouched side. Record why you did not upgrade with the same weight as why you did. That is my line.

One next action

Before your next submission, run npx expo install --check once. If it comes back empty, move straight on to Step 3.

And if a report arrives that the app runs on your phone but never launches on some devices, something optional may have ended up on the startup path. I wrote about how to spot that in a piece on fixing a launch design.

Since I fixed the order, the night before a submission has become much calmer for me. I hope it does the same for you.

Related: Why a Rork Max Android app crashes only on older OS versions

Share

Thank You for Reading

Rork Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.

  • ✦Copy-paste ready implementation code
  • ✦New advanced guides published daily
  • ✦$5/mo or $10 for lifetime access
View Membership →

If you found this article helpful, a small tip ($1.50) would mean a lot to us. Your support helps keep this site ad-free and covers server and hosting costs.

Related Articles

⟐ Business2026-10-25
It Looks Opaque, but App Store Connect Says the Icon Has an Alpha Channel — Checking the PNG Before You Upload
ITMS-90717 (Invalid large app icon) can fire on an icon that shows no transparency at all, because an alpha channel is enough. I built six sample PNGs to tell the cases apart, and share a stdlib-only checker and a flatten step.
⟐ Business2026-10-24
Google Play's Extension Ends November 1 — Count Backwards from Your Submit Day
The target API 36 extension on Google Play ends November 1. Instead of counting to the deadline itself, count back from the last day you can submit — with a small script that does the date math.
⟐ Business2026-10-23
Store Sales CSVs Come in Different Shapes: Reduce Them to Four Columns, Fix the Month-End Rate, and Keep the Raw Totals
A small Python script that reduces App Store and Google Play sales CSVs to four columns (date, app, amount, currency) and totals them by month and app. It never drops unreadable rows silently, fixes one exchange rate per month, and prints raw per-currency totals so you can reconcile.