iOS or Android First? How to Choose Your App’s Platform

iOS vs Android app development is not a prestige contest, and the platform “everyone serious builds for first” does not exist. The two systems differ in how apps reach people, how they ask for permissions, how many kinds of device they run on and how people expect to move around an app. Pick the first platform from your actual audience, your business model, the integrations you depend on, your markets, the devices your users carry and what your team can really support. Anything else is a guess dressed up as strategy.

In our mobile product work, this question arrives in the first call more often than any other. It usually comes pre-answered. “Our users are on iPhones.” “Android is where the volume is.” “iOS users pay more.” Each of these can be true for a product. None of them is true for every product, and the teams that pick on vibes find out the expensive way: a launch aimed at people who are not there, an acquisition budget spent sending ads to a store listing half the audience cannot install, and a second platform bolted on in a panic six months later.

This guide is the decision process we actually use. It covers what differs between the systems in ways that change your product, how to read your own evidence, where cross-platform code helps and where it does not, and how to choose a release sequence your team can survive.

iOS vs Android app development: the decision in one screen

Here is the short version before the long one. The first platform is the one where your riskiest assumptions can be tested with the people who will pay for the product, on the devices they actually use, by a team that can support what it ships. That sentence contains six inputs, and each one can overrule the others:

• Audience. Which platform your target users carry, measured, not remembered.
• Business model. How the product makes money, and which store rules apply to that model.
• Required integrations. Hardware, sensors, health data, payments, background work — the system features the product cannot live without.
• Geography. The platform split varies hugely by country, so “our market” matters more than “the market”.
• Device constraints. Screen sizes, old phones, cheap phones, company-issued phones, rugged scanners in a warehouse.
• Team capability. Who designs, builds, tests and supports each platform after launch, not only before it.

Notice what is missing: “which platform is better”. Horses for courses. A platform is better for a product, a market and a team, never in general. If someone gives you a universal answer, they are selling you the platform they already know how to build.

The best platform is the one your paying users already hold in their hand. Everything else is a debate club.

Why “iPhone users pay more” is not a platform strategy

The most common reason teams give for going iOS first is some version of “that’s where the money is”. Sometimes it is. But the claim usually rests on two things that have nothing to do with the product: a general belief about iPhone owners and the phones on the founders’ desks.

Asking your own team which phone they use is a head count at your own birthday party. Everyone there likes you, lives near you and has roughly your budget. Nobody at the party is your customer. Product teams in the US and UK skew towards iPhones, so the “survey” comes back unanimous, and a strategy gets built on a sample of five people who will never buy the product.

The prestige version is worse. “Serious products launch on iOS” treats the platform like renting an office in the glass tower so the letterhead looks good. The rent is real. The letterhead impresses nobody who was going to buy from you anyway. And the users you actually need may be across town on phones your launch does not support.

Even when a group of iPhone owners does spend more in general, that tells you nothing about whether they will spend it on you. A field-service tool, a delivery-driver app or a product for a price-sensitive market can have a paying audience that is mostly on Android, whatever the averages say. A premium consumer subscription in the US can be the opposite. The average is not your customer. Your customer is your customer.

Start with your audience and geography, not the global chart

Global averages are a starting point, not an audience definition. In StatCounter’s September 2026 mobile-web data, Android accounts for 69.17% worldwide and iOS for 30.81%. The United States shows 53.59% iOS and 46.39% Android; the United Kingdom shows 53.11% Android and 46.88% iOS. These are shares of observed mobile web traffic, not device sales or your product’s paying users. The worldwide chart is context; your own audience decides the launch.

Three markets, three different answers. A product launching in the US, one launching in the UK and one launching across several countries face three different defaults before they have looked at a single user. And a default is still only a default. Your target segment inside a country can differ from the country as a whole by a mile.

So get your own split. The cheapest sources are usually already in your hands:

• Your website and web app analytics. Sessions and, better, sign-ups by operating system and country. Sign-ups beat sessions: you care about people who commit, not people who bounce.
• Your existing customers. For B2B products, ask which devices the company issues or allows. A sales team on company iPhones and a warehouse crew on rugged Android scanners are one customer and two platforms.
• Your waitlist or landing-page test. Collect the operating system with the sign-up. It takes one field, or none, since the browser already tells you.
• Competitors’ customers, cautiously. Reviews and store listings show where rivals put effort. They do not show where their revenue comes from.

