Every operator mobile project starts with the same question, usually framed as a budget decision: do we build native, wrap the site, or ship a web app?
It isn’t a budget decision. It’s a decision about which problems you want to have.
Three options, three sets of problems
Fully native gives you the best performance, the fullest access to device capabilities, and the version least likely to raise questions about whether it’s a real app. The cost is duplication: your lobby, promotions and payment flows now exist twice, or they drift apart.
A WebView shell wraps your existing web product in a native container. One source of truth for the product, and the app follows the site. The cost is that you inherit whatever your web product is like on a phone — and that a wrapper with too little native substance invites the “this is just a website” problem.
A PWA skips the app stores entirely, installed from the browser. The cost is discoverability, and a weaker notification story on iOS.
None of that is controversial, and none of it decides anything on its own.
The question that does the work
Not “which is best” — how often does each part of your product change?
A casino lobby changes constantly: new games, new promotions, seasonal campaigns. Anything living in native code turns every campaign into a release, and every release into a review queue.
A sportsbook’s core betting interface changes far less often, but its data changes every second. That’s the opposite profile — stable interface, demanding data — and it points somewhere different.
Match the architecture to the change rate of each part of the product, rather than making one decision for all of it.
Which is why most operator apps that work well are hybrids. Where exactly the line falls between native and web is the part that’s specific to your product, your team and your release process — and it’s the part worth getting right, because it’s expensive to move later.
What tends to get underestimated
Three areas consistently cost more than planned, whichever route you take: authentication and session state across the native/web boundary, where credentials are stored, and what the product does on a bad connection.
They’re not exotic problems. They’re just rarely in the estimate, and they’re usually discovered by players rather than by testing.
Deciding it for a real product
The generic version of this decision is straightforward. The useful version depends on what your web product already does well, what your team can maintain, which stores you need, and what your release cadence realistically is.
That’s the conversation we usually have in the first week of a project — get in touch if it’s the one in front of you.