How to Build Your First AR App for XREAL Air 3: A Developer's Step-by-Step Guide to the XREAL SDK 2026

Shipping an AR app for XREAL glasses comes down to two decisions made early: which SDK stack fits your project, and how those glasses slot into the Android and Unity pipeline you already use. For most Unity developers, that means picking between XREAL's proprietary NRSDK and the broader OpenXR route, then building a scene around the device's spatial features, performance limits, and store requirements.

One honest caveat before we dive in. Some "XREAL Air 3 in 2026" details circulating in developer communities are still speculative. Hardware specs, exact SDK versions, and store branding all need verification against official releases. This guide covers what exists and works today, flags what remains unconfirmed, and points you to the right source of truth throughout: the XREAL developer portal and the XREAL Unity getting-started guide.

---

1. XREAL Developer Ecosystem Overview: NRSDK, OpenXR, and Anticipated 2026 Updates

XREAL's development ecosystem gives you two primary paths.

NRSDK is XREAL's proprietary SDK. It supports the XREAL Light and Air series and exposes the platform's spatial features directly—spatial anchors, plane detection, image tracking, and hand tracking. If you want tight integration with the hardware, this is the lane.

OpenXR is the industry-standard API layer for cross-platform XR work. It trades some XREAL-specific depth for portability. If your roadmap includes other headsets, or you want a more future-proof abstraction, OpenXR is worth the setup cost.

In practice, the choice is a scope question more than a technical one.

Option	Best for	Strengths	Trade-offs
NRSDK	XREAL-first apps	Device-specific features, tighter integration, mature AR feature set	Less portable outside XREAL
OpenXR	Multi-platform XR apps	Broader compatibility, standard API	May not expose every XREAL-specific feature
Hybrid	Teams targeting both	Flexible architecture, device-specific enhancements where needed	More integration work upfront

The XREAL developer portal is the source of truth for current SDKs, docs, samples, and release notes. If you are building for XREAL Air 3 specifically, treat any "2026 SDK update" as provisional until XREAL publishes hardware and software documentation for that device.

How to choose

Use this decision rule and stick to it.

Choose NRSDK if your app depends on XREAL's camera pipelines, plane detection, spatial anchors, or hand tracking, and your users are primarily on XREAL hardware. Choose OpenXR if your product roadmap spans multiple headsets or you want a standard abstraction layer for future migration. Choose both only if you can maintain a shared interaction core and separate device adapters—this adds work, but it pays off for teams building a platform rather than a single app.

For a first app, NRSDK usually wins. It lowers friction and lets you focus on scene setup and spatial behavior rather than cross-platform abstraction. If the app might expand beyond XREAL later, design the rendering and interaction logic so it can be swapped without rewriting the scene from scratch.

If spatial computing is new territory for you, the article What is Spatial Computing? Understanding the Next Computing Paradigm is a good place to orient yourself before writing your first line of AR code.

A practical rule: when your app depends on XREAL's camera, plane, anchor, or hand workflows, start with NRSDK. When it is mostly UI, media playback, or generic 3D interaction, OpenXR may be enough.

---

2. Environment Setup: Unity Version, Package Import, and Device Pairing for XREAL Air 3

Setup should feel routine. Repeatable pipelines, not fragile prototypes—that is the goal.

For current XREAL development, Unity 2021 LTS and Unity 2022 LTS are the safest starting points. Exact Air 3 support needs confirmation from official documentation once the hardware and SDK land. If you are starting today, pick an LTS release, not a tech stream build. Tech stream versions move fast and break things that matter.

Recommended setup checklist

Item	Recommended approach
Unity version	Unity 2021 LTS or 2022 LTS—confirm for Air 3 when official docs arrive
SDK import	.unitypackage today; watch for UPM (Unity Package Manager) support
Target platform	Android
Host device	Compatible Android phone or dedicated compute unit, if required by Air 3
Debugging	USB-C connection plus ADB (Android Debug Bridge) workflow
Minimum permissions	CAMERA, INTERNET, ACCESS_WIFI_STATE

Importing NRSDK into Unity

The current import workflow is straightforward.

1. Create a new Unity project using an LTS version.
2. Switch the build target to Android under Build Settings.
3. Import the NRSDK .unitypackage from the XREAL developer portal.
4. Follow the XREAL setup guide to configure the required XR settings—the package may automate some of this.
5. Add the XREAL camera rig and required manager components to the scene.

If a future version ships through UPM, the workflow will simplify further. For now, assume a package import flow unless XREAL documents otherwise.

Pairing and debugging the device

XREAL Air series development uses a USB-C connection and standard Android debugging tools. ADB still matters here.

1. Enable developer options on the Android host device. You do this by tapping the build number in device settings seven times.
2. Turn on USB debugging within the developer options menu.
3. Connect the host device and glasses with a supported USB-C cable.
4. Run adb devices in your terminal and confirm the device appears.
5. Build and deploy from Unity.

