The App Store now displays whether an app is a regulated medical device. Apple announced it on 26 March 2026, it covers the European Economic Area, the United Kingdom and the United States, and for new apps it is already a condition of distributing in those regions.
Here is the part that catches teams off guard, and it is the whole reason this post exists. The obligation is not triggered by whether your app is a medical device. It is triggered by your metadata. You have to declare a status if either of the following is true:
- your app's primary or secondary category is Health & Fitness or Medical, or
- your app is marked as containing frequent references to Medical or Treatment Information in the Age Rating questionnaire in App Store Connect.
That is a category-and-age-rating test. Which means a very large number of ordinary workout trackers, meditation apps, habit builders, sleep loggers, period trackers and supplement companions are now required to answer a regulatory question their teams have never asked. If the app is not a regulated medical device, you select No. Getting to the point where you can select No with a straight face is the work.
The deadline that makes this urgent is early 2027. New apps have needed a status since 26 March 2026 in order to distribute in the EEA, UK and US. Existing apps must provide a status by early 2027, and Apple's stated consequence is blunt: if you have not declared by then, you will no longer be able to submit app updates. Not a warning banner, not a demotion in search. No updates, which for a live product means no bug fixes, no new OS compatibility work, and no security patches until you answer.
This post covers what the declaration commits you to, who ends up in each bucket, why the ambiguous middle is the entire story, and the audit to run on your own app before you fill in the form.
Where the declaration happens, and what it asks
The declaration is made in App Store Connect. Apple's notice says apps declaring a regulated medical device status supply relevant regulatory information alongside it, such as contact details and safety information, and it notes that apps of this kind may require registration or authorization from regulatory bodies, such as the U.S. Food and Drug Administration.
Read that second clause carefully, because it is the trapdoor. Declaring Yes is not a checkbox that lights up a badge. It is an assertion that invites the obvious follow-up question — which authorization, in which market, held by whom. A team that declares Yes to look credible, without a regulatory position behind it, has created a worse problem than a team that declared No and needs to tighten its marketing copy.
What already applied, before the label
App stores have never been neutral about health apps, and the labeling mechanism does not replace the existing rules. It makes them visible.
Apple's App Review Guidelines have long carried a dedicated section on medical apps requiring that they be accurate, that apps providing medical or health information handle it responsibly, and that apps which could cause physical harm receive heightened scrutiny. There have also been long-standing requirements around identifying the regulatory clearance an app claims and the entity behind it. A separate section governs health and fitness data, restricting how HealthKit data may be used and prohibiting its use for advertising or sale to data brokers.
Google Play operates a comparable health apps policy, with declaration requirements for certain health features and additional restrictions on sensitive health data and permissions.
What this means practically: if the declaration feels like a new burden, it is usually because the app was already operating outside rules that were being enforced unevenly. Visibility changes enforcement economics. A rule that a reviewer might catch becomes a rule that a competitor, a journalist, or a hospital's procurement team can check in five seconds.
The three buckets — and why the middle one is the story
The declaration is binary, but the population answering it sorts into three positions.
1. Not a medical device. The app's intended use sits inside general wellness or another non-device category. Track your runs, log your meals, guided meditation, workout programming. This is the large majority of consumer health and fitness apps and it is a perfectly good place to be.
2. A regulated device with a regulatory status to point at. The app has been through a premarket pathway in the markets it serves and can name a clearance, approval, or registration. For these products the label is an asset — it is public, verifiable differentiation that a competitor cannot copy with marketing copy.
3. The middle. The app makes claims that sound diagnostic, therapeutic, or clinical, but the company has never made a determination, has never engaged a regulatory consultant, and has been quietly hoping the question does not come up.
Bucket three is where the pressure lands, and it is much larger than people assume. It includes a great many products in symptom checking, mental health, fertility, sleep analysis, blood-pressure and glucose adjacency, dermatology photography, movement assessment, and AI health assistants of every description.
Here is the part that matters: the declaration will not let you stay ambiguous. There is no "it depends" option. It is Yes or No, and whichever you select becomes a statement of record that is inconsistent with something else you have published unless you go and fix it first.
What a declaration actually commits you to
Treat a store-level regulatory declaration the way you would treat a statement in a security questionnaire or a regulatory filing, because functionally it is one.
It is public. Anyone can read it. Including your competitors' marketing teams, plaintiffs' firms, journalists writing about health app safety, and the compliance officer at the hospital evaluating your enterprise tier.
It is a consistency test across everything you have published. If you declare "not a medical device" while your homepage says the app detects a condition, you now have two contradictory public statements about your intended use. Intended use, as we covered in is your wellness app a medical device, is established by exactly this kind of promotional material. The declaration does not create the problem; it makes the contradiction trivially discoverable.
It is durable. Listings are archived, scraped, and screenshotted. "We changed it later" is a weak position.
It is made by a named human at your company. Somebody submits it. Decide deliberately who that is and what they reviewed first.
The correct sequencing is therefore: audit and align everything you publish, then declare. Not the reverse.
The audit to run now
This is a two-to-three-day exercise for a small team. If you ship in the EEA, UK or US under a Health & Fitness or Medical category, it is now on a clock. If you ship elsewhere, do it anyway, because every input to it is something an enterprise buyer will eventually ask about, and because the other stores are unlikely to leave this alone.
1. Inventory every claim you make anywhere
Collect the actual text from: your App Store and Play Store descriptions, subtitle, promotional text, keywords, and screenshot captions; your homepage and every landing page; paid ad copy across channels; your onboarding screens; push notification copy; email sequences; your sales deck; your founders' public talks and podcast appearances; and any AI-generated output your product routinely produces.
Put it in one document. Most teams have never done this and the result is usually uncomfortable — the marketing site and the product are frequently describing two different products.
2. Flag every diagnostic and therapeutic verb
Search the document for: detect, diagnose, screen, identify, monitor for, treat, cure, prevent, reduce risk of, manage, alert, warn, and any named disease or condition. Flag each hit and write next to it what the product literally does.
Distinguish carefully between a metric and an inference about disease. "Shows your overnight heart rate variability" is a metric. "Tells you when your body is fighting something" is an inference. The second is where the trouble lives, and it is usually the sentence the growth team is proudest of.
3. Reconcile marketing to product
Every flagged claim gets one of three dispositions:
- Rewrite it to describe what the product does rather than what condition it addresses. This is the answer for the majority.
- Keep it and own the regulatory position, meaning you have or will pursue an actual regulatory pathway with specialist support.
- Remove the feature, if the feature only makes sense with the claim and you are not pursuing the pathway.
Write the disposition down with a decision owner. This document is the thing you hand to regulatory counsel, and having it prepared converts an open-ended engagement into a scoped one.
4. Audit your AI outputs as claims
If your product has a conversational or generative component, its runtime output is part of what you are declaring about. Assemble an adversarial prompt set — symptom descriptions, medication questions, dosage requests, crisis language, "should I go to the ER" — and run it. Record what the product actually says.
Then build the constraints as tested requirements, not prompt suggestions: refusal and redirect behavior for clinical questions, designed escalation paths for crisis content, and a regression suite that runs every release with results retained. That evidence is both a safety control and documentation of your intent. If you are building anything in mental health or an AI coach, treat this as release-blocking.
5. Check your screenshots and your UI
Store listing screenshots are labeling. A screenshot showing a red "abnormal" badge next to a health metric is a claim, whatever the description text says. So is an in-app screen that presents a value against a clinical reference range without context.
6. Decide who signs
Name the person who makes and submits the declaration, and the evidence they will review first. For a company of any size this should not be whoever happens to have App Store Connect access.
If you run steps one and two and the result worries you, send us the document. Telling you which claims we would rewrite is a short conversation, and it is a better first move than a panicked listing update.
What changes commercially
Two things move, and they move in opposite directions depending on which bucket you are in.
If you are cleared or approved, the label is a moat. For the first time, a real regulatory position becomes visible at the point of consideration rather than buried in a compliance page nobody reads. Products that spent real money on a regulatory pathway have historically had no way to signal it to consumers. That changes.
If you are in the ambiguous middle, the label is a forcing function. Your options compress to: narrow the claims and declare honestly, or fund a regulatory program. The third option — stay vague — stops being available.
There is also a second-order effect worth planning for. Once regulatory status is machine-readable at the listing level, it becomes usable by everyone downstream: enterprise procurement checklists, health-system app formularies, insurer and employer benefit catalogs, comparison sites, and researchers publishing on health app safety. Expect it to become a filter in B2B buying long before it changes consumer behavior.
The corollary is a genuine competitive risk: an unlabeled app sitting next to a labeled competitor in the same search results may read as less credible, even where "not a medical device" is entirely correct and appropriate for the product. The defense is not to acquire a label you do not need — it is to make the rest of your trust surface strong. Published security posture, a clear privacy position, real clinical advisors where you have them, and honest copy about what the product does and does not do. That is the same argument we make on our own trust page, and it works.
The Android and advertising picture
Google Play has its own health apps policy and its own declaration mechanics, and the two platforms have historically diverged in both wording and enforcement. Do not assume a single declaration serves both. Do assume that whatever you tell one platform will be compared to what you told the other.
Advertising platforms are the third front and often the fastest-moving. Meta, Google Ads, and TikTok all restrict health claims and health-related audience targeting, and their automated enforcement acts on the same copy your store listing carries. A claim rewrite driven by a store declaration usually needs to propagate into your ad creative in the same sprint, or you will spend the following month on appeals. We deal with this constantly in claim-safe marketing work — the platforms' rules are the brief, not an obstacle.
What to do if you realize you are in bucket three
Do not panic and do not rewrite everything in an afternoon.
First, stop the bleeding. Pause new ad creative containing flagged claims. That is a same-day action with no engineering cost.
Second, complete the claims inventory described above. You cannot make good decisions without seeing all of it at once.
Third, get a scoped opinion. With the inventory in hand, a regulatory consultant can give you a real read in a fraction of the time an open-ended engagement takes. This is the point at which paying a specialist is obviously worth it.
Fourth, sequence the fixes. Marketing copy is fast. Store listings take a release. In-app copy and UI take a sprint. AI output constraints take longer and need a test suite. Feature removal, if it comes to that, is a product decision with revenue attached. Work backward from early 2027 rather than forward from today, because the last item on that list is a quarter of work and the update lockout does not care why you were late.
Fifth, write down the decision. Whatever position you land on, document who decided, on what basis, and when. If the question is ever revisited by anyone — a regulator, an acquirer, a customer's compliance team — the existence of a reasoned, contemporaneous decision matters a great deal.
If this reads like more work than expected, that is the honest picture. The version of it we run as a paid engagement is the Healthtech & Mental Health MVP Blueprint — $1,999 over seven days, producing the intended-use boundary, the sensitive-data and claims inventory, the clinical dependency map, and the specialist decision points. It is deliberately priced as planning, not consulting, because most teams need the map more than they need an opinion.
Where we stop
We build wellness, fitness, and telehealth products, we map intended-use boundaries and claims during planning, and we build the technical controls that hold a product inside its boundary. We will tell you when a sentence in your marketing copy worries us, and we will decline to build a claim we think crosses the line.
We do not determine whether your product is a regulated medical device, we do not provide regulatory or legal sign-off, and we do not issue certifications of any kind. We will raise the question in week one rather than at submission, and we will tell you plainly when you need a specialist we are not. That boundary is on our trust page and we hold it even when it costs us the engagement.
This article describes Apple's announcement of 26 March 2026 and reflects what was confirmed as of August 2026. It is general information about app store policy and how regulatory status is communicated, not legal or regulatory advice. Confirm current requirements against Apple's own developer documentation and App Store Connect, and engage qualified regulatory counsel before making any determination about your product's status.
Send us your store listing and your homepage copy and tell us what the product actually does. That comparison is where this conversation usefully starts. Get in touch, or see the pricing page for what scoped work costs.
Frequently asked questions
Which apps have to declare a medical device status?
Any app whose primary or secondary category is Health & Fitness or Medical, and any app marked as containing frequent references to Medical or Treatment Information in the Age Rating questionnaire in App Store Connect. The trigger is metadata, not product function, so a large number of apps that are plainly not medical devices still have to answer the question.
What happens if we miss the early 2027 deadline?
Apple's stated consequence for an existing app without a declared status is that you will no longer be able to submit app updates. For a shipping product that means no bug fixes, no new OS compatibility work and no security patches until you declare, so treat it as a release-blocking dependency rather than a compliance chore.
Will my fitness app get labeled as a medical device?
Almost certainly not, if it tracks workouts, logs nutrition, or delivers coaching without disease claims. You will still have to answer, because a Health & Fitness category is enough to trigger the requirement, but the honest answer for most of these products is No. The apps that need to think hard are the ones whose copy uses diagnostic language or names specific conditions.
What if we declare "not a medical device" and we're wrong?
The declaration is a public statement, and being wrong exposes you on two fronts: platform enforcement, which can mean removal, and regulatory exposure, since your own published statements are evidence of intended use. The mitigation is to align every public claim before declaring, and to document the reasoning behind whichever position you take.
Does a label mean the app is safe or accurate?
No. A regulatory-status label tells you which regulatory framework an app sits under, not how well it works. An app can be correctly labeled as not a device and still be poorly built, and a cleared device can still have usability problems. It is a disclosure mechanism, not a quality rating.
Do we need FDA clearance to keep selling our wellness app?
Not if your intended use genuinely sits within general wellness. The realistic outcome for most teams in the ambiguous middle is not a regulatory submission — it is narrowing the marketing claims to match what the product actually does. That is a copy and product decision, and it is far cheaper.
How does this interact with HIPAA?
It does not, directly. Device status and HIPAA are separate questions answering different things: whether your product is regulated as a device, and whether you handle protected health information on behalf of a covered entity. A product can be either, both, or neither. We cover the second question in do fitness and wellness apps need HIPAA compliance.
Does this apply outside the US?
Yes. Apple's declaration requirement covers the European Economic Area, the United Kingdom and the United States. Regulatory frameworks differ across those markets, so a position that is correct in one may not be in another — the EU in particular classifies many software products more strictly than the US does. If you distribute across all three, treat each as its own question rather than assuming one answer travels.
Can Zee Palm handle the declaration for us?
We can help you build the claims inventory, align your copy and UI, and implement the technical controls that keep the product inside its stated boundary. We cannot make the regulatory determination that sits behind the declaration, and we will not pretend otherwise — that belongs to your regulatory counsel.