iOS or Android: where to start when you can't do both

Start with the platform the people who'll open the app actually use, not the one in your own pocket. In Romania, most mobile traffic comes from Android, but the national average isn't necessarily your customer. Look at your own data first, then at what each app store requires, and only then decide.

What the big numbers say

StatCounter measures which operating system is running on the phones that visit websites in its network. In April 2024, in Romania, Android had 74.4% and iOS 25.2%. Two things to keep in mind when you read that number:

• it counts page views, not phones sold or people;
• it's the national average. An app for a trucking company's drivers and an app for a high-end salon's clients can have very different audiences.

For your own audience there's a better source: your website analytics. Almost every analytics tool shows which operating system your mobile visitors use. If the people already looking for you are 60% on iPhone, the national figure matters less.

The questions that tip the scale

If the answer to all three is "I don't know," the national numbers point to Android. If the app is for your own employees, it's even simpler: build it for the phones they already have.

What each store requires before you publish

This is where first launches often lose weeks, so put it on the calendar from day one.

Apple. The developer program is paid yearly. A company enrolls as an organization and needs a D-U-N-S Number, which Apple uses to verify the company's identity, legal status and address. If your company doesn't have one yet, getting it goes on the calendar before any release.

Google. The developer account is a one-time fee at registration, and identity is verified when you set up the account. For personal accounts created after November 13, 2023, Google requires a closed test before you can publish to the store: a group of opted-in testers and at least 14 days of continuous testing. For a business, the cleanest option is an organization account in the company's name, not one tied to an employee's phone.

The store fees are set by the stores, not by us. What drives the cost of the app itself is different: how many screens it has, whether it takes payments, sends notifications or shows a map, and how many platforms it ships on at launch.

The third option: one codebase

"iOS or Android?" assumes you'll write the app twice. You don't have to anymore. With Flutter, for example, you write one codebase that produces both the Android and the iOS app. That's how we usually work: build once, test first on the platform where most users are and publish there, then put the same app in the other store once the account and testing are ready.

There's one more route for simple apps: a web app that opens in the browser on any phone and skips the stores entirely. We wrote about the difference in our article on web apps versus store apps.

How we decide in practice

1. We check your website analytics for mobile operating systems.
2. We figure out who the first 20 to 50 users are and what phones they carry.
3. We open the developer accounts in the company's name in week one, so the launch isn't waiting on paperwork.
4. We build a single codebase and launch first on the winning platform.
5. After a few weeks of real use, we publish on the second one.

If you're starting from scratch, our MVP article helps you cut everything the first version doesn't need.