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
- Annual OS releases and store policy changes create unavoidable work.
- Dependency, certificate and API churn is a steady baseline cost.
- Crash triage and review responses are ongoing commitments.
- Budget maintenance separately from enhancement, or the app decays.
Costs that arrive without you doing anything
Both platforms release a major version annually, each bringing interface changes, deprecated APIs and new permission behaviour. Store policies change and can require modification to remain listed.
This work is not optional and is not driven by your roadmap. An app that is not maintained will eventually stop working or stop being distributed.
Dependency and certificate churn
- Third-party libraries need updating for compatibility and security.
- Signing certificates and provisioning profiles expire.
- Backend API versions the app depends on change.
- Payment and identity providers update their integration requirements.
Each is small individually. Together they represent a steady baseline of effort that should be budgeted rather than absorbed.
Support and crash triage
Real users on real devices find defects that testing does not. Crash monitoring, triage and fixing represent an ongoing commitment, and the crash-free rate is worth treating as a standing target.
Store reviews also need attention. Unanswered negative reviews depress both rating and conversion.
Budget it explicitly
A useful planning approach is to treat maintenance as a recurring annual proportion of the original build, then decide separately what enhancement budget the product deserves.
Projects that budget only for the build reliably end up with an app that decays, and the eventual remediation costs more than the maintenance would have.
Deciding when to rebuild
Every app eventually reaches a point where maintenance costs more than a rebuild would. Recognising it deliberately is better than drifting there.
The signals are consistent: dependencies that cannot be upgraded without breaking others, a framework version no longer receiving security updates, simple changes requiring disproportionate effort, and nobody remaining who understands core parts.
Even then, a rebuild is not automatically right. Incremental replacement of the worst areas often delivers more value sooner, and it avoids reproducing years of accumulated behaviour in one step.
Frequently asked questions
A recurring proportion of the original build cost is a reasonable planning figure, adjusted for how many integrations and third-party dependencies the app carries.
It will keep working for a while, then break with an OS release or fall foul of a store policy. Recovering from that state usually costs more than continuous maintenance would have.
It reduces duplicated feature work. It does not remove platform-specific obligations, and it adds the framework itself as another dependency to keep current.
