Native vs cross platform app development: how to choose

Almost as soon as you decide to build a mobile app, someone asks about native vs cross platform app development. Do you build two apps, one for iPhone and one for Android, or a single app that runs on both? Either way you can end up with a good app. Which one is right for you comes down to what the app has to do, who uses it, how soon you need it and who will keep it running after launch.

We wrote this for founders, product owners and operations leads planning iOS and Android app development who'd like to understand the trade offs before their first call with a development partner.

What do native and cross platform actually mean?

Native means building each app with the language and tools that Apple or Google provide for their own phones. On iPhone and iPad that's Swift, usually with SwiftUI (Apple's toolkit for building screens). On Android it's Kotlin, usually with Jetpack Compose (Google's version of the same thing). So you get two apps with two codebases. A codebase is simply all the source code behind an app, and these two share a design but none of their code.

Cross platform means you write one codebase and it produces apps for both iOS and Android. Most teams choose one of two options:

• React Native, made by Meta. Developers write in JavaScript or TypeScript (a stricter form of JavaScript), and the app builds its screens from the phone's own buttons, lists and menus. If your developers already know React for the web, they'll pick it up fast.
• Flutter, made by Google. Developers write in a language called Dart, and Flutter draws every pixel on screen itself, so the app looks identical on every phone.

Both give you real apps that go into the App Store and Google Play. Older cross platform tools often just wrapped a website inside an app frame, which is how the approach earned a poor reputation. That's no longer what you're buying.

How do native and cross platform compare?

This table covers the questions buyers ask us most often. Treat it as a general pattern rather than a set of rules, because a good team can close most of these gaps in either direction.

Performance

Native apps use the phone's own toolkit directly, so they squeeze the most out of the hardware. That extra speed matters if your app is full of animation, 3D graphics, live video processing or gameplay. Most business apps aren't like that. For booking, ordering, account management, field service or internal tools, today's cross platform frameworks are quick enough that your users won't notice any difference.

Access to device features

Cross platform apps can use the camera, location, push notifications, payments, Bluetooth and fingerprint or face sign in. They do it through plugins, which are small add on packages that link the shared code to each phone's features. Native apps simply get new features first, often on the day Apple or Google announces them. So if your app relies on something brand new, like a fresh augmented reality toolkit or a new watch integration, native keeps you in front.

One codebase versus two

With one shared codebase, your business rules live in one place, your tests run once and a bug gets fixed once. Most cross platform apps still need a little code written just for iPhone or just for Android, but the bulk is shared. Go native and every feature is built and tested twice. Over time the two apps tend to drift apart, and keeping them level takes steady effort from the team.

Team skills

Native needs specialists for each platform. Cross platform lets one team handle both, and React Native is an easy step for teams already building web applications in React. Ask yourself who will be looking after this app in three years' time, as well as who's building it now.

User experience

iPhone and Android users expect small things to work differently, like where the back button sits, how menus slide open and how text is sized. Native apps pick up these habits for free. A cross platform app can match them as well, but only if your designers and developers plan for each platform instead of shipping one identical layout to everyone.

What drives mobile app development cost?

Native or cross platform does move the price of mobile app development, but it's rarely the biggest factor. What the app actually has to do matters far more.

• Number of screens and featuresHigh
• Connections to other systemsHigh
• Offline use and data syncingMedium
• Security and compliance rulesMedium
• Native or cross platformMedium
• Custom design and animationMedium

A general view of how much each factor tends to affect cost, not a measurement.

Nearly every app also needs a back end behind it: the servers, the database and the APIs (the connections the app uses to fetch and save data). That work costs the same whichever route you pick for the app on the phone. If you want the bigger picture on budgets, our guide on what drives custom software cost walks through it.

When is a progressive web app enough?

Sometimes you don't need an app store at all. A progressive web app, or PWA, is a website built to act like an app. People open it in their browser and can pin it to their home screen. It loads quickly, can handle some tasks offline and, on most modern phones, can send push notifications. Nobody has to download anything, there's no store review to wait for, and one version works on phones, tablets and desktops.

A PWA is often all you need when:

• People only use it now and then, say to check an order, book a slot or read something, and wouldn't bother installing an app for that.
• You already have a modern web application and want a version that works well on phones, soon.
• The app needs few device features beyond the camera, location and notifications.
• App store visibility doesn't matter to how customers find you.

It's a weaker choice if you need deep access to the phone, work running in the background, lots of offline use, or the trust and discoverability of an app store listing. Some browser features also reach iPhone later than Android, so test your must have features on both before you commit.

Which route suits your app?

Find the row that sounds most like you. Most projects match one of them pretty closely.

If this first version is really about learning what customers want, keep it small. Our guide on how to build a minimum viable product shows how.

React Native or Flutter?

Once you've settled on cross platform, the next question is nearly always React Native or Flutter. Both are mature and widely used. React Native makes sense if your team already works in JavaScript or React, or if you'd like to share code with a web application. Flutter is a good fit when your app has a strong, custom branded look that should be identical on every phone. You won't go far wrong with either. The real danger is picking one that the people maintaining your app later can't support.

Pick the route your app needs today and your team can still look after in three years.

What are the most common mistakes?

• Choosing on price alone. A cheap first release that can't handle a key feature often ends up costing more, because it has to be rebuilt.
• Forgetting the back end. The app is just the part people see. Plan the servers, data and security behind it at the same time.
• Designing one layout for both platforms and never checking it against how iPhone and Android users expect things to work.
• Underestimating the app stores. Apple and Google review every release and change their rules from time to time. Leave room in your plan for reviews and keep an eye on store requirements.
• Leaving nothing in the budget for upkeep. New phones come out and operating systems update every year, so every app needs regular maintenance, whichever route you take.
• Piling on third party plugins. Each one is something your team has to keep updated and secure. Our application security checklist explains how to review them.

What should you decide before starting?

Even a one page brief gets you a quicker and more accurate estimate. Before you speak to any development team, try to answer these five questions.

Five decisions to make before you build

1. UsersWho will use it, and on which phones?
2. Start hereMust havesWhich features can't it launch without?
3. Device needsCamera, location, sensors or offline use?
4. ConnectionsWhich systems does it need to talk to?
5. TimingWhen does it launch, and who looks after it?

If you know which phones your customers use, write it down. Your website analytics will usually show the split between iPhone and Android visitors. Sort out who owns the app store accounts now, too. They should be in your company's name, not your developer's. Then agree how updates will work after launch, so the app keeps working as phones and operating systems change.

How does V6 Cube help you decide?

We don't walk in with a favourite framework. We look at your users, your features and where you want the app to be in a few years. Then we recommend native, cross platform or a progressive web app, and we write down why. You get a fixed estimate agreed before work begins, and you own all the code and designs.

Our custom software development service covers the app, the back end and the links to the systems you already use. If you'd rather build up your own product team, our dedicated development teams can add iOS, Android or cross platform engineers who work your hours and follow your process. For a mobile example, see how we rebuilt a retail storefront, where a faster checkout on the mobile web lifted orders that grew online orders 2.4x within a year. Our pages on retail and ecommerce software and travel and hospitality software show what these apps usually connect to.

Projects usually start within one to two weeks, and we're happy to sign a confidentiality agreement first. Get in touch with our team and we'll reply within one business day.