TL;DR
- Yawell ring projects use the QRing companion app path on the public site. A2C glasses use HeyCyan. Do not mix names.
- App work has three discussion paths: existing companion app, white-label, fully custom. None is automatic with logo packaging.
- Freeze store account ownership, SDK/API scope, data roles, and maintenance in the project agreement.
App Scope Is a Separate Commercial Line
Buyers often put “white-label app” next to “logo on box.” Factories price and schedule them differently.
Yawell’s public App/SDK page frames software as a review process: branding, interface access, data ownership, server deployment, and release responsibility depend on hardware, data flow, markets, and the agreement (App/SDK customization).
Three Paths
Software industry guides describe the same trade-off buyers see on wearables: white-label is usually faster and cheaper with limited uniqueness; custom costs more time and money when you need differentiated UX, data flows, and integrations (white-label vs custom app development explainers such as daily.dev).
| Path | Typical discussion | Decision gate |
|---|---|---|
| Existing companion app | Use the platform app with the selected product | Model compatibility, markets, launch needs |
| White-label app | Brand identity, store assets, configuration, maintenance | Engineering review against the existing app and hardware branch |
| Fully custom app | UX, data flow, backend, integrations, release ownership | Separate scope, schedule, and commercial review |
Pick the smallest path that meets the brief. Expanding later is normal; assuming full custom in a private-label quote is how timelines break.
SDK, API, and Integration Review Topics
Public review topics include:
- SDK/API purpose, platforms, fields, docs, auth, versioning
- Data ownership for project data, app assets, accounts, export
- Server deployment regions and operational ownership
- Firmware vs app vs cloud boundary for each feature
- Store accounts, signing, privacy materials, acceptance, maintenance
- NDA and IP for custom assets
If you need raw sensor streams or your own cloud, say so in the first RFQ. Do not discover the gap at sample sign-off.
Data Ownership and Market Rules
Under GDPR terminology, a controller decides the purposes and means of processing personal data; a processor processes personal data on behalf of a controller (GDPR secondary explainers such as processor glossaries). Wearable compliance guides stress contracts, purpose limitation, and vendor roles when apps handle wellness data (GDPR wearable tech overviews). This is not legal advice: put roles, residency, and deletion/export rules in the project agreement.
For EU users and other strict regimes, handshake ownership is not enough for diligence.
Keep health language wellness-bounded and source-bound on the product side. App copy can create the same regulatory risk as hardware packaging (buyer checklist).
What to Put in the RFQ
- Product line and model candidates (rings = QRing path).
- App path: existing / white-label / custom.
- Target OS versions and store countries.
- Must-have data fields or SDK use cases.
- Preferred hosting regions.
- Who will own the developer accounts.
- Maintenance window expectations after launch.
Common Mistakes
- Assuming private label includes white-label app.
- Mixing HeyCyan requirements into a ring project.
- Leaving store-account ownership blank.
- Requesting “medical” app claims without regulatory scope.
- Changing app path after golden sample without requote.
FAQ
1. Can every ring model support the same SDK?
Not automatically. Confirm against the selected hardware branch.
2. Who publishes the app?
Whoever the contract names. Write it before development starts.
3. Is white-label cheaper than custom?
Usually yes in time and scope, if the existing app can meet the product story.
Next Step
Send app path, markets, and account-ownership preference with your hardware shortlist.
Discuss App and SDK integration or open the App/SDK page. Related: customization layers, OEM/ODM service.