When a business orders its first app, the conversation quickly runs into a choice: native development or cross-platform. Vendors name frameworks, argue about performance and throw around arguments that are hard to evaluate without a technical background.
Yet the choice itself is managerial, not technical. It determines how much you pay upfront, how fast you reach the app stores, how many people you'll need to grow the product and how painful it will be to change vendors. Below we break down both approaches without jargon and give you a practical decision algorithm.
Native development and cross-platform in plain words
A mobile app has two target platforms: Apple's iOS and Google's Android. They are built differently, speak different programming languages and are published in different stores.
The "native or cross-platform" question is really a question of how you cover both platforms: with two separate apps or with one shared codebase.
Native development: two separate apps
A native app is written in the language of a specific platform. For iPhone — usually Swift, for Android — Kotlin.
In practice this means you'll have two apps with the same features but different code. And, as a rule, two developers or two teams.
- Each version uses platform capabilities directly, without intermediaries
- The interface behaves exactly the way iPhone or Android users are used to
- Every feature has to be built twice — separately for iOS and for Android
- Every bug has to be found and fixed in two places
The native approach gives maximum control over the platform. But you pay for that control twice — in money and in time.
Cross-platform: one codebase for iOS and Android
The cross-platform approach means one codebase that builds into two apps: one for the App Store and one for Google Play. The most mature tools today are Flutter from Google and React Native from Meta.
The team writes screens, logic and integrations once. Platform differences — for example, notifications or payments — are handled point by point.
- One team instead of two
- Features ship on both platforms at the same time
- Most of the code is shared, so fixes are applied once
For most business apps — delivery, service booking, catalogs, personal accounts, education — this is more than enough.
Flutter and React Native: what the difference means for the client
Flutter draws the interface itself, so the app looks the same on any device and handles animations predictably. React Native relies on native interface elements and is closer to the "home" look of each platform.
For the client the practical difference is small: both tools are mature and both cover typical business tasks. What matters more is what the team building your project is strong at.
At Qazaqsoft we more often choose Flutter: a single design behaves identically on both platforms, the interface doesn't depend on the OS version, and development is faster.
How the choice affects budget, timeline and team
The main difference between the approaches lies not in the technology but in the economics of the project. And you need to count not just the development, but everything that comes after release.
Budget: where the difference comes from
Native development means two codebases. So almost every task is done twice: a new screen, business logic, a bug fix, pre-release testing.
At the same time, cross-platform doesn't make a project "twice as cheap". Part of the work doesn't depend on the number of platforms.
- Discovery, design and prototypes cost the same under either approach
- The backend, database and API are shared in both cases
- Analytics, store publishing and marketing don't double either
- What doubles is the mobile code itself: screens, on-device logic, tests
So the savings from cross-platform are significant but not twofold. The more screens and on-device logic the app has, the bigger the difference.
Timeline: time to the first release
A cross-platform project usually reaches the market faster. There's no need to synchronize two teams or run the same test scenarios twice.
In native development, the iOS and Android versions drift apart easily: one team makes the deadline, the other doesn't. Either the release waits for the lagging platform, or one audience gets the product later.
For a first app, speed to market often matters more than technical nuances. The sooner the product reaches users, the sooner you understand what to change in it.
Team: who you need and how many people
Native development requires at least two developers: one for iOS, one for Android. Plus testing two apps and constant coordination between them.
For cross-platform, one or two developers are enough for the entire mobile product at the start.
This affects not only cost but also the project's resilience. If an iOS developer leaves a native project, half the product freezes until a replacement is found. In a cross-platform project, knowledge isn't split by platform — the team is interchangeable.
When cross-platform is the right choice
For most business tasks, cross-platform is the sensible default. Let's list the situations where it works best.
Typical business apps
Most apps that businesses order are built from the same building blocks: lists and cards, forms, a personal account, notifications, payments, chat.
- Delivery, stores and marketplaces
- Service booking: clinics, salons, car services
- Personal accounts, loyalty programs and subscriptions
- Education and content apps
- Internal corporate tools: for couriers, field crews, sales reps
In all these scenarios Flutter covers the task completely. A user won't be able to tell such an app from a native one — neither by speed nor by interface smoothness.
MVP and hypothesis testing
If this is your first app and the hypothesis hasn't been validated, spending the budget on two parallel codebases is risky. You pay double for a product the market may not even need.
Cross-platform lets you launch on both platforms at once with a single team. If the hypothesis fails, you lose less. If it works — you already have a working product on both platforms to build on.
The alternative of "going native but only for one platform" looks like a saving, but in practice it cuts off a significant part of the audience. And when it's time for the second platform, everything has to be written from scratch.
Limited budget and a long horizon
Cross-platform doesn't win only at the start. Every update, every promotion, every new screen afterwards is also built once.
For small and medium businesses this is often the deciding argument: the development budget is always limited, and spending it on duplicating work is the most useless way to use it.
At Qazaqsoft we've built Flutter products with chat, subscriptions, push notifications and payments — and one team carried both platforms from the first release to a mature product without splitting into iOS and Android.
When native development is necessary
Cross-platform is not a universal answer. There are classes of tasks where the native approach is justified, and an honest vendor will say so directly.
Heavy graphics and non-standard rendering
Games, augmented reality, real-time video processing, complex 3D scenes — all of this demands maximum performance and direct access to the device's graphics subsystem.
Flutter handles interface animations well, but games and AR scenarios are the territory of native tools and specialized game engines.
If the core of your product is graphics rather than business logic — discuss native development from the very start.
Deep work with hardware
If the app constantly talks to external devices and sensors, native code becomes the center of the product rather than the exception.
- Bluetooth devices: medical instruments, trackers, smart appliances
- NFC and contactless payments on the terminal side
- Background geolocation with strict accuracy and battery requirements
- Long-lived background services: audio recording, streaming, telephony
In cross-platform, such things are done through "bridges" to native code. One or two bridges are normal practice. But when bridges multiply, the benefit of cross-platform melts away: you're writing native code anyway, just wrapped in an extra layer.
Platform features on release day
Apple and Google show new capabilities every year: widgets, new notification formats, integrations with system services. Native apps get access to them immediately, cross-platform ones — with a delay, once the community updates the tooling.
If your strategy is to showcase the platform's newest capabilities, the way large banks and ecosystems do, the native approach makes sense. For most businesses this race is irrelevant.
A simple rule: if your requirements include two or three items from this section — seriously discuss native. If none — you'd most likely overpay for it for nothing.
Myths that distort the choice
A lot of outdated judgments have accumulated around this choice. Some of them were true ten years ago, some were never true.
Myth: cross-platform is slow
This myth was born in the era of first-generation hybrid apps, which were essentially a website wrapped in a shell. They really were slow and looked foreign.
Modern Flutter compiles to machine code and renders the interface at the device's full speed. In a typical business app the user won't notice a difference from native.
It's not the technology that's slow — it's bad code. A slow app can be written natively too; such projects come to us for audits as well.
Myth: native is always more expensive
At the start, native development really is more expensive because of the two codebases. But there are cases where it's more economical over a long horizon.
If the product leans heavily on hardware and platform APIs, a cross-platform project gets overgrown with native inserts. Maintaining such a hybrid eventually costs more than honest native: the team has to know both the framework and both platforms.
The right question is not "what's cheaper in general" but "what's cheaper for your set of features over a two-to-three-year horizon".
Myth: cross-platform is not a serious technology
Apps from banks, marketplaces and services with millions of installs run on Flutter and React Native. Google uses Flutter in its own products, Meta builds its own on React Native.
Both technologies left the experimental stage long ago: they have stable releases, large communities and mature libraries for typical tasks.
The question is not the seriousness of the tool, but the maturity of the team using it.
Myth: you'll have to rewrite it in native anyway
Rewrites do happen, but rarely because of the technology choice. More often a product is rewritten because the first code was rushed, without architecture or tests — and that happens under any approach.
If the product grows into tasks that genuinely require native, by that point you'll have a validated business model, an audience and revenue. The rewrite becomes a clear investment, not a catastrophe.
And most products never grow into such tasks — which is perfectly normal.
Related service
We'll help you choose the approach and build your mobile app
We'll go through your features and tell you honestly whether cross-platform is enough or you need native. We'll design the app, build it with Flutter, release it to the App Store and Google Play and stay on for support — with the code, accounts and keys belonging to you, not to us.
Support and growth after release
The release is the beginning of expenses, not the end. A mobile app lives in an environment that changes without your participation: new iOS and Android versions, new devices, new store requirements.
What mobile app support includes
Even if you don't add a single new feature, the app requires regular work.
- Updates for new operating system versions
- Updates to libraries and SDKs, including payment and analytics ones
- Fixing bugs that surface on new devices
- Meeting new App Store and Google Play requirements
- Small improvements based on user feedback
In a native project, every line of this list is multiplied by two: two codebases, two sets of dependencies, two testing cycles.
Speed of shipping new features
After release the product evolves: promotions, new screens, integrations with CRMs and payment systems. In cross-platform, every feature ships on both platforms simultaneously and in a single development cycle.
In native, every change goes through two cycles. That's not just more expensive — it's slower. Over time the team starts to economize: "let's ship Android-only for now, iOS later".
That's how out-of-sync versions appear: users of one platform see features the others don't have. This irritates the audience and complicates support.
Cost of ownership over two to three years
Comparing approaches by the development estimate alone is a mistake. Compare the cost of ownership: development plus support plus growth plus the team for the product's entire lifetime.
In our projects, maintaining a cross-platform app costs noticeably less than maintaining a pair of native ones — simply because there's one codebase and every task is solved once.
If a vendor names only the development price and stays silent about support — ask the question yourself. The answer says a lot about how they see the project after release.
How the choice affects hiring and changing vendors
Few people think about this at the start, but in a year or two the question comes up for almost everyone: expand the team, bring development in-house or change the vendor.
The talent market
There are plenty of Flutter developers in Kazakhstan and the CIS, and their number is growing: the technology is popular among young specialists and studios. React Native draws on the enormous community of JavaScript developers.
Native specialists exist too, but a native project needs two different ones at once — iOS and Android. Finding, hiring and retaining two narrow specialists is harder and more expensive than one or two versatile ones.
Losing one native developer means half the product stops. Losing a cross-platform developer is an inconvenience but not a blocker: the code is shared, and another specialist of the same profile will pick it up.
Handing the project to another team
Changing vendors is a normal situation, not a catastrophe. But how painful it is depends on what you received along the way.
A cross-platform project is easier to hand over: one codebase, one structure, one set of dependencies. The new team has to understand one project, not two.
- The code lives in a repository you have full access to
- The App Store and Google Play accounts are registered to your company, not the vendor
- Signing keys and certificates are kept by you
- The build and release process is documented well enough for another team to repeat it
Demand this from day one regardless of the approach. Vendor lock-in is created not by technology, but by missing access and documentation.
If you decide to hire in-house developers
With a cross-platform product you can start with one in-house developer: they'll handle both platforms and gradually take the project over from the vendor.
With a native product, hiring in-house means two positions at once, with different requirements, different interviews and different salary ranges.
For a company where the mobile app is a tool rather than the core product, the difference between "hire one" and "hire two" often decides whether an internal team happens at all.
How to make the decision: a simple algorithm
Let's condense everything into a sequence of questions. Answer honestly and in writing — preferably with someone who understands your business plans for the coming years.
- Do the requirements include heavy graphics, AR, constant work with sensors or external devices? If yes — discuss native or a hybrid
- Do you need both platforms? If yes and the budget is limited — cross-platform
- Has the hypothesis been validated? If this is the first app and demand isn't confirmed — almost always cross-platform
- What's the budget for the year ahead, including support, not just development?
- Who will grow the product in a year: the vendor, in-house staff or a mixed team?
If the choice is still not obvious after these questions — cross-platform will almost certainly suit you. Native is needed when the reasons for it are named specifically, not "just in case".
Typical forks with examples
A few situations we regularly work through in consultations.
- Food delivery with payments, a cart and push notifications — Flutter without a doubt
- A companion app for a Bluetooth medical device — more likely native or a hybrid with a native core
- An MVP of a services marketplace with chat and reviews — Flutter
- A mobile bank building its brand on platform features — native
- An internal app for employees — Flutter, sometimes even for one platform only if the devices are corporate
What should not be the basis of the decision
Let's list separately the arguments that sound convincing but have nothing to do with your task.
- "A competitor did it this way" — they have a different budget, team and history
- "It's more convenient for the vendor" — without explaining why it's convenient for you too
- "Our developer loves this technology" — love doesn't scale to a business plan
- "We read somewhere that technology X is dying" — both ecosystems have been actively developing for years
The decision should rest on your features, your budget and your planning horizon. Everything else is noise.
A checklist of questions for the vendor
These questions help you understand whether the vendor is proposing an approach deliberately or simply selling what they know. Ask them before signing the contract.
Questions about the choice of approach
- Why are you proposing this particular stack for our task?
- In which cases would you propose a different approach?
- Which features from our list will require native code, and how much of it will there be?
- Show us two or three live apps on this stack that you built and that we can download
A good vendor answers these questions calmly and with examples. A bad one gets irritated or retreats into generalities.
Questions about life after release
- What does support include and what does it cost per month?
- How quickly do you update the app for new iOS and Android versions?
- Who owns the code, the repository, the store accounts and the signing keys?
- What will another team receive if we decide to change vendors: documentation, access, build instructions?
The answers to this group of questions matter more than beautiful mockups. This is exactly where it's decided whether you'll own the product or be hostage to the contractor.
Red flags in the answers
- The vendor promises "native quality" but can't show live projects in the stores
- They insist their technology suits absolutely everyone without exception
- They dodge the question of code and account ownership
- They ask no counter-questions about your audience, features and plans
A good vendor starts the conversation with your tasks, not their technology. If all you hear in the first half hour is the name of a framework — that's a reason to be cautious.
