Custom Smartwatch OS: Data Residency and App Store Review
A white-label wearable app looks like a branding exercise until the first store review. The reviewer is not assessing your logo; they are assessing what the app collects, where it goes, what the privacy policy says about it, and whether the account deletion path exists at all. Because the factory builds the client and the cloud endpoints you specify, the answers belong to your entity, not to the manufacturer. The practical work is deciding those answers before the firmware is frozen, because changing a hosting region after a build is a re-release, not a setting.
Decide the hosting region before the app is written
Hosting region is the first question a European reviewer asks indirectly and a data-processing agreement asks directly. If your users are in Germany, France or the Netherlands, a cloud endpoint in another jurisdiction changes the transfer analysis, the sub-processor list and sometimes the retention schedule. The factory can point the app at the region you nominate; it cannot nominate one for you. Bring the region, the sub-processor list and the retention period to the kick-off, and treat them as part of the specification alongside screen flows. The same discipline applies across the AI wearables line, where the app is often the only user-facing surface.
What the reviewer actually opens
A reviewer works from the build, the listing and the policy. They check that the privacy policy is reachable inside the app, that it names the categories of data collected rather than a generic clause, and that the permission prompts match the declared use. Health and wellness data is a sensitive category in most store policies, so the wording matters: metrics are wellness guidance, never diagnosis, and the app should say so in the same words the packaging uses. Translation features must be described as a reference translation, never as certified, legal or medical output. If the app pairs with a companion robot, it must not claim to monitor, detect falls or contact an emergency service.
The documents that travel with the hardware
App review and hardware conformity are separate tracks that meet at the same revision number. The factory issues documents per model and hardware revision, not per product family, and the app build should be tied to the same revision so a reviewer's test unit matches the paperwork. Where the app depends on radio behaviour, the CE RED file is the reference point; the CE RED document checklist lists what a buyer should expect to receive. Toy scope is decided by the age grading printed on the packaging and booked with an accredited laboratory per build, which matters if the same app serves a children's SKU.
| Reviewer or DPA question | What satisfies it | Who owns it |
|---|---|---|
| Where is user data stored? | Named hosting region and sub-processor list in the DPA | Brand |
| Is the privacy policy in-app? | Reachable policy naming data categories and retention | Brand |
| Can a user delete the account? | In-app deletion path, plus a web route for non-installed users | Brand |
| Do permissions match use? | Prompt text aligned to declared purpose in the listing | Brand and factory |
| Is the build tied to a hardware revision? | Revision number on app build and conformity file | Factory |
| Is distribution licensed? | Google Play / GMS is not licensed by default; decide the route early | Brand |
Where the importer carries the duty
EU and UK importer duties sit with the importer: WEEE, BattG, DEEE/Triman registration, EORI and VAT. None of that transfers to a Shenzhen factory, and no supplier should imply otherwise. The same boundary applies to the app: the factory can implement a deletion flow, but the obligation to provide one is yours. A buyer who wants the supplier to hold the registration is buying a different commercial model, and should say so at quotation rather than at delivery. This is a reasonable place to say no to a supplier who offers to "handle GDPR" as a line item.
- Fix the hosting region, sub-processor list and retention period before the app build starts.
- Tie the app build number to the hardware revision named in the conformity file.
- Write the privacy policy around the data categories the app actually collects.
- Describe health metrics as wellness guidance and translation as reference output.
- Confirm the distribution route, since Google Play and GMS are not licensed by default.
- Keep importer registrations, EORI and VAT in your own name.
Sequencing a white-label programme
App and firmware white-label starts at 2,000 units, which usually sets the programme's shape: a first run on an existing hardware platform, then a custom smartwatch OS build once volumes justify it. Sampling runs 3-5 days for stock and 7-15 days configured, with sample cost credited against mass production, and production runs 25-35 days. The MOQ, sampling and lead times page sets out the thresholds per category, including 500 units standard, 300 for AI glasses and 1,000 for ring, education and companion models. If your first SKU is a ring, the smart health ring and the smart ring with charging case show the two enclosure routes. For wrist devices, compare the health smartwatch against the GPS sport watch, since sensor set and app permissions differ by platform. OEM/ODM services covers how a custom OS build is scoped, and how we build and test explains the IQC, IPQC, FQC and OQC gates at AQL 2.5 major and 4.0 minor.
Start by writing the two documents the reviewer will ask for: a privacy policy that names your hosting region and data categories, and a data-processing agreement with your sub-processor list attached. Send both to the factory with your target revision and volume, and ask for a written statement of which parts the build covers and which remain yours. That single exchange removes most of the ambiguity before tooling or firmware work begins.
Questions buyers ask
Can WingPhoenix ship a white-label wearable app under our brand?
Yes, app and firmware white-label starts at 2,000 units, and the app is built to your account, your hosting region and your privacy policy. Google Play and GMS are not licensed by default, so the distribution route has to be decided before the build, not after.
Who is the data controller for the app?
You are. The factory builds the client and the cloud endpoints you specify; the processing agreement, the hosting region and the store listing sit with your entity. That is also why the reviewer questions land on you rather than on the manufacturer.
Related: more on ai wearables · buyer guides · customisation tiers