iOS vs Android app development

The football platform we built started with a straightforward ambition: launch on both iOS and Android, reach the widest possible audience, and grow subscriptions from day one. The client was bootstrapped, the scope kept expanding, and the budget was finite. Midway through the project, we made the call to pause Android development entirely and reallocate everything remaining to the iOS build.

The client launched with iOS only, addressing roughly half the potential market. And because their target audience skewed younger and heavily towards Android, day-one adoption was approximately half what it would have been had we launched on both platforms. The subscription model they had built the business around had to be abandoned. Advertising came in to replace it, a direction they had explicitly said they would not take.

The platform decision asked late or under pressure rarely produces the right answer.

That sequence of events did not start with a technical decision. It started with a scope problem that forced a platform decision under pressure. The iOS versus Android question, when it gets asked late or under duress, rarely produces the right answer. Answered early and with a clear view of who the product is actually for, it is one of the most useful choices a product team can make.

What follows is an honest account of what the choice actually involves, drawn from projects where we saw the consequences play out in real budgets, real user numbers, and real revenue models.

What the iOS vs Android Decision Actually Involves

Most people frame this as a technical question. Which language, which IDE, which set of design guidelines. Those things matter, but they are downstream of a simpler question: who are your users, where do they live, how much are they likely to spend, and what business model does the product rely on?

The platform choice determines your addressable audience before a single line of code is written. Android commands 72.13% of global smartphone market share, according to GoodFirms, 2025. iOS holds a much smaller share globally but dominates specific markets and specific spending behaviours. Choosing iOS in a market where your users predominantly carry Android devices is a strategic error, and it compounds every decision that follows.

The choice also shapes your development timeline, your testing burden, and your design system. iOS apps run on a relatively controlled device ecosystem. Apple sells a defined range of hardware, which makes it easier to predict how an app will behave across screen sizes and operating system versions. Android runs on thousands of device configurations from dozens of manufacturers, which means testing is more complex and edge cases are more frequent.

Neither platform is the obvious right answer. The right answer depends on four things above all others: your audience's geography, their spending behaviour, your monetisation model, and your available budget.

Who Uses Each Platform and Where

The global numbers make Android look like the obvious choice. Over three billion active users worldwide, compared to iOS's approximately 1.56 to 1.8 billion, according to estimates from Statista and Counterpoint Research, 2026. Android holds 95% market share in India. Across much of sub-Saharan Africa, Latin America, and South-East Asia, Android is the default. For products designed to reach a global or emerging-market audience, ignoring Android means ignoring the majority of the people you are trying to reach.

iOS tells a different story in specific geographies. In the United States, iOS holds 58% market share. In the United Kingdom, Japan, Canada, and Australia, it holds over 50%. These are high-income markets where the average user spends more per app and where subscription models are considerably more viable.

Where your users actually are

The football platform we worked on was designed for younger users in a market where Android penetration was high. Building the more polished version of the product for the smaller half of the audience was not the plan, it was the outcome of a budget problem. Had the platform question been anchored to audience demographics from the start, the development sequence would have looked different.

For a product targeting a specific geography, the right question is which platform the people in your city, your country, or your demographic actually use.

How Platform Choice Affects Revenue Model

The football platform case is worth sitting with here, because the revenue model collapse was a direct consequence of the platform decision. Launching iOS-only in a market skewed towards Android meant the user base was too small to sustain subscriptions. The client introduced advertising, something they had explicitly ruled out, because they had no alternative. That is a revenue model forced on a product by a platform decision made under budget pressure.

The spending gap between platforms is real and measurable. iOS users spend up to 2.5 times more on in-app purchases and subscriptions than Android users, according to RipenApps. Apple's App Store captured an estimated 63 to 65% of total global app store consumer spend in 2024, according to Precedence Research, despite serving a smaller user base.

Matching the platform to the model

A subscription or premium-purchase model works better on iOS in high-income markets, where users are more accustomed to paying for software and where the platform has cultivated that expectation over many years. An ad-supported model, or a freemium model relying on volume, benefits from Android's larger global reach.

