The single most common objection we hear from café owners considering a branded ordering app is some version of: “Isn’t Apple going to take 30% of every order? Then I’ve just swapped DoorDash for Apple.”
It’s a reasonable fear built on a real number that has been in the news for years. It just doesn’t apply to you. Food ordering has always sat outside the in-app purchase system, on both stores, by explicit written policy. This post walks through what the rules actually say, what you really pay, and where the genuine edge cases are.
The short answer, and the rule behind it
Apple’s App Review Guidelines split purchases into two worlds. Digital content that is consumed inside the app — game currency, streaming subscriptions, premium features — must use in-app purchase, and Apple takes its commission there. Everything else does not.
Guideline 3.1.3(e), “Goods and Services Outside of the App,” covers the second world: apps that let people buy “physical goods or services that will be consumed outside of the app” must use a payment method other than in-app purchase, such as Apple Pay or ordinary card entry (Apple App Review Guidelines).
A flat white you collect from a counter is about as far outside the app as a purchase can get. So is a bag of beans, a catering tray, or a delivery order. Apple’s guidelines name a shipped product, a ride, and food delivery as examples of real-world services. Those transactions are required to go through your own processor, which means Apple has no mechanism to take a cut of them even if it wanted one.
Google Play draws the same line in the opposite direction — as a prohibition rather than a permission. Google Play’s Payments policy says its billing system is not used for purchases of physical goods or physical services, and lists food delivery explicitly among the examples (Google Play Payments policy). Google’s service fee attaches to Play Billing. No Play Billing, no service fee.
The 30% is a tax on digital goods. Your app sells coffee.
What you actually pay to run a café app
Once you take the store commission off the table, the real cost stack is short and boring. Here is the honest version for an independent café running a branded iOS and Android ordering app.
| Line item | What it costs | How often |
|---|---|---|
| Apple Developer Program | $99 USD | Per year |
| Google Play Console account | $25 USD | One time, ever |
| Apple / Google commission on food orders | $0 | — |
| Payment processing | ~2.6–3.3% + 25–30¢ per order (2.8% + 30¢ on Square in Canada for online orders) | Per order |
| App platform / build + maintenance | Varies — a done-for-you platform is a flat monthly fee | Per month |
Developer fees per Apple and Google Play Console; processing per Square’s pricing page. Confirm current rates for your country and plan.
Two things worth noticing. First, the store fees are essentially rounding errors — $99 a year is about $8 a month, less than a bag of beans. Second, the only line that scales with your sales is payment processing, and that is the same fee you already pay on a card tap at the counter. Nothing in this stack grows to 15–30% of revenue the way a marketplace commission does.
A worked example
The numbers below are illustrative — plug in your own volume — but the shape holds.
Take a café doing 900 app orders a month at an $18 average ticket, so $16,200 in monthly app sales.
If the 30% myth were true:
- Apple’s cut: $16,200 × 30% = $4,860 per month
What it actually is:
- Payment processing at 2.8% + 30¢: ($16,200 × 2.8%) + (900 × $0.30) = $453.60 + $270 = $723.60
- Apple Developer Program amortized: $99 ÷ 12 ≈ $8.25
- Google Play account: $25 once, ≈ $0.35/month over five years
- App platform fee: a flat monthly rate — on Tany, $99 CAD/month per location
Total real cost: roughly $831 a month, against a mythical $4,860. The gap is not a discount you negotiated; it’s a fee that was never charged in the first place.
Compare that to a delivery marketplace at 15–30% commission on the same volume and the picture gets starker still — we ran that math in what delivery apps really cost your restaurant.
The edge cases that genuinely do trigger in-app purchase
It would be dishonest to say “never” without naming the exceptions. There are three places where a café app could wander into in-app purchase territory.
1. A digital-only membership. If you sold a $5/month subscription that unlocked, say, a library of brewing videos inside the app and nothing else, that’s digital content consumed in-app, and Apple’s rules apply. But a coffee subscription that delivers actual coffee, or a membership that gives discounts on real drinks, is a real-world benefit — the same category as the orders themselves. Most café memberships are the second kind. If you’re designing one, see how coffee subscriptions and memberships work on Square.
2. Pure digital collectibles or unlockables. Badges, cosmetic themes, in-app currency with no real-world redemption. Rare in a café app, but it’s the line to stay behind.
3. Anything you sell that never leaves the phone. The test Apple applies is consumption. If the thing the customer bought is used up inside the app, it’s IAP. If it walks out of your shop in a cup, it isn’t.
eGift cards sit close to the line but land on the safe side in practice: they are stored value redeemed for physical food and drink, and every major restaurant app sells them through external payment. If you want the operational detail, see selling eGift cards on Square.
The Small Business Program: relevant, but not to you
You’ll see the App Store Small Business Program cited in a lot of app-cost articles — it drops Apple’s commission from 30% to 15% for developers earning under $1 million a year. It’s a real program and worth knowing about, but it applies to in-app purchase revenue. If your app’s only transactions are food orders, your IAP revenue is zero, and 15% of zero is the same as 30% of zero. Enrolling changes nothing about your ordering economics.
The same logic covers Google’s tiered service fee. Both discounts are answers to a question a café app never asks.
What Apple and Google will actually push back on
Store commission is not the risk for a restaurant app. Review rejection is. That’s where the real friction lives, and it’s worth knowing the pattern before you submit:
- Guideline 4.2.6 — commercialized templates. Apple restricts apps generated from a template unless they are submitted by the business itself, on that business’s own developer account. This is the single most important structural detail for a white-label café app: the app should be published under your Apple Developer account, not a vendor’s shared one.
- Guideline 2.1 — incomplete submissions. No demo account, no working test order, no reviewable build. Easy to fix, very common.
- Guideline 5.1.1 — privacy. Your privacy policy and App Privacy labels have to match what the app actually collects.
We covered the full list in why restaurant apps get rejected from the App Store, and the labelling side in app privacy labels and Data Safety for a café app.
Five questions to ask any app vendor about fees
Since the store commission is a non-issue, the fee questions worth asking are all about the vendor sitting between you and the stores. Ask these before you sign anything, and get the answers in writing.
- “Whose Apple Developer account will my app be published under?” The right answer is yours. If the vendor publishes under a shared account, you don’t control your own listing, and you’re exposed on Guideline 4.2.6.
- “Do you take any percentage of order volume, ever?” Some platforms advertise “no commission” and then charge a per-order fee, a fee above a volume threshold, or a fee on delivery orders specifically. Ask for the number at 500 orders a month and at 2,000.
- “Who receives the money, and when?” If orders settle into your own Square account on your normal deposit schedule, your cash flow doesn’t change. If they settle to the vendor and get remitted, that’s a different risk profile entirely — see Square deposit and payout times.
- “What happens to the app if I cancel?” Whether the listing, the reviews, and the download base stay with you is the difference between a channel you own and one you rent.
- “Is the monthly fee per location or per account?” For a single café it doesn’t matter. The moment you open a second one it matters a lot, and it’s the question most owners forget to ask up front — see multi-location mobile ordering on Square.
None of these are about Apple. All of them are about whether the economics still look good in two years.
What this means if you’re a café on Square
The decision about whether to run a branded ordering app should turn on things like whether you have enough repeat customers to justify it, whether your morning rush needs order-ahead, and whether you want loyalty and push notifications you own. It should not turn on a 30% fee that does not exist.
For a Square café, the practical version looks like this: your menu, prices, and customers stay in Square; the app takes orders and pushes them into your existing POS; payment runs through your Square account at your normal online rate; and the App Store’s role is distribution, not revenue share. That’s the model Tany runs on — a branded iOS and Android app plus web ordering, live in about a day on your existing Square setup, with 0% commission on orders.
If you take one thing away: when you’re comparing an app platform, ask what the platform charges and what your processor charges. Those are the only two numbers that matter. The app stores are charging you $99 a year to be in the phone, and that’s the whole story.
Sources
- App Review Guidelines — Apple Developer (Guideline 3.1.3(e), Goods and Services Outside of the App; Guideline 4.2.6)
- Understanding Google Play’s Payments policy — Play Console Help
- Apple Developer Program — membership
- Google Play Console — registration
- App Store Small Business Program — Apple Developer
- Square Pricing (Canada) — processing rates