One Codebase, Two Stores, Three Deadlines

The appeal of cross-platform development is one codebase instead of two. That part is real and it is why most business apps are built this way now.

What it does not give you is one schedule. There are three clocks running on any app in both stores, they do not coordinate, and only one of them belongs to you.

Clock one: yours

Features, fixes, whatever the business wants next. This is the only clock anyone plans around, and it is the one most likely to be deferred.

Clock two: the operating system

Apple’s schedule. A new iOS version each year, and periodically a change that does not merely deprecate something but terminates apps that have not adopted it.

We ran into exactly that recently: an app that would not launch at all on the current iOS, because it had not adopted a lifecycle model the OS now requires. Not a rendering glitch — a hard termination. Every launch.

The detail that makes this awkward for planning: the app’s own code was fine. The generated native project, produced from a framework template that was current when the project was scaffolded, had not been updated. Nothing in the codebase indicated a problem, and no test could have found it, because the failure is at the boundary between your code and the platform.

Clock three: store policy

Google’s schedule, and it is the one businesses are least prepared for because it is not tied to a visible OS release.

Play sets a minimum target API level, and it moves annually. Miss it and your app is not removed — it simply stops being available to new users on newer devices, quietly. Existing installs keep working, so there is no complaint and no signal.

On top of that sit policy changes: data safety declarations, account deletion routes, permission justifications. Each arrives with its own compliance date.

★ Insight ------------------------------------- The three clocks have different failure modes and that is what makes them hard to manage together. Missing your own deadline is visible and negotiable. Missing the OS deadline is catastrophic and obvious — the app does not start. Missing the store policy deadline is invisible: nothing breaks, nobody complains, and your install rate declines for a reason that looks like market conditions. The one with no symptom is the one that goes unnoticed longest. -------------------------------------------------

Why they never align

Each platform sets its dates for its own reasons. Apple’s cluster around its hardware cycle; Google’s around its policy calendar. Neither consults the other, and neither consults you.

So an app in both stores has compliance work arriving at unrelated points through the year, none of which produces a feature, and all of which is mandatory.

The common consequence: the business plans a feature release, and the two weeks before it are consumed by platform compliance nobody scheduled. The feature slips, and the explanation — “we had to do platform work” — sounds like an excuse because it was never in the plan.

Budgeting for the clocks you do not control

Three things that make this manageable.

Assume a fixed annual allocation for compliance. Not zero, and not “we will deal with it”. A realistic figure for a maintained app in both stores is a couple of weeks a year of work that produces no visible change. Putting that in the plan turns an interruption into a line item.

Launch the app on the newest OS beta, once a quarter. Not a simulator smoke test in CI — open it, on the OS your users will be on in a few months, and use it. Every one of the three defects we found in that recent piece of work was found by launching, and none by reading.

Track the target API deadline as a date, not a task. It moves annually and it is published well in advance. It belongs in a calendar, owned by a person, with the work scheduled before the month it is due.

What this means for the build-or-buy decision

If you are weighing a custom app against an off-the-shelf product, this is the cost most often left out of the comparison.

An off-the-shelf app is maintained by a vendor who absorbs all three clocks. That is a substantial part of what the subscription buys, and it is invisible until you own an app and discover that “finished” is not a state a mobile app occupies.

A custom app is right when it does something no product does — when the rules are the business, when it is a second channel rather than admin, or when it carries your name as part of the offer. Those cases are real and we build them.

What they are not is one-off projects. An app is a subscription you pay in engineering time, and the platforms set the renewal dates.

What a maintained app actually needs each year

Concrete, because “ongoing maintenance” is the vaguest line in any proposal.

A framework and dependency update, typically twice a year. Not for features — because security fixes arrive in dependencies and because falling far behind turns the next upgrade into a migration.

A target API level bump for Google, annually, on a published date.

An OS compatibility pass each time a major version ships, which means launching the app on the beta and using it.

A store listing review, because declarations drift as the app changes and the store checks them automatically.

None of those produce anything a user notices, which is exactly why they are the first things cut. The visible consequence of cutting them is nothing at all, until the year the app stops launching.

The three questions before committing

1. Who owns the platform calendar? A named person who tracks target API deadlines and OS releases. If nobody owns it, the answer is that nobody is watching.
2. When did we last launch this on a beta OS? If the answer is never, that is the highest-value hour available.
3. What is our annual maintenance allocation? If it is zero, the first platform deadline will be funded by cancelling something else.

---

Awesome Apps is an app developer in Sydney building and maintaining iOS and Android apps for Australian businesses. How we work, including ongoing maintenance, is set out here.