The fishing trip works the same way: you pick the lake after you know what you are fishing for, not because the lake has the prettiest jetty. Once you have your split, weight it by value. A segment that is 30% of sign-ups and 70% of revenue outranks the majority.

Your business model decides more than market share does

How the product makes money changes which platform should go first, and it also changes how each platform will treat you.

Subscriptions and in-app purchases of digital content run through each store’s billing rules, and those rules differ by store, by region and by year. They have changed repeatedly under regulatory pressure, including in the EU and the US. Check the current store policies for your launch markets before modelling revenue, so the payment flow and the business plan agree.

Physical goods and services — food delivery, rides, bookings, retail — generally sit outside the stores’ digital-goods rules and use their own payment providers. Here the platform question is less about billing and more about audience, devices and checkout friction.

Advertising-funded products need scale, and scale follows the majority platform in each market. An ad-funded app that launches only on the minority platform in its main market has halved its inventory before selling a single impression.

B2B products often have no purchase in the app at all. The customer pays by contract, and the app serves the people who do the work. For them, the device policy of the customer’s company matters far more than any store statistic.

The money logic is cold and simple. Every user you acquire on a platform where the product cannot yet make money is a user you paid for twice: once to bring them in, and again later to win them back when the second platform arrives, if they are still interested. Launch where the revenue model works first, not where the downloads look biggest on a slide.

Distribution: two stores, two sets of gatekeepers

Most comparison articles stop at “Apple reviews apps more strictly”. The real difference is broader: each store has its own route from a finished build to a user’s phone, its own paperwork and its own timing. Your launch plan has to fit both routes, or at least the first one.

Think of it as crossing two borders with two customs desks. One desk opens every suitcase but usually waves you through the same day. The other asks newcomers for weeks of stamped paperwork before the first crossing. Neither is worse. Both will wreck your launch date if nobody on the team has read the rules.

On the App Store, every submission goes through App Review. Apple states that on average 90% of submissions are reviewed in less than 24 hours, and an incomplete submission slows that down or fails it. Beta builds for external testers go through TestFlight, and version updates can use phased release, which rolls an update out to users with automatic updates over seven days, from 1% on day one to 100% on day seven, with the option to pause.

On Google Play, there is a sequence of testing tracks — internal, closed, open — before production. For personal developer accounts created after November 13, 2023, Google requires a closed test with at least 12 testers opted in continuously for 14 days before you can apply for production access. Updates can be released as staged rollouts to a percentage of users. From August 31, 2026, new apps and app updates must target Android 16 (API level 36) or higher, with separate requirements for some device categories.

The costs of entry are small and different too: the Apple Developer Program is US$99 per membership year, or local currency where available, and a Google Play developer account has a one-time US$25 registration fee. Those numbers never decide anything. The calendar does.

What this means for the product:

• Plan the release calendar backwards from the stores, not forwards from the last sprint. A marketing launch booked for the day the build is “done” is a launch booked on hope.
• Budget for rejection and resubmission on both stores. Missing privacy disclosures, unclear account deletion, broken demo credentials for the reviewer — the boring reasons are the common ones.
• Design the update path. Phased and staged rollouts only help if you watch crash and support data during the rollout and have someone empowered to pause it.
• Know your store listing rules before you design the onboarding. What you may say, show and charge for inside the app is store policy, not taste.

The store is the front door of a mobile product. It is also a door you do not own. Every day your app spends stuck in review or in a testing track, the ad campaign you booked keeps billing.

Permissions: the same feature asks differently on each system

Permissions are where “it’s the same app on both platforms” falls apart first. The feature is identical — notifications, location, photos, a Bluetooth sensor — but the system prompts, the defaults and the rules for asking again are different. Design them once and copy the flow across, and one platform will get a worse experience, usually the one nobody on the team uses daily.

A permission request is a job applicant asking for the company credit card during the interview. Maybe they will need it one day. Asking before anyone knows what they do gets a “no”, and a “no” to a system prompt is hard to take back: after a refusal, the recovery route depends on the permission, OS version and previous requests. Some paths require Settings; others allow another request. Design and test the route your supported devices actually provide.

The differences are specific, and they change the design:

