Cross platform apps run on both Apple and Android from a single codebase. A native app takes the other route, which means two codebases in two languages, each using the tools its platform ships with. That one choice shapes your budget, your hiring and how the app feels in somebody's hand. This page is about making it, before a supplier makes it for you.
Most owners meet this decision early, usually when the first quote lands. So it helps to know what you give up in each direction before anyone writes code. Our plain guide to web and mobile app development handles the bigger question of whether you need an app at all. This page deals only with how to build one.
What cross platform apps actually are
A cross platform framework gives your team one place to write the screens, the logic and the data handling. It then produces a real app for each store. React Native and Flutter are the names you will most often hear, though the shortlist moves over time. Ask your supplier which one they propose, and why that one for your app.
The important part is not the framework. Instead it is the shape of the work. One team writes one feature once, and both stores get it in the same release. Underneath, the framework still talks to the platform, so a cross platform app can open the camera, send a notification or read a file like any other app.
Cross platform apps are therefore not web pages in a wrapper. That older approach, where a website sits inside an app shell, is a different thing and it feels like one. Modern frameworks either use the platform's own controls or draw close copies of them.
What native development does differently
A native build normally uses Swift on Apple's side and Kotlin on Android's. Each team works with the platform's own toolkit. So a new operating system feature is usable as soon as that toolkit ships it. Nothing sits between the code and the device.
That closeness is the whole advantage. When a platform changes something, a native team can follow immediately. If your app leans hard on the hardware, native gives you every control the maker exposes, in the form the maker intended.
The cost is duplication. Two codebases mean two versions of every screen, two sets of bugs and two release cycles to keep in step. Small differences creep in, and over a year they stop being small.
A third option: no app at all
Before the argument between cross platform apps and native goes any further, check that you need an app. Plenty of businesses ship one because a competitor did, then watch the installs stall and the app go quiet.
An app earns its place when people come back often, when it needs the device itself, or when notifications are part of the product. If none of that is true, a fast mobile site does the same job with nothing to install. Our piece on responsive web design covers what that site has to get right.
Where cross platform apps are the sensible default
Most business apps are, at heart, screens over a database. Forms, lists, a login, a search, a few charts and some messaging. For that kind of product, cross platform apps are usually the right call, and the argument does not need much thought.
Three situations make the case even stronger.
- Your app has to reach both stores at once, when the budget only pays for one team.
- Feature parity matters more than platform polish, because your customers compare notes.
- Speed to a first release matters, since you still have to learn what people actually use.
A first release exists to answer questions, not to win design awards. Cross platform apps get you to those answers sooner, and the money you keep can pay for a second version worth having. Whichever route you take, the stages from idea to store stay the same, and our guide to mobile app development walks through them in order.
Where cross platform apps struggle
The honest list is short, yet it is real.
Heavy graphics work is the first case. Games, live camera effects and anything drawing complex scenes at speed will fight the extra layer. Continuous background work is the second, such as fitness tracking that has to run while the phone sleeps. Deep hardware use is the third, including Bluetooth accessories, sensors and secure payment terminals.
There is a fourth case that catches people out. Support for a brand new operating system feature usually reaches the framework later than it reaches the platform. Somebody has to add it first. Say your plan depends on shipping a feature in the weeks after a platform announces it. Then cross platform apps will hold you back.
Cross platform apps and native, side by side
The table below compares the things that actually move a decision. It leaves out the ones people argue about online and never notice in practice.
| What you are comparing | Cross platform | Native |
|---|---|---|
| Codebases to look after | Usually one | Two, so double the upkeep |
| Time to a first release | Shorter, if the app is mostly screens | Longer, because the work happens twice |
| Brand new platform features | Waits for framework support | Ready as soon as the platform ships it |
| Heavy graphics and games | Struggles once the scene gets busy | Still the safer choice |
| Hiring | One skill set to recruit for | Two, and rarely in one person |
| Feel on each platform | Close, though a fussy user may spot it | Exactly what the platform intends |
| Long term risk | Tied to a framework somebody else owns | Tied to the platforms themselves |
What the two approaches cost to build
Nobody can quote your app from an article, so treat any figure you read online as fiction. What you can do is reason about the shape of the bill.
Effort follows the number of screens and the number of platforms. A native project repeats most of the screen work twice. Cross platform apps repeat almost none of it, though a slice of platform specific work always survives, usually around notifications, payments and permissions.
A worked example, with round numbers chosen to make the arithmetic easy rather than to quote anybody. Imagine a build takes 100 days, and 70 of those days go on screens and logic. A native project repeats those 70 days for the second platform, so the total lands at 170 days. A cross platform project repeats perhaps 10 of them for platform specific plumbing, so the total lands at 110. Your own split will differ, and the only figure that matters is a quote against your own feature list.
The bill after launch
An app is a subscription to ongoing work, whichever way you build it. Platforms keep releasing new operating system versions. Each store also sets rules about how current a submitted build has to be, and those rules change. So ask your developer what applies before each release rather than trusting last year's answer.
The real question is how much upkeep each approach asks of you. Native means two upgrade paths, two sets of retired interfaces and two review queues. Cross platform apps have one of each, plus one extra risk. When the framework itself makes a major version jump, you either upgrade or you drift away from the platforms underneath.
Either way, put a maintenance line in the budget from the start. The same discipline applies on the web, which our piece on website maintenance nobody budgets for covers in more detail.
Hiring for cross platform apps
Teams decide this argument as often as budgets do. A cross platform team needs one skill set, so a small business can keep a single developer who understands the whole product. Native needs two, and a person genuinely strong in both is rare.
Ask a second question before you commit. Who takes this over in two years? A cross platform codebase is easier to hand to one new person. Native usually means two hires, or an agency with both benches.
Settle the handover details in writing, whichever route you take. Register the store developer accounts to your business rather than to the agency. Ask for the source code, the signing keys and the build instructions at every milestone. Those three items are what strand an owner when a supplier disappears, and neither route protects you from that.
Does the difference show to a user?
Rarely, on the kind of app most businesses build. Most people cannot tell which route you took. What they do notice is a screen that stutters when they scroll, a list that pauses before it loads, and an animation that lags a finger.
Those faults come from careless work far more often than from the framework. A sloppy native app feels worse than a careful cross platform one. So judge the team as hard as you judge the technology.
One honest exception remains. Long scrolling walls of rich content, and screens that animate constantly, are where the gap still shows. If that describes your main screen, build a prototype both ways and judge it on a real device.
When to move cross platform apps to native
Starting cross platform does not lock the door behind you. Plenty of products run for years on one codebase, then rebuild a single screen natively once that screen earns it.
Three signals say the moment has arrived. Your profiling points at the framework rather than at your own code. A feature you need has no reliable framework support, and the workarounds keep piling up. Or the app itself is now the business, so two teams cost less than the ceiling you keep hitting.
Until one of those lands, a rewrite is usually vanity. Cross platform apps that ship something every month beat native apps stuck in a rebuild no customer asked for.
How to decide in one sitting
Answer four questions honestly and the choice usually makes itself.
- Does the product depend on graphics, sensors or constant background work?
- Will you need brand new platform features in the week they launch?
- Can the budget carry two teams, this year and every year after?
- Is the first release there to learn something, or to be the finished product?
A clear yes to either of the first two questions points at native. Anything else, and cross platform apps are probably the cheaper way to find out whether the idea works at all. The build then follows the same route as any other project, which our walkthrough of the web development process sets out stage by stage.
One last habit is worth the ten minutes it takes. Write down why you chose what you chose, in a paragraph, and keep it with the project. Somebody will ask in two years, and by then the reason matters more than the choice.
Frequently asked questions
What are cross platform apps in plain English?
Cross platform apps come from one codebase that produces a real app for both Apple and Android. A native app takes the opposite route, with separate code for each platform in that platform's own language. The user rarely sees the difference on an ordinary business app. Your team feels it every week, because one codebase means one set of changes, one release to prepare and one skill set to hire for.
Are cross platform apps slower than native ones?
Usually not in any way a customer notices, on an ordinary business app. Judge it yourself rather than reading opinions online. Ask for a build on the oldest cheap phone your customers actually carry, load your longest real list into it, and scroll hard. Watch for stutter, for a pause before content appears, and for an animation that lags your finger. That test tells you more about how carefully the app was built than about the framework behind it.
Can a cross platform app use the camera or send notifications?
Yes. Modern frameworks reach the camera, location, storage, notifications and payments through the platform's own interfaces. Some of that plumbing still needs platform specific work, particularly notifications and in app purchases, so leave a little time for it in the plan. The rare gaps involve very new features or unusual hardware, where the framework may lag a release or two behind the platform itself.
Which approach is cheaper to build and to own?
Cross platform is normally cheaper on both counts, since the screen work happens once instead of twice and one team can carry it. Native costs more because a developer writes everything visible twice, once for each platform. The exception is a product that fights the framework, where the workarounds cost more than a second codebase would have. Ask any agency to quote both against the same feature list, then compare what each quote includes after launch.
How long does a first release usually take?
Longer than anyone hopes, and the honest answer depends on your feature list rather than on the technology. What shortens it is scope. A small first release that does one job well reaches the store far sooner than a complete product does. Cross platform helps here, because a single codebase removes a whole second round of screen work. Store review adds time at the end, so leave room for it.
Can I start cross platform and rewrite in native later?
Yes, and that path is common. Teams often keep one codebase for most of the product, then rebuild a single demanding screen natively when the evidence points that way. A full rewrite is a bigger decision, and it usually waits until the app is the business rather than one channel into it. Keep the server side separate from the app, so a rewrite touches one layer instead of everything at once.
Which cross platform framework should I pick?
Pick the one your team can staff and support, rather than the one winning arguments online. React Native tends to suit teams who already write for the web, because the language is familiar. Flutter tends to suit teams who want the same rendering everywhere. Both move quickly, so check what each one supports for your own feature list before you commit. Then ask who you could realistically hire next year in your city. That question usually matters more than any comparison table.
Do the app stores treat cross platform apps differently?
Review looks at the finished app rather than at the tools behind it, so the framework is not itself the thing being judged. Store rules change, so read the current guidelines before you submit rather than working from what somebody remembers. Trouble usually comes from the app itself, such as missing privacy details or an app that only repeats the website. Cross platform apps add one habit worth keeping, which is testing every release on real devices from both stores.