For a typical business app, cross-platform frameworks (React Native, Flutter) versus fully native (Swift/Kotlin) is largely a question of team preference and code-sharing economics. For a companion app tied to connected hardware, there's an additional factor that often dominates the decision: how well the chosen approach handles Bluetooth Low Energy, background execution, and platform-specific connectivity quirks — areas where the gap between cross-platform and native is real, not just theoretical.
BLE support: where the frameworks genuinely differ
Both major cross-platform frameworks have mature BLE plugin ecosystems today, and for straightforward BLE interactions — connect, read/write characteristics, subscribe to notifications — the gap with native has narrowed substantially. Where it hasn't fully closed is in edge cases: platform-specific BLE quirks (particularly across the fragmented Android OEM landscape), newer BLE features not yet wrapped by a plugin, or debugging a connectivity issue that turns out to be a plugin bug rather than an app bug. A team that hits one of these has to either wait on the plugin maintainer, patch the native plugin code themselves (which requires the native skills a "cross-platform" choice was meant to avoid needing), or work around it in ways that add complexity.
Background execution and platform restrictions
iOS and Android both impose real restrictions on background BLE scanning and connection maintenance, for battery and privacy reasons — restrictions that exist regardless of framework choice, but that are more directly and predictably controllable from native code than through a cross-platform abstraction layer, particularly for apps that need reliable background reconnection to a device (a fitness tracker syncing overnight, a security sensor that needs to stay connected). This is less "cross-platform can't do it" and more "native gives more direct, predictable control over exactly how the OS treats your app's background behavior."
Where cross-platform is a strong, low-risk choice
- Standard BLE interaction patterns — connect, read/write, notify — well within what mature plugins handle reliably today
- Apps where most of the value is in UI/business logic rather than deep platform integration, where code-sharing genuinely saves significant development time
- Teams without dedicated iOS and Android native expertise, where the realistic alternative isn't "native done well" but "native done by a team learning as they go"
- Faster initial time-to-market across both platforms simultaneously, particularly valuable for validating a product before committing to a larger native investment
Where native is worth the extra cost
- Products with demanding background connectivity requirements, where predictable OS-level background behavior materially affects the product experience
- Apps pushing into newer or more obscure BLE features not yet well-supported by cross-platform plugins
- Teams that already have strong native iOS/Android expertise, where the cross-platform code-sharing benefit is smaller relative to what's given up
- Products where platform-specific UI conventions and deep OS integration (widgets, complex background services, platform-specific health/fitness APIs) are central to the product, not incidental
A pragmatic middle path
Some teams start cross-platform to validate the product and reach both platforms quickly, with an explicit plan to migrate specific problem areas (typically the BLE/background layer) to native modules if and when a real limitation is hit — rather than committing fully to either extreme upfront. This works when the app's architecture keeps the BLE/hardware-interaction layer reasonably isolated, so a later native migration of just that layer doesn't require rewriting the whole app.
How we approach this
We evaluate this against the product's actual BLE and background-execution requirements, not team preference alone, and we're direct about where cross-platform genuinely fits versus where it's a false economy. See our mobile & web app work for how this fits into building companion apps for connected hardware.