iOS and Android: one codebase or two?

Once it is settled that an app is needed, a second question arrives and is frequently decided by the wrong person: one codebase for both platforms, or two separate apps. The discussion is usually about price, though price is a consequence. What decides it is something else — how much the app has to talk to the phone itself.

In short

• If the app mostly displays data, takes input and sends notifications, a shared codebase is almost always enough.
• If it leans on device capabilities — precise background location, the camera as a core function, tight system integration — separate apps become justifiable.
• A second platform costs more than at build time. It costs again at every future change.
• Starting with one platform is a legitimate choice, if it is stated out loud rather than deferred quietly.
• The largest long-term expense is not the platform — it is post-launch updates, which nobody budgets.

Where the real line falls

It helps to sort apps by how much they depend on the device rather than by how complex they are. The first group essentially displays and collects information: customer self-service, order tracking, internal tools, catalogues. They use the phone as a screen. For those, a shared codebase is not a compromise but a sensible choice.

In the second group the app uses the phone as an instrument: continuous background location, demanding camera or audio work, close ties to operating-system features, offline operation with a local database. A shared codebase remains possible, but part of the work will still be done separately per platform — and the benefit shrinks.

A practical check: list the features that would not work without a phone. If that list is short or empty, you are in the first group. If it holds two or three items, separate apps deserve serious consideration.

What "almost identical" means

Shared-codebase apps look almost the same on both platforms, and that "almost" is usually exactly where the argument starts. The differences show in small things: how the back action behaves, how list scrolling feels, how system prompts and date pickers are presented. Users often do not notice; platform reviewers and internal evaluators do.

So the question is not whether it will be perfect but who those small things matter to. For an internal tool, almost nobody. For a consumer app competing in a store, possibly a great deal.

What proposals almost never contain

• The list of supported system versions. More old versions means more work, and it has to be decided up front.
• Who creates the store accounts and who will own them. This becomes a common problem a year later, when people change.
• What happens when a store rejects an update. That is a normal part of the process, not an exception.
• Whether the app must work offline, and what happens to the data when the connection returns.
• How many updates per year are expected purely to keep the app working.

Choosing to start with one platform

This is frequently the most rational choice, particularly for a first version. But it deserves to be made deliberately: say which platform you are starting with, why, and what would have to be done twice if the other is needed. A decision deferred quietly tends to return as an unexpected cost.

If you do not know which platform your customers use, that is not a technology question but a data question — and the answer is frequently already in your website statistics.

Illustrative scenario, not a description of a client project

Imagine an internal app for staff: lists, forms, photographs and notifications. Two separate apps are chosen, because that is "higher quality". The result works well, but every later change takes twice as long, and the same staff request changes every month. A year in, the biggest problem was not quality — it was pace. This is an example of how we weigh the choice, not a promise about a particular outcome.

This decision is often taken first when it should be taken third: after it is clear what the app does, and after it is clear who will maintain it.