Your menu's allergen list is kitchen data. The diner's allergy is health data.
Allergen information in an app is two different things wearing one name, and keeping them apart is most of the work. What a dish contains is a fact about the dish. It belongs on the dish as structured data, it is not health data about anybody, and neither store asks you to declare it. What a customer tells you about their own allergy is a fact about a person. Apple classes that as Health data, Google Play classes it as Health info, and from the moment it leaves the phone both stores want it on a form. Everything below comes from Apple's and Google's own published rules, read on 14 October 2026. Most people hit this while building a booking app for business.
What follows is the shape of the record, the one claim never to make, what the stores actually say, and how a correct allergen list goes quietly wrong six weeks after launch. The short answer to the rule question is that there is no allergen rule. There is a health app rule, and you can walk into it by accident.
Start hereThe short version
Describe the dish accurately and never describe the person.
Store allergens as structured fields on each dish, with contains and may contain kept apart. Show them unchanged. Do not interpret them, do not score dishes against a diner, and do not use the word safe. The app is a faithful copy of the kitchen's own list, and every ounce of trust it has comes from being exactly that.
Then decide whether you want to hold anything about the diner at all. A free text allergy note on a booking is useful to your staff and genuinely safer than a phone call nobody wrote down. It is also health data, it needs a reason to exist, a retention answer and a deletion route. Plenty of good booking apps let the diner type it, show it to the host, and delete it with the booking. That is a complete answer, not a shortcut.
What belongs in an allergen record, and what does not?
A boolean per allergen per dish, and a second boolean for may contain. That is the whole model, and it is boring on purpose. Allergen data written as a sentence inside a dish description cannot be filtered, cannot be audited, and cannot be checked by anything except a person reading it. The same words in tick boxes can be listed on a dish page, filtered by a diner, printed for the kitchen and diffed when something changes. Use the allergen list your own food regulator publishes. Do not write your own list, and do not copy one from another app.
Keep contains and may contain in separate fields that render in separate words. Contains means the allergen is in the recipe. May contain means the kitchen cannot rule out cross contact: a shared fryer, a shared board, flour in the air, or a warning that came in on the supplier's own packaging. Those are different facts and a diner acts on them differently. One merged field, or a faint version of the same icon, makes that decision for them. Give the kitchen somewhere to say why, in free text, and show it.
Modifiers are where neat models fall over. If the kitchen will make a burger without the brioche bun, the modified dish has a different allergen set, so the modifier carries its own allergens rather than subtracting from the dish. If you let a diner request a change in free text, that text goes to the kitchen and the allergen record does not move. Nothing a customer types may ever edit a dish.
What does not belong is anything about the diner, unless you have decided to hold it deliberately. Do not quietly build a profile from their filters. Do not write an allergy into HealthKit: Apple is explicit that apps must not write false or inaccurate data into HealthKit or any other health management app, and a note from a booking form is not a clinical record. Apple also says in the same guideline that you must disclose the specific health data you collect from the device. If you keep an allergy, say so plainly on the screen where you ask for it.
Apple, App Review Guidelines 5.1.3 Health and Health Research, read 14 October 2026
Check yours
Where each piece of allergen data belongs
Tick what your app does. The left answer is the field to build. The right answer is what it costs you on the two store privacy forms.
Nothing ticked. An app that prints the kitchen's own allergen list and keeps no customer record has no health data at all, and nothing to declare on either form.
Does Apple or Google have a rule about allergen data?
No, and it is worth saying clearly because the question comes up in every review of a menu feature. Apple's App Review Guidelines contain no clause about allergens, food labelling or diet. Google Play's Health Content and Services policy does not mention them either. Nobody at either store is going to reject your app for the way you formatted a nut icon, and no platform makes you print a particular allergen disclaimer. Checked on 14 October 2026.
What does exist is broader and more interesting. Apple opens guideline 1.4 by saying that if your app behaves in a way that risks physical harm, it may be rejected. Guideline 1.4.1 then sets the accuracy bar: medical apps that could provide inaccurate data or information, or that could be used for diagnosing or treating patients, may be reviewed with greater scrutiny. Apps must clearly disclose data and methodology to support accuracy claims relating to health measurements, and Apple says that if the level of accuracy or methodology cannot be validated, it will reject the app. Apps should also remind users to check with a doctor in addition to using the app and before making medical decisions.
Read that carefully and you can see exactly where a menu app is and is not exposed. A dish level allergen table makes no health measurement and diagnoses nobody, so 1.4.1 is not aimed at it. A feature that reads a person's allergy and tells them what to order is making a judgement about an individual, and the accuracy bar in that guideline is the one you would be judged against. The distance between those two features is one screen, which is why teams cross it without noticing.
Google's side is a flat prohibition rather than a scrutiny warning. Its policy says it does not allow apps with health and medical related functionalities that are misleading or potentially harmful. An allergen list that is out of date is both. That is the real risk on a restaurant app, and it is an operations risk, not a review risk: nobody rejects you at submission, and the wrong answer ships quietly and stays wrong.
Google Play, Health Content and Services policy, read 14 October 2026
When does a menu app become a health app?
Google answers this one directly, and the answer is wider than people expect. Its policy says that if your app is not primarily a health app, but has health related features and accesses health data, it is still in scope of the health app policy. Storing a diner's allergy is accessing health data. One free text field on a booking form can put a restaurant app inside a policy written for symptom checkers.
Being in scope brings three concrete obligations. Every health app completes the Health apps declaration form on the App content page in Play Console. A health or medical app that is not a regulated medical device must include a clear disclaimer in its app description saying it is not a medical device and does not diagnose, treat, cure, or prevent any medical condition. And apps must remind users to consult a healthcare professional for medical advice, diagnosis, or treatment. Google's declaration guidance adds that an app making a health claim should disclose the basis of that claim, the types of users it is intended for, any risks, and all required disclaimers and warnings.
So the practical question is not whether to write a disclaimer. It is whether you want to be in that conversation at all. There are three honest designs. Hold nothing: the diner reads the dish record and tells the waiter. Hold it for the booking only: free text, shown to staff, deleted when the booking closes. Hold it on the profile: now you are a health app on Google Play, you declare it, and you earn the convenience of the diner not retyping it every time.
On the forms themselves, an allergy maps cleanly. Apple's app privacy details page defines its Health data type as health and medical data including any other user provided health or medical data, which covers a typed note. Google Play's Data safety form has Health info in the Health and fitness category, described as information about a user's health such as medical records or symptoms. Both stores only count data that leaves the device, so an allergy filter applied on the phone and never sent anywhere is not collected on either form.
Google Play, Health Content and Services policy, read 14 October 2026
How do you stop the allergen list going quietly wrong?
Decide who owns it before you build it. An allergen record that anyone can edit and nobody is responsible for will be correct at launch and wrong by the second supplier change. Put one named role on it, usually the person who signs off recipes, and give the app a change log so you can answer the only question that matters after an incident: what did the app say on the day, and who last touched it. A timestamp and an author on every dish costs an hour and is the difference between a record and a guess.
Then fight the cache. A phone that downloaded your menu last month will happily show it offline, which is a lovely feature for opening hours and a dangerous one for allergens. Version the menu, send the version with every response, and have the allergen view refuse to render from a cache older than your own limit without refetching. When it cannot refetch, say so on the screen instead of showing stale ticks. If a dish changed and someone has an open booking with a note about that allergen, push notifications are the right tool, and this is one of the few cases where nobody will mind the interruption.
Keep the allergen record out of the features that want to be clever. If you also run a loyalty card app, it is tempting to recommend dishes from what someone usually orders and what they avoid. That turns a menu into a health recommendation and it drags the loyalty data into health scope with it. Keep the two stores of data apart, and keep allergen filtering on the device wherever you can.
One payment note, because it surprises people building the booking side. Apple's guideline 3.1.3(e) says that 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 table, a deposit and a no show fee are all real world services, so they do not go through in app purchase and Apple takes no cut of them. That decides which payment layer to use before you write a line of checkout code.
Apple, App Review Guidelines 1.4.1 and 3.1.3(e), read 14 October 2026
Three ways to hold the data, and what each one costs you
Most menus start in the first column and most of them should end in the third. The middle column is the one worth planning for, because it is cheap enough to actually get filled in.
| What you need from it | A sentence in the description | A tick box per allergen, per dish | Ingredients, allergens derived |
|---|---|---|---|
| Work to set up | None, you are already typing descriptions | A tick list on every dish, once | An ingredient list per dish, plus one allergen map |
| A diner can filter the menu | No | Yes | Yes |
| Shows may contain as its own answer | No | Yes | Yes |
| Survives a recipe change on its own | No | No | Yes |
| One place to fix a mistake | No | The dish | The ingredient, across every dish |
| Who can keep it right | Whoever writes copy | A manager, in minutes | Whoever owns the recipes |
Where this lands if a builder generated your app
Nothing moves because an AI wrote the code. You own the allergen record, you answer both store privacy forms, and on iOS you are the one who presses submit. App Review Guideline 4.2.6 is the reason: apps created from a commercialized template or app generation service are rejected unless they are submitted directly by the provider of the app's content. The restaurant is the content owner, so the restaurant submits.
Newly is an AI app builder. You describe the app in plain English and it writes a real React Native and Expo project that you own, with two way GitHub sync so a developer can take it further. It uploads iOS builds to TestFlight, publishes to Google Play internal testing, and can build a standalone Android APK. There is no free tier, and it is paid from $25 a month. For this job the useful part is that asking for a menu with structured allergen fields takes one sentence, and the generated screens read those fields instead of a paragraph of copy.
The honest limit is that no builder can tell you what is in your food. A generated app starts local first, data on the phone, which is the cheapest correct answer on both privacy forms. Ask for bookings, accounts or a saved customer allergy and a backend arrives with sign in, a database and file storage, and from that point you have real answers to give on both forms. Say out loud which of the three designs above you picked, because the agent will build whichever one you describe.
Questions people ask about allergen information in an app
No. Neither store has an allergen rule. Apple's App Review Guidelines do not mention allergens, food or diet anywhere, and Google Play's Health Content and Services policy does not either, read on 14 October 2026. What Google does require is a disclaimer on apps that fall inside that health policy: a health or medical app that is not a regulated medical device must include a clear disclaimer in its description saying it is not a medical device and does not diagnose, treat, cure, or prevent any medical condition, and must remind users to consult a healthcare professional. A menu that lists what is in each dish is not that app. An app that advises a person on their own allergy is.
Describe the menu, then decide what you keep about people
Write the allergen list as fields on the dish, name the person who owns it, and pick one of the three designs for the diner's own allergy before you build the booking form. Those three decisions are the whole job, and they are much cheaper to make now than to unpick later.
Start building