The short answer

Check six things: the package contains arm64 binaries, the build is a native arm64 binary not an x86 translation, it targets the headset OS/SDK, its graphics API matches the headset GPU and drivers, the input and UI adapt to near-eye use, and you verify with a demo or device logs. Only when all checks pass can you expect native local use.

Time needed about two hours, spread over two sessions

Key takeaways
  • An ARM binary is necessary but not sufficient; graphics API and driver mismatches commonly break XR rendering or features.
  • Store labels rarely show ABI, SDK level or exact graphics backend; inspect APK/IPA metadata or release artifacts instead.
  • UX problems — tiny UI, wrong input mapping, narrow field of view — are the most common reasons an app is unusable on glasses.
  • Ask developers for a signed arm64 test build or device logs before buying; a 10–15 minute demo is the best proof.
  • Treat streaming as a fallback only for casual use; latency and controller mapping often break fast games and tight productivity workflows.
Before you start
  • The exact headset model and firmware channel you intend to buy or test (for example Apple Vision Pro, XREAL Air 2 Ultra, Ray-Ban Meta).
  • The app package or a link to its release artifacts, or permission to request a signed test build from the developer.
  • A desktop with adb for Android logs or access to macOS/device console tools to inspect IPAs and device logs.
  • An account on the store the app is published in to read release notes and region availability.
  • A short list of must-have interactions you need the app to support (for example hand-tracking, controller input, full-screen virtual monitor).

The steps

  1. Identify the headset modelNote the exact headset model and the firmware channel you will buy or test.You should see: You have the model and firmware channel written down and ready to reference.
  2. Open the headset support pageOpen the vendor's developer or device support page for that exact model.You should see: You see GPU, OS and driver notes or links to SDK and driver documentation on the vendor site.
  3. Obtain the app package or release notesDownload the APK/AAB/IPA or locate the app's GitHub/releases or official release notes.You should see: You have a local APK/IPA or a release page that mentions architectures, SDKs or headset support.
  4. Inspect the binary for arm64Open the APK/IPA: unzip the APK and check lib/ for arm64-v8a, or request lipo/file output for an IPA.You should see: You see a lib/arm64-v8a folder or Mach-O arm64 slice in the inspection output.
  5. Confirm OS and SDK targetsCheck the Android manifest (uses-sdk/targetSdkVersion) or release notes for OpenXR, ARCore or visionOS mentions.You should see: You find explicit SDK or platform mentions indicating the app targets XR-capable APIs or the headset vendor SDK.
  6. Verify graphics API compatibilitySearch code or release notes for Vulkan, OpenGL ES, Metal or required extensions and compare them to the headset GPU documents.You should see: You find a clear match or a documented mismatch between the app's APIs and the headset's supported APIs.
  7. Test input and UI fitRequest a demo build or use a vendor streaming/demo path to check controller/hand-tracking, UI scaling and legibility inside the headset.You should see: The app accepts input correctly and UI elements are legible and reachable within the headset’s virtual screen and FOV.
  8. Collect logs or performance numbersRun the app on device or during the developer's demo while collecting adb logcat (Android) or device logs (visionOS) and note frame-times.You should see: Logs show successful GPU initialization and frame timing without repeated GL/Vulkan/Metal errors or crashes.
  9. Decide using the rule of thumbDecide to buy only if the app passed binary, OS, graphics and UX checks or if you accept a streaming fallback.You should see: You can state yes or no backed by files, logs or a working demo rather than assumptions.

Check if apps run on ARM XR headsets

To verify an app will run natively on an ARM XR headset, run six concrete checks: binary architecture, native vs emulated build, OS/SDK target, graphics API and driver match, input/UI fit for near-eye displays, and a working demo or device logs. Each check rules out a different way an app can fail on a headset.

  • Confirm the package contains arm64 binaries (APK lib/arm64-v8a or IPA Mach-O arm64).
  • Confirm the build is native arm64 and not an x86 app relying on a translation layer.
  • Confirm the app targets the headset OS or an officially supported XR SDK level.
  • Confirm the app’s graphics API (Vulkan/OpenGL ES/Metal) matches the headset GPU and driver features.
  • Confirm input and UI: controller or hand-tracking support, UI scaling, and field-of-view usability.
  • Validate with a signed demo build, a remote demo session, or device logs showing successful GPU init and input.

Confirm binary architecture and native build

Open the app package and verify it contains arm64 artifacts. Seeing arm64 slices means the app includes an ARM binary and may run natively; absence of arm64 implies the store may deliver an emulated or incompatible build.

On Android, unzip the APK or extract the app bundle and inspect the lib/ folder for arm64-v8a. On visionOS/iOS, check for Mach-O arm64 slices or ask the developer for lipo -info or file output that shows arm64.

Confirm the app targets the headset OS and required SDK

Check the app targets an XR-capable platform and SDK. An app built only for phone UI will often misbehave on glasses because it does not use headset input hooks or XR APIs.

