Getting a café or restaurant app onto people’s phones is two different jobs that often get confused. One is building the app. The other is publishing it — getting through Apple’s and Google’s gatekeeping and onto the App Store and Google Play. This guide is about the second job: the accounts, fees, timelines, and rejection traps that decide whether your finished app actually reaches customers.
If you’re weighing whether to do this yourself or use a done-for-you platform, knowing exactly what publishing involves makes that decision honest. It is written for an independent café or restaurant owner, usually on Square, in Canada or the US.
What you need to publish, end to end
Regardless of who does the work, every app on the two big stores needs the same ingredients:
- An Apple Developer Program account — $99 USD per year.
- A Google Play developer account — a one-time $25 USD registration fee.
- The built app binaries — a signed iOS build and an Android build (
.ipaand.aab), produced from actual source code. - Store listings — app name, subtitle, description, keywords, category, and screenshots sized for multiple devices, plus an app icon.
- A privacy policy URL and accurate privacy disclosures — Apple’s “privacy nutrition labels” and Google’s Data Safety form both require you to declare what data you collect.
- A working demo path for reviewers — a guest mode or a real test account, so a human (Apple) or automated/manual checker (Google) can actually use the app.
Miss any of these and you don’t get rejected for a bad app — you get rejected for an incomplete submission, which is avoidable.
The fees, plainly
The store fees themselves are modest and are the same whether you’re a one-location café or a chain:
| Item | Apple App Store | Google Play |
|---|---|---|
| Developer account | $99 USD / year | $25 USD one-time |
| Renewal | Annual | None |
| Commission on digital goods | 15% under $1M/year, 30% above (Small Business Program) | 15% on first $1M/year, 30% above |
| Typical review time | 24–48 hours | Often within a day; several days for new accounts |
A crucial clarification on commission: those 15–30% cuts apply to digital goods and in-app purchases — think a subscription unlocked inside the app. Physical goods and services bought through an app, including food for pickup or delivery, are explicitly exempt. When a customer orders a latte for pickup, Apple and Google take nothing; the payment runs through your normal payment processor (Square, in most café cases) at standard card-processing rates. This is the single most misunderstood point about restaurant apps, so it’s worth stating clearly: the app-store commission does not touch your food sales.
The fees above are also just the listing fees. They don’t include the real cost driver: designing, building, and maintaining the app, which we cover next.
The part that actually costs money: building the app
A bare developer account gets you nothing customers can use. You still need the app itself, and there are three honest paths:
- Custom build from scratch. A developer or agency builds a native iOS and Android app to your spec. This is the most flexible and by far the most expensive and slowest — see our breakdown of what a custom restaurant app really costs before going this route. You also own ongoing maintenance: OS updates, store-policy changes, and bug fixes, forever.
- A progressive web app (PWA). Cheaper, but it isn’t a real App Store/Play listing and gives up push notifications’ reliability and native polish. We compare the trade-offs in PWA vs native app for restaurant ordering.
- A white-label / done-for-you platform. A provider has already built the app, maintains it, and publishes a branded version for you — usually handling the accounts, store listings, and review submission as part of onboarding.
Which path fits depends on budget, how fast you need to launch, and whether you want to own a codebase or rent a finished product.
The submission process, step by step
Here’s what publishing actually looks like once the app is built, so the timeline is concrete.
- Enroll the developer accounts. Apple’s enrollment includes an identity check and can take a day or more to approve; Google’s is faster. Start this early — it’s the most common cause of a slipped launch date.
- Prepare the listings. Write the title, subtitle, and description, choose your category, and produce screenshots for the required device sizes. This doubles as your app-store optimization (ASO) work — the keywords and screenshots here decide whether anyone searching “[your town] coffee” finds you.
- Complete the privacy disclosures. Fill Apple’s privacy labels and Google’s Data Safety form to match what the app truly collects (typically name, email or phone for login, and order history). Inaccurate labels are a frequent rejection reason.
- Upload the builds. Submit the signed iOS build via App Store Connect and the Android
.aabvia the Play Console, attaching a demo account or guest path. - Submit for review and wait. Apple’s human review is usually 24–48 hours; Google is often same-day for established accounts. First submissions on new accounts run longer — plan for it.
- Handle any rejection and resubmit. If rejected, the store cites a specific guideline. Fix it, reply or resubmit, and you re-enter the queue. A clean second submission usually clears quickly.
Why restaurant apps get rejected (and how to avoid it)
Apple in particular is strict, and the rejections are predictable:
- “Minimum functionality” / repackaged website. Apple’s guideline 4.2 rejects apps that are just a website in a wrapper. A real ordering app with native sign-in, push notifications, saved cards, and order history clears this; a thin web shell does not.
- Broken or missing guest/login path. If the reviewer can’t get past the front door, it’s an automatic rejection. Provide a working demo account or a guest checkout.
- Privacy gaps. No privacy policy URL, or labels that don’t match behavior.
- Crashes during review. Test the exact build you submit on a clean device.
- Payment-method confusion. Make sure physical-goods checkout uses your normal processor, not Apple’s in-app purchase — using the wrong one for food triggers a rejection.
None of these are exotic. They’re checklist items, and a complete, genuinely functional ordering app passes them.
The done-for-you shortcut
If reading the above made you want to skip the developer accounts, privacy forms, and review queue entirely, that’s the case for a white-label platform. With this model, the app is already built and store-approved as a template; your branded version is configured, submitted, and shepherded through review for you, and the provider maintains it against future OS and policy changes.
Tany is one example: a branded order-ahead app for iOS and Android plus web ordering, built on your existing Square POS, with the App Store and Google Play publishing handled as part of getting you live — typically in about a day rather than the weeks a custom build and first-time review take. It runs $99 CAD/month per location with unlimited orders, and because food is a physical good, no app-store commission touches your sales. For the realistic end-to-end timeline either way, see how long it takes to launch a restaurant app.
The takeaway
Publishing a restaurant app to the App Store and Google Play means an Apple Developer account ($99/year), a Google Play account ($25 once), built binaries, complete listings, and accurate privacy disclosures — then a review that’s usually 24–48 hours on Apple and often same-day on Google. The store fees are small; the cost and effort live in building and maintaining the app, and in clearing predictable rejection traps like thin content and missing demo paths.
The strategic point: app-store commission does not touch food sales, so the math for a café app is about reach and retention, not store taxes. Whether you build custom, ship a PWA, or use a done-for-you platform, knowing exactly what publishing involves is what lets you choose honestly.