Key takeaways
A founder comes to us with two quotes. One agency wants to build separate apps, Swift for iOS and Kotlin for Android. The other proposes a single React Native app for noticeably less money. Both sound confident, both say their approach is the right one, and the founder wants to know who is telling the truth. Usually both are, for different apps. The real question is which kind of app you're building.
Native means building each platform with its own tools: Swift and SwiftUI for iOS, Kotlin and Jetpack Compose for Android. That's two codebases, often two developers or teams, and full access to everything the operating system offers on the day it ships.
Cross-platform means one codebase that ships to both stores. In 2026 the two serious options are React Native and Flutter. React Native uses JavaScript or TypeScript and renders real native components, which makes it a natural fit if your web product is already built in React: the team knows the language and some logic can be shared. Flutter uses Dart and draws its own interface, which gives very consistent visuals across platforms and handles animation-heavy UIs well. Both are mature, both run large production apps, and both have good tooling. The old complaint that cross-platform apps feel sluggish is mostly out of date for typical business apps.
Writing one codebase instead of two does not halve the budget. A good chunk of the work is the same whatever you choose, and cross-platform apps still need some platform-specific effort. As a rule of thumb, a cross-platform build for a typical business app comes in at roughly 30% to 40% less than two separate native builds, with a similar gap in timeline.
The bigger saving shows up after launch. Every feature, bug fix and design tweak happens once instead of twice, and you avoid the classic situation where the Android app lags two releases behind iOS because that team is smaller or busier.
We build cross-platform apps by default for most clients, and we're comfortable saying so. But there are real cases where native is the better call, and it's worth being honest about them.
Notice what's not on that list: "we want it to feel premium" and "we might have millions of users one day." A well-built React Native or Flutter app can feel excellent, and scaling problems almost always live in the backend, not in the app framework. There's also a middle path people forget: a cross-platform app with one or two native modules for the parts that genuinely need it. That covers a lot of apps that seem to need native at first glance.
“Pick the framework for what the app has to do on the device. Almost everything else is a backend or design problem, and neither Swift nor Flutter will fix it for you.”
Whatever you build, two companies decide whether it goes live. Apple's review is the stricter of the two, and rejections on a first submission are common. The usual reasons are mundane: no way to delete an account from inside the app, privacy disclosures that don't match what the app collects, a login wall with no demo account for the reviewer, or an app that is basically a website in a wrapper. Google Play has its own hoops, including a closed testing period before new personal developer accounts can publish to production, and both stores regularly raise the minimum SDK versions your app must target.
Plan for this. Leave a week or two of buffer before any public launch date, fill in privacy labels and data safety forms early, and give reviewers a working test account. If you sell digital goods or subscriptions inside the app, read the in-app purchase rules and fees before you design your pricing. That decision can shape your business model more than the choice of framework does.
A mobile app is never finished the way a brochure website can be (and even a website needs a regular maintenance routine). Apple and Google ship major OS updates every year, deprecate APIs and set deadlines for building against newer SDKs. Libraries need updating. New screen sizes appear. An app that nobody touches for eighteen months will usually need real work before its next update can even be submitted.
This is also where cross-platform can bite if it's handled carelessly. A major React Native or Flutter upgrade sometimes means updating native modules as well. Teams that stay current find this manageable. Teams that skip several versions find it expensive, and occasionally end up rebuilding parts of the app.
Start with a list of everything the app needs to do on the device itself, separate from what the backend does. If that list is mostly forms, lists, accounts, payments, notifications, maps and content, cross-platform is almost certainly the right call: you'll ship sooner and maintain one codebase. If a few items are deep hardware or performance requirements, check whether they can live in a native module inside a cross-platform app before committing to two full native builds. A shared set of design tokens and components, as described in our design systems guide, also keeps the iOS and Android versions consistent.
Then ask whoever is quoting how they would handle those specific items, what the maintenance plan and cost look like after launch, and who takes care of store submissions and rejections. Their answers will tell you more about whether they're the right partner than the framework they happen to prefer.
Usually. As a rule of thumb, a React Native or Flutter build for a typical business app comes in at roughly 30% to 40% less than two separate native builds, and the bigger saving comes after launch because every change ships once instead of twice.
When the app's core value depends on heavy use of device features, demanding graphics performance, or day-one access to new iOS and Android capabilities. For most business apps, cross-platform covers the requirements well.
A common rule of thumb is 15% to 20% of the original build cost per year, covering operating system updates, app store requirements, bug fixes and small improvements. Budget for it from day one.
It varies, and Apple's review in particular often rejects a first submission for fixable reasons such as missing in-app account deletion or privacy disclosures that don't match the app. Google Play requires a closed testing period before new personal developer accounts can publish. Leave a week or two of buffer before any public launch date.
Work with us
We work with businesses in the US and worldwide. Tell us where things stand and we'll give you an honest recommendation, even if that means a smaller project than you expected.
Design & UXAs soon as more than one person touches your product's UI, inconsistency creeps in. A design system is how you prevent that without slowing down.
Web DevelopmentWhat to check weekly, monthly, quarterly and yearly to keep your small business website secure, fast, and bringing in leads.
Web DevelopmentBoth platforms can produce a great website. The right choice depends on who's updating the content and how complex the product actually is.
No spam, just practical writing on AI, SEO, and building things that grow.