Your Clinic's App: Getting It Approved, and Every Update After That

Apple's published pages describe more than one lawful way to get a clinic's branded app onto the App Store. The advice circulating in the aesthetics market says one of those routes is closed. The sentence everyone quotes for that is not an Apple publication.

The received wisdom runs like this: healthcare apps must be submitted by the clinic itself, so your software vendor cannot publish for you, and a permission letter will not save you. The guideline that supposedly says this says something narrower. The rejection text that supposedly proves it was pasted into a developer forum by a third party in April 2024.

Approval is also the smaller half of the problem. The rules that govern every update after launch are where a clinic app quietly dies, and four of them carry dates between January 2026 and early 2027.

This post quotes the guideline text, names the document each line comes from, prints the two Apple statements that point in opposite directions, and sets out what both stores publish about updates.

Every source on this page was read on 19 August 2026. We make med spa software, so we have an obvious interest in how clinic apps get published and updated. The guideline text and platform deadlines below hold regardless of whose software you run them in.

What guideline 5.1.1(ix) actually says about healthcare apps

The App Store Review Guidelines page states Last Updated: June 8, 2026. Guideline 5.1.1(ix) reads: "Apps that provide services in highly regulated fields (such as banking and financial services, healthcare, gambling, legal cannabis use, air travel and crypto exchanges) or that require sensitive user information should be submitted by a legal entity that provides the services, and not by an individual developer."

Three things get lost in retelling. Healthcare is named, so a clinic app is in scope. The verb is "should", not "must". And the contrast is between a legal entity and an individual developer. The word agency does not appear, and neither does vendor. A software company is itself a legal entity.

The entity question gets teeth at enrollment instead. Apple's enrollment page states that Apple does "not accept DBAs, fictitious business names, trade names, or branches", and that "your organization's name will be displayed as the seller name of your apps on the App Store". The seller name is public, and it is what connects enrollment to the rejection pattern below.

Guideline 4.2.6 and the shared binary Apple names as acceptable

Guideline 4.2.6 is the rule that actually constrains vendor-built apps. It states that apps "created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content", and that such services "should not submit apps on behalf of their clients".

Most write-ups stop there. The guideline does not. Its next sentence names an alternative: "Another acceptable option for template providers is to create a single binary to host all client content in an aggregated or 'picker' model, for example as a restaurant finder app with separate customized entries or pages for each client restaurant."

Apple's text therefore describes two compliant shapes. One clinic, one app, submitted by the clinic's legal entity. Or one app published by the platform provider, with each clinic as an entry inside it. The failure mode 4.2.6 targets is many near identical binaries filed from one account, not vendor-built software as such.

Apple tells you to attach authorization. A 2024 forum post says it will not help.

Apple's App Review page carries a section called "Avoiding common issues". One item, "Submitted by incorrect entity", reads in part: "If you need to provide partnership documentation or authorization, attach the files in the Attachment section in App Store Connect and provide any descriptions or links in the Review Notes field." That is Apple, on Apple's site, inviting authorization documentation as part of the fix.

Against it sits the text the market quotes. It appears in Apple Developer Forums thread 750018, created in April 2024 by a third-party developer posting as jis248, who pasted a private App Review rejection. That rejection says the app "must be published under a seller and company name that is associated with the organization or company providing the services", and adds: "Please note that you cannot resolve this issue with documentation showing permission to publish this app on behalf of the content owner or institution."

Two points about that quotation. It is a private rejection reproduced by a developer, not a policy Apple published. And the underlying facts were a seller name mismatch, an account named for one orthopedic business submitting an app branded as another, which is a different situation from a vendor filing under an authorization it discloses up front.

The two sources point in different directions and we are not picking between them. If your app is submitted by anyone other than the clinic named in it, expect the seller name question, and expect to answer it in the Attachment and Review Notes fields Apple names.

What Google Play requires of the account that publishes your app

Google's Play Console Requirements policy, section 1.2, places "Health apps, such as Medical apps and Human Subjects Research apps" among developers who "must register as an Organization". That sets the account type, Organization rather than Personal. It does not say which organization. We read the current policy and the July 2026 preview article in full and found no published Google requirement that the publishing organization be the healthcare provider itself.

