Require two independent, model- and region-specific proofs before trusting an app: (1) an official compatibility or store listing naming your exact device, country and minimum firmware/OS build, and (2) a through-the‑lens demo or an installable package built for that exact device/OS. Treat claims without both as unverified.
Time needed about two hours, spread over one day
- Marketing that says “works with smart glasses” is not proof; require the exact model, region and minimum firmware.
- Two independent proofs—an official listing that names your model/region and a through‑the‑lens demo or device-specific package—are the practical minimum.
- Companion (phone) apps and native headset apps behave differently; verify where the code runs for your use case.
- Region and firmware differences are the most common reasons an app won’t run even when marketed broadly.
- If a developer refuses a demo or device build, treat the app as unverified and insist on a documented trial or refund policy before buying.
- Glasses powered on and paired to your phone or companion app with access to Settings/Device Info.
- A browser signed into an app store account set to your country or the vendor store account used for the headset.
- Ability to capture screenshots or a 30–90 second through‑the‑lens video from the headset or phone.
- The exact model string, SKU/variant and firmware/OS build copied or photographed from your device.
The steps
- Record exact model and firmwareOpen headset Settings or the vendor pairing app, go to About/Device Info and copy or screenshot the Model, SKU/variant, Firmware/OS build and Serial number.You should see: A screenshot or copied text file showing Model, SKU/variant and the Firmware/OS build string.
- Search the vendor compatibility page or storeOpen the headset’s official app store or vendor compatibility page while signed into your country account and look for the app listing that names your exact model.You should see: The listing displays your exact model string or SKU and lists your country among supported regions.
- Check the app listing for headset screenshotsInspect the app store listing for in‑headset screenshots, headset UI examples or explicit version/build notes that match your firmware.You should see: You see screenshots captured inside the headset or an explicit note showing supported firmware/build numbers.
- Request or locate a through‑the‑lens demoIf the listing is ambiguous, ask the developer for a 30–90 second through‑the‑lens demo recorded on your specific model or find one linked on the vendor page or directory.You should see: A short video clearly showing the app’s in‑headset UI running on the same model or SKU you own, with the About screen or build visible where possible.
- Inspect package metadata or request a device buildIf offered an installable, check its metadata or ask the developer to confirm it targets your headset OS/build and CPU architecture.You should see: Package metadata or developer confirmation states the target headset OS/build and CPU architecture that match your device.
- Confirm native vs companionRead the listing and support docs to determine where the code runs; look for headset screenshots and package targets versus phone screenshots and streaming language.You should see: A clear statement on the listing or docs that the app runs on the headset or that it requires a companion phone.
- Verify region and account requirementsEnsure the app is visible from an account set to your country and check whether pairing to a phone account or vendor account is required.You should see: The app listing appears when viewed from your country account and any account/pairing requirements are documented.
- Request a trial, demo session or refund policyIf proofs are partial, ask the developer for a scheduled remote demo, short trial instructions or a documented refund/trial policy before you buy.You should see: You receive a scheduled demo time, trial instructions or a written refund/trial policy.
- Install and run the app safelyInstall the app from the official store or the provided installable, launch it on the headset, exercise the feature you need and record a short through‑the‑lens clip showing the working UI.You should see: The app launches on the headset, the in‑headset UI appears and the feature behaves as in the demo; you have a recording with timestamps.
How to check if an app will run on your exact glasses
Require two independent, model- and region-specific proofs before you accept a compatibility claim. First, an official compatibility page or store listing that names your exact model, country and minimum firmware/OS build. Second, either a through‑the‑lens demo recorded on that model or an installable package built for that device/OS. Both are needed.
- Minimum acceptable proof: official listing plus through‑the‑lens demo or device-specific installable.
- Weak evidence: family-level marketing, phone-only screenshots, or claims that omit firmware or region.
Identify your exact model and firmware before you begin
Record the exact model string, SKU/variant, and the headset OS or firmware build before you check compatibility. Device family names are not specific enough because availability and builds vary by SKU and region. Capture the exact text as a screenshot or copied string so you can show it to support or developers.
- Find Model, SKU/variant, Firmware/OS build and Serial in Settings > About or the vendor pairing app.
- Note region‑locked or carrier/enterprise SKUs; they often have different app availability.
Which proofs actually count and how to prioritise them
Prioritise evidence that explicitly names your model, country and minimum build. The strongest proof is an official compatibility page or headset app store listing that matches your exact strings plus a through‑the‑lens demo made on that model. Next strongest is a device-targeted installable whose metadata names the headset OS and architecture.
- Tier 1: Official compatibility/store listing naming your model and country, plus a through‑the‑lens demo on that model.
- Tier 2: Downloadable package (APK or equivalent) with metadata targeting your headset OS/build and CPU architecture.
- Tier 3: Support emails that reference your exact model and build but provide no demo or installable.
- Not proof: generic “works with smart glasses”, phone screenshots, or family-level lists without models.
What a through‑the‑lens demo must show
A valid through‑the‑lens demo is a short recording made through the headset that shows the in‑headset UI running on the claimed model. It must make the device model visible or include the About screen, show the UI and controls you need, and include a visible build/version or a unique feature tied to that app version.
- Minimum elements: visible in‑headset UI, clear indication of the device model, and the feature you care about being used.
- Ask for a 30–90 second unmodified clip; staged or composited footage is suspect.
How to tell if an app is companion-only or native to the headset
Check whether the app runs on the headset or only on a phone. Native headset apps list the headset as the supported device, include in‑headset screenshots and target the headset OS in metadata. Companion apps show phone screenshots, list phone OS requirements, or say they stream from a phone. Choose based on whether you need offline or low‑latency operation.
- Signs it’s native: headset screenshots, headset store listing, or package metadata targeting headset OS.
- Signs it’s companion: phone screenshots, listing only in phone app stores, or text saying “requires companion app”.
- If you need headset-hosted features (for example offline AR overlays), a companion-only app is not acceptable.
Check region, store visibility and OS requirements
App availability can vary by country, vendor store and firmware build. View the vendor store while signed into an account set to your country and inspect the app listing for supported regions and minimum firmware or OS build. If the listing is absent for your country, ask support to confirm availability for your model and SKU.
- Use an account set to your country; screenshots from other countries are not proof.
- Confirm whether pairing to a phone account or a specific vendor account is required.
- Ask for the exact minimum firmware/OS build string; vague “latest firmware” answers are not helpful.
If you can’t verify support, escalate before you buy
If you lack both a model-specific listing and a through‑the‑lens demo or installable, ask the developer for a timed demo, device-specific installable or beta access, and a documented trial or refund policy before you buy. Open a ticket that includes your exact model, firmware build and country so responses are specific and testable.
- Request a 30–90 second demo recorded on your exact model or a test build targeting your firmware.
- Insist on a written trial or refund policy if the developer won’t demonstrate support.
- Use GlassesApps to compare claims and find device‑specific listings in our directory via /apps.
Why verification commonly fails and the usual sequence
Typical failure follows a pattern: marketing lists broad compatibility, you buy, the app is visible only on the phone or in another region, support asks you to update firmware, and you discover the required OS build is not available for your SKU. Recording model and firmware upfront shortens support cycles and proves mismatches quickly.
- Red flags after purchase: app missing in headset store, phone-style UI in headset, or crashes tied to older firmware.
- Capture model and firmware before purchase so you can show the exact mismatch to support.
Safe testing steps after purchase
Install only from the official store or a developer-provided installable and test the exact feature you need. Confirm the app launches on the headset, the in‑headset UI appears, and the inputs work. Avoid jailbreaking or sideloading unsigned builds unless the vendor provides written instructions and a rollback method.
- Collect reproducible evidence: exact error messages, screenshots or through‑the‑lens recordings, firmware build and timestamps.
- If asked to sideload, get written instructions and a clear rollback plan; prefer official store installs.
Where this usually goes wrong
- The app is visible on your phone but not in the headset storeThe app is a companion-only build or is region-restricted and not published for your headset/region.Confirm whether the app is companion-only; if not, ask the developer to publish for your region or provide a demo or installable for your model.
- The app installs but shows a phone-style UI or missing featuresYou installed a companion build or a generic package that lacks the native headset UI.Request a headset-specific build or an update; if the vendor won’t provide one, treat the app as unsupported for your use case.
- App crashes or behaves incorrectly after installFirmware/OS build mismatch or unsupported CPU architecture.Capture firmware/OS build, a through‑the‑lens recording of the crash and timestamps; send them to developer support and ask whether a patch or compatible build is available.
- Developer claims support but refuses a demo or test buildMarketing-led claim without engineering support or a policy preventing demos.Insist on a documented trial or refund policy in writing before buying. If none exists, treat the app as unverified.
The checklist
- Record exact model and firmware
- Search the vendor compatibility page or store
- Check the app listing for headset screenshots
- Request or locate a through‑the‑lens demo
- Inspect package metadata or request a device build
- Confirm whether the app is native or companion
- Verify region and account requirements
- Request a trial, demo session or refund policy
- Install and run the app safely
Frequently asked questions
What if the app lists my device family but not my exact model?
Treat family-level listings as unverified. Vendors often bundle several SKUs under one family name while firmware and availability differ. Ask the developer or vendor to confirm the exact SKU and firmware build they support, and request a through‑the‑lens demo recorded on your specific model.
Can I rely on a developer email saying the app works on my glasses?
Not by itself. A support email must reference your exact model and firmware build to be useful. Prefer emails that include a link to an installable package or a scheduled demo; vague assurances without device details are unreliable.
How do I check an APK or package to see if it targets my headset OS?
Inspect the package metadata and manifest for target SDKs, device features and supported CPU architectures. If you can’t read manifests, ask the developer to state the targeted headset OS/build and architecture in plain language. Metadata that names the headset OS is stronger evidence than a generic phone APK.
Is a companion app ever sufficient?
Yes, when your use case tolerates phone-hosted execution, for example a remote control. Companion apps are not sufficient for features that must run on the headset itself, such as offline AR overlays or low-latency navigation. Decide whether you need native execution and verify the app type accordingly.
Where can I find device-specific app proof quickly?
Start with the vendor app store and the developer’s compatibility docs. Use GlassesApps to look up device-specific listings and through‑the‑lens demos via /apps. If the directory entry lacks required proofs, request them from the developer before purchasing.
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.