A real-money casino app is approved in two different senses before a player sees it. The regulator licenses the product, and the store licenses the distribution. Apple states its side of that arrangement in a single paragraph of the App Review Guidelines and then asks for the paperwork that proves the other side. An operator who reads only the paragraph arrives at review with an accurate description of the rule and no licence document per storefront — which is the reason submissions in this category get rejected for missing information rather than for a broken build.
The paragraph is guideline 5.3.4. Apps that offer real-money gaming, casino games among the examples given, must have the necessary licensing and permissions in the locations where the app is used, must be geo-restricted to those locations, and must be free on the App Store. Illegal gambling aids, card counters included, are not permitted. Guideline 5.3.3 adds the payment rule: in-app purchase may not be used to buy credit or currency for use in connection with real-money gaming of any kind.
Three sentences describe a duty. The review then asks for evidence of it, and that evidence is organised per storefront rather than per app. This article works through what Apple’s published documents actually request, what does not change when an operator takes the alternative-distribution route in the European Union, and the items that belong in the build plan rather than in the week before submission. The comparison with Google Play’s application form is covered in the store gate analysis; this article stays on the iOS side.
The licence is requested for each storefront
Apple’s App Review Help page on providing information for a complete review is explicit about regulated fields. Developers with apps operating in regulated fields must provide documentation demonstrating they are qualified and authorized to provide those services. If the app is available in multiple countries and regions, developers may need to provide additional documentation for each location where the app is distributed. The documentation table lists the requirement for guideline 5.3.4 as a gambling licence, and the general instruction is to attach everything App Review will need in the App Review Information section before submitting. Incomplete submissions are rejected.
That is a different shape of obligation from a single global attestation. The licence an operator holds for one market does not answer for another, and the storefront list is the unit the reviewer works through. A submission that offers the app in six markets and attaches one licence leaves five storefronts undocumented, and the rejection arrives as a request for more information rather than as a technical fault.
Two further conditions sit alongside the licence. Guideline 5.1.1(ix) covers highly regulated fields and states that apps providing services in fields such as banking, financial services, healthcare, gambling and crypto exchanges, or that require sensitive user information, should be submitted by a legal entity that provides the services and not by an individual developer. The licence holder and the publishing entity are therefore part of the same review question. Apple’s guidelines introduction also frames the whole category as a scheduling risk: only include the functionality if legal obligations have been vetted everywhere the app is made available, and expect extra time during review.
The three duties that survive every distribution route
Licensing, geo-restriction and a free download are stated as conditions of the app, not conditions of the App Store listing. They apply whether the binary is reviewed for the App Store, for an alternative app marketplace in the European Union, or for web distribution from the operator’s own domain. Apple’s help documentation describes the review type as a per-version choice in App Store Connect, with Notarization evaluating a version against a subset of the App Review Guidelines.
The practical reading is that the licence pack is not a store formality that a different route allows an operator to skip. It is the evidence that the product is legal in each place the app can be installed, and the route decides who inspects that evidence and under which subset of rules. An operator planning a market list should build the licence inventory before choosing the route, because the inventory is the part that takes calendar time and legal review, while the route is a configuration decision made in App Store Connect.
The payment rule belongs in the same list. Because guideline 5.3.3 forbids in-app purchase for real-money gaming credit or currency, the wallet and deposit flow cannot be routed through Apple’s payment system. That constrains the client architecture: the app has to hand off to a payment surface the operator controls, and the review notes have to explain how the player funds an account without an in-app purchase of gambling credit. A build that shows a store payment sheet for chips fails on the payment rule before the licence is examined.
What the review notes have to carry
The guidelines treat App Review Information as part of the submission rather than as a support channel. The help page asks for the app’s concept and business model for a new app, the purpose and target audience, the device models and operating systems tested, the external services and platforms that deliver core functionality, and a description of regional differences in features or content — or a confirmation that the app behaves consistently across regions. Backend services have to be live and reachable during review.
For a gambling app, the regional-differences field is where the licence map becomes visible to the reviewer. A build that hides the lobby in unlicensed territories is not the same product in every storefront, and the notes should say so plainly, listing which markets show which product scope. The same page asks for detailed explanations of non-obvious features and in-app purchases in the review notes, and for an active demo account or a fully featured demo mode where account-based features exist. Apple also allows a demonstration mode instead of a demo account where the app handles sensitive information or operates in a highly regulated industry, provided the mode shows full features and functionality using demonstration data.
Geo-restriction evidence is the item teams under-prepare. The published requirement is that the app be restricted to the locations where it is licensed; the review question is how that restriction behaves. The geolocation architecture control contract covers the client side of that boundary. The submission evidence is different: a written description of the refusal path, the licence scope it enforces, and how a reviewer can observe it from a permitted and a non-permitted location.
The EU route changes the review, not the licence
In markets covered by the Digital Markets Act, Apple supports alternative app marketplaces and web distribution, and its guidelines describe notarization as the review path for apps distributed that way. The mechanics are documented: a marketplace or web-distributed app goes through the review type selection, and web distribution additionally requires a registered alternative distribution domain and a public key in App Store Connect, an alternative distribution package assembled with the ID Apple provides, and transaction reporting for the Core Technology Commission where eligible purchases occur.
None of that replaces the licence question. A casino app distributed from an operator’s own domain in the EU still has to be legal in each country where it can be installed, still has to be geo-restricted to licensed territories, and still has to answer the payment rules for real-money credit. The route changes the reviewer, the eligibility checks and the update path; it does not change the regulator’s scope. For a brand whose market list includes both licensed EU states and markets outside the EU, the App Store remains the route with the wider footprint, and the alternative route is a market-specific addition rather than a substitute.
The comparison that matters commercially is the one in the native app or PWA channel analysis: a store binary carries review time and licence documentation per storefront, while an installable web app carries browser and payment constraints instead. Neither removes the licence obligation. The store decision should be made on distribution reach and update control, with the licence pack costed in either way.
What to settle before the build starts
- The storefront list and the licence behind each one, matched to the exact product types the app will expose.
- The publishing legal entity, confirmed as the licence holder or as the entity Apple’s regulated-field guideline permits to submit.
- The geo-restriction refusal path, with the licence scope it enforces written down and a way to demonstrate it at review.
- The payment architecture, settled as a hand-off outside in-app purchase, with review notes that explain the funding flow.
- The demo access route, either a live demo account or a demonstration mode with full features on demonstration data.
- The regional-differences statement, listing which markets show which product scope, so the reviewer reads the app as the operator intends it.
- The update and recertification trigger list, covering ownership changes and licence changes that require a new submission.
If the app is the shop window for commissioned game content, the licence pack is only half the gate: the games behind the lobby need their own market certification evidence, which the localised certification analysis treats as a build question rather than a translation task. Where an operator needs original titles for a licensed app footprint, the Engine project brief is the route to request a project quote, with scope, markets and ownership settled in writing first.
Frequently asked questions
What licence does Apple ask for from a real-money casino app?
App Review’s documentation table lists a gambling licence for guideline 5.3.4, and the help page states that developers in regulated fields must provide documentation showing they are qualified and authorized to provide the services. Where the app is available in several countries or regions, additional documentation may be required for each location where it is distributed.
Can a casino app sell chips through in-app purchase on iOS?
No. Guideline 5.3.3 states that apps may not use in-app purchase to purchase credit or currency for use in conjunction with real-money gaming of any kind. The wallet and deposit flow therefore has to run outside Apple’s in-app purchase system, and the review notes should explain how the player funds an account.
Does a real-money casino app have to be free on the App Store?
Yes. Guideline 5.3.4 requires apps offering real-money gaming to be free on the App Store. The same guideline requires the necessary licensing and permissions in the locations where the app is used and geo-restriction to those locations, and it excludes illegal gambling aids such as card counters.
Can an individual developer account publish a gambling app?
Apple’s guideline 5.1.1(ix) states that apps providing services in highly regulated fields, gambling among them, or requiring sensitive user information should be submitted by a legal entity that provides the services rather than by an individual developer. The publishing entity and the licence holder are therefore reviewed together.
Does EU alternative distribution remove the licence requirement for a casino app?
No. Apple documents notarization as the review path for apps distributed through alternative app marketplaces or from the operator’s own website in the EU, and web distribution adds requirements such as a registered distribution domain and a public key. The licensing, geo-restriction and payment conditions attached to real-money gaming continue to apply on that route.