Choosing iOS for a subscription product and then discovering your audience is on Android is not a recoverable error without significant additional spend. The revenue model and the platform choice need to be made together, not sequentially.

When Budget Forces the Decision

Building native apps for both platforms at the same time roughly doubles the development cost. Two codebases, two sets of platform-specific components, two testing environments, and two submissions to different app stores with different review processes. For a well-funded product with a large addressable market, this is manageable. For a bootstrapped product with a fixed budget and a changing scope, it is where things break.

On the football platform, the decision to pause Android was not made because Android was the wrong platform. It was made because the budget had been consumed by scope expansion and repeated design changes driven by a team member who was making visual decisions without accounting for their development cost. The remaining money had to go somewhere, and iOS received it because it was further along.

Fix your scope before you fix your platform. Budget pressure during build forces platform decisions that should have been made at the start, and those late decisions carry the highest long-term cost.

Cross-platform frameworks like React Native and Flutter reduce some of this cost by allowing a shared codebase to run on both platforms. They are not a free solution: there are performance trade-offs, platform-specific UI behaviour can feel inconsistent, and complex native features often require additional platform-specific code anyway. But for a product where reaching both audiences matters and the budget is limited, they are worth evaluating early rather than late.

The Cost of Choosing the Wrong Platform for Your Audience

The football platform is the clearest example we have of this cost made concrete. Half the potential user base unavailable at launch. A subscription model abandoned in favour of advertising. Ongoing financial strain on a product that had been designed around a different economic assumption. None of that was inevitable. It was the downstream consequence of a platform mismatch between the product and its audience.

Choosing the wrong platform is not always a catastrophic failure. Sometimes it is a slower erosion: acquisition costs are higher because you are reaching users on a platform they are less engaged with, retention drops because the experience feels slightly off for the way those users expect apps to behave, and revenue per user sits below what the model required.

The cost is also felt differently depending on the product category. A travel booking app targeting business travellers in the UK and US will feel the cost of an Android-first decision less acutely than a social platform targeting younger users in markets where Android dominates. The category shapes how serious the mismatch becomes.

Map your target user's device before you commit to a platform. If you do not have that data yet, run a brief survey or look at what the apps your audience already uses are built on.

Design and UX Differences Between Platforms

iOS and Android have distinct design languages that shape what users expect from an app. iOS uses Human Interface Guidelines, which favour clean typography, gesture-based navigation, and a visual hierarchy built around the assumption that users tap to navigate. Android's Material Design system emphasises elevation, ripple effects on interaction, and navigation patterns that often differ structurally from their iOS equivalents.

These are not just aesthetic differences. A bottom navigation bar behaves differently on iOS than on Android. A back gesture on iOS is typically a swipe from the left edge. Android devices have historically had a dedicated back button, though this has evolved. Users who are accustomed to one pattern notice when the other feels wrong, even if they cannot articulate why.

Designing for platform conventions

Building a single design and deploying it identically on both platforms saves design time upfront but costs it in user experience. The app can feel slightly foreign to users on either platform, which is a subtle but real friction. For products where the interaction quality is part of the value proposition, this matters more than it does for utility-first tools.

Where a product's emotional design is doing significant work, and this is central to what we think about at WAA, the platform conventions need to be understood rather than overridden. Designing for the ideal interaction without accounting for how each platform's users actually navigate is a version of designing for the ideal user rather than the actual one.

App Store vs Google Play: Discovery and Optimisation

Both stores reward apps that communicate clearly what they do and for whom. An accurate, specific listing reduces the mismatch between what users expect and what they find when they open the app. That matters because a user who downloads with correct expectations is far more likely to stay. Users who arrive misaligned abandon quickly, and early abandonment is the metric that most reliably predicts whether a product will survive.

