App Store approval for healthcare apps: 2026 distribution guide

TL;DR

App Store approval for healthcare apps in 2026 is decided by two choices you make before anyone writes code: which entity submits the app, and which of four distribution routes it travels. Both are hard to reverse. Apple reviewed 9,100,620 submissions in 2025 and rejected 2,093,244 of them, a little over 23%, and the safety rules that healthcare teams fear account for the smallest share of those rejections.

• Private distribution does not skip App Review. Custom apps on Apple Business Manager are reviewed against the same guidelines as public ones.
• Moving between private and public distribution requires a new app record and a new submission, so the route is close to permanent.
• A healthcare app should be submitted by the legal entity providing the service, not by an individual developer or by the agency that built it.
• Substance use content is priced by the age rating questionnaire, not by a content ban.

The rejection numbers Apple publishes about itself

Rejection is ordinary. Planning for it is not.

Apple's 2025 App Store Transparency Report puts 9,100,620 submissions through review and 2,093,244 of them out again. The report also breaks rejections down by the guideline section cited, and those figures count citations rather than apps, because one submission can be rejected under several guidelines at once. Performance drew 1,354,418 citations, legal 495,673, design 415,532, business 283,820. Safety, the section holding every rule about medical accuracy and controlled substances, drew 151,159. It is the smallest bucket on the board.

That ordering matters more than it looks. The rule most healthcare founders worry about is the one least likely to catch them. The rules that do catch them are dull: a broken demo login, a placeholder screenshot, a support URL that returns a 404. Apple says over 40% of unresolved issues sit in guideline 2.1, app completeness, and that on average 90% of submissions are reviewed in under a day.

Two more numbers reframe what a rejection costs. 387,087 submissions were approved after an earlier rejection, so a first no is usually a conversation. Of 26,305 appeals against apps already removed, 423 were restored. Fixing before launch is cheap. Reinstatement after removal is not. Apple's year in review adds the detail that stings for a live product: nearly 800,000 of the 2025 rejections were updates to apps already shipping.

The March 2026 rule that can freeze your updates

On March 26, 2026 Apple announced that App Store product pages in the European Economic Area, the United Kingdom and the United States will show whether an app is a regulated medical device, and that developers must declare a status in App Store Connect to distribute there.

The trigger is wider than the category picker. The declaration is required if the app's primary or secondary category is Health & Fitness or Medical, or if the age rating questionnaire marks it as containing frequent references to medical or treatment information. A peer support app for people in recovery, filed under Lifestyle, is caught by the second condition alone.

It already applies to new apps. Existing apps have until early 2027, and an app without a declared status can no longer submit updates after that. For a B2B healthcare product under a support contract, that is a clause in your maintenance agreement you cannot honor.

How we built this guide

Four rules, applied to everything below.

• Every rule about Apple's behavior comes from Apple's published text or published data, linked so you can read it yourself. Opinions are labeled as opinions.
• Every distribution claim is checked against what App Store Connect actually lets you do, not against how the route is marketed.
• Where our own data appears, it is a share of an unnamed base. Any group with fewer than three data points is not published.
• Nothing here predicts an approval. Review outcomes sit with Apple, and a vendor who promises otherwise is selling something they do not control.

One disclosure. Mercury Development sells healthcare app development and handles submissions, so every question here is one you should also put to us. The closest existing guide we found, Momentum's mHealth walkthrough, covers FDA pathways and medical category paperwork and leaves the distribution choice untouched.

The four distribution routes at a glance

Route 1: the public App Store listing

The default, and the right answer more often than nervous healthcare teams assume. Everything Apple builds well sits here: search, ratings, automatic updates, analytics, volume purchase for organizations at no extra effort.

The cost is that your product description becomes a public document, read by reviewers, regulators, competitors and patients who were never the intended audience. Apple also warns on its App Review page that an app may not be approved if it offers little functionality "or only applies to a small niche market", wording aimed at the single-facility tool pushed to the open store.

