Building Augmented Reality Apps with Expo and AppLighter

You've got the product idea, the 3D model, and the camera permission prompt drafted. Then you open the app on a real phone, and the first thing that breaks is not the rendering, it's the path into AR. Users can't find the feature, the device gets hot, tracking jitters in bad light, and suddenly the “cool demo” feels like a fragile experiment instead of a feature people will use.

Table of Contents

• Why Augmented Reality Apps Deserve a Place in Your Expo Stack
  • The product decision comes before the code
• Choosing the Right AR Approach for Your App
  • Native AR, WebAR, and custom 3D are not interchangeable
  • Match the stack to the job
• Setting Up AppLighter for AR Development
  • Start with the app shell, not the camera screen
  • Keep the project structure narrow
• Integrating Camera Feeds and 3D Overlays
  • Build the session around entry, active state, and exit
  • Keep 3D content anchored to the user's task
• Solving the Discoverability and Trust Problems in AR
  • Discoverability needs visible entry points
  • Trust depends on privacy and operational clarity
• Testing on Real Devices and Tuning Performance
  • Build a small but intentional device matrix
  • Tune the scene before you chase the GPU
• Deployment Best Practices and Launch Checklist
  • Launch with explicit fallbacks
  • Measure the behavior that matters

Why Augmented Reality Apps Deserve a Place in Your Expo Stack

A lot of teams reach for augmented reality apps because the demo looks impressive, then they discover the actual value is product behavior, not visual spectacle. Retail try-on, spatial guidance, onboarding overlays, and guided repair all work because they reduce guesswork in the physical world. Pokémon GO made that shift visible in 2016, when it was downloaded more than 100 million times in its first month and later passed 500 million downloads by late 2016, showing that smartphone-based AR could create mass-market behavior without special headsets (worldmetrics.org).

A chart showing market growth of augmented reality apps, highlighting business benefits and user engagement features.

That matters for Expo developers because AR is no longer an exotic side project. It's a feature that can sit beside commerce, support, and onboarding flows, as long as the implementation is disciplined. The market data is also hard to ignore, with 1.3 billion global AR users in 2023, equal to 14.3% of the world population, and a projection of 1.8 billion mobile AR users by 2025 (worldmetrics.org).

The product decision comes before the code

The first question is not which AR library looks coolest. It's whether AR belongs in the core user journey or just in a narrow, high-value moment. If the feature needs the camera, 3D positioning, and close-to-the-hardware tracking, you'll need to accept more device variance and more QA overhead. If the feature is mainly about visualizing an object in place, a lighter implementation can be enough.

The second question is how much of the experience has to live inside the app shell. That affects camera permissions, navigation, state handoff, analytics, and even support scripts. A sharp team treats AR like any other product surface, which means it gets a discovery path, a fallback path, and a deactivation path when the device isn't a good fit.

Practical rule: if the AR feature can't answer “what happens when the camera is denied?” in one sentence, it isn't ready to ship.

For a clean entry point into an Expo workflow, the getting-started path at AppLighter's Expo integration guide is a useful reference point for the surrounding app architecture, even before you touch AR code.

Choosing the Right AR Approach for Your App

The wrong AR stack usually fails for ordinary reasons, not dramatic ones. It's too heavy for the bundle, too narrow on devices, or too awkward to maintain after the first launch. The right choice depends on whether you need deep hardware access, browser reach, or simple 3D presentation inside an otherwise standard app.

Native AR, WebAR, and custom 3D are not interchangeable

Native AR modules are the strongest fit when you need tracking, surface anchoring, or more direct access to device capabilities. The trade-off is maintenance burden, because the implementation becomes more sensitive to iOS and Android differences, native build steps, and framework updates. This is the path that makes sense when the AR scene is the product.

WebAR reduces install friction and works well for demos, marketing flows, and lightweight try-before-you-buy experiences. It's attractive when distribution matters more than deep device integration. The downside is that browser constraints can make performance tuning and tracking consistency harder to control.

Three.js with expo-gl is useful when you want 3D overlays without full AR tracking. It's lighter, easier to reason about, and often faster to ship inside an Expo app. It won't replace native AR for plane detection or occlusion, but it can be the better decision when the actual product goal is visual context rather than spatial intelligence.

Here's the decision matrix I'd use on a real project.

Match the stack to the job

If you're building a shopping experience, the design choice may be closer to visualize outfits before buying than to a full spatial engine. That kind of use case often works because the user wants confidence, not a technical showcase. A leaner experience can outperform a heavier one if it loads faster, fails less often, and keeps the user oriented.

Use native AR when the scene has to stay pinned to the physical environment.

Use WebAR when distribution friction is the biggest problem.

