A customer note is an audience setting, not a text field.

Who should be able to see a customer note?

Fewer people than your first version will allow. Run a shop for a month and you learn that the notes staff write are not one thing. There is the service record, which is what was done and with what. There is the preference, which is the chair by the window and no small talk. There is the safety note, which is the reaction to a product or the medication that rules a treatment out. And there is the conduct note, which is two missed slots and a deposit from now on. Four kinds, and only two of them are safe to put in front of the customer.

So the field that matters is not the text, it is the audience beside it. Three tiers are enough. Client visible, which means the person can read it in their own app and correct it, and that is the cheapest accuracy mechanism you will ever ship. Staff visible, which means anyone on the rota today. Owner only, which is where a conduct note lives. A fourth tier for the staff who actually perform a given service is worth it once you have more than a few people, because a receptionist does not need the allergy list.

Two details save you from the usual accidents. The first is that the tier gets chosen at write time, by the person typing, with a sensible default. Asking staff to sort notes afterwards does not work, and asking them to remember which screen is internal does not work either. The second is that a note must never travel in a notification payload. A lock screen preview is a disclosure to whoever is holding the phone, so send the fact that a note exists and fetch the body behind a login. That is the one place where push notifications and a notes feature collide, and it is easy to get right in advance and expensive to fix afterwards.

Reading is worth logging too, not just writing. For a safety note, who looked and when is the record that shows the treatment was informed. It also changes behaviour: a staff list that shows who opened a client record is a quieter deterrent than any policy document. Keep the log small, keep it out of the client-facing app, and give it the same retention window as the notes it describes.

What does Apple require if a note mentions a customer's health?

One flat prohibition, and a set of rules about consent that people miss because they are looking in the wrong guideline. Start with the honest version of the scope. Guideline 5.1.3, Health and Health Research, read on 14 October 2026, opens by saying health, fitness, and medical data are especially sensitive and that apps in this space have some additional rules to make sure customer privacy is protected. Its first sub-item covers data gathered in the health, fitness, and medical research context, and the sources it names are APIs: the Clinical Health Records API, HealthKit, Motion and Fitness, the MovementDisorder APIs, and health-related human subject research. A sentence a therapist typed into a box comes from none of them. So whether 5.1.3(i) binds your free text is a judgement call, and Apple has not published an answer. Anyone who tells you it plainly applies, or plainly does not, is filling in a blank.

The next sub-item has no such qualifier, and it is the sentence to build around. Guideline 5.1.3(ii): apps must not write false or inaccurate data into HealthKit or any other medical research or health management apps, and may not store personal health information in iCloud. No API scope, no threshold, no exception for a short note. That rules out CloudKit as the store for those rows. It rules out leaving a cached copy in iCloud Drive. And it rules out the quiet case that catches people: a local database in the app's Documents folder gets swept into an iCloud backup unless you exclude it. If health notes are in your product, they live on a server you control or in on-device storage you have marked as excluded from backup.

What definitely applies, health or not, is 5.1.2 on data use and sharing. Sub-item (i) says that unless otherwise permitted by law, you may not use, transmit, or share someone's personal data without first obtaining their permission, and that you must clearly disclose where personal data will be shared with third parties, including with third-party AI, and obtain explicit permission before doing so. That last clause is new enough that most notes features have not caught up with it: sending client notes to a model somebody else hosts is third party sharing, and it needs saying out loud. Sub-item (ii) closes the other door. Data collected for one purpose may not be repurposed without further consent unless otherwise explicitly permitted by law. A note taken to keep a treatment safe is not a marketing segment.

Three more lines from 5.1.1 shape the build. Data minimisation, 5.1.1(iii), says apps should only request access to data relevant to the core functionality of the app and should only collect and use data that is required to accomplish the relevant task, which is an argument against the open text box that invites anything. Privacy policies, 5.1.1(i), must explain your data retention and deletion policies and describe how a user can revoke consent or request deletion of their data, so you are publishing a retention number whether or not you have decided on one. And 5.1.1(v) says that if your app supports account creation, you must also offer account deletion within the app.

The last one is about who ships the app, and it surprises solo founders. Guideline 5.1.1(ix) says apps that provide services in highly regulated fields, with healthcare on its list, or that require sensitive user information, should be submitted by a legal entity that provides the services, and not by an individual developer. If your notes carry health information, enrol the business in the Apple Developer Program rather than publishing from a personal account. Finding that out before you build is a form, and finding it out after a rejection is a month.

Apple, App Store Review Guidelines, 5.1.1 to 5.1.3, read 14 October 2026