• Notifications. On Android 13 and higher, notifications are off by default for newly installed apps; the app must request the notification permission and wait for the user to grant it. iOS requires authorization for user-facing alerts, sounds and badges; it also supports provisional authorization, which delivers notifications quietly before an explicit choice. On both, the old habit of assuming notifications “just work” is dead, and a retention plan built on push messages needs a design for earning the “yes”.
• Location. Android distinguishes approximate from precise location, and background location must be requested separately from foreground access. On Android 11 and higher, the system dialog does not offer “Allow all the time”; the user has to enable background location on a settings page. iOS distinguishes When In Use and Always authorization, and accuracy is a separate choice. Specify the access the feature needs and its behaviour when the user shares approximate location. A ride tracker, a delivery app or a safety product lives or dies on this flow.
• Bluetooth. On Android 12 and higher, scanning for and connecting to devices uses the “Nearby devices” permission; on Android 11 and lower, Bluetooth scanning required location permission, which puzzled plenty of users. iOS Bluetooth access uses a purpose string explaining the need. If your product pairs with a sensor, a lock or a wearable, you will be designing this flow for several system versions at once.
• Photos and files. Use the system picker for a selected photo instead of requesting broad library access. The Android photo picker grants access to selected media, and Apple’s Photos picker supports selection without handing the app the whole library. A product that demands the full photo library to upload one avatar is asking for more than it needs, and users can tell.

The design pattern is the same on both platforms even though the prompts are not: ask at the moment the feature is needed, explain in one line what the user gets, and design the path for “no” so the product still works. What changes per platform is the wording, the sequence and the recovery route, and those are specified per platform or they are not specified at all.

Device fragmentation: a small line-up versus a hire-car fleet

Designing for iOS means designing for a relatively small set of phone sizes from one manufacturer, most of them running recent system versions. Designing for Android means designing for many manufacturers, a wide range of screen sizes and prices, older system versions that stay in use longer and manufacturer-specific changes on top of the system.

Android is a hire-car fleet. You know the rules of the road, but you do not know which car you will get: this year’s model, an eight-year-old hatchback with a sticky clutch, or something with the controls moved around by the manufacturer. You still have to arrive on time. iOS is closer to a fleet of one make in a few model years. Different in size, familiar in every other way.

What fragmentation actually breaks:

• Layouts at small widths, large font settings, foldables and tablets, where a screen designed at one size stretches or crams.
• Performance on low-memory phones, where the smooth animation on the designer’s flagship becomes a slideshow and the app is killed in the background.
• Background work such as ride recording, syncing and reminders, where some manufacturers’ battery-saving layers stop tasks the system itself would allow.
• Camera, Bluetooth and sensors, where hardware and drivers differ from brand to brand.
• System versions, where an older version handles permissions, notifications or storage differently from the latest one.

The answer is not “test on every device”. Nobody can, and nobody needs to. It is a device list built from your own audience data: the phones and versions that cover most of your users, plus the deliberately awkward ones — the cheapest popular model in your market, the oldest supported system, the smallest screen, the manufacturer with the most aggressive battery saving. The design has to be specified for those too, including large text sizes and what happens when the system kills the app mid-task.

The money line here is blunt. You pay the same to acquire a user on a cheap phone as on an expensive one. If the app stutters, crashes or forgets their workout on the cheap phone, you paid for a user whose first impression is a crash and whose second action is uninstall.

Interaction behaviour: same app, different reflexes

People bring years of habit to their phone. iOS and Android users have learned different reflexes for going back, finding actions, reading dialogs, sharing, picking dates and switching tasks. An app that ignores those reflexes does not look “unique”. It feels broken, and users rarely explain why. They just use it less.

Hand a right-handed child left-handed scissors and they will still cut. Badly, slowly, and convinced it is their own fault. That is what an iOS design copied pixel for pixel onto Android does to Android users, and the reverse is just as true.

The biggest single difference is going back:

• Android has a system back action — a gesture from the screen edge or a button, depending on the phone — that every app is expected to respect. With predictive back, the system can even preview where the gesture will lead. If your app treats system back as “exit” in the middle of a multi-step form, users lose their work.
• iOS has no system back button. Back lives in the app’s navigation bar and in the swipe from the left edge within a navigation stack. A design that relies on a hardware or system back will strand iOS users.

Beyond back navigation, the differences that most often show up in our reviews are these: where primary navigation and actions sit, how dialogs and bottom sheets behave, the system share sheet, date and time pickers, text fields and keyboards, notification styles, widgets and home-screen shortcuts, and default typography. None of them requires two different products. All of them require a decision about what is shared and what follows each platform’s conventions.

That decision is a design artefact, not a vibe. We write it down: which components and flows are identical, which adapt to the platform, and which exist only on one platform because the system offers something the other does not. Without that document, platform consistency is decided by whichever developer picks up the ticket.