Use Three.js + expo-gl when the 3D content matters more than the tracking layer.

A practical rule is to choose the simplest stack that still supports the business outcome. Teams get into trouble when they build for “future flexibility” before they know whether users will even activate the feature once.

Setting Up AppLighter for AR Development

AR work gets easier when the base app already has the boring parts handled. Authentication, routing, TypeScript, and predictable state management keep the AR feature from becoming a one-off island. That matters because AR usually needs a clean route in, a clean route out, and a place to store session state without threading props through half the app.

Start with the app shell, not the camera screen

Use the existing navigation structure to isolate AR in its own route group. That lets you control camera permissions, loading states, and exit behavior without polluting unrelated screens. In practice, the AR screen should own its own session state, while shared state should only carry what the rest of the app needs, such as selected product, anchor metadata, or last-known AR mode.

Expo-specific setup is where teams usually trip. Native AR features need the dev client path, not a casual hope that everything will run inside the standard preview flow. Camera permissions also need to be declared early in the app config, because a permission denial is not an edge case, it's a normal user behavior.

For the broader integration pattern, the Expo integration notes in AppLighter's core concepts are the right anchor for how the app shell should behave before AR enters the picture.

Keep the project structure narrow

A clean structure usually separates the AR scene from the rest of the interface. One folder handles camera and rendering, another handles shared state, and another handles feature gating or device checks. That separation makes it easier to swap in a different rendering path later without rewriting the entire navigation tree.

If you're bringing in assets for product visualization, an AI toolkit for 3D artists like Sculpty's AI tools can help the content pipeline. The important point is not the tool itself, it's keeping asset creation and app integration decoupled so you don't block engineering on every model tweak.

Treat AR as a feature module. If it can't be mounted and unmounted cleanly, it's too entangled with the rest of the app.

The setup is done correctly when the app can launch normally, request camera access only when needed, and enter the AR route without forcing unrelated screens to understand any of the 3D details.

Integrating Camera Feeds and 3D Overlays

The camera layer and the 3D layer solve different problems, and they need to stay loosely coupled. The camera provides reality, the overlay provides the digital object, and your job is to keep the two in sync without turning the component tree into a knot. Most failures here are not rendering failures, they're state-handling failures.

Build the session around entry, active state, and exit

A stable AR flow usually has three states. The first state asks for permission and initializes the camera. The second state renders the scene and tracks whatever the user is manipulating. The third state tears everything down cleanly when the user exits or the app loses focus.

That state machine matters because AR screens tend to behave badly when a user backgrounds the app or leaves mid-session. If the camera stays mounted too long, you get unnecessary resource use. If the state survives too aggressively, the next session may reopen with stale anchors or a broken view hierarchy.

A good pattern is to keep object position, selected model, and UI visibility in shared state, while the camera lifecycle stays local to the AR route. That gives you a single source of truth for the scene without making every UI component aware of the rendering internals.

Keep 3D content anchored to the user's task

The overlay should answer a task, not just occupy space. A product preview needs scale, placement, and enough visual grounding to feel believable. A repair overlay needs clear labels and a stable camera reference. A guided onboarding scene needs to highlight one thing at a time or users will lose the thread.

If the user has to hunt for the object in the scene, the scene is already failing.

This is also where navigation discipline matters. Don't bury the AR experience under nested modal layers unless the feature needs that structure. A direct entry route with a clean exit button is usually easier to maintain and easier for users to trust.

The strongest implementations keep the React Native UI minimal while the AR scene is active. Buttons, prompts, and helper text should stay visible enough to guide the user, but not so heavy that they compete with the camera feed.

Solving the Discoverability and Trust Problems in AR

The hardest part of shipping AR isn't making the object appear. It's helping people find the feature, understand it, and feel safe enough to use it. Nielsen Norman Group points out that mobile AR often suffers from poor discoverability, low-visibility instructions, and vague icons, and recommends explicit visual indicators, clear labels, filters, and step-by-step guidance rather than assuming users will stumble onto the feature naturally (Nielsen Norman Group).

A checklist graphic titled Solving the Discoverability and Trust Problems in AR for mobile developers.

Discoverability needs visible entry points

A good AR icon is not enough if the user doesn't know what it does. Put the entry point where the task already lives, such as a product detail page, a help step, or a post-purchase setup screen. The best pattern is often a plain label next to a button, not a clever glyph that makes sense only after the user already knows what to expect.

The other half of discoverability is the first interaction. Short onboarding copy works better than a wall of instructions, especially when the camera is involved. Keep the language literal, tell the user exactly what will happen, and make the exit route obvious before the feature starts.

Trust depends on privacy and operational clarity

