Wellness app development sits in an odd regulatory spot. Most consumer wellness apps are not medical devices and are not covered by HIPAA, so founders sometimes assume no health rules apply. Two federal rules still shape what the app may claim and what it must do with the data.
This guide covers the FDA's general wellness policy, which decides whether a feature drifts into device territory, and the FTC Health Breach Notification Rule, which governs what happens when health data leaves the app without the user's permission. It then turns both into product, data and release decisions.
What is wellness app development?
Planning a consumer wellness app?
Agnotic builds iOS, Android and cross-platform wellness apps for founders, with claims review, consent and data flows planned from the first sprint.
Wellness app development is the design and build of consumer apps that track or encourage healthy habits, such as sleep, activity, nutrition, stress or weight, without diagnosing or treating disease. The product decisions that matter most are which claims the app makes and how it collects, shares and protects the health data it holds.
The wording of a single onboarding screen or app store listing can change which rules apply. That is why claims review belongs in product planning, alongside the feature list, rather than in a legal check the week before launch.
When is a wellness app not a medical device?
A wellness app is outside FDA device oversight when its intended use is limited to general wellness and it presents low risk. FDA's guidance General Wellness: Policy for Low Risk Devices, issued on 6 January 2026, uses exactly those two factors to define a general wellness product.
The guidance describes two kinds of general wellness use. The first is maintaining or encouraging a general state of health or a healthy activity, with no reference to a disease, such as weight management, physical fitness, relaxation or sleep management. The second relates healthy lifestyle choices to reducing the risk or impact of certain chronic diseases where that link is well understood and accepted.
Separately, section 520(o)(1)(B) of the Federal Food, Drug, and Cosmetic Act, added by the 21st Century Cures Act, excludes software intended for maintaining or encouraging a healthy lifestyle from the device definition, as long as it is unrelated to diagnosing, curing, mitigating, preventing or treating a disease or condition.
- Likely wellness: "Track your sleep and build a calmer bedtime routine."
- Likely wellness, second category: "Regular activity, as part of a healthy lifestyle, may help reduce the risk of type 2 diabetes."
- Drifts toward device: "Detects sleep apnea from your breathing sounds."
- Drifts toward device: "Adjusts your insulin dose based on today's meals."
The words matter, but so does the function. A feature that alerts a user to a possible arrhythmia is making a disease claim whatever the marketing copy says. When a planned feature sits near the line, review FDA's device software guidance for that function before building it, not after.
Which privacy rule applies to a wellness app?
For a wellness app that is not run by or for a HIPAA covered entity, the main federal health privacy rule is the FTC Health Breach Notification Rule at 16 CFR Part 318. HIPAA usually does not apply, because the app sells directly to consumers rather than acting as a health plan, provider or their business associate.
The FTC rule reaches more apps than many founders expect. In 16 CFR 318.2, health care services or supplies include any website, mobile application or internet-connected device that tracks things like vital signs, fitness, fertility, sleep, mental health or diet. A vendor of personal health records is an entity outside HIPAA that offers or maintains a personal health record, meaning an electronic record that can draw information from multiple sources and is managed primarily for the individual.
In practice, an app that combines data from a phone's health store, a wearable and the user's own entries is likely to meet that multiple-source test. Assume the rule applies unless counsel concludes otherwise.
What counts as a breach under the FTC rule?
Under 16 CFR 318.2, a breach of security is the acquisition of unsecured health information without the individual's authorization, and it expressly includes an unauthorized disclosure, not only a hack. Sending identifiable health data to an analytics or advertising partner without the user's permission can therefore be a breach.
The timing rules are set in 16 CFR 318.4. Notices to affected individuals must go out without unreasonable delay and no later than 60 calendar days after the breach is discovered. When 500 or more people are affected, the FTC must be notified at the same time as the individuals.
- Software development kits: Every third-party SDK in the app is a potential disclosure path. List what each one receives.
- Event names: An analytics event called "logged_migraine" discloses health information even if the payload is empty.
- Advertising identifiers: Linking health events to an advertising ID and sending them out is the pattern regulators have focused on.
- Server logs: Request logs that capture health fields and ship to a third-party logging service are another quiet disclosure.
How should a wellness app handle consent?
A wellness app should ask for consent per purpose, at the moment the purpose arises, and store each decision so the backend can enforce it. One long privacy policy accepted at signup is weak evidence of authorization for a specific disclosure later.
- 1. Map the data: List every health field the app collects, where it is stored and every party that receives any part of it.
- 2. Separate purposes: Running the feature, product analytics, research and marketing are different purposes and need separate choices.
- 3. Ask in context: Request access to sleep or heart data when the user turns on the feature that needs it.
- 4. Record decisions: Store each consent with its version, time and scope, and make the server check it before any outbound call.
- 5. Make withdrawal real: Turning a choice off stops the flow immediately and, where promised, deletes data already shared.
Platform policies add another layer. Apple and Google each set their own conditions for health data read through HealthKit and Health Connect, so read the current policy text for each store before designing the permission screens.
What does the wellness app architecture look like?
A wellness app usually has a mobile client, a backend that stores user data and runs the logic, connectors to device health stores and wearables, and a small set of outbound integrations. The privacy decisions above should be visible in that architecture.
- Mobile client: Reads from the phone's health store with the narrowest permissions, caches little, and encrypts what it keeps.
- Backend: Holds health data in its own store, separate from account, billing and marketing data, with access logged.
- Consent service: A single place that answers "may this data go to this party for this purpose?" for every outbound path.
- Analytics gateway: Strips or generalizes health fields before events leave, and blocks any event type not on an approved list.
- Deletion path: One job that removes a user's data from every store and notifies processors, tested before launch.
This shape also makes a later move into regulated care easier. If the company adds clinician-reviewed programs or partners with a health plan, the separated health store and consent records are the foundation for HIPAA safeguards.
How should a first wellness release be scoped?
A first wellness release should do one habit loop well: capture a signal, give the user a clear view of it, and prompt a small action. Apps that launch with sleep, nutrition, mood and activity all at once usually ship each one thinly and collect more data than they use.
- Core loop: One metric the user cares about, such as sleep consistency or daily steps, with a simple goal and a weekly summary.
- Data sources: Start with the phone's health store, then add one or two wearables whose APIs cover the core metric.
- Engagement: Reminders and streaks tied to the goal, with quiet hours and an easy way to pause them.
- Content: Short, reviewed explainers written within the wellness claims the team has agreed on.
- Measurement: A few product metrics, such as week-four retention, collected through the analytics gateway without raw health values.
Keeping the first release narrow also keeps the claims review and the data map short. Each later feature then gets its own review of wording, data fields and recipients before it ships, which is far cheaper than unwinding a data flow after users have been told about it.
Where do wellness app builds go wrong?
Wellness app builds go wrong when growth tooling is added faster than the data review that should come with it. The patterns below are the ones to check for in any wellness release plan.
- Claims creep: Marketing copy or a new feature starts naming a disease, and nobody revisits the device question.
- SDK sprawl: A new attribution or crash tool is added in a hurry and receives health events by default.
- Consent in name only: The toggle exists in settings, but the backend never reads it.
- No breach playbook: The team cannot say who decides whether an incident is a breach or how 60 days would be met.
- Coaching without guardrails: Free-text chat with coaches or an AI assistant invites users to describe symptoms, and the app has no escalation path.
How Agnotic can help
Agnotic Technologies designs and builds wellness apps for founders and consumer health companies. We map claims and data flows during discovery, build the consent service and analytics gateway into the first release, and integrate HealthKit, Health Connect and wearable APIs with the narrowest permissions each feature needs.
For teams already in market, Agnotic audits the shipped app for outbound health data, removes or gates risky SDK paths, and writes the incident runbook the FTC timelines require.
Ship a wellness app with clean data flows
Start with our mobile app development services, or browse more guides and playbooks.
Related reading on Agnotic
More on mental health apps, women's health tracking, mHealth products and wearables in care.
