The slowest step in a gambling app launch happens before the build
Why getting an Apple developer account for a gambling company is often the slowest step before submission: legal entities, D-U-N-S and brand names.
Ask an operator what will delay their app and they’ll name review. Ask again after launch and a surprising number name something earlier: getting an Apple developer account for a gambling company enrolled, verified and in the right name. It sits outside the engineering plan, and nothing can be submitted until it’s done.
It rarely goes wrong through carelessness. Apple’s enrolment rules ask a precise legal question, and gambling businesses are rarely structured to give a simple answer.
Why an Apple developer account for a gambling company is different
Apple’s guidelines make the account a compliance matter, not an admin task. Guideline 5.1.1(ix) says apps in highly regulated fields, and it names gambling, “should be submitted by a legal entity that provides the services, and not by an individual developer.” Guideline 5.3.4 adds that real-money gaming apps “must have necessary licensing and permissions in the locations where the app is used.”
So the account holder is expected to be the business providing the gambling service, not whoever owns the code. Apple’s enrolment help is explicit that an agency can’t stand in: when a contract developer builds for an organisation, “the organization must be the one to submit the app for review,” though the developer can assist.
That’s why App Store delivery for gambling apps starts with a question about corporate structure rather than code.
The D-U-N-S number Apple developer enrolment depends on
Organisations enrolling in the Apple Developer Program need a D-U-N-S Number, the nine-digit identifier assigned by Dun & Bradstreet. Apple uses it to check “the identity and legal entity status” of the organisation, and it must be registered to the legal entity itself.
Apple says to allow up to five business days to receive a number once requested, and that expediting “will not shorten this waiting period.” Then allow up to two business days for Apple to receive the record from D&B. Any correction to the D&B record takes up to two further business days to reach Apple.
None of that is long on its own. It becomes long when the record is wrong. If D&B lists the business under a different legal status, or hasn’t verified it, enrolment stops with a message that the organisation “is not listed as a legal entity” and complete business registration documents are needed to fix it. Organisations may also be asked for notarised business documents, which for a group registered in another jurisdiction means waiting on a notary abroad.
Brand name, trading name, legal name
Apple states: “We do not accept DBAs, fictitious business names, trade names, or branches.” The legal entity name is displayed as the seller of the app on the App Store.
Most operators trade under a brand that bears no resemblance to the licensed company behind it, so the seller name players see is often one they’ve never heard of.
The surrounding checks follow the same logic. The enrolling email must be on the organisation’s domain, and the website must be public, functional and “associated with your organization.” The person enrolling must have legal authority to bind the organisation, and if they aren’t the owner or founder they need a reference who can confirm it. A brand domain, a group email and a licensed entity in three different places are exactly the mismatch that turns a quick enrolment into a “could not verify organization” stall.
One operator, several brands
Multi-brand operators hit a harder version of the same problem. Each brand may sit under a different licence, and sometimes a different licensed entity, in a different market. Apple’s guidelines tie the submitting account to the entity providing the service, and every app under an account shows that account’s legal name as seller.
Guideline 4.3 also discourages multiple Bundle IDs of the same app, which matters when several brands share one product underneath. How brands, entities, licences and accounts line up has consequences for review, for what players see, and for how the apps themselves are built. Each of those is expensive to change once apps are live.
What it costs
The cost isn’t the annual fee, which Apple lists as 99 USD. It’s the calendar. A finished app waiting on a D&B correction, a notarised document or an authority reference is a launch date moving for reasons no one on the product team can speed up.
The published rules are the easy part. The hard part is matching them to how your group is actually structured: which entity holds which licence, which brands sit where, and who can sign. That answer is different for every operator, and it’s worth having before the build starts rather than after. Read Guideline 5.3 in plain English for the rest of the rule, or get in touch if you want to talk through your own setup.
This is a plain-language summary of Apple’s published enrolment requirements and guidelines, checked on 28 September 2026. It is not legal or compliance advice. Apple’s enrolment requirements, D-U-N-S guidance and App Store Review Guidelines are the authoritative versions.