Integrations and hardware: test the riskiest system dependency first

Most apps that fail on one platform do not fail on the screens. They fail on a system dependency nobody tested early: a Bluetooth sensor that disconnects when the screen turns off, background location that stops after ten minutes on a certain brand, a health-data integration with different data types on each platform, NFC, a camera feature, a payment method, an SDK from a partner that supports one platform better than the other.

Hair dye comes with an instruction everyone skips: do a patch test 48 hours before colouring your whole head. Product teams skip the equivalent too. They design every screen, build half the app and then connect the heart-rate strap for the first time three weeks before launch. That is the whole head dyed before the patch test.

The fix is small and unglamorous. Before committing to a platform order, list the system dependencies the product cannot live without, pick the riskiest one and build a throwaway technical prototype on the real target devices. A few days of that work can change the platform decision completely. For example:

• Health and fitness data. Apple’s HealthKit and Android’s Health Connect expose different data types and permission flows. If your product needs a specific metric, check that it exists and is readable on both before you promise it.
• Wearables and sensors. Pairing, reconnection and background data collection behave differently across system versions and, on Android, across manufacturers.
• Background location and long tasks. Ride recording, route tracking and delivery status depend on background execution rules that differ between platforms and change with system updates.
• Payments and wallets. Supported methods, regions and review rules differ.
• Partner SDKs. A banking, identity or hardware partner may treat one platform as the first-class citizen and the other as an afterthought. Ask before you sign, not after.

The prototype’s job is to answer one question: can this platform do what the product depends on, on the devices our users carry? If the answer is “only on one of them”, your platform order has just been decided for you, and it was decided for the price of a week, not a launch.

Cross-platform does not mean designed or tested once

Cross-platform frameworks such as Flutter and React Native let a team share much of the code between iOS and Android. For many products that is the right call: one team, one codebase, features landing on both platforms together. We weigh the trade-offs in detail in our guide to native vs hybrid app development.

What cross-platform does not do is erase the differences in this article. The permissions are still different. The stores are still different. The back gesture still exists on one platform and not the other. The cheap Android phone still has a battery saver. Shared code is a way to build; it is not a way to stop thinking about two systems.

A dubbed film is the right picture. The plot, the actors and the edit are shared. The voices, the jokes that do not translate and the lip-sync are done again for each audience, and when a studio skips that work, the audience notices in the first minute. A cross-platform app still needs its lip-sync: platform-specific design decisions, platform-specific testing on real devices and platform-specific release work.

AI coding tools have not changed this, whatever the demo videos say. They can generate code for two platforms faster than ever. They cannot tell you which users you are serving, how your permission prompts should read on Android 12 or why the ride recording stops on one brand of phone. Faster typing, same homework.

Teams choose cross-platform hoping to kill two birds with one stone. Done carelessly, the stone misses both: the app feels slightly foreign on each platform, and the time saved on code is spent on bug reports from the platform nobody tested properly.

What we recommend when a team goes cross-platform:

• Design shared flows once, then review them per platform for navigation, dialogs, pickers and permissions.
• Keep a platform-specific QA pass in every release, on real devices from each platform’s device list, not only simulators.
• Budget for native modules where a system feature or SDK has no good cross-platform wrapper, usually exactly around the riskiest dependency.
• Track crashes, reviews and funnels per platform. Averages across both hide the platform that is quietly losing users.

Team capability and a release sequence you can actually support

The last input is the one teams overestimate most. Launching on both platforms at once doubles more than the build. It doubles store work, device testing, analytics set-up, release management, support scripts and the number of places a bug can hide. A small team that tries it is running two marathons on the same weekend on one pair of legs. They will finish, maybe. They will not enjoy the second one, and neither will the users.

The opposite failure is just as common. Teams stuck between the two options for months end up like Buridan’s ass, the philosophers’ donkey that starved standing between two equally attractive haystacks. While the debate continues, a competitor ships on one platform, learns from real users and adds the second.

There are three workable sequences, and each has a condition attached:

Owning an app on a platform is a puppy, not a sofa. The purchase is the cheap part. Every year brings new system versions, new store requirements and new devices. Apple, for example, requires apps uploaded to App Store Connect from April 28, 2026 to be built with Xcode 26 or later using the iOS 26 SDK, and Google Play sets a rising target API level every year. Somebody has to feed and walk the thing on each platform you launch, for as long as it lives.

