Our studio builds high-end React Native and web applications every single week. We love the ecosystem when it fits the problem.
So when a client contacts us asking to build an app in React Native, and we tell them: “Do not use React Native. Write this in pure Swift and Kotlin,” they often look at us like we’ve lost our minds.
Every other dev shop quoted them a single unified codebase. “Cut your engineering costs in half!” their sales pitches promised.
Here is the truth: Cross-platform only saves you money if your app is primarily a UI presentation layer for remote JSON APIs.
The moment your product enters any of the following four domains, “Write Once, Run Anywhere” becomes an expensive lie.
1. Complex Bluetooth Low Energy (BLE) Peripherals
If your mobile app communicates with custom hardware (medical sensors, smart rings, vehicle telemetry dongles), BLE on Android and BLE on iOS have almost nothing in common.
- iOS
CoreBluetooth: Strict state preservation and restoration routines. If the app is terminated in the background, the OS wakes your app viabluetooth-centralbackground mode and hands back peripheral restoration identifiers. - Android
BluetoothGatt: A notorious minefield of manufacturer-specific quirks. Samsung devices handle GATT MTU negotiation completely differently than Pixel devices. You need custom retry loops and thread dispatchers just to avoid error 133 status codes.
If you wrap this in a community-maintained React Native BLE plugin, you now have three layers of abstraction to debug when a hospital patient’s telemetry monitor disconnects. When it breaks, you will have to write native Swift and native Kotlin anyway—except now you also have to write JNI / TurboModule bridges.
2. Real-Time Audio DSP or Sub-10ms Latency
If you are building an audio synthesis tool, a digital audio workstation, or an app that processes microphone buffers in real time, you cannot afford to serialize audio buffers across a JavaScript bridge or Dart FFI boundary.
iOS requires AVAudioEngine with real-time render callbacks executed on high-priority audio threads. Android requires the Oboe C++ library with AAudio backends.
Trying to shove audio processing through a cross-platform layer will introduce jitter, buffer underruns, and audible clicks that will destroy your app reviews.
3. Deep Background Geofencing & Location Beacons
Apple and Google treat background location as a privacy and battery fortress.
On iOS, significant motion changes and geofencing are governed by CLRegion and CLLocationManager. Android requires foreground services with persistent notification channels, battery optimization exemption dialogs, and permission escalations across Android 14 and 15.
Cross-platform plugins for background geolocation frequently fall behind operating system updates. The moment iOS 18 drops a new privacy permission requirement, your unmaintained third-party npm package will crash on startup for 30% of your users.
The Rule of Thumb We Give Every Founder
Is your app:
├─ CRUD forms, social feeds, marketplace, onboarding, e-commerce?
│ └──► Pick REACT NATIVE or FLUTTER. You'll move 2x faster.
│
└─ Medical device BLE, audio synthesis, background geofencing, lock screen widgets?
└──► Pick SWIFT & KOTLIN. You'll spend 40% less debugging hardware race conditions.If an agency tells you that cross-platform is always the right choice, they aren’t evaluating your product. They’re evaluating their own hiring bench.