A client intake form is five questions and a consent line, and the medical one changes what you are allowed to build.

What should a first visit intake form actually ask?

Start from the appointment, not from a template you found. The honest test for every field is whether the visit goes worse without it. A name, one way to reach them, the service they booked, and anything that would change what you do on the day. For most businesses that is four or five questions. Apple's guideline 5.1.1(x) is explicit that an app may request basic contact information such as a name and email address so long as the request is optional for the user and features and services are not conditional on providing it. Guideline 5.1.1(v) adds that apps may not require users to enter personal information to function, except when it is directly relevant to the core functionality of the app or required by law. On an intake form the answers are the core functionality, which is the exception that sub point (v) names. That does not retire sub point (x): anything the appointment does not actually need stays genuinely optional, and submitting the form must not depend on it. Asking for a date of birth so you can segment a mailing list fails both.

Three fields cause most of the trouble and none of them look dangerous. A free text box labelled anything we should know collects whatever the client decides to type, which on a massage, physio or tattoo form is a medical history whether you planned one or not. A photo upload turns into a request for a protected resource, and Apple asks you to use the out of process picker or a share sheet rather than requesting full access to Photos. And a date of birth falls under guideline 5.1.4, which says apps may ask for a birthdate and parental contact information only for the purpose of complying with children's privacy statutes such as COPPA and the GDPR. If any of your clients are minors that field stops being optional, and a privacy policy stops being optional with it.

The field to leave out entirely is a card number. You do not want it, your app does not want it, and neither store asks you to have it. If the first visit needs money up front, that belongs at the end of the form as a payment sheet whose inside your app never sees, which is a separate job from the form itself and is covered in adding payments.

What changes if the form collects health information?

The guidelines have a section for exactly this, 5.1.3, and it opens by saying health, fitness and medical data are especially sensitive and that apps in this space have additional rules so customer privacy is protected. Three parts of it reach a typed intake form. Sub point (i) bans using or disclosing to third parties data gathered in the health, fitness and medical research context for advertising, marketing or other use based data mining, and finishes with the sentence most people skip: you must disclose the specific health data that you are collecting from the device. Sub point (ii) is the one that quietly breaks an architecture, because it says apps may not store personal health information in iCloud. And guideline 5.1.1(ix) says apps that provide services in highly regulated fields, naming healthcare among them, should be submitted by a legal entity that provides the services and not by an individual developer.

That last one is a practical problem for a solo founder, and it is cheaper to solve before you build. If the app is for a clinic, the clinic's legal entity should hold the developer account and press submit, not you personally. Moving a published app between developer accounts afterwards is slow, dull work that nobody budgets for.

Now the premise worth correcting, because it sends people down a week long detour. Nothing in the guidelines says health information has to be collected through HealthKit. HealthKit reads and writes the Health app's own store, and guideline 2.5.1 points the other way: HealthKit should be used for health and fitness purposes and integrate with the Health app. A question asking whether somebody takes blood thinners is not a HealthKit data type and has nowhere to go in that store. Guideline 5.1.3 names HealthKit as one source among several, alongside the Clinical Health Records API, Motion and Fitness and the MovementDisorder APIs, and then applies its rules to data gathered in that context. The rules follow the data, not the API. Typed answers are covered by sub points (i) and (ii) with HealthKit nowhere in the project, and adding it to an intake form buys you a permission prompt, a purpose string and a longer review conversation for nothing.

If you do read from HealthKit the rules tighten rather than relax. Guideline 5.1.2(vi) says data gathered from HealthKit and the Clinical Health Records API may not be used for marketing, advertising or use based data mining, including by third parties. Writing into it badly is called out too: 5.1.3(ii) opens by saying apps must not write false or inaccurate data into HealthKit or any other medical research or health management apps. So the safe shape for a service business is boring. Ask the question in your own form, keep the answer somewhere you control, never in iCloud, show it to the practitioner who needs it, and leave HealthKit out of it.

