iOS First, Android First, or a Web App? How to Pick the Starting Platform for Your App

Almost every client with an app idea asks me the same thing in the first message: "Should it be on iPhone, Android, or both?"

Building everything at once feels safe. It usually costs more and takes longer, and you learn about your users later. Starting with one platform, or with a web version, gets the first real users in front of the product sooner.

I'm Ilya, a solo developer in Bali. I've built apps that live on iPhone, in a browser, or both. Here is how I'd choose, with market numbers for the US and Australia and dates next to them.

Start with the numbers for your market

The share of phones in your country should be your first input. StatCounter publishes monthly figures for mobile operating systems. They measure web traffic from each system, not the number of phones sold, so treat them as a good signal and not a census.

As of the StatCounter pages I checked on 28 October 2026:

The pages update every month, so open them again before you decide.

The gap between rows is the point. In Australia iPhone leads by a wide margin. In North America it leads by a smaller one: close to half of mobile traffic is Android, so you can't ignore it. Worldwide, Android leads by a wide margin. If your customers are in Sydney, "iPhone first" has strong support in the data. If they are in Chicago or Toronto, it has some. If you sell in Southeast Asia or Latin America, the same logic can point the other way. Look up your own country.

Your audience may not match the market

National averages describe everyone. Your customers are a smaller group, and they can differ a lot.

A short test costs nothing. Ask ten people who fit your target customer which phone they use, or look at which devices visit your website if you already have one. Ten answers will not be a scientific sample, and if nine of them hold the same kind of phone, you have a direction.

Three paths

Path 1: a web app first

A web app runs in the browser. A progressive web app, or PWA, goes a step further: the user can add it to the home screen and open it like an app. There is no app store review and no store developer account, and an update reaches every user as soon as you publish it.

This path suits you if:

• the main job of the app is showing information, taking requests or running a simple workflow
• you want real users as fast as possible to see whether anyone cares
• you don't yet know which phone your customers use

The limit is access to the phone. Features that rely on deep device integration are easier in a native app.

Path 2: iPhone app first

A native iPhone app lives in the App Store. It can reach the device's features more directly, and it feels at home on the phone.

This path suits you if:

• your customers are mainly in markets where iPhone leads, such as Australia, and to a lesser degree North America, per the table above
• the app needs strong device features
• you want to be in the store as a trust signal

You pay for an Apple developer account and go through App Review. I wrote a separate guide on that process: how to publish an app on the App Store and Google Play.

Path 3: Android app first

This path suits you if your audience is in an Android-majority market, or if your customers are people you already know use Android. Worldwide numbers favor Android, so for international products it can be the first choice.

Both platforms at once

Two platforms from the start make sense when you know your audience is split and you have the budget. Ask your developer whether both versions come from one codebase or two. The answer changes the price and the cost of every later change.

What I've done in my own projects

Lunelo is an AI task planner. You speak or type what you need to do, and an AI model (Claude Haiku) turns it into a list of tasks. It exists as an iPhone app and as a web app (PWA). See the Lunelo case.

Lilu is my own app. It came out in the App Store on 24 September 2026 and is also on Google Play, so it covers both platforms. See the Lilu case.

The platform is a decision about your audience and your app's job, and different products can answer it differently.

A simple way to decide

Answer four questions.

1. Where do my first 100 users live? Check that country's iOS and Android share.
2. What phones do ten of those people carry? Ask them.
3. Does the app need deep phone features? If yes, lean native. If it is mostly screens and forms, a web app may be enough to begin.
4. How fast do I need real feedback? If speed matters most, start with the web version.

Then pick the single path that fits most of the answers, and plan the second platform for after you have real users.

What it costs

A mobile app from me starts at $1,500 and takes from 4 weeks. After launch, I include 30 days of fixes. If the app uses AI or a server, you pay those providers month by month. The Apple and Google accounts are opened in your name and at your expense. Payment is by bank transfer (to an Indonesian account), PayPal or crypto (USDT or USDC).

Summary

• iOS leads mobile traffic in Australia (62.59%) and in North America (53.03%), both September 2026. Worldwide, Android leads at 69.17%.
• Check your own country, and then ask real customers which phone they use.
• A web app (PWA) is the quickest way to real users. An iPhone app suits iPhone-heavy markets and device features.
• Plan the second platform after you have users.

Published: October 28, 2026. By Ilya Litau, more on the About page.