Native or cross-platform? Choosing the right approach for a business mobile app

The options

Native: Swift on iOS, Kotlin on Android

Each platform gets its own app, written with the platform's own language and interface toolkit — Swift and SwiftUI for iOS, Kotlin and Jetpack Compose for Android.

• Strengths: full and immediate access to every device capability and new operating system feature; the most natural look and behaviour on each platform; the best basis for demanding performance.
• Trade-offs: two codebases, two sets of skills, and features implemented twice.

Cross-platform: React Native and Flutter

One codebase produces apps for both platforms. React Native, maintained by Meta, uses JavaScript or TypeScript and renders native interface components. Flutter, maintained by Google, uses the Dart language and draws its own interface.

• Strengths: one team and one codebase for most of the app; faster delivery of features on both platforms at once; React Native lets teams reuse web skills.
• Trade-offs: an additional layer between the app and the operating system; specific device features may need native code written separately; dependence on the framework's roadmap and its plugin ecosystem.

Shared logic: Kotlin Multiplatform

Kotlin Multiplatform shares business logic — data models, validation, networking, offline storage — between platforms, while each platform keeps a native user interface. It suits teams that want native interfaces without duplicating the rules underneath.

Progressive web apps

A progressive web app is a website that can be installed on the home screen, work offline to a degree and, on recent versions of iOS and Android, send notifications. There is nothing to publish in the app stores.

• Strengths: one codebase for web and mobile; instant updates; no store review.
• Trade-offs: more limited access to device features, with differences between browsers and platforms; less natural behaviour than a native app; less visibility than a store listing for consumer apps.

What actually decides

What the app has to do on the device

List the device capabilities the app needs: camera and barcode scanning, Bluetooth with specific hardware, background location, NFC, biometrics, offline operation for hours or days. The more an app depends on deep or unusual device features, the stronger the case for native — or for a cross-platform framework with native modules where needed.

Offline and synchronisation

For field and warehouse apps, offline operation is usually the hardest requirement: data captured without coverage must be stored locally, synchronised later and reconciled when two people changed the same record. This logic matters far more than the interface framework, and it should be designed early, together with the back-end it synchronises with.

Who uses it, and on which devices

An internal app used by fifty technicians on company-issued Android devices has different constraints from a consumer app that must work on whatever phone customers own. For internal apps, device management (MDM) can distribute the app without the public stores and enforce security policies.

Your team and the long term

The best framework is often the one your team, or the team that will maintain the app, can work with confidently for years. A mobile app is not finished at launch: Apple and Google release major operating system versions every year, and stores periodically raise the minimum requirements for updates. Budget for this maintenance from the start.

What matters more than the framework

Most of the effort in a business app is not in the screens:

• The back-end and integrations. A field app is only as useful as its connection to the ERP, the service management system or the warehouse — see our notes on system integration. Design the APIs the app needs explicitly, rather than exposing internal systems directly to devices.
• Security. Authentication with the company directory, secure storage of tokens on the device, encryption of local data, and the ability to revoke access to a lost device.
• Release process. Automated builds, tests and distribution to testers make frequent updates practical, as with any other software — the principles in our article on CI/CD apply in full. Store review adds time to each public release, so plan for it.
• Observability. Crash reporting and usage analytics, with attention to what data is collected and with which consent.

A simple way to decide

• Native when the app is central to your product, relies heavily on device features, or must feel exactly right on each platform.
• Cross-platform when you need both platforms with one team, and device requirements are mainstream.
• Kotlin Multiplatform when you want native interfaces but significant shared logic.
• Progressive web app when the use is occasional, device needs are light, and avoiding the stores is an advantage.

And before any of these, check whether you need a custom app at all — or whether the mobile client of an existing product would do. Our article on build vs buy covers that question.

Where to start

Write down the users, devices, device capabilities, offline needs and systems the app must connect to. That page usually makes the choice of technology obvious. Our software engineering service designs and builds mobile apps together with the APIs and integrations behind them, so that the app and the systems it depends on are delivered as one.