Apple, App Store Review Guidelines, last updated 8 June 2026, read 14 October 2026

Where do the answers live, and who can delete them?

Pick one of three shapes and know which one you picked. On the device only, which means one phone, nothing shared and nothing to breach. On your own server, which means every member of staff reads the same record and you have taken on consent, retention, deletion and secure transport. Or inside the records system you already pay for, with the app as a front end to it. The third is usually right for a business that already keeps a client list. The first is usually right for a solo practitioner who mainly wants to stop printing paper.

Whichever you choose, Google's user data policy sets the shape of the screen rather than the server, and it is unusually specific. The disclosure has to be within the app itself and not only in the app description or on a website. It has to be displayed in the normal usage of the app without the user navigating into a menu or settings. It has to describe the data being accessed or collected and explain how that data will be used or shared. It cannot sit only in a privacy policy or terms of service, and it cannot be bundled with other disclosures unrelated to that collection. Consent has to come from an affirmative user action such as a tap or a ticked box, cannot be read into somebody navigating away or pressing back, cannot come from a message that dismisses itself, and has to be granted before any collection starts. Google names health data and Health Connect data in its list of personal and sensitive user data, so an intake form with a medical question sits squarely inside all of that.

Three obligations are easy to forget because they land after the visit. Apple's guideline 5.1.1(i) requires a privacy policy that explains your data retention and deletion policies and describes how a user can revoke consent or request deletion. Guideline 5.1.1(ii) requires an easily accessible and understandable way to withdraw consent, which in practice is a screen rather than an email address nobody reads. And if your app has accounts at all, 5.1.1(v) requires account deletion from inside the app. Google asks that personal and sensitive user data be handled securely, including transmitting it using modern cryptography, and prohibits selling it, which it defines as transfer to a third party for monetary consideration.

Decide your retention period now and write it into the policy, because a date is the only version of this that survives contact with a busy week. A tattoo consent form and a one off dog grooming questionnaire do not need the same shelf life, and the honest answer for most service businesses is shorter than their instinct. Keeping a medical answer for seven years because the software made it easy is a decision, even when nobody made it on purpose.

Google Play, user data policy, read 14 October 2026

How do you get the form filled in before the visit?

The form being in an app is not what gets it filled in. The reminder is. The sequence that works is a booking confirmation carrying one link, one reminder the day before, and a form that opens on the first question with no account to create. Every step between the link and the first question costs you completions, and a login is the most expensive step there is. Guideline 5.1.1(v) is on your side: if your app does not include significant account based features, let people use it without a login.

Do not gate the form behind a notification permission either, and that is a rule rather than advice. Guideline 5.1.2(i) says your app may not require users to enable system functionalities such as push notifications, location services or tracking in order to access functionality, content or use the app. Ask for notifications after the form is submitted, when the reason for asking is obvious, and keep a text message or an email as the fallback for everybody who says no.

Then expect a share of your clients to arrive with nothing filled in, forever, and build for that rather than against it. The same form has to work on a tablet at the desk, and somebody at the desk has to be able to finish it on a client's behalf. A completed form is also a client who committed something before the appointment, which is the cheapest no show insurance there is, and it is why the deposit usually ends up on the same screen. If you are working out how the money moves, which payment layer to use is the comparison that matters for a real world booking, and what it costs to publish an app is the number worth having before you start, since the form and the reminders are the cheap part of the whole thing.

One last case, because service businesses hit it constantly. When the client is a child the parent fills the form in, and guideline 5.1.4 applies: an app that collects, transmits or has the capability to share personal information from a minor must include a privacy policy and comply with all applicable children's privacy statutes. Apple also spells out that the parental gate used in the Kids Category is generally not the same thing as securing parental consent to collect personal data. A swim school intake form needs the policy and a real decision about what it keeps, not a tick box that says the parent agreed.