Choose this route when the app would make sense to a stranger who found it in search.

Route 2: a custom app on Apple Business Manager

Private distribution to organizations you name. You set the distribution method to private in App Store Connect, enter each buyer's Organization ID, and after approval the app appears only inside those organizations' Apple Business Manager accounts, where IT assigns licences to managed devices or to named users.

Two things here are widely misunderstood, and both come from Apple's own documentation. Custom apps go through App Review on every version against the same guidelines as public apps, and Apple needs working credentials to sign in and operate the app. Going private removes your audience, not your reviewer. And switching distribution methods requires a new app record and a fresh submission, which forfeits the ratings, the reviews and the installed base attached to the old one.

What the route buys you is a narrower metadata surface. The description, keywords and screenshots stop being marketing and become documentation for a buyer who already signed.

Route 3: unlisted app distribution

An app published on the App Store that does not appear in search, charts, categories or recommendations. It is reachable only through a direct link, which Apple grants after a separate request on top of the normal submission.

Apple is blunt about the limit, and so should you be with your client. Its own page states that unlisted apps are available to anyone who has access to the link. Hidden is not private, and access control has to live inside the app. For a product handling protected health information, that means authentication built for strangers arriving at the front door, because strangers will.

The route also has a one-way gate. An app already approved for private distribution has to be recreated as a public record before you can request an unlisted link, and there is no documented path back to a full public listing.

Route 4: the Enterprise Program, and why it is rarely yours

The Apple Developer Enterprise Program lets an organization sign builds and hand them to its own staff outside the App Store, with no review at all. It is also the route agencies reach for when a client says the word private, and it is almost always the wrong one.

Eligibility requires a legal entity with 100 or more employees, and use is limited to proprietary in-house apps distributed to that organization's employees. A clinic's patients are not its employees. Neither is your agency's client. Apple restricts the program to cases that public App Store apps, custom apps, Ad Hoc distribution and TestFlight cannot address, and requires applicants to pass a verification interview plus a continuous evaluation process.

Opinion, stated plainly: a vendor proposing enterprise signing so that a hospital can hand an app to patients is planning to fail an audit on your account.

Who submits the app decides more than what the app does

Guideline 5.1.1(ix) is short and it settles the org chart. Apps providing services in highly regulated fields, and Apple names healthcare in the list, should be submitted by the legal entity that provides the service rather than by an individual developer. Apple's App Review page repeats the point under the heading of submission by the wrong entity, and asks for partnership documentation in the attachments when the relationship is not obvious.

In practice that is one rule with two consequences. The clinic or the device maker holds the developer account and appears as the seller, and your development partner works inside that account under a named role. Make the seller name read as the institution behind the care: guideline 5.2.1 expects an app to come from the party that owns or has licensed the rights, and a reviewer checking a medical claim looks at the seller first.

Agencies get this wrong expensively. They publish under their own account to save the client a week of onboarding, then discover that transferring the app later means moving a developer account, signing assets and every subscription attached. Set it up correctly on day one.

Writing the listing for a substance use or recovery app

A belief is widespread in healthcare product teams, and it reduces to roughly one sentence: Apple bans any app that mentions drug use. That is not what the guideline says, and acting on it leads teams to write descriptions so vague that they fail a different rule instead.

Guideline 1.4.3 in the App Review Guidelines bars apps that "encourage consumption of tobacco and vape products, illegal drugs" or excessive alcohol, and separately bars facilitating the sale of controlled substances outside licensed pharmacies and legal dispensaries. Encouragement is the test. A relapse prevention tool, a craving tracker or a peer support community does the opposite of encouraging, and the guideline has room for all of them.

The real cost lands somewhere most teams never look. Apple's age rating questionnaire asks how frequently your app references alcohol, tobacco or drug use. Answer frequent, which is the honest answer for a recovery product, and on the scale Apple applies from iOS 26 onward the app is rated 18+, the same tier as real money gambling. Answer frequent to medical or treatment information and you land at 16+. Infrequent on either one lands at 13+. None of this is a rejection. All of it feeds the parental controls and the content restrictions an administrator sets on managed devices, which is a real problem in a treatment facility handing out iPads.

