Mobile App Release Challenges: Why Code Persistence Matters
Article Summary
Daniel Tome from Qantas reveals why mobile releases are fundamentally different: once your code ships to a user's phone, you've lost control of it forever.
This article breaks down the unique constraints mobile engineers face compared to backend and web developers. Tome explains why mobile code persistence creates challenges around versioning, rollbacks, and feature releases that other platforms simply don't experience.
Key Takeaways
- Backend APIs must support multiple client versions simultaneously for months or years
- Phased rollouts (1%, 5%, 10%) plus feature toggles act as safety nets
- Force upgrades should only interrupt users for security or critical fixes
- Server-Driven UI lets teams update layouts without App Store review cycles
- Apple review delays mean 2-3 day slips, requiring earlier code freezes
Mobile engineering success means building APIs that support yesterday and tomorrow simultaneously, because you can't instantly patch code living on millions of devices.
About This Article
Mobile engineers struggle with backward compatibility when app versions are fragmented across different releases. Remove one API field and you can break entire screens for users on 18-month-old versions, even if that's only 0.03% of your customer base.
Daniel Tome's team at Qantas handles this by adding new fields instead of removing old ones. They track how each version uses the API before they retire endpoints. Server-Driven UI helps them update layouts without pushing a new binary release.
This eliminates emergency hotfix binaries that need 1-3 days of App Store review. Instead, they can update the UI instantly and launch features across versions without forcing everyone to upgrade right away.