Why Apple rejects casino apps, and what each rejection costs

Ask why Apple rejects casino apps and most people point at Guideline 5.3. That section matters, and we’ve covered it separately. But Apple App Store gambling policy is spread across the whole of the Review Guidelines, and the rejections that recur for real-money and sweepstakes casino apps usually cite something else.

“This is just a website”

Guideline 4.2, Minimum Functionality, is short and direct: an app “should include features, content, and UI that elevate it beyond a repackaged website.” A sub-point, 4.2.2, adds that apps shouldn’t primarily be “web clippings, content aggregators, or a collection of links.”

Casino products run into this more than most. The web product already exists, and wrapping it is the fastest route to a store listing. The result can be an app that is, from a reviewer’s point of view, the website with an icon.

This is rarely a quick fix. The response to a 4.2 rejection is product work, not a changed sentence in the review notes. How much the app should do natively, and where the line sits between native and web, is a decision we’ve written about in native, WebView or PWA. Discovering it at review means making that decision under a deadline.

The reviewer who can’t get in

Guideline 2.1, App Completeness, asks developers to “include demo account info (and turn on your back-end service!) if your app includes a login.” Apple’s pre-submission checklist is blunter: “Provide App Review with full access to your app.”

For a casino app, full access is harder than it sounds. The app requires a login, the account usually has to pass identity checks, and the product is restricted by location. A reviewer who hits a registration wall, an unverified account or a location block has not seen the app. From their side, that’s an incomplete submission.

Apple does allow for this: where a demo account isn’t possible “due to legal or security obligations”, a built-in demo mode can be used instead, “with prior approval by Apple”, and it must exhibit “your app’s full features and functionality.” Prior approval and full features both take planning, and neither can be arranged the afternoon a rejection arrives.

Licensed, restricted, and listed in the same places

Guideline 5.3.4 requires real-money gaming apps to “have necessary licensing and permissions in the locations where the app is used” and to “be geo-restricted to those locations.” Separately, 5.1.1(ix) says apps in regulated fields including gambling “should be submitted by a legal entity that provides the services, and not by an individual developer.”

Together, those put three things under review at once: who holds the licence, where the app actually works, and where it’s listed. In most operator organisations, those sit with different people, and a mismatch is often invisible until a reviewer asks for the paperwork. The same question comes up earlier, at enrolment: see the Apple developer account for a gambling company.

The app must also be restricted to its licensed locations while the reviewer still sees all of it. How those two requirements are reconciled is specific to the product and what its licences permit.

The sweepstakes wording problem

Sweepstakes and social casino apps meet a different version of the same difficulty. Guideline 5.3.3 says apps “may not use in-app purchase to purchase credit or currency for use in conjunction with real money gaming of any kind.” Guideline 3.1.1, meanwhile, requires in-app purchase for “in-game currencies.”

Which of those rules a reviewer applies depends on what they conclude the product is. That conclusion is drawn from everything they see: the store listing, the screenshots, the in-app copy, how prizes and redemption are described. Guideline 2.3 asks that metadata “accurately reflect the app’s core experience”, so the listing is part of the evidence, not decoration around it.

Language that reads as real-money gambling invites the real-money questions, including licensing the product may not have been built around. Much of what decides a sweepstakes submission is how the product explains itself, and that copy is usually written by people nowhere near the App Store process.

What Apple App Store gambling policy costs when it’s read late

The obvious cost is time: each rejection is a fix, a resubmission and another wait in the queue. Apple’s guidance adds a less obvious one: “if your app is repeatedly rejected for the same guideline violation,” review “will take longer to complete.”

So rejections compound. A launch date slips once for the fix and again for the slower review that follows, while marketing booked against the date sits idle. And because the slower review is tied to repeat rejections, each avoidable one makes the next submission harder, not just later.

None of these causes is obscure. What makes them expensive is that they’re decided by product, compliance and marketing choices made long before anyone opens App Store Connect.

Which of them applies to your app, and in what order to deal with them, depends on the product, the markets and the paperwork behind it. That’s what our App Store delivery work starts with. If a rejection is in front of you, or a submission is coming up, get in touch.

---

Apple’s guidelines change, and the wording is what review applies. This summarises the published rules as they stood on 28 September 2026 and is not compliance advice. Check the current App Store Review Guidelines before submitting.