So the question is not “can we build it for both?” Almost anyone can build it. The question is whether you can support it: fix, test, release and answer users on both platforms every month, without the first platform rotting while the second one launches. If the honest answer is no, launch on one, learn fast and add the second when you can do it properly. Don’t put all your eggs in one basket is good advice for investments. For a small team’s first release, one basket you can watch beats two you can’t.

Platform mistakes we keep being called in to fix

Every mistake in this list was made by a smart team with a deadline. None of them looked like a mistake on the day.

• Choosing by the founders’ phones. The launch fits the boardroom and misses the market. The fix costs a second platform built in a hurry, and the users who arrived early and left do not come back for the sequel.
• Copying one platform’s design onto the other. Android users get iOS controls and no working system back, or iOS users get Android patterns with nowhere to go back to. Reviews call it “clunky”, and nobody on the team can reproduce the complaint on their own phone.
• Leaving permissions to the developers. Prompts appear wherever the code happened to need them, usually on first launch, and the refusal path is a blank screen.
• Testing on the office drawer of phones. Three recent flagships pass every test. The cheap phones your users actually carry do not.
• Discovering the store rules at submission. Billing, privacy disclosures, account deletion and testing-track requirements arrive as surprises the week the campaign goes live.
• Launching both platforms with one platform’s team. The second platform becomes a permanent version behind, and its users learn to expect it.
• Treating cross-platform as “done once”. One codebase, zero platform-specific QA, and a crash rate on one platform nobody looks at because the dashboard shows the average.

The pattern underneath is the same every time: a decision that should have been made with evidence was made by default. Defaults are free on the day and expensive for years.

How we approach the platform decision at ANODA

We do not have a favourite platform, and we are suspicious of anyone who does. When a client asks us “iOS or Android?”, we answer with a process, not a preference.

• We gather the evidence the client already has — analytics, customers, markets, the business model — and name what is missing.
• We list the system dependencies and flag the riskiest one for an early technical prototype.
• We write the platform requirements: permissions and their timing, background behaviour, integrations, the supported system versions and the device list.
• We design the shared and platform-specific UX as one coherent product: which flows are identical, which adapt, which exist on one platform only.
• We recommend a release sequence the team can support, with the conditions for adding the next platform.

ANODA connects the launch audience to the real product: the permission moments, device constraints and first useful task that a generic platform comparison leaves out. Sometimes the answer is iOS first, sometimes Android first, sometimes both with a cross-platform codebase, and sometimes “not an app yet”. The grass is always greener on the other store; the evidence usually tells you it is the same grass, with different fences. When the answer includes Android, our Android app development team builds from the approved designs and tests on the device list your users actually carry. For related reading on planning, budgeting and building mobile products, the ANODA UX blog covers the rest of the journey.

When web first is the better experiment

If the first release tests whether people want a content, booking or account workflow and does not depend on mobile-only capabilities, an existing or responsive web product may answer that question before two store releases. State the learning goal first: who should complete which task, and what would justify investing in a mobile app next. A web-first experiment is not a substitute when the core job depends on the device, offline work or background behaviour.

Keep identity and records continuous when a second platform arrives. Decide how accounts, saved work and subscriptions are recognised across web, iOS and Android, and who owns the backend contract. Otherwise “add Android” becomes a migration for users who already trusted the first release.

Write down the conditions for revisiting the choice: the audience split changes, a required integration becomes available, the first task is validated, or the team can support the second release. Review those signals after launch instead of defending the first decision forever.

If the first release belongs on Apple devices and its value depends on Apple capabilities, our iOS app development service implements the Swift journey, device integrations and TestFlight release around that audience. Bring the task and the devices it must work on; we turn the platform decision into a working product.

The decision rule

When the team is ready to decide, go through these questions in order and stop at the first one you cannot answer with evidence:

1. Do we know which platform our target, paying users carry, in each market we are launching in?
2. Does our business model work on that platform under its current store rules?
3. Have we tested the riskiest system dependency on real devices on that platform?
4. Do we have a device list and a permission map for it?
5. Can we staff design, build, testing, release and support for it for the first six months?
6. Do we have a dated, conditional plan for the other platform?

Any question you cannot answer is your next task, not a reason to guess. When all six have honest answers, the platform decision usually makes itself, and it rarely matches the phone in the founder’s pocket.

iOS versus Android is not a question of taste or status. It is a question of who you are building for, what the product depends on and what your team can keep running. Use your audience and your capabilities, test the riskiest dependency first and choose the release sequence you can support. Every month you don’t decide, you are choosing to keep paying for the debate.