Add Games to Your App: Run an HTML5 Game Inside a WebView
How to put a finished HTML5 game inside an Android or iOS app you already have: local or hosted files, saves, the back button and the licence.
To add games to your app, you do not need a game engine inside it. You need a WebView: the component Android and iOS provide for showing web content inside a native screen. You put a finished HTML5 game folder either inside the app package or on your own HTTPS server, point a WebView at its index.html, and your app gains a games section that runs on the same code as the browser version.
This guide is for teams that already have an app (a retail app, a bank, a school platform, a club or a media brand) and want in-app games as a feature, not a new app in the store. It covers the choice between local and hosted files, the WebView settings that break games when they are wrong, saving progress, the back button, which of our templates fit, and how the licence counts apps. Platform details come from the Android Developers and Apple Developer documentation, read on 30 October 2026.
Add games to your app: how the WebView route works
A WebView is a browser engine without the browser around it. Your native code creates it, decides its size and settings, and tells it what to load. On Android the class is WebView; on iOS it is WKWebView. An HTML5 game does not know the difference: it sees a page, a canvas and storage, as it would in Chrome or Safari.
That is why the route is popular for in-app games. The game team works in HTML, CSS and JavaScript, the app team adds one screen and a few settings, and the same game folder can also live on the website. There are three moving parts to plan:
- Where the files live: packed inside the app, or served from your HTTPS server.
- How the WebView is configured: JavaScript, storage, the address the game runs from.
- How the game and the app talk: opening, pausing, the back button, closing.
Our templates fit this shape because each one ships a ready game/ folder with an index.html, built for static hosting, with no PHP or database needed for the game itself. What none of them includes is the native part. Every edition lists native apps or app-store builds under "Not included in this edition", so the WebView screen is your team's work, or a job we quote separately.
Browse the HTML5 game templates
Local or hosted: where the game files should live
Local: the game ships inside the app
Android's guide to loading in-app content says web content compiled into the app does not need internet access or use the user's bandwidth. You copy the game/ folder into the app's assets and load it from there. The price is size: the game adds to the download, and every game update means a new app release through store review.
Hosted: the app loads the game from your server
The WebView opens an HTTPS address on your own domain. You can update the game without a new app build, and the app stays small. The price is that the game needs a connection, and a slow network shows up as a slow first load.
Apple has a specific rule here. Guideline 4.7 of the App Review Guidelines covers HTML5 and JavaScript mini games that are not embedded in the binary. Among its conditions, the app may not extend or expose native platform APIs to that software without Apple's permission, and it must provide an index of the software it offers, with universal links. Read 4.7 in full before you choose the hosted route for iOS.
- App size: local adds the game's weight; hosted adds almost nothing.
- Updates: local needs an app release; hosted changes when you upload.
- Connection: local can start without a network once installed; hosted needs one.
- Review: local games are reviewed as part of the app; hosted games on iOS fall under guideline 4.7.
Android WebView settings that make or break a game
Most "the game shows a white screen" reports come from three defaults. All three are documented on Android Developers.
- JavaScript is off. The WebView guide says JavaScript is disabled in a WebView by default. Every HTML5 game needs it, so enable it in WebSettings.
- Storage is off. The WebSettings reference says the default value of setDomStorageEnabled is false. Games that keep progress in localStorage need it on, or every session starts from zero.
- file:// is the wrong address. Android's in-app content guide explains that file:// URLs are opaque origins that cannot use APIs such as fetch() or XMLHttpRequest, and recommends against turning on the file-access workarounds. Our item pages say the same from the game side: editions such as Gridspark and Twirldrop do not run from file://.
The fix for the third point is WebViewAssetLoader from the AndroidX Webkit library. It serves files from your app's assets over an HTTPS address, and Android's own example loads https://appassets.androidplatform.net/assets/index.html. To the game, that looks like a normal website, so ES modules, fetch and storage behave as they do on your server.
iOS: WKWebView, local files and the data store
On iOS the component is WKWebView. Apple documents loadFileURL(_:allowingReadAccessTo:) for local content: the second argument is the file or folder WebKit may read, and passing a folder lets the page load the files around it.
Because our editions do not support opening from file://, test that path carefully, or skip it. Apple also provides WKURLSchemeHandler, a protocol for loading resources with URL schemes WebKit does not handle, so your app can serve the game folder under its own scheme. Capacitor does this for you: its default iOS scheme is capacitor.
Storage lives in the WKWebsiteDataStore. Apple's page says the default store saves website data persistently to disk, and that a non-persistent store keeps data only in memory, which is meant for private browsing. If someone on your team sets a non-persistent store, players lose their progress every time the app closes.
iOS has no system back button, so your games screen needs its own way out: a close button in your native bar, or one the game calls through a message handler.
Saving progress inside the app
Our games save in the player's browser storage, not on a server. Solitaire Links and Deepforge say it plainly on their pages: progress is kept in localStorage, with no account or cloud sync. Inside an app that has three consequences.
- The address is part of the save. Browser storage belongs to an origin. If you move from one scheme or host to another, for example from a test domain to appassets.androidplatform.net, players start again. Pick the address once.
- The save key is part of the save. The Tenguin item page tells buyers to keep the save key unchanged on a live game, or players lose their progress. Several TypeScript editions keep the storage key in brand.ts. Change it on purpose, before launch, never after.
- Clearing app data clears the game. Uninstalling or clearing the app's storage removes the save, just as clearing a browser does.
If progress must follow the user across devices, that is a server feature none of our editions include. Every edition lists cloud saves or accounts as not included. Deepforge is the friendliest starting point: its page describes export and import of the save in the menu, and a small window.DeepForge API that lets the host page pause, resume, read the save and listen for save events.
See Deepforge and its host-page API
The back button, pausing and leaving the game
HTML5 games are usually a single page. That matters on Android, where the back button walks the WebView's history. Android's WebView guide shows the pattern: check canGoBack() and call goBack(), or let the system handle the event; with AndroidX you register the same logic on the OnBackPressedDispatcher. In a one-page game, history is often empty, so back closes your games screen at once, in the middle of a level.
Decide what back should do and write it down:
- First press opens the game's pause menu; second press leaves the games screen.
- Or back always leaves, after the game has saved. Every edition saves locally, but check when it writes: at the end of a level or during play.
- When the app goes to the background, pause the game. Without the pause, timers keep running behind your app's other screens.
Our editions do not come with an app bridge. What some offer is a way in from the page: Gridspark and Ricopop have a tap-to-start screen and a full-screen button you switch on or off in a config file, and Deepforge exposes pause and resume to the page. Anything else, such as a message to native code when a level ends, is a small change in the source that your team or a quoted job adds.
See Gridspark, plain JavaScript with no build step to play
Licence: one game, one app, and what to ask first
Our terms give a perpetual, non-exclusive licence to use the edition in one end product, for you or for one client. Your app with its games section is that end product. Players may access it free of charge or through advertising monetisation. You may change the code, art and audio, and white label is allowed: your brand replaces ours.
Three situations need a closer look.
- Several apps. An agency putting the same game into three client apps needs three licences. Buying several templates in one order gives a bundle discount: 5% for 2, 10% for 3, 15% for 4 and 20% for 5 or more.
- Android and iOS versions of the same app. One licence lets you publish that game wherever you want, Google Play and the App Store included. It stays one licence per end product.
- A games SDK for other developers. The terms forbid redistributing the template or its code inside another product meant for developers. A games module you sell to other app makers is that kind of product.
If your app charges for the games section or sells items inside it, ask us first too. The terms name free access and advertising monetisation, and several editions list real-money purchases as not included. On iOS, guideline 3.1.1 says that unlocking features or content, game levels included, must use in-app purchase.
Licences, invoices and quotes for companies
FAQ
Can I put an HTML5 game inside an Android or iOS app?
Yes. Load the game folder in a WebView (WebView on Android, WKWebView on iOS), either bundled with the app or from your HTTPS server. Turn on JavaScript and storage, and serve the files from an HTTPS-style address rather than file://.
Do the games work offline inside the app?
Only if you bundle the files and the edition loads nothing from the network. Several of our editions keep art, audio and fonts local; Ricopop's page says it needs a connection. Test in airplane mode before you promise it.
Will players lose progress when I update the app?
Not if the address and the save key stay the same. Saves live in the WebView's storage for that origin. Changing the scheme, host or storage key starts everyone from zero.
How many licences do I need for my app?
One per end product. One app with one game is one licence; the same game in apps for three clients is three. The same app on Google Play and the App Store needs no second licence: you may publish the licensed game wherever you want.
Next step
Pick a game, play its demo on a phone, then read its "Not included in this edition" list and its manual's chapter on saves. If you would rather we build the games screen into your app, send us the app, the platforms and the game you like, and we reply with scope, price and timing.