Most teams meet Guideline 5.3 the same way: they build the app, submit it, get rejected, and only then read the rule properly. It’s a short section of Apple’s App Store Review Guidelines, it’s public, and a great deal of what’s painful about gambling app submission follows from it.
Worth reading before the build, not after the rejection.
What the published rule covers
For apps offering real-money gaming — sports betting, casino, poker, horse racing, lotteries — Apple’s guidelines set out conditions that are, in practice, non-negotiable. In summary, they concern:
- Licensing — holding the necessary permissions for every location the app is used in, which is not the same as where the company is registered.
- Geographic restriction — limiting availability to those locations.
- Free download — real-money gaming apps can’t be paid downloads.
- Payment method — funding real-money play sits outside Apple’s in-app purchase system.
There is also a longstanding expectation that these apps offer real native functionality rather than being a thin wrapper around a website, which interacts with a separate guideline.
The wording changes from time to time, and the wording is what review applies. The App Store Review Guidelines are the only authoritative version.
The difficulty isn’t the rule
Almost none of the real difficulty is in understanding what Apple has written. It’s in the distance between a published rule and a product that was scoped, designed and staffed before anyone read it.
Three areas account for most of the trouble we see:
Evidence. Review expects to be able to verify the claims a submission makes. Documentation that exists somewhere is not the same as documentation ready to submit.
Category. Real-money gaming and simulated gaming sit under different expectations with different payment logic. A product that borrows its approach from the wrong category gets rejected for the borrowed part.
Consistency. The markets a product is licensed for, the markets it’s technically restricted to, and the markets it’s listed in are usually maintained by different people in different systems.
The most common expensive mistake isn’t a policy violation. It’s a commercial plan that assumed a market the permissions don’t cover.
Rejections are not all the same
If a submission is refused, the reason matters enormously and is frequently misread as a blanket ban.
There is a real difference between a submission that hasn’t demonstrated compliance — usually fixable, sometimes quickly — and a business model that isn’t permitted in that form at all, which is a strategic problem rather than a submission problem.
Teams that skip that distinction can spend months solving the wrong one.
Working out which one you’re looking at, and what it takes to clear it, is specific to the product, the markets and the paperwork. If you’re staring at a rejection and can’t tell which kind it is, that’s a conversation worth having early — get in touch.
Apple’s guidelines change. This is a plain-language summary of the published rules as of July 2026, not compliance advice — check the current App Store Review Guidelines and take proper advice before submitting.