Writing the app is half the work; getting it into users' hands is the other half. Publishing to the stores involves generating a signed release build, going through Apple's or Google's review, versioning correctly and updating without breaking those who already have the app installed. Mastering this release pipeline is a typical senior responsibility.
Debug vs release build
The build you run day to day (debug) is different from the one that goes to the store (release). Debug prioritizes development speed and diagnostics; release prioritizes size, performance and security.
| Aspect | Debug | Release |
|---|---|---|
| Code optimization | Minimal (compiles fast) | Maximum (faster, smaller) |
| Obfuscation/minification | Off | On (e.g., R8/ProGuard) |
| Logs and debugging | Enabled | Removed/disabled |
| Signing | Automatic debug key | Production certificate/keystore |
| Destination | Your device/emulator | App Store / Play Store |
Code signing: what and why
Every installed app is cryptographically signed. The signature proves the package came from you and wasn't tampered with along the way. On Android this is a keystore (your private key); on iOS, certificates and provisioning profiles issued by Apple.
The analogy: the signature is the tamper-evident seal on a medicine bottle. The OS only installs if the seal matches, and only accepts an update if it is signed with the same key as the previous version — otherwise, it refuses.
Losing the production signing key is catastrophic: without it you can't publish updates to the same app, and users are stuck on the old version. Guard it like a vault — secure backup and restricted access.
The review process
You don't publish directly: you submit the build and it goes into review. Apple does mostly manual and stricter review (content guidelines, privacy, API usage); Google combines automated checks with review, usually faster. Common reasons for rejection: requesting permissions without justification, crashes, a missing privacy policy, or trying to bypass the platform's payments. Plan review time into your launch schedule.
Versioning: name vs build number
There are two numbers and they serve different audiences:
- Version name / marketing version (e.g.,
2.3.0): what the user sees. Semantic, readable. - Build number / version code (e.g.,
147): an integer that always grows, used by the store to know which is newer.
versionName "2.3.0" // the user sees this
versionCode 147 // the store compares; never repeat or decreaseInterviewers often ask the difference between the two — the key is: the build number is the monotonic technical identity; the version name is human communication.
Updating without breaking those who already have the app
Users update at different paces; for days or weeks, old and new versions coexist. Essential precautions:
- API compatibility: the backend must serve old and new versions at the same time; avoid breaking contracts.
- Local data migration: if the database schema changed, migrate the data of those who updated without losing anything.
- Force updates sparingly: only block versions that are truly incompatible.
Gradual rollout
Instead of releasing to 100% at once, the stores allow phased rollout (e.g., 5% → 20% → 50% → 100%). That way, if the new version has a serious crash, you see it in the metrics and pause before it reaches the whole user base. It is the launch safety net — combine it with crash monitoring to react in time.
Conclusion
Publishing is a pipeline: generate an optimized release, sign it with the production key (and protect it), go through review, version with a readable name and an ever-increasing build number, and update while respecting those on older versions — ideally all with a gradual rollout. Whoever masters this path delivers value to users safely, without turning a launch into a fire drill.