DK Times, a multilingual news app I built, has shipped 60+ releases across the App Store and Google Play. A cadence like that teaches you things no tutorial covers.
EAS + OTA changes your release psychology
With Expo Application Services, JS-only changes ship as over-the-air updates — no store review, live in minutes. Native changes (new SDK, new permissions) need a full build and review. This split changes how you plan: batch native changes into infrequent, well-tested releases; let everything else flow continuously.
The discipline that matters: know which kind of change you're making before you make it. Accidentally depending on a native change in an OTA update is the classic foot-gun.
Your oldest user is your real target
Users sit on old versions for months. Every API response, every push notification payload, every deep link must work for versions you shipped a year ago. Practical rules:
- Never remove a field from an API response; add new ones
- Version your notification payload handling
- Feature-flag server-side, so old clients degrade gracefully
Push notifications are a system, not a feature
For a news app, notifications are half the product. The hard parts were never sending them — they were token lifecycle (refresh, invalidation on reinstall), per-language topic segmentation across 8 languages, and not double-notifying a user on two devices. Budget real engineering time here.
Review rejections are a tax — minimize the rate
App review will reject you for things that passed ten times before. What kept our rejection rate low: a demo account in review notes, screenshots that match the actual build, and never shipping a "coming soon" screen. When rejected, reply politely and resubmit fast — arguing costs days.
The meta-lesson
Mobile punishes big-bang releases. Sixty small releases beat six big ones: smaller blast radius, faster feedback, and a team that treats shipping as routine instead of an event.