Most café owners assume the risky part of launching a mobile app is building it. In practice, the build is the predictable part. The part that stalls launches is app review — a set of written rules at Apple and Google that a food-ordering app can violate without anyone on the project noticing until a rejection email lands.
The good news: the rules that catch restaurant apps are few, published, and quotable. This guide walks through the six that matter most, in the order they tend to bite, with the exact guideline number so you can check your own build or ask your vendor a specific question instead of a vague one.
The rule that decides who can even submit your app
Start with the one that has the biggest consequences and the least awareness: Apple’s Guideline 4.2.6.
“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.”
Read that carefully, because it settles an argument that comes up on almost every white-label project. If your app is built from a vendor’s template — which nearly every affordable restaurant app is — then you, the restaurant, must be the one submitting it, from your own Apple Developer account. The guideline goes on to say those services “should not submit apps on behalf of their clients.”
Apple does allow one alternative: the vendor can ship a single binary hosting all client content in an aggregated or “picker” model. Apple’s own example is, almost too conveniently, “a restaurant finder app with separate customized entries or pages for each client restaurant.” That is a real, compliant pattern — it is just not a branded app for your café. It is a directory you appear inside.
One dead end worth naming: the Apple Developer Enterprise Program is not a workaround. It exists for distributing proprietary, internal-use apps privately to a company’s own employees, not for shipping customer-facing apps for clients.
Google’s approach differs in form but lands in the same place. Play does not ban the shared-account model outright, but its “Best Practices for White Label Developers” page recommends the decentralized model, where each client has a separate developer account, because it isolates the blast radius: policy violations on a single account can lead to the removal of all associated apps. Translated for an owner: if your app lives on a vendor’s shared account alongside a hundred others, someone else’s violation can take your app down.
The practical takeaway is the same on both stores: own the developer accounts. They cost $99 USD per year (Apple) and a one-time $25 USD (Google Play). That is cheap insurance for an asset your business depends on, and it means you keep the app if you ever change vendors. This is the same “own the channel” logic that applies to owning the customer relationship instead of renting it from a marketplace.
The rules that catch ordering apps in review
Assume the account question is settled. Here are the five rules that reject actual builds.
| Rule | What it requires | Why café apps trip it |
|---|---|---|
| Apple 5.1.1(v) | “If your app supports account creation, you must also offer account deletion within the app.” | Loyalty means accounts. Many builds ship sign-up but no delete path. |
| Apple 4.8 — Login Services | If you offer a third-party social login, you must also offer an equivalent login that limits data collection to name and email and lets users keep their email private. | Adding “Sign in with Google” for convenience quietly triggers the rule. |
| Apple 3.1.3(e) | Physical goods and services consumed outside the app “must use purchase methods other than in-app purchase,” such as Apple Pay or card entry. | Rarely broken deliberately — but worth confirming, because using IAP for food is itself a rejection. |
| Apple 2.1 — App Completeness | Include demo account info and turn on your back-end service if the app has a login. | Reviewers get a login wall, cannot get past it, and reject. |
| Google Play spam policy | Apps must provide value through unique content or services; identical descriptions, screenshots, and feature graphics across apps are prohibited. | Template vendors reuse listing copy across clients. |
Two of these deserve a note.
Guideline 4.8 is opt-in, not automatic. If your app authenticates customers with phone or email on your own system, the rule does not apply. It applies the moment you add a third-party login button. That is a real design decision to make deliberately rather than by accident.
Guideline 3.1.3(e) is good news, not bad. It is the rule that keeps Apple’s commission away from your food sales. Food is consumed outside the app, so orders run through Apple Pay or normal card entry on your own processor at normal card rates — which is why Apple Pay and Google Pay in a café ordering app is a checkout-speed decision rather than a commission one.
The Google Play testing rule that surprises first-time publishers
Apple’s review is fast on average: Apple publishes that 90% of submissions are reviewed in less than 24 hours. Google’s gate is different — it is a waiting period, not a judgement call.
Personal Google Play developer accounts created after November 13, 2023 must run a closed test with at least 12 testers opted in continuously for 14 days before they can apply for production access. The 14 days must be consecutive; a tester opting out and back in resets the clock. (The requirement was reduced from 20 testers to 12 in December 2024.)
The detail most people miss: organization accounts are exempt. If your café is an incorporated business and you register the Play account as an organization rather than as an individual, the 12-tester requirement does not apply to you at all. If you do register personally, you need a dozen willing regulars and two clean weeks — plan the launch date around it.
One more ongoing obligation: new apps and updates on Google Play must target Android 16 (API level 36) or higher as of August 31, 2026. That is a maintenance commitment for whoever owns your build, not a one-time launch task. Worth asking a vendor how they handle it before you sign anything.
A pre-submission checklist
Before anyone hits submit, walk this list. It maps one-to-one to the rules above.
- Developer accounts are in the restaurant’s name — Apple ($99/yr) and Google Play ($25 one-time). Register the Play account as an organization if you can.
- The app does something a website cannot — order-ahead, saved cards, loyalty balance, order history, push. A menu and a phone number is a website in a wrapper.
- Account deletion exists inside the app, reachable without contacting support.
- Login options are checked against 4.8 — social login means you owe an equivalent option.
- Food does not go through in-app purchase — it runs on your processor.
- A working demo account is in the submission notes and the back end is live.
- Privacy answers are complete and accurate — Apple’s App Privacy questions and Google’s Data safety form. Getting these wrong is its own rejection; see our guide to app privacy labels and Data safety for café apps.
- Store listings are unique per app — your own description, icons, graphics, and screenshots.
If you want the wider version of this — screenshots, keywords, and the rest of the submission paperwork — the companion piece is how to publish a restaurant app to the App Store and Google Play.
What “rejection” actually costs you
Worth being level-headed about the stakes. A rejection is not a catastrophe; it is a resubmission. Apple tells you which guideline you failed, you fix it, and you resubmit into a queue that mostly clears in under a day.
The expensive failures are the structural ones:
- A 4.2.6 rejection is not a bug fix. If the app was submitted on the wrong account, the fix is re-registering accounts and resubmitting — days or weeks, plus the awkward conversation with your vendor.
- A shared-account takedown is not your fault and still your problem. If another client’s app on the same Play account violates policy, yours can go with it, and you have no control over the remediation.
- A missed testing window moves your launch. Discovering the 12-tester rule the week you wanted to go live costs you two weeks minimum.
Each of these is avoidable with one question asked early: whose developer accounts will my app live on? If the answer is “ours,” ask why, and read Guideline 4.2.6 out loud.
Where a vendor fits
None of this means you should build the app yourself. It means you should know which parts are non-negotiably yours: the developer accounts, the store listings, and ultimately the app itself.
A good vendor builds and maintains the app, prepares the listings, handles the submission mechanics on your accounts, and keeps you on a supported API level. That is the model behind Tany — a branded iOS and Android ordering app on top of your existing Square POS, with loyalty, eGift cards, and push, at $99 CAD/month per location. A bad vendor treats store compliance as your surprise, six weeks into the project.
Ask the compliance questions before the design questions. The design you can change later.
Sources
- App Store Review Guidelines — Apple Developer
- Apple Developer Enterprise Program
- What’s included in the Apple Developer Program
- App Review — Apple Developer
- Google Play Console registration fee
- Google Play — Closed testing requirements for personal developer accounts
- Google Play — Target API level requirements
- Google Play — Spam and minimum functionality policy
- Google Play — Best practices for white label developers