What does Google Play require before you store that note?

A disclosure inside the app, consent before you collect, and a promise not to sell. Google's User Data policy, read on 14 October 2026, settles the classification question Apple leaves open. Its definition of personal and sensitive user data includes, but is not limited to, personally identifiable information, financial and payment information, authentication information, phonebook, contacts, device location, SMS and call-related data, health data, Health Connect data, inventory of other apps on the device, microphone, camera, and other sensitive device or usage data. Health data is named in the list, with no mention of an API, so a typed health note is in scope on Android.

Four obligations come with that label. Limit the access, collection, use and sharing of personal and sensitive user data acquired through the app. Handle all of it securely, including transmitting it using modern cryptography, which in practice means HTTPS everywhere and no exceptions for a sync endpoint you wrote in a hurry. Use a runtime permissions request whenever one is available, before touching data that Android permissions gate. And do not sell personal and sensitive user data, where Google defines a sale as the exchange or transfer of that data to a third party for monetary consideration. You are also on the hook for your dependencies: Google tells you to ensure your SDK providers do not sell data from your app.

Then the part that is genuinely prescriptive. Google's prominent disclosure must be within the app itself, not only in the app description or on a website. It must be displayed in the normal usage of the app and not require the user to navigate into a menu or settings. It must describe the data being accessed or collected and explain how the data will be used or shared. It cannot only be placed in a privacy policy or terms of service, and it cannot be bundled with other disclosures unrelated to personal and sensitive user data collection. The consent request must be clear and unambiguous, must require affirmative user action such as a tap to accept or a ticked box, must not treat navigation away from the disclosure as agreement, must not use auto-dismissing or expiring messages, and must be granted before your app begins to collect or access the data.

There is a structural problem hiding in that, and it is the most useful thing on this page. Google's model assumes the user of the app is the person the data is about. In a staff notes feature they are not. The person tapping is an employee, and the subject is a client who may never install anything. A consent dialog shown to a member of staff collects nothing meaningful from the client. So the client's permission has to be captured where you actually meet them, on the intake form or at the first appointment, and the app records that it happened, with a date and a version. The in-app disclosure still belongs in the client-facing side of the product if you have one. If you do not, the honest answer is that your paperwork is carrying the consent and the app is carrying the receipt.

Worth saying what this costs you, because it is a real reason some businesses stop short. A notes feature that holds health information commits you to a privacy policy with a retention figure, a deletion route, a disclosure screen and a decision about who in your shop can read what. Plenty of businesses do not need any of it. If all you want is to recognise a regular and reward them, a loyalty card app keeps a visit count and a balance and never asks any of these questions. Reach for notes when the service genuinely depends on remembering something.

Google Play, User Data policy, personal and sensitive user data, read 14 October 2026

What should the note itself actually store?

Eight fields, and the text is the least interesting of them. A client id. An author id, because an unsigned note is an argument waiting to happen. A created timestamp. A category, from the four kinds above. A visibility tier. The body. A review date, which is the one almost nobody adds and the one that keeps a note true. And a soft delete marker, so a removal is recoverable for a while and then is not. Everything else you may want later is a join: who read it, which appointment it came from, which version of your terms was in force.

Edits need a rule, and the rule differs by category. A preference can be overwritten freely. A safety note should be append only, with the previous wording still readable. The reason is specific: an edit that loosens a safety note is the single most dangerous write in the system. Someone changing no nut oils to no oils has either corrected a mistake or created one, and a month later nobody can tell which without the old text. Keep the history, show it struck through, and let staff see who changed what.

Two more choices cost nothing now and a lot later. Search is the first. Staff will ask for it, and searching free text across every client is the feature that quietly turns a note store into a profiling tool, which is exactly what Apple's 5.1.2(iii) warns against when it says apps should not attempt to surreptitiously build a user profile based on collected data. Scope search to one client record and the problem does not arise. Offline is the second. Staff work in basements with no signal, so there will be a local cache, and on iOS that cache has to be excluded from iCloud backup if it holds health text. Write that exclusion on the day you add the cache.

Where money touches notes, store a reference and not a retelling. A conduct note that says a deposit is now required should point at the payment record by id, so the amount and the date come from the system that actually knows them. That keeps the note short, keeps it from going stale, and keeps a staff opinion out of your financial record. It also means the notes feature does not care which rails you picked, so you can settle which payment layer to use on its own merits rather than because of a text field.

Apple, App Store Review Guidelines, 5.1.2 Data Use and Sharing, read 14 October 2026