Native Android vs React Native for UK trades and field-service apps

UK trades, field-service and fleet businesses asking us to build a mobile app in 2026 land on the same fork: native Kotlin or React Native? Developer Twitter argues this endlessly. The honest answer depends on three things specific to your business — not on which framework is "winning."

The three questions that decide it

1. What does your workforce actually use?

Across the UK trades market we've served — plumbers, electricians, landscapers, roofers, plant-hire operators, field surveyors — Android is the dominant device by a wide margin. Pixel, Samsung, Motorola, OnePlus. Rugged Androids (Caterpillar, Ulefone) for outdoor trades. Cheap-to-mid-range Androids for office staff with a phone.

Most UK trades businesses we work with run 95% Android. The remaining 5% is the founder's personal iPhone. Building two-platform from day one to serve one device is wasted engineering.

Survey your team. If you're 90%+ Android, ship Android-first. iOS can come in v2 if it ever justifies itself — most of the time it doesn't.

2. How deep do you need to go into the device?

Native Kotlin gives you the full Android API surface with zero abstraction tax. React Native gives you a high-level abstraction that covers 80% of common needs and breaks at the edges.

These features are noticeably easier (or only possible) in native:

• Foreground services that survive Doze mode (essential for fleet tracking, time-tracking, scheduled location capture)
• Custom camera flows with metering, exposure control, RAW capture (essential for trades documenting work)
• Background sync that respects WorkManager constraints
• Tight integration with Android-specific features (App Widgets, Quick Settings tiles, Direct Boot)
• Bluetooth Low Energy with custom GATT services
• USB and NFC for hardware integration (printers, terminals, ID readers)
• System share targets and intent filters

TradeLinkers, our flagship UK trades platform, runs on native Kotlin + Compose specifically because the calendar, document-capture and trade-portfolio features all hit native APIs hard.

3. How fast is your team going to ship new features?

React Native's genuine win is iteration speed for cross-platform changes. If your app is mostly screens, forms, lists and API calls, you can ship a new feature on iOS and Android in roughly the same time it takes to ship it on Android alone in native.

That said: hot reload exists in both frameworks. Compose is much faster to iterate on than view-based Android ever was. The pure-velocity advantage of React Native has narrowed since 2022.

Where each one breaks

Native Kotlin breaks when…

• You need iOS, full stop. There's no "Kotlin Multiplatform Mobile" shortcut that ships customer-grade iOS today. KMM is maturing fast, but production-ready iOS via KMM in 2026 is still a brave choice.
• Your engineering team is small and split between mobile and web — context-switching Kotlin and TypeScript every day adds friction.
• You're shipping a v1 marketing-grade app where simplicity matters more than depth.

React Native breaks when…

• You hit a native module that doesn't exist or is poorly maintained — then you're writing native code anyway, on a foreign architecture.
• You need precise control of native performance (60fps animations on mid-range Android, custom Camera2 flows).
• Your app needs to operate offline-first with custom sync — possible, but you're working against the framework.
• You're building a long-lived product that outlives several React Native major versions — the upgrade tax is real.

The Expo Managed Workflow question

Expo SDK 52 in 2026 is excellent. EAS Build handles signing and submission. Expo Router with its file-based navigation feels close to Next.js. For a cross-platform app where you don't need a custom native module, Expo Managed is the right starting point.

Where it bites: the moment you need a config plugin for a third-party SDK that doesn't have one, you're ejecting to the Bare workflow, and you've given up half the Managed Workflow's value. Audit your dependency list before committing.

The Flutter elephant

Flutter is technically excellent and the Material 3 implementation is the best on Android. The framework concern is Google's commitment level — staff cuts to the Flutter team in 2023–2024 left the community jittery. Material 3 implementation on iOS is still awkward. We've shipped Flutter and it's fine, but we don't recommend it as a first choice for a UK trades business in 2026 unless the team already has Flutter expertise.

Costs in 2026

For a 8–12-week v1 trades or field-service app shipped by a UK studio:

• Native Android (Kotlin + Compose): £18k–£35k
• React Native + Expo (Android + iOS): £24k–£45k
• Native Android + native iOS (two codebases): £35k–£70k

The cost gap isn't enormous. The real cost difference is maintenance over years three to five — native is easier to upgrade per platform, React Native costs more to maintain if you span major versions, two-native is just two of everything.

Our default recommendation for UK trades

Build native Kotlin + Compose for Android first. Ship to internal track in eight weeks, production in ten. Survey your customers at week sixteen — if 15%+ are asking for iOS, plan an Expo-based iOS companion. If they're not asking, don't build it.

This is exactly the path TradeLinkers took. v1 Android shipped, scaled to thousands of trades on a single codebase, iOS still on the "when the demand justifies it" shelf. Total engineering hours saved by not building iOS day one: roughly 700.

How we'd scope yours

A 30-minute call covers: target audience device split, feature surface (camera, location, payments, offline), Play Store readiness, and timeline. We come back with a fixed price and a one-page SOW within five working days. If we don't think we're the right fit, we'll say so — we've referred clients to Flutter shops and React Native specialists before.