Whether a booking and loyalty app is a health app at all is not settled by Google's own text. Its health app categories page defines Medical apps as apps "developed by a healthcare provider (such as a HIPAA covered entity) or similar institution", listing electronic health records, patient portals, telehealth and symptom checkers. We found no published Google rule assigning appointment booking or clinic loyalty apps to any of those categories, read on 19 August 2026.

The table sets out what each store publishes about accounts, review inputs and timing, in the store's own language.

Read the timing row precisely. Apple's figure is an average, it counts submissions reviewed rather than approved, and Apple publishes no measurement window. Google publishes no headline percentage at all, only an outer bound with two hedges attached.

The demo access row surprises clinics. A booking app holds real client records, so handing App Review a live login is rarely acceptable, and Apple's demo mode alternative requires prior approval. Start that conversation before you submit. Apple separately publishes an expedited path for "extenuating circumstances, such as fixing a critical bug", with no published grant rate and no turnaround commitment.

Apple publishes the issues to avoid before you submit

The old Common App Rejections page now redirects to Apple's App Review page. What exists today is the "Avoiding common issues" section, introduced as: "We've highlighted some of the most common issues to help you better prepare before submitting for review." Apple lists fourteen items and does not rank them. It publishes one number alongside them: "On average, over 40% of unresolved issues are related to guideline 2.1: App Completeness." That is a share of unresolved issues, not of rejections, with no published measurement window.

The table maps Apple's items, in Apple's published order, to the artifact a clinic has to produce. The left column is Apple's. The right column is ours.

Three of the fourteen are the ones Apple itself names as covered by guideline 2.1, where it says over 40% of unresolved issues land: crashes, placeholder content and incomplete information. Apple's sentence ends with "and more", so treat that list as open rather than closed. All three are fixable before you hit submit, and so is a broken link.

The last row is the only one specific to this industry. Settle the seller name question at enrollment, not at submission, because the seller name follows whichever entity holds the developer account.

Privacy policy, purpose strings and account deletion

Guideline 5.1.1(i) requires a privacy policy link in App Store Connect metadata and inside the app, and requires the policy to do three things clearly and explicitly: identify "what data, if any, the app/service collects, how it collects that data, and all uses of that data"; confirm third parties given the data "will provide the same or equal protection of user data"; and "explain its data retention/deletion policies and describe how a user can revoke consent and/or request deletion of the user's data".

Guideline 5.1.1(ii) adds: "Ensure your purpose strings clearly and completely describe your use of the data." Apple's App Review page repeats that all apps accessing user data are required to include a purpose string.

Guideline 5.1.1(v) is the one clinics discover late: "If your app supports account creation, you must also offer account deletion within the app." That is a hard must, unlike the should in 5.1.1(ix). Deletion has to coexist with whatever medical record retention your state requires. Work out the split before review, not during it.

How a client pays for a treatment booked in the app

Guideline 3.1.3(e) states: "If your app enables people to purchase physical goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase to collect those payments, such as Apple Pay or traditional credit card entry." A facial or a filler appointment is consumed in your treatment room, so it sits on that side of the line.

The boundary matters. Guideline 3.1.1 states that to open features or functionality within the app, including subscriptions and access to premium content, "you must use in-app purchase". A membership entitling a client to treatments in your clinic is a different product from one that opens content inside the app, and the two land under different guidelines.

On steering, a carve-out changes the answer for a US audience. Guideline 3.1.3 says apps in that section cannot encourage users toward another purchasing method, "except for apps on the United States storefront and as set forth in 3.1.1(a) and 3.1.3(a)". Guideline 3.1.1(a) confirms the prohibition on buttons and external links applies in all storefronts "except for the United States storefront, where this prohibition does not apply". Our breakdown of what a custom med spa app costs covers the money side this post leaves alone.

Four dated requirements between January 2026 and early 2027

Four platform changes carry dates, each with a published consequence in the platform's own words.

Take the medical device row first, because it reads more alarming than it is. Apple's Developer News post of March 26, 2026 names two triggers: a primary or secondary category of Health and Fitness or Medical, or being "marked as containing frequent references to Medical or Treatment Information in the Age Rating questionnaire". A clinic booking app listed under Health and Fitness is in scope of the question. Apple's next sentence says: "If your app is not a regulated medical device, you can select No." App Store Connect Help adds that an app without health or medical features "should select No", after which "no further information is required".

