iOS and Android: do you really need both at launch?

In France, Android accounts for 63.26% of mobile traffic and iOS for 36.72% (StatCounter, July 2026). Those figures are not enough to decide on. The second platform does not double your development budget, but it does roughly double everything around it: the rules, the update cycles, and the ways a submission can be refused.

What platform share tells you, and what it does not

The split in France is roughly two thirds to one third in Android's favour (StatCounter, July 2026). That is useful but limited: the measurement counts page views in a browser, not app usage, and certainly not what people spend. Two audiences of different sizes do not necessarily behave the same way once they are inside an application.

I do not have a defensible public figure for how spending splits between iOS and Android in France, and I would rather say so than quote an approximate one. What I do notice is that "which platform is bigger" is almost always the wrong question. The right one is where the people you are actually targeting happen to be.

An app for a company's field technicians is decided by looking at that company's handsets, not at a national average. A consumer app aimed at a young urban audience does not split like the average either.

What the second platform actually costs

The cost of the second platform is not where people expect it. With a shared codebase, development does not double. What doubles is everything around the code: two accounts to keep alive, two review processes with different rules, two enforced update calendars, and two sets of store assets governed by contradictory instructions.

On fees: 99 USD a year with Apple against 25 USD once with Google (Apple, 2026; Google Play Console Help, 2026). That is the negligible part. On timing: Apple reviews 90% of submissions in under 24 hours (Apple App Review, 2026), while Google enforces a target API level that rises every year — existing apps must reach Android 15 (API level 35) by 31 August 2026 (Google Play Console Help, 2026).

The key difference sits elsewhere: the two stores do not ask for the same things. Google caps marketing text at "not more than 20% of the image" on screenshots and discourages device frames; Apple explicitly permits overlays and requires its own frames, used without modification. One set of screenshots for both stores usually breaks one of them.

When shipping on one platform is the right call

A single platform is often the right decision, and it is rarely presented that way. It halves the surface you have to test, cuts the number of rules you must satisfy, and lets you fix things quickly during the weeks when you are still learning what people actually do with the app. The saved budget usually funds a better second version rather than a second platform.

Three situations where it is clearly right: an internal app where you know the handset fleet, a field app for teams equipped by the company, and a first version whose purpose is to learn rather than to cover the market. In all three, the second platform does not bring users. It brings work.

There is a second-order benefit that rarely gets counted. Reviewing on one store means one set of rejection rules to learn properly rather than two learned badly, and the first submission is where most teams discover the rules they did not know existed. Getting that wrong once is a delay measured in days; getting it wrong twice, in parallel, on two stores with different requirements, is how a launch date slips by a month.

In practice, shipping on one platform is also the fastest way to discover early that half the planned features interest nobody — the subject of the specification trap.

When you need both from day one

Some cases settle themselves. As soon as the audience is consumer and not known in advance, giving up a third or two thirds of the market is not a saving, it is a ceiling. The same applies when the app is part of something already sold, where a customer told "we are not on your phone" is a customer lost on the spot.

The clearest case is a product whose value depends on users meeting each other: two-sided booking, a marketplace, anything that connects people. A single platform there does not remove half the users. It removes a much larger share of the possible matches.

One more case is worth naming because it is usually discovered too late: an app sold to a company whose staff use their own phones. The handset fleet is then not uniform at all — it follows the national split. Telling an operations director that you cover two thirds of their teams is asking them to handle the remaining third themselves, which none of them will do.

What actually decides it

In short: platform share describes a country, not your audience. The question is not which platform is more common, but whether the people you are targeting are genuinely on both sides, and whether you have the budget to maintain two listings, two calendars and two rule sets for years.

The most important thing is that this decision can be revisited. Launching on one platform and adding the second six months later is a common and often healthier path. The reverse — withdrawing a platform you can no longer maintain — is seen far less often, because it is much harder to justify to the people already using it.

I often find the question arrives the wrong way round. People ask what the second platform costs, when the useful question is what it returns. On an internal app the answer is sometimes zero, and nobody had worked it out. On a consumer app the answer is almost always "more than it costs", and the hesitation is coming from somewhere else — usually a budget fixed before anyone knew what was going to be built.

Frequently asked questions

Which platform should I start with if I can only pick one?

The one your audience is on, not the larger one. In France Android leads mobile traffic at 63.26% against 36.72% for iOS (StatCounter, July 2026), but a national average describes neither a professional clientele, nor a company handset fleet, nor a young urban audience. If you know your users, look at their phones rather than at the statistic.

Does a shared codebase mean both platforms cost nothing extra?

It cuts development cost substantially, but not the rest. You still need two developer accounts, two store listings governed by contradictory asset rules, two review processes and two update calendars to keep pace with. The extra cost of the second platform is mostly maintenance and compliance, not code.

Can the second platform be added later without redoing everything?

Yes, provided it is decided at the start. An app designed from day one to accommodate a second platform extends to it without rewriting. An app designed for one, with technical choices that depend on it, is paid for in rework. It is an architecture decision taken before the first line of code, not an option switched on later.

The number of platforms is a budget decision before it is a technical one, and it follows the same reasoning as the rest of the costs that arrive after launch: what matters is not what it costs to build, but what it commits you to maintaining every year.