Short answer: if your app is made of accounts, content, forms, lists, maps, payments and notifications, and you need both iOS and Android, build cross-platform. If the core of the product is something the device does, such as real-time camera or audio processing, augmented reality, demanding graphics, complex Bluetooth hardware, or deep integration with watches, widgets and other system features, build native. If you already have a good web app and need a store presence, consider a hybrid wrapper.
Where we stand. BBR builds cross-platform with React Native and with Capacitor, and does not offer full native Swift or Kotlin builds. We have tried to make the case for native fairly below, because sending the wrong project down the cross-platform route helps nobody.
The three approaches, defined
- Native. Two separate apps: Swift for iOS, Kotlin for Android, each using the platform’s own tools and interface toolkit. Usually two engineers or two teams.
- Cross-platform. One codebase producing both apps. React Native drives the platform’s real interface components from JavaScript or TypeScript. Flutter draws its own interface with its own rendering engine from Dart. Both compile into ordinary store apps. We compare the two in Flutter vs React Native.
- Hybrid and web-based. A web application displayed inside a native shell (Capacitor is the common tool), or a progressive web app installed from the browser with no store involved.
Comparison
| Criterion | Native | Cross-platform | Hybrid (Capacitor) / PWA |
|---|---|---|---|
| Codebases for iOS + Android | Two | One | One, often shared with the website |
| App-side build effort for both stores | Highest, roughly double | Roughly one build plus 10–25% | Lowest when a web app already exists |
| Interface performance | Best available | Very good for typical apps | Good for content and forms; weaker for long lists and heavy gestures unless carefully built |
| Platform look and feel | Automatic | Close, with some care | Has to be designed in deliberately |
| Access to device features | Complete, from day one of each OS release | Broad through libraries; native modules for gaps | Common features through plugins; PWAs are limited to what browsers expose |
| New OS features | Immediately | After library support arrives, or via your own native module | Latest of the three |
| Hiring | Two specialist skill sets | One; React Native draws on the large JavaScript pool | Web developers |
| Keeping platforms in step | Needs discipline; features drift | Automatic | Automatic |
| Long-term maintenance | Two codebases to update every year | One codebase plus framework upgrades | One codebase; the shell needs occasional updates |
When native is required
Choose native, without much agonising, if one or more of these describes the heart of the product and not a side feature:
- Real-time media processing. Camera filters, computer vision on live video, low-latency audio, professional photo or video editing.
- Augmented reality or demanding 3D outside a game engine. (Games themselves are usually built in an engine such as Unity, which is a different decision.)
- Complex hardware communication. Continuous Bluetooth connections to medical, industrial or fitness devices, especially in the background.
- Deep operating-system integration. Apps that are primarily a watch app, a widget, a keyboard, a share extension, a CarPlay or Android Auto experience, or that depend on health and home platform frameworks.
- Adopting new OS capabilities on release day as a competitive requirement.
- An existing native team and codebase. If you already have capable Swift and Kotlin engineers, switching frameworks has a cost that a new feature rarely justifies.
- A single platform, permanently. If the product will only ever be on iPhone, the main argument for cross-platform is gone.
When cross-platform wins
- You need both stores and have one budget. This covers the majority of startups.
- The app is a front end to a service. Marketplaces, booking, delivery, fintech dashboards, content, communities, e-commerce, internal field apps. The difficult logic lives on the server; the app presents it.
- Speed of iteration matters. One change, one review, one test pass, both platforms updated together.
- You want a small team. One or two engineers can own the whole app, and with React Native they can often work on the web front end too.
- Feature parity is important. With two native codebases, one platform tends to fall behind.
The caveat: cross-platform does not mean zero platform work. Permissions, push notification setup, in-app purchases, store rules and some interface conventions differ between iOS and Android and still need individual attention and testing on both.
The third option: Capacitor-style hybrid apps and PWAs
Hybrid apps have a poor reputation earned a decade ago, when phones were slower and web views weaker. Today the approach is reasonable for the right kind of product.
Capacitor
Capacitor packages a web application as a real iOS and Android app and gives it access to native features through plugins: push and local notifications, camera, file system, in-app purchases, ads. It fits well when:
- you already have a working web app and want it in the stores without a second front end;
- the interface is content, forms, charts and data;
- the app is drawn on a canvas, as many HTML5 games are, so native interface components are irrelevant;
- budget is tight and the alternative is no app at all.
Both of BBR’s published apps use it. Grow.io is an HTML5 canvas game wrapped with Capacitor, with AdMob ads and in-app purchases. Live Gold & Silver Prices is a data app with price alarms delivered as local notifications. In both cases the interface did not need native components, so a web-based front end was the economical choice.
It fits badly when the app depends on long, fast-scrolling lists with complex rows, elaborate gesture-driven navigation, or an interface that must feel exactly like the platform’s own apps. Note also that Apple’s review guidelines reject apps that are only a repackaged website with no app-like functionality, so a hybrid app has to offer something beyond the site.
Progressive web apps
A PWA is a website that can be installed to the home screen, work offline to a degree and, on supporting platforms, send push notifications. There is no store review, no commission and no install friction beyond a link. The limits: browser support for installation and push is narrower on iOS than on Android, you get no store discovery, and access to device features is restricted to what browsers allow. PWAs suit tools people reach through a link or search and use occasionally. They suit daily-habit consumer products less well.
Cost and time implications
Taking an app whose client side is 12 person-weeks on one platform:
| Approach for iOS + Android | App-side effort | Relative calendar time |
|---|---|---|
| Two native codebases | About 21–24 person-weeks | Similar to one platform if two engineers work in parallel; longer if one does both |
| Cross-platform | About 13–15 person-weeks | Slightly longer than one platform |
| Capacitor around an existing web app | About 3–6 person-weeks | Shortest, because the front end already exists |
These are planning estimates. The backend, admin panel and design are the same in each row and are not included. The more important number is the recurring one: every feature and every yearly OS update is done twice in the native row for as long as the app lives. Full budgeting is covered in how much it costs to build a mobile app and schedules in how long an app takes to build.
A decision procedure
- Write down the three things the app must do best. If any of them appears in the “native is required” list, go native and stop here.
- Do you need both stores within the first year? If not, pick the platform your users are on and use whichever technology your team knows.
- Is there already a good web app, and is the interface mostly content and forms? If so, price a Capacitor build before anything else.
- Do users need store distribution, store billing or reliable push on iOS? If not, consider a PWA or a responsive web app first.
- Otherwise, build cross-platform, and choose the framework based on the team you can hire or contract. For most teams with web experience that points to React Native.
Whichever route you take, the choice of approach matters less than the quality of the team executing it. Our mobile app development service page explains how BBR approaches cross-platform builds, and the MVP tech stack guide places this decision in the context of the rest of the stack.