The SDK row catches dormant apps. The condition attaches to uploading a build, so it applies to any new binary no matter how small the change. An app last built in 2025 cannot ship a one-word copy fix until someone rebuilds it on Xcode 26 against an OS 26 SDK.

Google's September 30, 2026 date belongs to the package name registration change under Android developer verification, not to the health app account type rule in section 1.2. That section is already in force and is unchanged in Google's July 2026 preview article.

Over-the-air updates: three documents that point in different directions

Shipping a fix without a store review is the question every clinic asks after its first slow approval. Three Apple documents govern it, and they are usually quoted one at a time.

Read side by side, these point in different directions rather than flatly contradicting each other. Guideline 2.5.2's prohibition is qualified by the clause "which introduces or changes features or functionality", so it is not an unconditional ban on downloading anything. The License Agreement at 3.3.1(B) then permits interpreted code under three lettered conditions. Section 3.3.1(C) is the tightest of the three and the one most often missing from the discussion, because it reaches any mechanism that adds features outside the App Store, Custom App Distribution or TestFlight.

Cite the agreement version when you rely on it. The PDF sits at an unversioned URL and its contents change under the same link. The current English text is version LYL255, dated August 18, 2026. Google's rule has a similar shape: an explicit self-update prohibition, an interpreter exception, and a limit that runtime-loaded interpreted code "must not allow potential violations of Google Play policies".

Know the tooling history before anyone proposes CodePush. Microsoft's App Center retirement page states App Center "is scheduled for retirement on March 31, 2025", and its 15 April 2026 update extends Analytics and Diagnostics "until the end of March 2027". That page points to a self-hostable CodePush server Microsoft published at github.com/microsoft/code-push-server. Both that repository and microsoft/react-native-code-push carry archive banners dated May 20, 2025 and are read-only.

Staged rollout, forward fix, and the absence of a rollback button

Neither store publishes a way to take a bad version back. What they publish is a way to slow it down and a way to replace it.

Apple's App Store Connect Help page on phased release describes a seven-day schedule for users with automatic updates on eligible devices: 1% on day one, then 2%, 5%, 10%, 20%, 50%, and 100% on day seven. You may pause "for up to 30 days, with no limit on the number of pauses". The caveat is Apple's own: "apps and app updates in phased release can be manually downloaded from the App Store by anyone at any time". Phasing staggers automatic delivery, it does not cap who can get the build.

Google's staged rollout works differently. Percentages do not advance on their own, since Google states "your app's staged rollout percentage won't increase automatically". Halting stops further distribution and nothing more: "Users who already received the app version in your staged rollout version will remain on that version." A halted rollout can be resumed.

On Android, reversal is closed off at the system level. Android's versioning documentation states the system "uses the versionCode value to protect against downgrades", and that "you can't upload an APK to the Play Store with a versionCode you have already used". Recovery is a forward fix at a higher versionCode, paired with a halt. Plan your release calendar around that, not around an undo.

What your software has to do

This is a requirements list, stated in the second person, with no vendor attached. Hold any candidate system against it.

• Publish under a seller name a reviewer can tie to your clinic, or supply the authorization files Apple names in the Attachment section.

• Give App Review usable access without exposing a real client record, which means a demo account or a demo mode cleared with Apple in advance.

• Offer in-app account deletion for every account your app lets a client create, per 5.1.1(v).

• Collect payment for in-clinic treatments through a method other than in-app purchase, per 3.1.3(e).

• Keep answering the App Store Connect fields Apple ties to update submission: age rating responses and regulated medical device status.

• Rebuild against the current SDK floor whenever you need to ship, including for a one-line change.

• Ship a forward fix quickly, because neither store publishes a way to take a version back.

Every item is a platform requirement, not a preference. If a system cannot show you how it handles one, that is the question to press. Our notes on what med spa software actually costs and on push notifications for med spas cover running an app once it is live.

What to check on your own app this month