There is outside evidence that the App Store treats this content differently. A content analysis published in 2025 in Addiction Science & Clinical Practice scraped both stores for opioid recovery apps and found 41.3% of the iOS apps restricted to users 17 and older against 8.8% on Google Play. Read that with two caveats: the sample was collected in 2022, and the 17+ tier it refers to has since been replaced by the current scale. The same study found one product published as 53 separate variants with identical descriptions, each named for a different treatment center, which is the pattern guideline 4.3 treats as spam.

So write the listing like a clinician. Name the population and the clinical purpose. Describe what the app helps a person do rather than what it helps them stop. Keep the sharpest clinical language inside the authenticated product, where the reviewer still sees it through the demo account you provide.

Which route fits your situation

Four routes is a short list. Sequence it by who is allowed to see the product.

One health system, one contract, devices they manage. Custom app through Apple Business Manager. The metadata stops being public, the reviewer still checks the build, and their IT team gets the deployment model they already run.

Patients enrolled at a treatment facility, private release intended. Custom app again, and resist the pull toward a public listing for reach. A public page for a facility-scoped product invites the niche market objection and puts clinical language in front of an audience it was never written for.

Franchisees, study sites or partners you cannot list in advance. Unlisted distribution, with authentication inside the app and a written note that the link is not a security control.

A product patients should find on their own. Public listing, submitted by the clinical entity, clearance documents attached, medical device status declared.

What our healthcare records show about distribution

These are our own observations, from our own delivery records, and the group is narrow on purpose. We looked at healthcare engagements where the recorded material names an intended distribution path for an iOS app. Any group with fewer than three data points is not published.

Around 50% of them were scoped to named organizations rather than to an open listing: hospitals and nursing facilities buying in volume, patients enrolled at a treatment facility, study sites licensed to a principal investigator. The rest went to a public page.

Two patterns sit under that split, and both are uncomfortable for our side of the table. In each engagement where App Store review appeared as a named delivery risk, the risk was raised by us rather than by the buyer. And in none of them was the risk a feature. It was language: how the product described its own purpose in a field the store reads as regulated. The rework that follows is a rewrite of the listing and the screenshots, landing after the build is finished and the launch date is promised to a board.

Review subjectivity is real, and it is not what stops you

Apple does not hide the judgment call. The guidelines say Apple will reject content it believes crosses a line, then answer the obvious follow-up by borrowing a Supreme Court Justice's remark about recognizing such things on sight. The same document calls itself living and warns that new apps may produce new rules at any time. That is an honest description of a curated store, and an admission that two reviewers can read the same healthcare app differently.

Here is where we part company with the complaint. Subjectivity is a variance problem, and variance is survivable when the median case is strong. What kills healthcare projects is not the reviewer who read your craving tracker oddly. It is the team that discovered in week eighteen that the clinic could not be the seller, that the private route needed a different app record, and that the description had to be rewritten by someone who understood both the clinical protocol and guideline 1.4.3.

All of that is knowable in week one. Pick the entity, pick the route, write the listing early and put it in front of whoever will defend it. Then let the review be subjective, because subjective now costs days rather than a rebuild. Mercury Development has shipped to Apple's stores since 1999, including HIPAA work like the claims system running for a medical billing firm since 2006, and the pattern holds: the store punishes late decisions, not brave ones.

Written by Rob Devereaux, Chief Operating Officer at Mercury Development. Rob has run the firm's operations from Hudson, Ohio since 2019 and has over 20 years of operational and financial experience. The delivery records behind this article's distribution findings sit in the operations he oversees.

Built the app and still undecided about the route? Send us the listing draft

Tell us what the product does, who is meant to install it, and which organizations are involved. We come back in writing with the route we would take, the wording we would change in your listing, and the evidence to attach in App Store Connect before you submit anything.