The exact pairing procedure for XREAL Air 3 depends on final hardware requirements. Treat all device-specific steps as provisional until XREAL publishes them.

AndroidManifest basics

These permissions cover the baseline for an AR app:

<uses-permission android:name="android.permission.CAMERA" />
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />

You will likely need additional permissions depending on your feature set—voice input, location, or account services each require their own declarations—but this set gets you through the initial build.

Copy-paste startup checklist

1. Install Unity 2021 LTS or 2022 LTS
2. Create a new Android project
3. Import NRSDK
4. Add required XREAL prefabs to the scene
5. Set Android permissions in the manifest
6. Connect the host device over USB-C
7. Confirm ADB recognition with: adb devices
8. Build and run

For the canonical setup reference, use the XREAL Unity getting-started guide. If you are completely new to Unity, the article Getting Started with Unity for AR Development: A Beginner's Guide covers foundational concepts worth reading before you configure any XR settings.

---

3. Building Your First Scene: Spatial Anchors, Plane Detection, and AR Object Placement

Your first scene has one job: prove three things work together.

1. The device renders correctly into the AR view.
2. The app detects real-world surfaces.
3. The app places content on those surfaces and keeps it there.

Everything else—voice, AI, polish—comes after those three are solid.

Core scene components

XREAL's Unity workflow starts with the NRCameraRig prefab. Think of it as the scene's entry point. It manages camera views and sensor data, and it gives the spatial stack a home. Without it, nothing else locates itself correctly in physical space.

Component	Purpose
NRCameraRig	Main XR entry point—camera and sensor management
NRPlaneDetector	Detects horizontal and vertical surfaces
NRAnchor / spatial anchor API	Persists content in physical space across sessions
PC Simulator	Allows iteration without physical hardware nearby

Build your first scene

Start with a cube on a table. Seriously. A cube on a table proves everything that matters.

1. Add NRCameraRig to the scene.
2. Add NRPlaneDetector as a component.
3. Create a 3D object—a Unity primitive cube works fine.
4. Write a placement script that raycasts against detected plane data.
5. Instantiate the object at the raycast hit point.
6. Attach an anchor if you need the object to persist across sessions.

A minimal placement script looks like this:

using UnityEngine;

public class PlaceOnPlane : MonoBehaviour
{
    public GameObject prefab;

    public void Place(Vector3 position, Quaternion rotation)
    {
        Instantiate(prefab, position, rotation);
    }
}

This is intentionally stripped down. In a real app, you wire this to plane detection results and user input—a tap, a gaze trigger, or a controller event. But the core placement logic does not get more complicated than this.

Plane detection and object placement

NRPlaneDetector is how your app understands real-world geometry. Horizontal planes—tables, floors, desks—are the typical first target because they are plentiful and predictable. Vertical detection opens up walls, whiteboards, and anchored panels.

Once you detect a plane, decide how the content should behave:

Mode	Behavior	Best use cases
World-locked	Object is fixed in the physical environment	Anchors, maps, tools, persistent AR overlays
Head-locked	Object is fixed relative to the user's view	HUDs, menus, notifications, status panels

This distinction matters more than most first-time AR developers expect. A head-locked menu always stays accessible but can feel intrusive. A world-locked guide sits naturally on a surface but requires the user to walk toward it. Match the mode to the content's purpose, not just what is technically easier to implement.

Spatial anchors and persistence

If your app needs virtual objects to survive a restart, spatial anchors are the mechanism. NRAnchor (or the spatial anchor API, depending on your NRSDK version) keeps content tied to a physical-world position across sessions.

A common pattern:

1. Place an object on a detected plane.
2. Attach an anchor and save the anchor ID or spatial reference.
3. On next launch, query for saved anchors.
4. Restore the object in the same location.

Anchors matter most for collaborative tools, persistent annotations, and room-scale experiences where users return repeatedly. For a first app, skip anchors until placement and detection are working cleanly. Add persistence as a second pass.

Use the simulator early and often

I cannot overstate how much time the NRSDK PC simulator saves. You can iterate on scene layout, UI flow, interaction logic, and anchor creation without waiting for a full device deploy cycle every time.

Use the simulator to test:

• Scene loading and startup behavior
• UI navigation and readability
• Basic interaction logic
• Anchor creation and retrieval
• Content layout and scale

Then move to the physical device for real-world validation—lighting conditions, depth perception, and tracking behavior all feel different on actual hardware. But catch the obvious bugs in the simulator first.

Prototype the interaction before chasing spatial accuracy. If the app feels right in the simulator, you are already most of the way to a shippable experience.

For implementation details and working code examples, the XREAL Unity getting-started guide remains the best reference.

---

