AR app development is two native frameworks, and the first question is whether you need to touch either.
AR app development on phones means ARKit on iOS or ARCore on Android. Both are native frameworks owned by the platform, not by your stack, and neither ships a React Native SDK. But the most common AR job, putting one 3D object in somebody's room, does not need either of them, because each platform already ships a viewer that does it from a link. So this page is about three paths and how to tell which one you are on. Every figure below comes from Apple's and Google's own documentation, read on 10 October 2026. If you are still working out the shape of the thing, start with building an app.
What follows is the device floor on each platform, the real cost in frames, heat and megabytes, the one maintained way to get AR into an Expo project, and the honest limit. There is a point where the cross-platform answer costs more than two native modules would, and it arrives earlier than most people expect.
Start hereThe short version
Three ways in, and most apps want the cheapest one.
ARKit and ARCore do the same job. They read the camera and the motion sensors, work out how the phone is moving through the world, and find surfaces you can anchor things to. ARKit is Swift and Objective-C, rendered through RealityKit, SceneKit or Metal. ARCore publishes SDKs for Android, the Android NDK, Unity, iOS, Unreal Engine and the web. Neither of them targets React Native.
That leaves three ways in. Hand a model file to the platform's own viewer and write no AR code. Use ViroReact, which wraps both frameworks behind React components. Or write a native module per platform and call the frameworks directly. One question sorts them: does your app have to react to what the camera sees, frame by frame, or does it just need to show something in a room.
Which devices can actually run an AR app?
Apple states the floor plainly. All ARKit configurations require an iOS device with an A9 or later processor, and ARKit itself needs iOS 11.0 or later. That covers almost every iPhone in use. The features people actually want are much narrower. People occlusion, where somebody walking in front of your virtual object hides it, is supported on Apple A12 and later devices. Motion capture, which maps a person's body onto a character, wants an A12 chip or later too. Scene reconstruction, the polygonal mesh of the room, requires a device with a LiDAR Scanner, and Apple's own example is the fourth-generation iPad Pro.
Face tracking is its own branch with its own rules. A face-tracking configuration detects faces within 3 metres of the front camera. Apple says it supports devices with the Apple Neural Engine on iOS 14 and iPadOS 14, while iOS 13 and earlier needed a TrueDepth camera. If you use it, your app must include a privacy policy describing how you intend to use face tracking and face data. Two property list details decide who can install the app. The camera usage description is required, because ARKit asks for camera permission the first time a session runs. And if AR is the whole point, the arkit key in the required device capabilities section keeps the app off devices that cannot run it. If AR is a side feature, check the supported flag on the configuration class instead and hide the button.
Android is a list rather than a rule. A phone runs ARCore only if Google has certified it, and certification checks the camera, the motion sensors, the design architecture and whether the CPU is powerful enough for real-time calculations. The device must also have shipped with the Google Play Store. Where no higher version is listed against a model, the baseline is Android 7.0 or newer, and some models need 8.0, 10 or 13. An app that requires AR has to declare a minimum SDK version of 24 or higher, while an app where AR is optional can go down to 19. Depth, which is what occlusion leans on, is not universal: Google puts Depth API support at over 88 percent of active devices as of May 2026.
Two practical notes before you plan testing. The Android emulator can run AR, but only an x86 or x86_64 virtual device on Android 8.1 or later, and only the rear camera, which is emulated with a virtual scene. The front camera is not supported there at all, so face AR has to be tested on hardware. And ARCore does have an iOS SDK, but only for Cloud Anchors and Augmented Faces, verified on ARKit-compatible devices running iOS 12.0 or later. If what you really need is a live preview and a photo rather than tracking, the camera is a far smaller problem, and worth ruling in first.
Apple, ARKit documentation, device support and feature requirements, read 10 October 2026
Pick the job
Which AR path your app actually needs
Tick what the app has to do. The lightest tool that does each job is not always a framework.
Nothing ticked. If none of these is the app, you probably do not need an AR framework in the project at all.
What does AR cost in frames, heat and megabytes?
More than a normal screen, and the cost is continuous rather than a spike. An AR session holds the camera open, runs motion tracking on every frame, and renders 3D on top of the result. Google's own performance guidance for ARCore puts the goal well: users generally prefer frame rates that are consistent and lower over frame rates that are variable and higher. It also tells you to switch features off when they are not in use, because Instant Placement and Augmented Images both raise CPU use while they are enabled.
Heat is the real constraint, and both platform owners say so. Google points you at the Android power APIs for the current thermal status and the thermal headroom, and says a VIO frequency low message in the logs means ARCore is being starved of CPU. Apple arrives at the same place from the other side: its guidance on people occlusion suggests you might disable occlusion for performance reasons if the device has reached a serious or critical thermal state. Read that twice, because it is the whole lesson. The platforms expect you to degrade the experience on purpose. An AR feature that only works on a cold phone is not finished.
Then the assets, where the numbers get refreshingly concrete. Google's Scene Viewer documentation recommends a total model size of 10 MB and enforces a hard limit of 15 MB. It recommends staying under 100,000 triangles, with 30,000 to 50,000 as the comfortable range, no more than around ten materials, and textures no larger than 2048 by 2048 pixels. Treat those as a budget even if you never touch Scene Viewer, because they are roughly what a mid-range phone can load and light without dropping frames. Most first AR builds fail here, on a model exported straight out of Blender, rather than on the AR code.
If you are going to measure any of this, measure a production build on real hardware, which is Google's advice too. Simulators do not throttle, debug builds are slow in ways that do not match a release, and one warm minute on a real phone tells you more than an hour of profiling. Everything else is the ordinary work: bundle size, cold start, list rendering, images. That part is the same as any other app, and app performance covers it without the AR tax on top.
Can you build an AR app from a React Native or Expo project?
Yes, through ViroReact, and it is the only maintained option worth naming. ViroReact is an open-source, MIT licensed library that wraps ARKit on iOS and ARCore on Android behind React components. The current package is @reactvision/react-viro, version 3.0.3 published on 7 October 2026. It requires React Native's new architecture, lists an iOS deployment target of 15.1, and its own documentation is blunt about the catch: it does not work with Expo Go. You add it to the plugins array in app.json, run expo prebuild, then expo run:ios or expo run:android. Four iOS permission strings go in as well, for camera, microphone, and reading and saving photos.
What you do not get is an AR module from Expo itself. Expo had one, it was experimental for its whole life, and Expo's own deprecation notice says the AR module was removed from all SDK versions when SDK 38 shipped. GLView is still in the SDK, and three.js on top of it will render 3D happily, but rendering 3D is not AR. Nothing in Expo works out where the phone is in the room. That part is the native framework or nothing, which is why a wrapper exists at all.
Before you install anything, check whether the cheapest path covers you. Apple's AR Quick Look takes a .usdz or .reality file and lets the user place it on a surface ARKit finds, then move it, scale it and share it through the standard share sheet. You can present it inside the app, or simply link the file from a page: Apple says that when the user clicks the link in Safari, or inside a web view displayed in your app, iOS presents the scene in AR Quick Look on your behalf. Android has the same shape. Scene Viewer takes glTF 2.0 or .glb, launches from an intent or a model-viewer tag, and needs an ARCore device on Android 7.0 or later with Google Play Services for AR up to date. A web view and two model files cover a surprising amount of what people mean when they ask for AR.
The split is clean. If the app shows a thing in a room, the store viewers do it with no native code, no permission prompt of your own and no device gate to maintain. If the app has to respond to the room, with plane detection you drive, image or object triggers, or anchors several people share, then ViroReact is the cross-platform answer and it pulls you into prebuilt native directories and a development build. Either way the project stays an ordinary React Native app, which is the general case that cross-platform development deals with.
Apple, ARKit documentation, previewing a model with AR Quick Look, read 10 October 2026
When does a cross-platform stack stop being the right tool?
At the point where the AR is the product. A wrapper is a layer over somebody else's framework, and layers lag. ViroReact pins to a narrow React Native range in its own package metadata, so moving to the newest React Native can mean waiting for a release. Its front camera AR sits in a separate package on purpose, because on iOS ARKit reaches the front camera only through the TrueDepth API, which the library says Apple scans binaries for under review guideline 2.5.1, so apps that do not need it stay clear of it. Both are sensible engineering decisions. They are also the shape of every wrapper: the thing you want this quarter is somebody else's release away.
The second signal is the SDK list, and it is the one people skip. ARCore's documentation ships getting-started guides for Android in Kotlin and Java, the Android NDK in C, Unity through AR Foundation, iOS, Unreal Engine and WebXR. React Native is not among them. Apple's side is the same story: the ARKit renderers are RealityKit, SceneKit and Metal, and the sample code is Swift. When neither platform owner targets your stack, every new feature reaches you through a middle layer somebody maintains in their spare time.
So the test is which half is hard. If the hard part is the app, with accounts, lists, payments and sync, and the AR is one screen, build the app in React Native and reach for the store viewers or ViroReact for that screen. If the hard part is the AR, with continuous meshing, occlusion, multi-user anchors, hand or body tracking, or a game loop, the usual answer is Unity with AR Foundation, which both platforms document, or two native modules you write yourself. Choosing that is not a failure of nerve. It is reading the job in front of you.
One more limit, and it is about devices rather than code. Android AR is a certified list, not a platform guarantee, and something under one active device in eight still has no Depth API. On iOS, the features that make AR look convincing start at the A12 and the LiDAR Scanner, not at the floor. So any serious AR feature has to be designed twice: once with the good hardware and once without. Decide whether that is worth it before the first component, not after the first demo.
Google, ARCore supported devices and SDK guides, read 10 October 2026
What each path actually gives you
| What you need | Store viewers | ViroReact in an Expo project | Native ARKit and ARCore |
|---|---|---|---|
| Place one model on a surface | Yes | Yes | Yes |
| Ships without a native build | Yes | No | No |
| Plane detection you drive yourself | No | Yes | Yes |
| Front camera face AR | No | Through a separate package | Yes |
| One codebase for both stores | Yes | Yes | No |
Where this lands if you describe the app instead of writing it
Newly is an AI app builder. You describe the app in plain English and it writes a real React Native and Expo project you own, with two-way GitHub sync. It uploads iOS builds to TestFlight, publishes to Google Play internal testing, and can build a standalone Android APK. It does not submit to the App Store on your behalf, because Apple requires the owner of the content to submit. It is $25 a month and there is no free tier.
Where that fits here is the app around the AR. A catalogue, accounts, a cart, an order history, a settings screen, a share sheet. In an AR app that sells something, that is most of the code, and it is ordinary React Native work. Pair it with the store viewers and you have a working product with no AR SDK in the project at all: a .usdz for iOS, a .glb for Android, and a link on the product screen.
The honest limit is the other case. An AR-first app is not the shape a describe-it-and-preview-it loop is best at, because ViroReact needs prebuilt native directories and a development build, so you end up working in the generated project like any other React Native developer. You own the code, so nothing blocks you. But if the AR is the product rather than a screen inside it, read the section above once more before you start, and price Unity or two native modules honestly against it.
Questions people ask about AR app development
It is building on one of two native frameworks: ARKit on iOS and ARCore on Android. Both read the camera and the motion sensors, work out where the phone is in the room, and find surfaces you can place things on. Neither is a cross-platform API, and neither is owned by your app framework. There is also a third path most people miss. Each platform ships a viewer, AR Quick Look on iOS and Scene Viewer on Android, that places a single 3D model in a room from a link, with no AR code in your app at all.
Build the app first, then decide how much AR it needs
Get the catalogue, the accounts and the screens working as a real Expo project you own. Then look at one screen and decide whether it needs a framework or just a link to a model file. That order saves most of the AR work people expect to do.
Start building