12 October 2026 · 3 min read
AR Smart Glasses Reference Designs: What Still Needs OEM Custom Development?
After Cellid's October 12 Snapdragon START announcement, learn what an AR reference platform does and which firmware, app and third-party interfaces an OEM buyer must define.
An AR reference design can provide a starting point for hardware development. It does not automatically deliver a brand's custom HUD, companion app, AI backend or connection to a watch. Those functions require defined interfaces, permissions, software ownership and acceptance tests.
On October 12, 2026, Cellid announced that it had joined Qualcomm Technologies' Snapdragon START program to develop AR reference designs. Its company-issued release describes Crux as a binocular full-color reference design powered by Snapdragon AR1+ Gen 1 and plans demonstrations at the October 13–15 Augmented Enterprise Summit. As of this October 12 review, the planned event demonstrations have not occurred. Cellid's original announcement.
The sourcing implication is that hardware platforms and ecosystem support can reduce some development work while leaving the customer's application scope to be engineered. Future Audio does not claim membership of Snapdragon START or use of Cellid's Crux optics. Our Cue platforms are separate references with their own documented specifications and integration requirements.
What is included in a hardware reference?
A reference may include optics, a camera, microphones, speakers, processing, wireless connectivity and baseline software. Buyers should request the exact board and optical revision, available sample, tooling status, supported interfaces and documentation. A processor name or product rendering does not establish access to every sensor or the ability to run a customer's AI model locally.
Future Audio's Cue One and Cue Air are documented camera-free monochrome waveguide references. Cue Pro combines a documented camera, microphones, stereo audio and green waveguide in a project platform. Final hardware, appearance, software access and sample readiness require project review. These are not equivalent to a full-color Crux reference design.
Which parts need customization for your project?
| Layer | Requirement to define | Evidence before approval |
|---|---|---|
| Hardware and optics | Camera, display, fit, lens arrangement, controls and power budget | Exact sample and documented configuration |
| Firmware | Capture controls, display commands, sensor events and update behavior | Agreed interfaces and a working demonstration |
| Companion app | Pairing, permissions, screen content, video transfer and user controls | Test build on required phone systems |
| AI or business backend | Inputs, service endpoint, response format and data retention | End-to-end workflow and service-region checks |
| Third-party devices | Required fields, permissions, transport and licensing | Approved interface and supported-device test |
Hardware and optics
- Requirement to define
- Camera, display, fit, lens arrangement, controls and power budget
- Evidence before approval
- Exact sample and documented configuration
Firmware
- Requirement to define
- Capture controls, display commands, sensor events and update behavior
- Evidence before approval
- Agreed interfaces and a working demonstration
Companion app
- Requirement to define
- Pairing, permissions, screen content, video transfer and user controls
- Evidence before approval
- Test build on required phone systems
AI or business backend
- Requirement to define
- Inputs, service endpoint, response format and data retention
- Evidence before approval
- End-to-end workflow and service-region checks
Third-party devices
- Requirement to define
- Required fields, permissions, transport and licensing
- Evidence before approval
- Approved interface and supported-device test
The buyer may own software development or commission it as part of an agreed scope. Camera/audio SDKs and display interfaces should be assessed separately. SDK access does not automatically include firmware source code, unrestricted raw microphone access or ownership of third-party software.
How would a running HUD differ from a reference display?
A running display needs defined metrics, units, refresh rate, latency and disconnect behavior. Begin with simulated pace, distance and heart-rate screens to verify the display path. Then validate the approved source of live data. A camera/display board does not measure every running metric by itself.
Garmin distinguishes cloud data APIs from real-time device SDK pathways. Apple documents workout sessions and watch-to-phone mirroring. Actual compatibility still depends on supported watches, permission, session behavior and the selected software architecture. A phone's access to historical workout records is not proof of live HUD delivery. Garmin developer overview and Apple workout documentation.
Running video adds another workload. Define continuous recording or short clips, timestamp synchronization, transfer timing, storage and stabilization. Test HUD, recording and audio together for runtime and heat. Microphone-array noise reduction should be distinguished from tested wind performance. A proposed sports exterior also requires engineering assessment of optical positioning, grip, sweat exposure and internal packaging.
What should the first OEM quotation cover?
Separate evaluation hardware, firmware work, app development, third-party integration, mechanical changes, tooling, validation and certification. Identify deliverables, acceptance tests, maintenance and intellectual-property terms. A ready tool does not establish a ready custom app.
Future Audio can review an existing platform as the hardware starting point and scope firmware and app changes around your intended workflow. The standard production reference MOQ is 1,000 units; sample and pilot quantities, costs and lead times are quoted separately. Bring example HUD screens, priority metrics, target devices and the desired user experience to an integration discussion or sample review.