The Question Nobody Asks Before Picking a Mobile AR Platform

Most teams pick a framework and live with it for years. Here's how to get it right the first time.

I evaluated three platforms for a client porting an Android AR app to iOS. The project was 3D object scanning for warehouse operations. It needed to replicate existing camera-based capture workflows, integrate with a React backend, and eventually ship as a reusable third-party SDK.

Most teams skip this analysis. They grab the framework their devs already know, ship it, and spend the next two years paying for it. Four criteria drove the evaluation. React Native won.

The contenders

• Native Swift -- unrestricted ARKit access, no abstraction layer, requires a Swift specialist
• Flutter -- native AR bridge via ar_flutter_plugin / arkit_plugin, uses Dart
• React Native -- native AR bridge via ViroReact (relaunched as ReactVision by Morrow in 2025), uses TypeScript/JS

Criterion 1: Level of effort

If your team already works in React, React Native costs you nothing to adopt. Same language, same mental model, same toolchain, same state management patterns.

Flutter requires Dart. Dart is not hard, but it is not JavaScript, and "learn a new language first" is a tax you do not need on a focused feature port with a deadline attached.

Native Swift demands a specialist or a months-long ramp, and it produces a codebase that shares nothing with your Android implementation. Maintenance debt starts accumulating before you ship a line of feature code.

React Native wins this one going away.

Criterion 2: AR API completeness

This is where cross-platform skepticism usually lives, and it is a fair concern. The question is whether the abstraction actually exposes the full native AR API or quietly caps your capabilities.

ViroReact compiles to true native draw calls. It is not a WebView. Not a shim. On iOS it calls ARKit directly; on Android it calls ARCore. When a capability falls outside ViroReact's abstraction, React Native's native module bridge fills the gap. Writing a custom native module to call ARKit APIs directly is documented, production-tested, and well-covered by community examples.

Flutter's AR plugins are architecturally comparable -- native bridges, not web wrappers. But the ecosystem is fragmented. Maintenance has lapsed on key packages. A community fork emerged to compensate. You would write the same custom native code to hit advanced scanning APIs, just in a less familiar environment with thinner documentation to lean on.

Native Swift has unrestricted access to the full ARKit surface -- Object Capture, RoomPlan, LiDAR, no abstraction in the way. That is the honest ceiling. The gap narrows fast once you account for React Native's native module bridge, and both cross-platform frameworks can reach the same APIs. React Native's path there is just better documented and more widely used in production.

One note specific to warehouse environments: ARKit's object scanning degrades under inconsistent lighting. Variable and harsh conditions affect all three platforms equally. Put it in your QA plan regardless of which framework you pick.

Criterion 3: Maintainability

React Native means one codebase. The team that owns Android owns iOS. No skill set fragmentation, no parallel development tracks.

A lot of React Native developers wrote off ViroReact during the years it went quiet. That calculus changed in 2025 when Morrow acquired it, relaunched it as ReactVision, and put a full-time engineering team behind it. MIT licensed, commercially backed, actively maintained. The risk profile is not what it was.

Flutter's ar_flutter_plugin ecosystem has not had that kind of investment. The forked engine variant is a community-maintained patch on a maintenance gap. That is a shaky foundation for a production AR feature.

Native Swift gives you two codebases, two toolchains, and two sets of required skills, maintained in parallel indefinitely. The operational cost is real and it grows.

Criterion 4: SDK strategy

This is the criterion that actually decided the evaluation, and the one most platform comparison posts skip entirely because they are thinking about apps, not platform products.

When the feature eventually becomes a distributable SDK, the platform you picked determines your distribution reach and your maintenance overhead in ways that are very hard to undo.

A React Native module ships as an SDK that integrates naturally into any React Native app and shares business logic with React web applications. Consumers work in a JS/TS ecosystem they already know. The community has well-established patterns for taking an internal React Native feature and packaging it for third-party consumption.

A Flutter SDK requires consuming apps to be Flutter apps. It shares nothing with a React web stack. That is not a niche limitation -- it is a structural ceiling on adoption.

A Native Swift SDK has the broadest iOS reach but produces an Android-incompatible artifact that shares nothing with a React stack. You are effectively maintaining three separate products.

If SDK distribution is anywhere in your roadmap, React Native is the only viable option.

The verdict

React Native won because it was the right tool for the job. The team already speaks the language. ViroReact has funded maintenance behind it now. The API access is uncompromised. The SDK path is viable. None of the other options can say all four.

If deep ARKit gaps surface during implementation that cannot be resolved through the native module bridge, native Swift is a legitimate fallback. A targeted proof-of-concept sprint will answer that question in days.

Michael Stelly is a Senior React Native Technical Lead and founder of ReFactory, a consultancy specializing in React Native architecture and modernization. Building production RN apps across healthcare, logistics, and retail since 2018.