The two stores differ in how they surface apps. The App Store has historically been more curated, with editorial features that can drive significant volumes of downloads for products Apple chooses to promote. Google Play has a larger total inventory, with 2.44 million apps and three times more downloads than the App Store, according to GoodFirms, 2025, which means discoverability without editorial support can be harder.

Review timelines and submission differences

App Store review times have shortened but can still run to several days for new submissions or significant updates. Google Play's review process is generally faster. For a product that needs to push frequent updates, the review cycle is a real operational consideration, and it affects how quickly you can respond to user feedback or fix a live issue.

Both stores use keywords, ratings, and review volume as ranking signals. A product launching with poor early reviews, often the result of releasing before the product is ready, can dig a ratings hole that takes months to recover from.

When a Native App Is Not the Right Answer at All

A native app requires a user to find it, download it, grant permissions, and open it before experiencing any value. That sequence is a meaningful barrier for some use cases, and the question worth asking before committing to a build is whether the barrier is proportionate to what the product actually does.

We faced this question on a performance coaching survey app. The original brief called for audience members to download a native app to respond to in-session surveys. We pushed back, because asking an audience of fifty or a hundred people to download an app in the middle of a presentation is a significant friction point for what is, in practice, a single touchpoint.

The solution we recommended used the iOS native app for the presenter side only. A survey is created in the app, a QR code is generated using iOS's built-in libraries, and it appears on screen during the presentation. Audience members scan it and reach a fully branded, mobile-responsive web page. No download required. The survey closes the moment the presenter marks it finished, and no further responses are recorded. Survey completion rates improved substantially compared to what an app-download approach would have produced.

Before choosing between iOS and Android, ask whether a native app is the right format at all. A mobile-responsive web experience removes the download barrier for lower-frequency touchpoints and can deliver a comparable experience without the store submission process.

Progressive web apps, mobile-responsive sites, and hybrid approaches are legitimate answers for many use cases. The platform decision only matters if a native app is genuinely the right format, and that question deserves its own evaluation before the iOS versus Android conversation begins.

How Platform Choice Compounds Every Development Decision That Follows

The platform decision is made once and then lived with for a long time. Every subsequent choice about architecture, third-party integrations, payment processing, push notifications, and testing infrastructure is shaped by it. This is why making the decision late, or under budget pressure, carries such a high cost.

Push notifications are a good example of where platform differences compound into real behavioural differences. On iOS, users must opt in to receive push notifications, and the opt-in rate sits at 43.9%. On Android, the default has historically been opt-out, with opt-in rates of 91.1%, according to Mobiloud. A re-engagement strategy built around push notifications performs very differently on the two platforms, and a product designed for one platform's engagement model can feel broken when it migrates to the other.

The dating app we worked on is a different illustration of how early decisions compound. The client skipped discovery for the messaging component and focused the early work on onboarding. The result was a generic messaging system that allowed automated and fake messages, directly undermining the verified-profile promise that the entire product was built around. Rewriting the messaging section cost approximately £15,000 in additional budget and two months of additional work. The platform was not the issue there, but the principle is the same: decisions made early without adequate thinking lock you into expensive corrections later.

Conclusion

The iOS versus Android decision is not a technical preference to be settled at the start of a project and then forgotten. It is a strategic choice that reflects who the product is for, how it will make money, and what the realistic budget for reaching that audience looks like. Made well, it aligns the product with its actual market. Made badly, or made late under financial pressure, it can halve your addressable audience before you have written a line of code.

The football platform we worked on is the clearest demonstration we have of what happens when the platform decision gets overtaken by scope and budget problems. iOS-only launch, younger Android-skewed audience, subscription model abandoned. Those consequences were not unforeseeable. They were the predictable result of a decision made without the right information at the right time.

The right process asks the audience question first, the revenue model question second, and the platform question third. Cross-platform frameworks and progressive web approaches deserve evaluation before native is assumed. And if a native app is the right answer, the platform choice should be made before the scope is set, not after the budget has been spent.

If you are working through a platform decision and want to think it through properly before committing to a build, let's talk about your product.

Frequently Asked Questions