Native or cross-platform: deciding on evidence rather than preference
Both approaches build excellent products. The decision follows device capability requirements, team composition and roadmap shape.
ZooBieDoo Infotech Engineering TeamRead
Key takeaways
- A bad mobile release cannot be rolled back — only replaced.
- Stage every rollout and watch crash-free rate at each step.
- Remote flags and kill switches avoid emergency releases.
- Plan for old versions persisting in the field for months.
You cannot roll back an installed app
Once a build is on a device, the only fix is another build, and that means review time plus however long users take to update. A bad release can be live for days.
This asymmetry with the web is the single most important thing to design around, and it argues for caution on release day rather than speed.
Stage every rollout
Both stores support releasing to a small percentage of users and increasing gradually. Use it as a default rather than for risky releases only.
Watch crash-free rate, key funnel metrics and store reviews at each stage. Halting at five percent is inexpensive; discovering the problem at full rollout is not.
Remote configuration and kill switches
- Ship risky features behind a remote flag so they can be disabled without a release.
- Keep a kill switch for anything touching payments or data integrity.
- Support a forced-update mechanism for genuinely critical fixes.
- Make sure the app degrades sensibly if remote configuration is unreachable.
Support multiple versions in the field
A meaningful proportion of users will be on older versions for a long time. The API has to keep working for them, which constrains how quickly you can change server contracts.
Decide a support window explicitly, monitor version distribution, and use forced updates sparingly — they are disruptive and generate poor reviews when overused.
Monitoring a release properly
The window immediately after a release is when problems are cheapest to contain, and it is often when nobody is watching. Decide in advance what will be monitored and by whom.
- Crash-free rate compared against the previous version, not against an absolute target.
- Key funnel steps — a release that raises crashes slightly but breaks checkout is worse than it looks.
- New store reviews, which surface issues telemetry misses.
- Error rates on the API from the new version specifically.
Comparing against the previous version rather than an absolute threshold catches regressions that a fixed target would miss.
Frequently asked questions
Long enough to gather meaningful signal at each stage often a day or two per step for a moderately used app, faster for very high volume.
Version the API and support older contracts for as long as meaningful usage remains. Breaking older app versions is effectively a forced update without the user being told.
For security or data integrity issues, yes. Used routinely it produces poor reviews and abandonment.