A 2022 review of augmented-reality tracking and collaboration found a lack of security solutions in collaborative AR, including gaps in distributed trust management (PMC review). That matters because camera-based apps aren't just visual interfaces, they're systems that may capture surroundings, coordinate spatial data, or manage shared anchors.

This is also where product teams need to be honest about scope. If the feature only needs a local camera view, don't design it like a multiplayer spatial platform. If you're sharing anchors or working across users, document that clearly and keep the data flow tight. The more the feature depends on the physical environment, the more important it is to explain what is stored, what is transient, and what the user can revoke.

Practical rule: ask for camera access at the exact moment the user understands why the app needs it.

For teams shipping commerce-focused AR, it's useful to study how virtual try on reduces returns because that same trust logic applies here. Users need to believe the preview is useful, not intrusive, and that confidence starts with a clean permission flow and an easy way to leave the experience.

Testing on Real Devices and Tuning Performance

Simulator success means almost nothing for AR. Real devices vary in camera quality, thermal behavior, GPU headroom, and how aggressively the OS throttles long-running sessions. A build that feels fine on one flagship phone can fall apart on a midrange Android device the first time the user moves from bright daylight into a dim room.

Build a small but intentional device matrix

Start with a flagship iPhone, a flagship Android device with current AR support, and at least one older device that still represents real users. That gives you a meaningful spread without pretending you need a full lab. Watch how the app behaves when tracking begins, when it loses the surface, when the phone heats up, and when the user switches between AR and standard screens.

The NIST evaluation framework recommends five steps for AR assessment, determine evaluation scope, identify users and context, develop scenarios and tasks, select usability metrics, and define measures (NIST IR 8422). In practice, the useful technical checks are frame rate, latency, tracking accuracy, and battery consumption, while task checks should include completion rate and time-on-task. One reference example in that same material reports that AR guidance improved repair speed by 25% (NIST IR 8422).

Tune the scene before you chase the GPU

The biggest performance mistakes are usually self-inflicted. Oversized textures, unnecessary re-renders, and constantly changing props can make the scene feel unstable even before the rendering engine is stressed. Keep asset sizes disciplined, avoid rebuilding 3D objects on every state change, and keep nonessential UI updates out of the AR loop.

Thermal throttling is a product problem, not just a systems problem. Once the device gets hot, the experience gets worse in a way users can feel immediately. If the app runs long sessions, give users a way to reduce quality, pause tracking, or exit the AR mode without losing their place.

The performance monitoring guide at AppLighter's monitoring notes is useful as a companion for the general app-side telemetry you'll want around these sessions, especially when you're separating UI slowness from actual AR rendering issues.

Watch for the real bottleneck. If the frame rate is fine but interactions feel laggy, the problem is often state churn or asset loading, not the camera feed.

A stable AR app is one that degrades gracefully. If lighting is poor, tracking fails clearly. If the device is weak, the scene simplifies instead of crashing. If the session runs too long, the app gives the user an exit before the OS does it for them.

Deployment Best Practices and Launch Checklist

Shipping AR means planning for failure modes that ordinary screens don't have. The app store listing needs to show the feature clearly, the privacy policy needs to explain camera use, and the app itself needs to degrade cleanly when the device can't support the full experience. Users are far more forgiving of a limited AR mode than they are of a broken one.

An infographic titled Deployment Best Practices and Launch Checklist for augmented reality applications, featuring a rocket launching.

Launch with explicit fallbacks

Your first release should tell users what happens when AR isn't available. If the device doesn't support the feature, route them to a static preview or a non-AR alternative. If camera permission is denied, give them a clear path back without trapping them in a broken screen. If lighting or tracking fails, explain the issue in plain language and offer a retry.

The launch checklist is also a content checklist. Preview screenshots should show the AR behavior, not just the app shell. Metadata should make the feature obvious. Support docs should tell users how to enable the camera, how to exit the scene, and what to do if the phone is struggling.

Measure the behavior that matters

Standard app analytics are not enough on their own. Track AR entry, exit, permission denial, and session completion, then compare those behaviors to the task the feature is supposed to support. A shopping preview, onboarding demo, or support workflow has to prove its value in usage, not just in engagement spikes.

The best product teams ship AR as an incremental capability. They start with one reliable use case, observe how users discover it, and improve the flow before expanding into more ambitious spatial features. That approach is safer, easier to maintain, and much more likely to survive the practicalities of actual devices.

---

If you're ready to turn an AR concept into a production-ready Expo feature, AppLighter gives you the app foundation so you can focus on the hard parts that differentiate the experience. Visit AppLighter to build faster, keep your architecture clean, and ship augmented reality features that survive real devices and real users.