Open App Store Connect and look at four fields. Confirm your age rating responses were submitted after the updated questionnaire went live on January 31, 2026. Open Manage app information and confirm the regulated medical device status field has an answer in it, even if that answer is No. Check the seller name on your listing and decide whether a reviewer would tie it to your clinic. Check the date of your last uploaded build, and if it predates 28 April 2026, ask whoever maintains the app to confirm it still builds on Xcode 26 against an OS 26 SDK.

Then read your privacy policy against the three tests in 5.1.1(i). Most clinic policies handle the first and skip the third, the one about retention, deletion and revoking consent. On the Play side, confirm your account is registered as an Organization, that details match your Dun and Bradstreet profile as section 2.2 asks, and that package names are registered ahead of September 30, 2026. To walk through this against your own setup, book a demo and bring your App Store Connect screen.

Frequently asked questions

Can my software vendor put my clinic's app on the App Store for me?

Apple's guideline 5.1.1(ix) says healthcare apps "should be submitted by a legal entity that provides the services, and not by an individual developer". It contrasts a legal entity with an individual developer and does not mention vendors or agencies. Guideline 4.2.6 separately bars template services from submitting on behalf of clients, while naming an aggregated or picker single binary as an acceptable alternative. Apple's App Review page tells developers to attach partnership documentation or authorization in App Store Connect where entity questions arise. More than one compliant arrangement exists on Apple's own pages.

How long does App Store review actually take?

Apple publishes one figure on its App Review page: "On average, 90% of submissions are reviewed in less than 24 hours." It is an average, it counts submissions reviewed rather than approved, and Apple publishes no measurement date or window. Google publishes no equivalent percentage, only outer bounds, stating review times may reach "up to seven days or longer in exceptional cases" for certain accounts and apps. We found no audited primary source for what developers experience in practice, read on 19 August 2026.

Why do apps get rejected for looking like a template?

Guideline 4.2.6 states that apps "created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content", and that such services "should not submit apps on behalf of their clients". The guideline's own alternative is a single binary hosting all client content in an aggregated or picker model, using a restaurant finder as its example. The target is many near identical binaries filed from one account.

Does Apple take a cut when a client books a treatment in my app?

Guideline 3.1.3(e) states that where an app lets people purchase physical goods or services "that will be consumed outside of the app, you must use purchase methods other than in-app purchase to collect those payments, such as Apple Pay or traditional credit card entry". A treatment delivered in your clinic is consumed outside the app. Guideline 3.1.1 draws the other side of the line: anything that opens features or content inside the app requires in-app purchase.

Will describing injectables change my app's age rating?

Apple's age rating questionnaire in App Store Connect includes a marking for frequent references to Medical or Treatment Information. Apple's Developer News post of March 26, 2026 names that marking as one of two triggers for the regulated medical device status requirement, alongside a primary or secondary category of Health and Fitness or Medical. We found no published Apple statement mapping treatment descriptions to a specific age band, read on 19 August 2026.

What is the regulated medical device declaration and do I have to answer it?

It is a field in App Store Connect under Manage app information, announced in Apple's Developer News post of March 26, 2026 for apps distributed in the European Economic Area, the United Kingdom and the United States. Apple states that existing apps in scope must provide a status by early 2027, and that "if you haven't declared your app's status by early 2027, you'll no longer be able to submit app updates". App Store Connect Help states an app without health or medical features "should select No".

Do I need a D-U-N-S number to publish a clinic app?

For an organization account on either store, yes. Apple's enrollment page states an organization, excluding government entities, "must have a D-U-N-S Number so that we can verify your organization's identity, legal entity status, and address". Google's Play Console Requirements list a D-U-N-S number at section 2.1.2 for organizations, and section 2.2 asks that account information stay consistent with your Dun and Bradstreet profile. Apple also states it does not accept DBAs, trade names or branches.

My app has not been updated in a year and now it will not accept a change. Why?

Two published requirements are the usual cause. Apple's Upcoming Requirements page states that since April 28, 2026, apps uploaded to App Store Connect "must be built with Xcode 26 or later using an SDK for iOS 26, iPadOS 26, tvOS 26, visionOS 26, or watchOS 26", and that condition attaches to the upload itself. Separately, Apple asked for responses to the updated age rating questions by January 31, 2026 "to avoid an interruption when submitting your app updates".