iOS or Android First? Picking Your Launch Platform
Executive TL;DR
- The global split is a distraction. Android holds roughly 68% of worldwide devices while the App Store takes about 70% of combined store consumer spending — and both numbers invert by country: iOS leads the US at about 60%, while India is over 90% Android.
- Pick the platform where your paying users already are, then make the choice reversible. Keep domain logic, API contracts and analytics platform-agnostic from day one so the second platform is a UI project, not a rebuild.
- For most B2B products and many early consumer ones, the honest first answer is neither — ship mobile web, learn what people actually do, and spend the native budget once you know which platform your revenue sits on.
The confusion is largely due to two true statements. Android has far more users: StatCounter estimated Android's share of worldwide mobile OS usage at around 68% in July 2026, versus around 32% for iOS. iOS users spend much more: the App Store generated $117.6 billion in consumer spending in 2025 vs. Google Play’s $49.2 billion, which is close to 70% of combined store spending—whereas Google Play produced around three times as many downloads.
Both are real, and neither tells you what to build because they both flip depending on where you sell. July 2026 data also shows iOS leading in the U.S. at around 60% and Japan at about 64%, while India has over 92% Android and under 8% iOS. A fintech for Indian small businesses and a productivity app for US knowledge workers are having entirely different conversations.
Mistake #2: Believing the choice is a permanent decision. But it’s only forever if you make it so. Teams that put business rules inside view controllers discover the second platform costs as much as the first. Teams that don’t tie the domain, API contract, and analytics schema to the UI layer find it costs a fraction.
So the question, which is useful, is narrower than the usual debate.
iOS first, Android first, cross-platform both at once, or mobile web first — which launch path fits your market and your budget?
| iOS first | Android first | Cross-platform | Mobile web / PWA | |
|---|---|---|---|---|
| Cost to first launch | Moderate — one codebase, a narrow device matrix, predictable tooling | Moderate, plus a wider device and OS-version matrix to support | Highest single build, but it is both platforms at once | Lowest — no store, no native toolchain |
| Audience reach | Strongest in the US, UK, Japan, Australia and higher-income segments | Strongest almost everywhere else: India, Africa, Latin America, most of Asia | Both, immediately | Anyone with a browser, including desktop |
| Monetisation | Best-documented in-app spending; the App Store takes roughly 70% of combined store consumer spending | Larger download volume, weaker per-user store spending; ads and non-store payments often fit better | Same store economics as whichever platform the user is on | You own the payment flow and avoid store commission entirely |
| Release and iteration friction | App review adds a delay to every release; plan for rejections | Faster review in practice, staged rollouts and easy beta tracks | One release process, but native modules still need platform work | Deploy whenever you like — the fastest learning loop available |
| QA and device burden | Lowest — few screen sizes, fast OS adoption | Highest — many manufacturers, skins, screen sizes and live OS versions; test on a cheap device, not a flagship | Both matrices, plus the framework's own quirks | Browser matrix, which is easier than either native one |
| Rework risk for platform two | Low if the domain layer is shared, high if logic lives in the UI | Same, with the same caveat | Lowest — platform two is mostly layout work | Low — a native shell later reuses the API and the learning |
| Fails when | Your users are in Android-majority markets, or price sensitivity is the product | Revenue depends on in-app purchases from high-spend markets | You need deep platform-specific capability: heavy camera, background processing, widgets, complex offline sync | You need push reliability on iOS, deep hardware access, or store presence as a distribution channel |
When to pick each option
If your paying users are in iOS-majority markets and your model depends on in-app spending (a US or Japanese consumer subscription, a premium tool, anything where willingness to pay matters more than installed base), start with iOS. The practical bonus is the smallest device matrix in mobile, which means less QA and faster iteration while you are still changing the product weekly. The trap is to think that the global revenue split applies to your product; it describes spend in the store across all apps, not your conversion rate.
Start with Android if you are in an Android-majority market—say, India, Southeast Asia, Africa, or Latin America—or where distribution matters more than per-user revenue. It’s also the right move if your monetization is not store-based at all: ads, marketplace commission, B2B invoicing, or payments outside the app. Device matrix budget explicitly. Your first test device is a mid-range phone with modest RAM, not the newest flagship, because that's what your users are holding.
Cross-platform when you really need both at launch—a two-sided marketplace where a missing platform breaks liquidity, or an enterprise rollout where IT won’t accept half a fleet. React Native or Flutter gets you one team and one release cycle, but you pay for it in being tied to the framework’s own release treadmill and native modules for anything deep. Don’t pick it to hedge your indecision. Pick it when both platforms are a requirement, not an ambition.
Make more of a mobile web than you think. If your product is mostly forms, lists, dashboards, and text—which covers most B2B—then a responsive web app ships faster, iterates without review, costs nothing in store commission, and tells you from real traffic which platform your users are on. That is the decision data you are currently missing. Graduate to native when you hit a specific wall: reliable push, hardware access, offline-first behavior, or the store itself being a channel you need.
Rendering diagram…
// packages/core — imported unchanged by the web app, the iOS app and the Android app.
// Nothing in here imports React, SwiftUI, Compose, or a navigation library.
export type Plan = 'free' | 'pro';
export type Entitlement = { canExport: boolean; seatLimit: number };
// Business rules live here, not in a screen. When pricing changes, one file changes.
export function entitlementsFor(plan: Plan, seatsUsed: number): Entitlement {
const limits: Record<Plan, number> = { free: 3, pro: 50 };
return {
canExport: plan === 'pro',
seatLimit: limits[plan] - seatsUsed,
};
}
// One event schema for every client. If iOS and Android name the same action
// differently, you cannot compare platforms — which is the comparison that
// decides where the next engineer's month goes.
export const events = {
signupCompleted: (p: { method: 'email' | 'oauth' }) =>
({ name: 'signup_completed', props: p }) as const,
exportBlocked: (p: { plan: Plan }) =>
({ name: 'export_blocked', props: p }) as const,
};
// Platform-specific work is injected, never imported. The core does not know
// whether it is running in a browser, on iOS or on Android.
export interface Platform {
track(event: { name: string; props: object }): void;
secureSet(key: string, value: string): Promise<void>; // Keychain / Keystore / IndexedDB
}
export function makeApp(platform: Platform) {
return {
tryExport(plan: Plan, seatsUsed: number) {
const ent = entitlementsFor(plan, seatsUsed);
if (!ent.canExport) {
platform.track(events.exportBlocked({ plan }));
return { ok: false as const, reason: 'upgrade_required' as const };
}
return { ok: true as const };
},
};
}
// The test that proves the architecture works: this file's test suite runs in Node,
// with no simulator and no emulator. If it cannot, your logic has leaked into the UI.MVP development planner
Scope, budget, and launch plan
Choose the product, platforms, and modules. The range, phases, and team update as you go. It is a planning figure, not a quote.
Newsletter
One architecture teardown or evaluation, every other week
Practical write-ups on framework choices, migrations, and scaling decisions – written for people who have to defend the call in a meeting.
Newsletter
Get the 2026 Tech Stack Guide
Join the KarmaKoders newsletter for architecture notes, stack evaluations, and build playbooks.