4. Integrating AI Features: Voice Commands and On-Device LLM Hooks (Exploring XREAL's AI Roadmap)

XREAL has discussed AI and LLM directions publicly, but a dedicated "XREAL AI Layer" API does not appear in verified current documentation. Do not build your architecture around a named XREAL AI SDK unless you see it in official release notes. This section covers what you can build now, not what might exist later.

Voice commands: the fastest AI feature to ship

Android gives you a working voice path through SpeechRecognizer (Android's native speech recognition API) without any external dependency. That is the fastest way to add hands-free input to an AR app.

Approach	Pros	Cons
Android SpeechRecognizer	Native, fast to prototype	Android-specific, limited customization
Wit.ai or similar cloud service	Easy integration, flexible	Requires network access
Whisper-based integration	Strong accuracy	Higher latency or compute cost

A minimal viable voice feature for an AR app does not need to be sophisticated. Commands like "place cube," "move left," "show menu," and "take screenshot" cover most hands-free use cases without forcing a heavy AI stack into the app. Build the simple version first. Add sophistication only if users ask for it.

On-device LLM options

Local inference is possible when the host Android device's SoC (System-on-Chip, the integrated processor that handles compute) supports it. MediaPipe LLM Inference and Qualcomm AI Engine are current examples of on-device inference frameworks. Which one applies depends entirely on the chipset in the host device.

Design for graceful fallback:

1. Check device capability at runtime.
2. Run on-device inference if supported.
3. Fall back to a cloud API if the network is available.
4. Fall back to simple command-based UI if neither is viable.

Users on lower-end devices should not hit a broken experience because the app assumed a Snapdragon 8 Elite.

Cloud LLMs: the practical starting point

For most teams, REST-based cloud APIs are the fastest route to sophisticated AI behavior. OpenAI and Google Gemini APIs both work inside a Unity Android app through standard HTTP requests.

Good AR use cases for cloud LLMs:

• Conversational assistants that respond to what the user sees
• Contextual help for spatial tools
• Object labeling and identification
• Summarizing notes pinned in physical space
• Generating captions for real-world items

AI in AR should reduce friction, not create it. Avoid long, slow, text-heavy interactions that block the core spatial experience. The user is standing in a room. Keep the response fast and relevant to what is in front of them.

Keep the AI claim honest

Until XREAL publishes a verified AI API, frame AI as an integration layer you own and control—through Android, cloud services, or device-specific runtimes. That keeps your product realistic, your architecture clean, and your technical claims defensible when developers ask how it works.

For broader context on where this technology is heading, the article The Future of On-Device AI in AR Glasses covers the landscape well.

---

5. Publishing Your App: From Development to the XREAL Ecosystem

XREAL Space—previously called Nebula—is XREAL's primary app distribution platform for the Air series. If you want to publish, start with a developer account at developer.xreal.com.

Submission checklist

Requirement	What to expect
Developer account	Required before submission
Android API level	Must match current platform requirements—confirm at submission time
App icon assets	Required in multiple sizes
Privacy policy	A public URL is required
Content rating	Likely a self-rating workflow, similar to IARC
Package validation	App must run correctly on supported devices

The 2026 store branding should be verified against official XREAL materials closer to that date. Right now, XREAL Space is the confirmed name. Revenue share terms are not publicly documented in current research—do not state specific percentages without direct verification from XREAL.

What reviewers actually look at

AR store review differs from standard mobile app review. An app can pass basic Android validation and still fail because it creates a poor glasses experience. Expect reviewers to check:

• Launch reliability across cold starts
• Headset compatibility on supported hardware
• Input handling and responsiveness
• Text readability in the glasses' optical system
• Frame stability under real-world conditions
• Permission prompt clarity
• Privacy policy completeness

Write your privacy policy before you start the submission process, not after. If you use camera access, voice input, analytics, cloud AI, or account services, explain each one in plain language. Reviewers read these.

Monetization models

Familiar business models apply here:

• Paid download
• Freemium with unlockable features
• Subscription service
• One-time in-app purchases

Do not assume a specific revenue share split until XREAL publishes it. Those numbers are unconfirmed in available research.

Submission order that works

1. Finalize Android build settings and confirm API level.
2. Test on the target host device—not just the simulator.
3. Verify every permission prompt shows the correct rationale.
4. Measure startup time and frame stability under sustained load.
5. Prepare store assets: icons, screenshots, description.
6. Publish and link the privacy policy.
7. Complete all developer portal requirements.
8. Submit and monitor the feedback queue.

Store assets for AR apps

Generic app-store screenshot conventions do not translate well to AR glasses apps. Your screenshots and preview images should show:

• Spatial content sitting convincingly in a real-world environment
• Text that is readable at glasses resolution
• A real indoor environment, not a white studio render
• The interaction model—how does the user actually drive this thing?
• A clear value proposition visible in under ten seconds

Reviewers and users both need to understand immediately that this is not a flat-screen app. Show the glasses context. Show the spatial depth. Show something they have not seen on a phone screen.

---

6. Common Pitfalls and Performance Optimization for XREAL Air 3

XREAL Air 3 hardware specs are not fully confirmed in public documentation at time of writing. Treat performance targets as provisional. That said, AR glasses apps demand aggressive optimization regardless of the specific numbers, and a 90Hz-class display—if that spec holds for Air 3—implies roughly an 11ms frame budget. That is tight. Most Unity scenes are not built to hit that target without deliberate work.

Top performance risks

Risk	Why it hurts
Too many draw calls	Drops frame rate quickly—batching is essential
Excessive overdraw	Wastes GPU time on transparent layers
Real-time global illumination	Heavy on mobile hardware, rarely worth the cost
Large texture memory	Increases load times and thermal pressure
Poor anchor and object management	Causes jitter and tracking instability
Background processes on the host device	Steals CPU and GPU headroom from your app

Optimize for stereo rendering

If the device supports Single-Pass Stereo Rendering (a technique that renders both eye views in a single GPU pass rather than two sequential passes), enable it. It cuts draw calls roughly in half for stereo output. This is one of the highest-leverage optimizations in XR development and costs almost nothing to enable if the driver supports it.

Beyond that:

• Reduce overdraw by simplifying UI layer composition.
• Bake lighting rather than running real-time global illumination.
• Limit transparent materials—they stack overdraw fast.
• Use low-overhead materials and simple shaders where possible.
• Pool frequently instantiated objects instead of creating and destroying them at runtime.

Thermal and battery reality

Here is something that surprises developers coming from flat-screen mobile: the glasses themselves are relatively passive. The thermal load lives in the host Android device. That phone is running the compute, powering the USB-C bus, and managing all your app logic simultaneously.

Practical implications:

• Monitor CPU and GPU temperatures on the host device, not just frame rate.
• Test under real-use conditions—20-minute continuous sessions, not two-minute bursts.
• Keep CPU-intensive AI inference or heavy networking off the main render thread.
• Expect throttling to appear during sustained use, especially in warm environments.

Battery drain is similarly driven by the host device and the power delivery overhead to the glasses. For apps targeting longer sessions, recommend an external battery pack or compatible power setup in your documentation.

Debugging toolkit

Use multiple tools in sequence. Unity logs alone will not find the frame budget problems that matter.

Tool	What it shows
Unity Profiler	Frame timing, CPU and GPU bottlenecks, memory allocation
Android Logcat	Runtime errors and device-level logs
Android GPU Inspector	GPU timing, shader performance, draw call analysis
NRSDK diagnostics	XREAL-specific tracking and sensor signals

A reliable debugging routine:

1. Profile in Unity Editor to catch obvious bottlenecks.
2. Reproduce on device—some issues only appear on real hardware.
3. Inspect Logcat for errors that do not surface in the editor.
4. Run Android GPU Inspector to find shader or draw call problems.
5. Confirm the rendering mode is configured correctly.
6. Validate anchor behavior and plane detection stability.
7. Run a thermal stress test—sustained load for 20+ minutes.

Pre-ship performance checklist

Before you submit, work through this list and answer honestly:

• Does the app hold frame time under sustained load, not just idle?
• Does it survive 20 minutes without significant throttling on the target host device?
• Are transparent UI elements controlled and not stacking overdraw?
• Is text readable in typical indoor lighting, including bright environments?
• Does the app recover gracefully if spatial tracking degrades or is lost?
• Is battery drain acceptable for the session length your use case requires?

If the answer is no to any of these, cut content until the behavior is correct. AR users have less tolerance for frame drops and jitter than flat-screen users do. An unstable AR experience is uncomfortable in a way that a stuttering video is not—the mismatch between the virtual and physical world creates genuine discomfort. Comfort is not a nice-to-have. It is a core product requirement.

For hardware context on how XREAL has approached developer-facing devices previously, the article XREAL Air 2 Ultra Review: A Deep Dive for Developers gives useful grounding before Air 3 details are confirmed.

---

Final Thoughts

Building your first XREAL app is not the complicated part. The hard part is making it feel effortless on a glasses display—readable, stable, spatially coherent, and fast enough that the hardware disappears.

Start with NRSDK if you want the most direct path into XREAL's spatial features. Start with OpenXR if portability matters from day one. Either way, begin with a plane, a cube, and an anchor. Get those three things working correctly on the device before adding voice, AI, or store-ready polish.

Stay honest about unconfirmed hardware details. Build against current official documentation. Ship something that behaves well before you ship something that looks ambitious.

The XREAL developer portal and the XREAL Unity getting-started guide are your authoritative references throughout. Everything else—including this guide—is a starting point, not a substitute.