What a casino app actually costs when you already have a casino
Why published casino app development cost estimates vary so wildly, and what drives the number for an operator that already has a platform and licence.
Search for casino app development cost and you’ll find figures that disagree by two orders of magnitude. Ask how much it costs to make a gambling app and published estimates range from a few thousand dollars to several hundred thousand, sometimes more.
Most of those numbers are answering a different question from the one an operator is asking.
Why casino app development cost estimates disagree
Almost every published estimate prices a casino business from scratch. The game engine or aggregation, the player account system, the wallet, the back office, the licence application, the compliance work. The app is one line in a much larger bill, and the range is wide because the businesses being priced are so different.
An operator who already runs a platform and holds a licence has paid for most of that. What they’re buying is narrower and, in some ways, harder: a mobile app that sits on top of a product that already exists, already has players, and already has its own release process.
So the useful question isn’t “what does a casino app cost”. It’s what determines the cost of this one, on this platform.
What the operator is actually paying for
Four things do most of the work.
How much runs natively. A fully native app, a web view shell and a hybrid are not three prices for the same product. They’re different amounts of code, maintained by different skills, with different ongoing costs. And the split is rarely uniform: a casino lobby and a sportsbook bet slip change at very different rates, which is why the decision is usually made part by part rather than once. We’ve written about how to think about that choice separately.
How many systems the app has to talk to. A casino app is rarely one integration. CRM, KYC, payments, analytics, push notifications, responsible gambling tools, bonus engines, and the platform itself. Each is a vendor with its own SDK or API, its own documentation quality, and its own idea of how sessions and identities work. The number and maturity of those integrations moves the estimate more than the screens do.
How many markets and listings. Both stores tie real-money gambling to where the app is used. Apple’s guideline 5.3.4 says these apps “must have 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.” Google Play requires a valid gambling licence “for each country or state/territory in which the app is distributed”. Every additional market adds paperwork, configuration, testing and store metadata, and it rarely adds them in a straight line.
How much the app has to prove it’s an app. Apple’s guideline 4.2 expects “features, content, and UI that elevate it beyond a repackaged website.” For a gambling app, meeting that bar is part of the build, not a finishing touch.
The cost after launch
Estimates tend to stop at the first approval. The spending doesn’t.
Every campaign that touches native code becomes a release, and every release becomes a review. Operating system updates arrive on the platform holders’ schedule, not yours. Vendor SDKs change. Store policies are revised, and the wording is what review applies. Neither store lets these apps charge through their own billing — Apple’s 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”, and Google Play requires that approved apps don’t use Google Play In-app Billing — so the payment flows stay yours to maintain too.
App Store and Google Play delivery for a gambling app is an ongoing operation. A launch budget that leaves it out is only part of the real number.
The expensive estimates aren’t the ones that come in high. They’re the ones that priced the first release and nothing after it.
Why a generic figure won’t help
The things that drive the cost are specific to the operator: what the web product already does well, which vendors are already contracted, which markets are live and which are planned, how often the product changes, and who will own the app once it ships.
Two operators on the same platform, in the same markets, can end up with very different numbers because their products change at different speeds or their vendor stack is different. A published range can’t account for that, which is why the ranges are so wide.
Getting a real estimate
A useful estimate starts from what you already have rather than from a blank page. It needs your platform, your integrations, your markets and your release cadence on the table, and it should cover what happens after the first approval as well as before it.
If store approval is the part you’re least sure of, Apple’s Guideline 5.3, in plain English covers the published rule. If you’re weighing a native or hybrid app on top of an existing casino or sportsbook and want a number you can plan against, get in touch.
Store policies change, and the wording is what review applies. Quotations are from the published App Store Review Guidelines and Google Play’s Real-Money Gambling, Games, and Contests policy, checked on 28 September 2026. This is not compliance advice.