iOS, Android or both? The single-codebase approach

Whether to build for iOS or Android comes down to which phones your users carry, your business model and your plan for maintenance after launch. If your audience is spread across both platforms, the most sensible route is usually to launch on both together from a single codebase. Starting on one platform first — for budget, testing or focus — is also a perfectly legitimate choice; what matters is that the product’s needs drive it.

Below we share the questions we ask when making this decision, what a single codebase does and does not give you, and how we thought it through when launching Tako.

Three options, briefly

Option	When it makes sense	What to watch
iOS only	Your audience is mostly on iPhone; you want to validate in one market first	Android users are left out at first
Android only	Your audience is mostly on Android, or the app will run on specific devices	iPhone users are left out at first
Both	Your audience is spread across both; the product must behave the same on each	Two stores, two test cycles, two sets of rules

Whichever you choose, today’s decision should not lock in tomorrow’s. A project built on a single codebase can launch on one platform and add the second later. With an app written separately for each, the second platform is almost a second project.

Four questions that decide it

1. Which phones do your users carry?

This is the most important question, and the answer lies in your own audience rather than in general statistics. In Türkiye, where we are based, Android has a broad user base; but in a corporate team, a particular profession or a product sold abroad, the picture can be entirely different.

If you have data, look at it: your website’s visitor statistics, your existing customers’ devices, the phones issued to your field staff. If you have none, even asking a handful of people from your target audience beats guessing.

2. What is the business model?

In-app purchases and subscriptions work under each store’s own rules. Selling digital content goes through the store’s payment system; selling physical goods or services follows different rules. If you are launching on both platforms, the set-up has to comply on both sides.

Tako’s free tier is ad-supported; extended features come through in-app purchases. That model was planned from the very beginning, with the store rules in view.

3. Which device features do you need?

Notifications, the camera, location, the compass or running in the background. Most of these exist on both platforms; but the way permissions are requested, the background limits and the wording shown to users all differ. If you need very specific hardware or a platform-only feature, that part may need platform-specific code.

4. Who will maintain it after launch?

Two separate apps mean adapting twice to two separate operating-system updates every year. With a single codebase, that work happens largely in one place. A platform decision made without a maintenance plan can bring an unexpected burden later on.

What is a single codebase, and what does it give you?

A single codebase means the iOS and Android apps are produced from the same source code. The app’s logic, screens and behaviour are written once, and separate packages come out for each platform.

What it gives you:

One project, one thing to maintain. A bug is fixed once; a feature is added once.
Consistency. The app looks and behaves the same on both platforms. A user switching phones does not feel lost.
Flexibility. Launching on one platform and moving to the second does not mean starting a second project.
A simpler budget. One process runs instead of two teams or two separate builds.

This is how we work on our mobile projects. Both Tako and Mümin 360 were built on a single codebase.

Its limits: a single codebase does not solve everything

To be honest, a single codebase does not make some work disappear:

Two stores, two processes. The App Store and Google Play have different submission steps, review styles and rules. Each needs its own screenshots, its own description and its own privacy declaration.
Platform-specific behaviour. On matters such as the back button, notification permissions, the settings screen or the share menu, users on each platform expect different things. A good app respects them.
Testing. The code may be shared, but the app is tested separately on both platforms, across screen sizes and operating-system versions.
Special requirements. If you need very heavy graphics work or a platform-only hardware feature, certain parts may have to be written per platform.

So “both” does not double the work — but nor can we say the second platform takes no effort at all.

The store side: two separate doors

The platform decision also shapes the store work:

App Store. Membership of the Apple Developer Program renews every year. Each release goes through Apple’s review. We cover the process and the most common rejections in the App Store review process.
Google Play. A developer account is opened with a one-off registration. Apps are reviewed too, and some newly opened accounts may be asked to run a closed test before publishing. For the current rules, the Google Play Console help pages are the most reliable source.

On both sides we recommend that the accounts are opened in your name. The app is published under your account; we run the submission and review process.

How we decided with Tako

Tako is a subscription tracker that gathers scattered subscriptions into one quiet screen. No account, no forced connection; the data stays on the device. It has been available in 11 languages from day one.

We built Tako on a single codebase and released it on the App Store first. That let us focus, in the first phase, on one store’s rules, one review process and one stream of user feedback. Because the core of the product — gathering subscriptions, showing monthly and yearly totals, reminding before each renewal — is independent of the platform, the code was structured the same way.

The lesson: the platform decision need not be either-or. A well-structured project turns “which one?” into a question of strategic order — “which one first?”

A short checklist for the decision

What data do you have on your target audience’s devices?
Can the business model be set up within both stores’ rules?
Do you need any platform-specific hardware or feature?
Is launching on one platform first enough to gather early feedback?
Have you set a threshold for moving to the second platform?
Who will take on maintenance for both platforms after launch?

The answers to these questions bear directly on cost too; we have gathered the other factors in what determines mobile app cost.

Frequently asked questions

Does an app built on a single codebase run more slowly?

For the great majority of everyday apps, users notice no difference. Lists, forms, notifications and calendars can all feel smooth. Where very heavy graphics or intensive computation are needed, platform-specific parts can be added.

Can we launch on iOS first and add Android later?

Yes. With an app built on a single codebase, that is largely a matter of testing, platform-specific adjustments and the store submission. With an app written separately for each platform, the second one is a much bigger job.

Which platform earns more?

There is no general answer. Earnings depend on which platform your audience is on and how much your product is worth to them. That is why we suggest starting the decision with your own audience’s data rather than general statistics.

Can you build an Android version of our existing iOS app?

First we review the existing app’s code and structure. Then we tell you plainly, with our reasons, whether to build on the existing code or move to a single codebase that carries both platforms.

If you would like to talk through which platform to start with, and in what order, see our mobile app development service or write to us.