On Android, inspect the manifest for uses-sdk and targetSdkVersion and look for OpenXR, ARCore or vendor SDK flags. On visionOS, check the App Store listing or release notes for a stated visionOS target. If the developer lists specific headset models or SDKs, treat that as a positive signal.

Check GPU, graphics API and driver compatibility

An ARM binary that calls an unsupported graphics API or driver feature will run poorly or crash. Identify the app’s graphics backend and compare it to the headset GPU and the vendor’s driver notes.

Look for mentions of Vulkan, OpenGL ES, Metal or required extensions in release notes, build files or native libraries. Then check the headset’s developer/device page for supported APIs and driver capabilities to confirm a match.

Check input, UI scaling and field of view

An app can run perfectly and still be unusable in XR. Verify controller mapping, hand-tracking support and whether the UI scales and reflows for a near-eye display and the headset’s field of view.

Ask whether the app maps controllers to actions, supports the headset’s hand-tracking gestures, and provides large enough UI elements for the virtual screen. If the app is 2D, preview it in a streaming/demo view to judge legibility before assuming it will be usable.

Obtain demos, logs and developer proof

The single most reliable proof is a signed demo build that runs on the target headset or logs showing a successful launch and GPU initialization. Request a test APK/IPA for your device or an adb logcat/device log that shows GL/Vulkan or Metal initialization and steady frame timing.

Use vendor demos and community reports as corroboration. Our /apps directory, the Nebula app listing at /apps/xreal-nebula and a quick run through /articles/10-minute-smart-glasses-test help you reproduce a short demo before buying.

Acceptable fallbacks and a buying rule of thumb

Fallbacks exist but each has clear trade-offs. Streaming preserves app functionality but adds latency and input mapping issues; sideloading can work but may be blocked by vendor policies; emulation often reduces frame-rate or strips features.

Rule of thumb: buy for an app only if it passes the binary, OS, graphics and UX checks, or if you accept the known compromises of a streaming fallback. If the app is central and it fails any core check, delay purchase until native support is available.

Why this process fails and the common failure sequence

The usual failure sequence starts with assuming an 'ARM build' equals a working app. Typical outcomes: the app crashes from a missing native library; it renders incorrectly because the driver lacks required features; or it runs but is unusable due to tiny UI or unmapped inputs.

People skip graphics/API and UX checks because they look at architecture only; that leads to chasing frame-rate problems or owning a headset that technically runs the app but cannot perform the intended task.

Sources and further reading

Where this usually goes wrong

  • App installs but crashes immediately on launchMissing native libraries or wrong ABI (for example x86 slices only) causing load failures.Request an arm64 build from the developer or inspect logs for 'UnsatisfiedLinkError' or equivalent to confirm missing libs.
  • App launches but rendering is broken or frames drop heavilyGraphics API or driver feature mismatch where the required Vulkan/OpenGL features are not present.Check the headset's driver notes and ask the developer whether they can add a fallback renderer or reduce GPU requirements.
  • App runs but UI elements are tiny, unreachable or controls are unmappedNo headset-specific UI scaling or input mapping; the app expects phone touch or mouse input.Ask the developer for a headset-adapted UI, or use a tested streaming solution as a temporary fallback while pushing for a native XR UI.
  • App works but latency makes interactions unusableUsing a streaming fallback with insufficient network or high encode/decode latency.Test the streaming path in your network environment; reduce resolution/bitrate or use a lower-latency link, or insist on a native build.

The checklist

  • Identify the headset model
  • Open the headset support page
  • Obtain the app package or release notes
  • Inspect the binary for arm64
  • Confirm OS and SDK targets
  • Verify graphics API compatibility
  • Test input and UI fit
  • Collect logs or performance numbers
  • Decide using the rule of thumb

Frequently asked questions

Can I rely on a Play Store or App Store 'ARM' label?

No. Store labels do not show whether the delivered binary is native arm64, which graphics API the app uses, or which SDK level it targets. Inspect the APK/IPA metadata, check release artifacts or ask the developer for an arm64 build or device logs.

What if an app has no native ARM build and the developer won't provide one?

Treat streaming or PC-hosted rendering as a fallback for casual use only. Streaming adds latency and input mapping challenges that often break fast games and precision workflows; if the app is critical, wait for an official native build or documented vendor support.

How do I ask a developer for proof the app works on my headset?

Ask for a signed arm64 test APK/IPA that runs on your exact headset model or for adb logcat/device logs showing successful GL/Vulkan or Metal initialization. Also ask whether the app targets OpenXR, ARCore, or visionOS SDKs and whether controller and hand-tracking are implemented.

Are there tools I can use to inspect APK/IPA files myself?

Yes. Unzip an APK and list the lib/ folder to see arm64-v8a entries. For IPAs, use lipo or file on macOS to show Mach-O slices. If you prefer not to run tools yourself, ask the developer for a short text file that proves the binary contains arm64 slices.

Find apps that work on your glasses

Every app in the directory lists the glasses it runs on, how it works on each, and the official source that proves it.

Browse the app directory