App Store review is not a perfectly predictable queue. A routine Capacitor release can clear in a day. The next one can sit for a week, or come back with a question about a screenshot, a privacy string, or an in-app purchase that has not changed in months. Meanwhile users are still on the last binary, and the fix you already wrote is sitting in a branch.

This piece is about what you can still do while that binary is in review, and how to make the next review shorter. It is not a promise that Apple will approve you on a schedule. Nobody outside App Review can promise that.

First, separate the two clocks

There are two clocks on a mobile team, and they get mixed up.

The binary clock is App Store Connect. You upload a build, fill in the form, and wait. That clock owns native changes: new plugins, new permissions, a new Xcode or SDK requirement, a capability you did not have before, or a brand new app that is not on the store yet.

The product clock is everything in the web layer of a Capacitor app. UI, business logic, copy, most bug fixes. Once a native version is already on the store and it includes your live update SDK, that clock does not have to wait for the binary clock.

If your current release is a first-time submission, you are stuck on the binary clock. There is no production app to update yet. Use the wait to tighten the listing, the review notes, and the test account. The first-time App Store review guide is a practical checklist for that situation.

If the app is already live, a stuck review is annoying, but it should not freeze the product. Ship web-layer fixes through a live update to the binary that is already in users' hands. Keep the in-review binary for the native changes it actually contains.

What to do on day one of a stall

When a build has been "Waiting for Review" or "In Review" longer than you planned, do this in order.

1. Check App Store Connect for a message, a rejected attachment, or a missing export compliance or privacy answer. A surprising number of stalls are a form, not a mystery.
2. Confirm which changes are in that binary. If the only important fix is a JavaScript change, you may be able to ship it to the live app today and leave the in-review binary alone.
3. Do not upload a second binary on top of the first one unless Apple asked for a new build, or you have a native fix that the first build lacks. Another upload often restarts the wait.
4. Prepare a calm reply if Review asks a question. Have a test account, a screencast of the flow they are likely to hit, and a short explanation of what the app does. The 2026 review notes cover the questions that come up again and again for Capacitor apps.
5. Tell support and your users the truth. If a broken flow is already in production, say you are shipping a fix to the live app, not that "Apple is blocking us" when the fix does not need a new binary.

What you can ship to the live app right now

For a Capacitor app that already uses live updates, you can ship JS, CSS, HTML, and assets to the current store version while a newer binary sits in review. That is the main way teams keep moving.

Good candidates:

• A regression in a React or Vue screen that slipped into the last store release.
• Copy, layout, or accessibility fixes.
• A feature flag flip or a remote config change that lives in the web layer.
• Analytics or logging that helps you see whether the production bug is real.

Bad candidates, even if you are in a hurry:

• A new native plugin or permission.
• A change to the app's purpose or a new executable path Apple has not reviewed in the native app.
• Anything that would make the in-review binary and the live web layer tell two different stories about what the app is.

The durable mental model is in App Store vs direct updates: the store owns the native contract, and direct updates own the web layer after that contract is in place.

How to make the next review less fragile

Stuck reviews are sometimes just volume. They are also often self-inflicted. A few habits reduce the number of times you have to wait.

Keep native releases boring. Group plugin upgrades, permission changes, and OS SDK bumps into planned binary releases. Do not hide a risky native change in the same build as a marketing screenshot refresh if you can avoid it.

Write review notes for a human who has never seen your app. Say what the app does, where to log in, and which buttons to tap. If a flow needs a credit card, provide a sandbox account. If a flow is hidden behind a role, say so.

Watch your metadata. Privacy nutrition labels, tracking answers, and permission strings must match the binary. Capacitor apps get rejected when a plugin still requests a permission the listing does not explain.

Do not use live updates as a way to surprise Review. If the current store binary can receive bundles, say in your notes that you ship web-layer updates over the air, and that native capabilities do not change that way. Clarity here prevents a longer conversation later.

What not to do while you wait

Do not spam new builds every morning. Do not open a high-priority ticket for a routine wait of a few days unless you have an outage and a documented expedite case. Do not publicly blame the reviewer. Do not ship a bundle that tries to reconstruct a native feature the live binary does not have.

And do not freeze the team. If the product clock can still move, move it. Use the binary wait for the work only the binary can do: certificate cleanup, the next permission, the Play Console side of the same release, documentation, and a staged rollout plan for when the new binary finally lands.

A note on tools, since I work on one

I work on Capgo, a Capacitor platform for live updates and cloud native builds. The relevant part for a stuck review is the live update path: ship a bundle to the version already on the store, watch it, and roll it back if needed. When the new binary is approved, you can point that version at the same channels.

If your app is not set up for live updates yet, a stall is a difficult moment to add a new SDK, because that addition itself usually needs a store release. Add it in the next binary, then you will have the product clock the next time review is slow. That is the useful outcome of a painful wait: the team should only be fully blocked when the change is truly native.

I'm Martin, and I build Capgo, so this is my own setup. Prices are from vendor pages checked 2026-11-08.

The constraint

One person, a Capacitor app (web code in a native shell), a Linux laptop, and a budget under $20 a month. I need three things: signed iOS and Android binaries, uploads to both stores, and a way to ship a hotfix the same afternoon.

Step 1: wire the project once

npm i @capgo/capacitor-updater
npx @capgo/cli@latest init

The init flow registers the app and adds the updater plugin. The plugin is what lets the installed app download a new web bundle later.

Step 2: build iOS in the cloud

Capgo Build takes the project, compiles it on Capgo's macOS machines with my signing certificate and provisioning profile, and uploads the result to App Store Connect. Android goes the same way to Google Play. Build minutes are included in the plan: 60 a month on Solo, which is plenty for a handful of releases.

Step 3: run it from CI on every tag

I trigger the build and the bundle upload from a GitHub Actions Linux job. Linux runners cost $0.006 a minute versus $0.062 for macOS runners, so keeping the macOS work on Capgo keeps the CI bill tiny.

Step 4: hotfix with a live update

When a bug is in JavaScript or CSS, I do not wait for review:

npm run build
npx @capgo/cli@latest bundle upload --channel production

Users get the new bundle on next launch. I can target a beta channel first, roll out gradually, and roll back in one click. Native code, permission or SDK changes still go through store review, as they should. Details in the live updates docs.

What this costs

Capgo Solo is $14 a month ($12 yearly) with 2,000 monthly active users and 60 build minutes, after a 14-day free trial. If usage is light, prepaid credits valid 12 months skip the subscription. Current plans.

How the alternatives compare for this pipeline

• Expo EAS: the same build, submit and update shape for React Native; free plan has 15 iOS builds a month, Starter $19 a month plus usage.
• Codemagic: 500 free macOS M2 minutes a month, then $0.095 a minute; OTA only for React Native.
• Capawesome Cloud: Capacitor live updates from $9 a month.
• Bitrise: Starter $99 a month, OTA via a CodePush-compatible add-on.
• Fastlane on GitHub Actions: free tooling, but you pay macOS minutes and maintain signing yourself.
• Ionic Appflow: closed to new apps since October 2026, sunset end of 2027.

FAQ

Is this App Store compliant? Yes. Capgo replaces only web assets inside the reviewed binary and never loads native code.

What if I already use Appflow? See the Appflow to Capgo comparison.