iOS, Android, or Both? The Platform Decision That Shapes Everything Else

This is the second post in a series adapted from my guide, Build It Right: An Insider's Guide to Mobile App Development for Non-Developers. Each entry takes one slice of the guide and turns it into something you can read in ten minutes.

Once you have a clear vision for your app and you understand what the project actually involves, the next question you'll face is the most consequential technical decision of the whole project. Which platform are you building for? iOS, Android, or both? And if both, are you building two apps or one?

This decision shapes your budget, your timeline, the kind of developer you hire, the technologies you'll be locked into, and the experience your users will have. Most clients answer it too quickly, usually because someone told them the answer was obvious. It rarely is.

There are three real options, and each one comes with trade-offs that don't show up until you're well into the project.

Option 1: Native iOS only

Your app is built specifically for the Apple platform using Swift (no new project should use Objective C). It runs only on iPhone and iPad (and, depending on the project, Apple Watch and Apple TV).

This is the right choice more often than people think. iOS users spend more on apps and in-app purchases than Android users, and by a meaningful margin. If your app is consumer-facing in the US, the UK, Canada, Australia, or Japan, you can capture most of your addressable market with iOS alone. The platform is also more consistent: a small set of devices, a unified design language, and users who update their OS quickly. That consistency translates directly to lower development cost per feature.

Native iOS apps also feel right on iOS. Animations, scrolling, gestures, system integrations like Face ID and Apple Pay, sharing to other apps, dark mode, accessibility features. Every one of these is something Apple has spent years refining, and a native app gets all of it for free. A non-native app has to approximate them, often with mixed results.

The downside is obvious: you're not on Android. If half your customers use Android phones, you're missing them.

Option 2: Native Android only

Your app is built specifically for Android using Kotlin (or, increasingly rarely, Java). It runs on the much wider range of devices in the Android ecosystem.

Android dominates global market share, especially outside the US. If your audience is primarily in India, Southeast Asia, Africa, or much of Latin America, Android is the more sensible starting point. Android also gives you more flexibility around what an app is allowed to do: background processing, deeper system integrations, alternative app stores, sideloading.

The complications are also real. Android runs on thousands of different devices with different screen sizes, hardware capabilities, and OS versions. Testing across that range is more expensive than testing iOS. Users update their OS more slowly, so you're often supporting older Android versions years after Apple users have moved on.

Option 3: Cross-platform

You write one codebase that runs on both iOS and Android. The two main contenders today are Flutter (from Google) and React Native (from React Foundation). The pitch is irresistible: build once, ship to both platforms, save money.

The pitch is also misleading.

In practice, "build once" is closer to "build 80% once and the remaining 20% twice, in a less pleasant way than you would have if you'd just built two native apps to begin with." That 20% includes most of the things that actually matter: how the app feels on the device, integration with platform-specific features, performance under real-world conditions, the way bugs get debugged, and the long-term maintenance story when the framework ships breaking changes.

Cross-platform makes the most sense when:

• Your app is mostly content. News apps, reading apps, simple utility apps, or apps that are essentially a wrapper around a web service.
• Your team is already a web team. React Native lets web developers reuse their JavaScript skills, which can be a real advantage if you're an existing web company adding a mobile presence.
• You genuinely have to ship to both platforms simultaneously and your budget can't support two native builds.

Cross-platform makes less sense when:

• The app is performance-sensitive or graphically rich.
• The app needs deep platform integration: background tasks, sophisticated camera access, hardware-specific features.
• The app is the core product of your business rather than a companion to something else.
• You're building something you intend to maintain for many years. Cross-platform frameworks change fast, and the cost of upgrades over time is significant.

The argument I hear most often for cross-platform is that it's cheaper. Sometimes it is. I've also watched several projects start cross-platform, hit a wall, and then get rebuilt natively at much greater total cost than if they'd gone native from the start. The savings are real, but they're conditional on the app staying within the boundaries the framework handles well. The further you push past those boundaries, the faster the savings disappear.

A simpler way to think about the decision

Strip the technical detail away and the question is really about three things.

Where are your users?

If you can name the country or region your customers live in, you can usually identify which platform dominates there. Build for that platform first. You can always add the other later.

What does the app do?

If the app is a simple, content-driven experience that doesn't lean heavily on the device's capabilities, cross-platform is a reasonable starting point. If it's performance-sensitive, deeply integrated with the device, or central to your business, native almost always pays off.

What's your budget, realistically?

Two native apps cost roughly twice as much to build and maintain as one. If you're trying to do both on a budget that only really supports one, you're going to ship something half-built on both platforms. Better to ship one platform well, validate the idea, and add the other once revenue justifies it.

What this means for who you hire

The platform decision narrows the pool of developers you should be talking to. A senior native iOS developer and a senior Flutter developer are both excellent at their work, but they're optimizing for different things, and the questions you should be asking them are different.

If you're building native iOS, you want someone fluent in Swift and SwiftUI, with shipped apps in the App Store, and ideally with experience in the specific iOS subsystems your app touches (HealthKit, ARKit, StoreKit, whatever applies). If you're building cross-platform, you want someone who has shipped apps in Flutter or React Native at scale, who can speak honestly about where the framework breaks down, and who has enough native knowledge to drop into platform-specific code when needed.

A developer who claims to be equally good at all three (native iOS, native Android, and cross-platform) and equally happy on any of them is worth examining carefully. Most of the strongest mobile developers I know have a clear primary platform and treat the others as secondary.

The next post in the series gets into the AI question: what AI-assisted development actually looks like in practice, where it genuinely helps, and where the marketing has gotten ahead of reality.

This post is adapted from Build It Right: An Insider's Guide to Mobile App Development for Non-Developers. If you'd rather just talk it through, reach me at scott@appswage.com.