What closed testing involves
Closed testing is a private release track used to validate builds with real users before they reach the public store listing. Testers install the app through an invitation rather than a public link, use it as they normally would, and report anything that breaks. The point is coverage of real devices and real routines — the failures that matter are the ones that only appear on a specific phone, a specific timezone or a specific way of scheduling doses.
Testers are not asked to follow a script. The most valuable reports have come from people simply using the app for their own protocol and noticing when something behaved differently than expected.
What we ask of testers, and what you get
The ask is modest: install the build, use it for your normal tracking, and report anything wrong with enough detail to reproduce it — device, what you did, what happened, and what you expected. Reminder delivery is the single most useful area to exercise, because it depends on operating-system behavior that cannot be fully simulated.
In return, testers get the features before general release and direct influence over what gets fixed first. Several of the app's scheduling behaviors exist in their current form because a tester pointed out that the original design broke for their routine.
- Install through the invitation, then use the app for your own protocol
- Report device, steps, expected result and actual result
- Reminder and notification issues are the highest-value reports
- Test data stays in your own account and is never published
Privacy during testing
Test builds use the same production privacy rules as the public app: your logs belong to your account, they are not shared with other testers, and nothing you enter is used as example content anywhere. Crash reports carry technical context about the failure, not the contents of your health records.
You can leave the program at any time and keep your account and your history; leaving the test track only changes which build you receive.