Why software is part of the product
A pair of audio glasses with no app still runs firmware: it decides touch gestures, volume steps, the noise reduction mode, the pairing behaviour and how the battery is managed. Most models also come with a companion app for the equalizer, controls, assistant or translation features, and firmware updates. For AI, translation and camera glasses, the app does much of the work. So when a customer says the product is bad, the cause is often software - a connection drop after an update, a touch strip that triggers by mistake, an app that will not log in - rather than hardware.
For a brand, that means the app and firmware need the same scrutiny as the frame and the battery. The questions are practical and best asked before the first sample rather than after the first customer review: who owns and maintains the app, what can be branded, how updates reach customers, what data is collected, and how long support lasts.
Three app models and what they mean for a brand
| Arrangement | What the buyer gets | Typical route | Watch-outs |
|---|---|---|---|
| Partner plant's public app | Ready app under the plant or solution provider's name | Catalog models, 50-500 pairs per model | Branding outside your control; app may change or be withdrawn |
| White-label app | Same app core with your name, icon, colours and store listing | Logo programs from 500-1,000 pairs or as agreed | Who publishes in the app stores, who answers reviews, update schedule |
| Custom app or SDK integration | Your own app built on a firmware interface | Full custom OEM/ODM from 3,000 pairs per model | Development time, documentation quality, long-term maintenance |
No arrangement is right for every buyer. A marketplace seller starting with a catalog model may accept the public app; a brand owner building a long-term line usually wants a white-label or custom app so that reviews, data handling and the store listing belong to the brand. Developer-focused programs with open interfaces such as BLE GATT are covered on developer smart glasses.
The buyer checklist
- Ownership. Who owns the app, the store accounts and the source code or configuration? What happens if the solution provider stops maintaining it?
- Branding scope. Which screens, texts, icons and voice prompts can carry your brand? Are voice prompts available in the languages of your markets?
- Feature list per firmware. Which features are in the firmware version you will ship: multipoint, equalizer, touch customization, assistant, translation? Record the version number on the spec sheet.
- Translation and AI terms. Languages and quality depend on the app and translation engine; typical cloud latency is 0.5-3 seconds per network and language pair. Which engine is used, and which features need a network?
- Updates. How are over-the-air updates delivered, tested and rolled back? Can an update be paused for a batch?
- Data and permissions. Which permissions does the app request, where is data processed, and what is in the privacy notice?
- Support period. How long will the app be maintained for new phone operating system versions? Write it into the agreement.
Firmware updates: the risk and the controls
Over-the-air updates are valuable because they fix connection issues, tune sound and add features after launch. They also carry risk: an update that fails halfway, runs on a low battery or ships with a regression can leave pairs unusable or change behaviour customers liked. Good programs control this in a few ways. Updates require a minimum battery level and keep a fallback image; each release is tested on the phones your customers use before release; release notes go to the brand before customers see them; and the firmware version on each shipped batch is recorded so that inspection can confirm it. Firmware stability and OTA are standard items in the test plan, with pass criteria confirmed per order. Typical failure patterns are discussed in firmware update failures.
Cybersecurity and data rules
In the EU, the cybersecurity requirements of the Radio Equipment Directive under Article 3(3)(d), (e) and (f) apply since 1 August 2025. Delegated Regulation (EU) 2022/30 names glasses among wearable radio equipment, and the harmonised standards are EN 18031-1, -2 and -3. In practice this touches the firmware and the app: secure update mechanisms, protection of personal data, sensible default settings and no default passwords. From 11 December 2027 these requirements move under the Cyber Resilience Act. For camera models, the European Data Protection Board statement of October 2026 - guidance rather than law - expects the recording indicator LED to work as designed and recording to be blocked when the indicator is covered, which is partly a firmware question. Details are in RED cybersecurity and EN 18031; confirm the scope with your test lab and counsel.
Data handling is also a listing and support question. Customers ask whether the app needs an account, what is recorded and whether voice data is stored. A short, accurate answer in the listing and the user guide saves support time and builds trust.
Distributors and retailers carrying several regions should also ask whether one app build serves all markets or whether regional builds exist, because app store availability, language packs and translation engines can differ by country. Enterprise buyers who deploy fleets of glasses - tour operators, event teams, field crews - usually want a way to hold firmware at a tested version across all units and to manage pairing centrally, which is a feature to confirm in writing rather than assume. The same applies to spare and replacement units: a warranty swap should arrive on the same firmware version as the fleet it joins.
Checking app and firmware on samples
When samples arrive, test the app with the phones your customers use: install, pair, update firmware, use every feature on the spec sheet and uninstall. Note the firmware version, app version and any permission requests. Repeat the check on the golden sample, and agree that the shipped firmware version matches it. White-label apps add time for store review, so plan it in parallel with batch production, which typically runs 20-35 days for catalog and logo programs and 45-75 days for full custom OEM, excluding certification queues. Reference ranges are confirmed in writing per program on MOQ and lead time. To brief an app or firmware requirement, use the quote form.