Shipping to Both App Stores Without Drama

Two stores, two cultures

Apple and Google run stores with genuinely different temperaments, and a release process must respect both. Apple reviews are human, stricter, and occasionally opinionated — a rejection for a metadata detail or an unclear subscription screen is normal life, and the first submission of a new app should budget days, not hours. Google's review is faster and more automated, but Android brings its own tax: staged rollouts you must manage, a device landscape you can't fully test, and policy changes that arrive with deadlines.

The practical consequence: treat store requirements as product requirements from day one. Privacy labels, data-safety forms, account-deletion requirements, subscription disclosure rules — teams that discover these at submission time lose weeks; teams that design for them lose nothing.

Releases should be boring

A healthy release is an uneventful one, and uneventfulness is manufactured. The ingredients we consider non-negotiable:

• —CI builds both platforms from a tag — no releases from a developer's laptop, ever; the pipeline is the only path to the stores
• —The automated suite gates the release: unit and widget tests in the pipeline, critical flows on the device farm — red blocks the tag
• —Staged rollouts by default: a release reaches a small percentage of users first, and crash monitoring decides whether it proceeds
• —Remote config and feature flags separate deployment from launch — code ships dark, features turn on when we choose, and can turn off without a store review
• —Store metadata is versioned like code: both languages, both stores, screenshots and texts in the repo, not in someone's head

The escape-hatch principle

Mobile's defining constraint versus the web: you can't instantly take a release back. A bad web deploy is rolled back in minutes; a bad app release lives on users' phones until they update. That asymmetry drives the whole discipline — the staged rollout is the ability to stop the bleeding early, the feature flag is the ability to disable a feature without shipping, and remote configuration is the ability to adjust behaviour while the binary stays put.

This is also why 'we'll fix it in the next release' is a weaker sentence on mobile than anywhere else. The next release is a review cycle away, and some users won't take it for months. The escape hatches have to exist before the incident.

Cadence is a feature

Teams that release rarely, release badly — each release grows large, risky, and frightening, which makes the team release even more rarely. The inverse loop is available to anyone: small frequent releases keep every diff reviewable, every rollback cheap, and every incident small. Our aim across products is a steady cadence where a release is a routine Tuesday event, not a quarterly ceremony with a war room.

That cadence is what clients actually buy when they buy release discipline: the confidence that improvement lands continuously, and that no single release can sink the product.