The Flash Problem
In 2010, casino games on mobile were Flash-based. You downloaded an app. The app contained Flash Player. The Flash Player rendered games written in ActionScript.
Flash had advantages: high performance, rich graphics, consistent behavior across devices. Flash had catastrophic disadvantages: it drained battery, crashed randomly, required constant security updates, and Apple refused to support it on iOS.
Operators faced a choice: develop separate native apps for iOS and Android, or build Flash apps that worked on Android but not on Apple devices.
Most chose both. Native apps for iOS. Flash apps for Android. This meant codebases diverged. The iOS version and the Android version evolved separately. Bugs on one platform did not exist on the other.
The mathematics of this: develop two games instead of one, maintain two codebases, test on ten different device types per platform. The cost scaled poorly.
HTML5 Arrives (2014-2016)
HTML5 introduced Canvas, WebGL, and modern JavaScript. Games could now run in a browser without plugins. A single codebase worked on iOS, Android, Windows, and Mac.
NetEnt released their first HTML5 game in 2014. It was Starburst, a slot. The performance was acceptable on modern phones. The load time was longer than the Flash version. The visual quality was equivalent.
Pragmatic Play was slower to migrate. Flash was generating revenue. Migration risked breaking working games. They did not commit to full HTML5 rollout until 2016.
Evolution Gaming stayed with Flash for live games much longer. Live dealer requires real-time video streaming plus game state synchronization. Flash handled both well. HTML5's JavaScript was slower at synchronization.
The Performance Window (2016-2018)
By 2016, HTML5 browsers on mobile were faster. JavaScript engines (V8, SpiderMonkey) had optimized for gaming. GPU acceleration worked on most devices. Games that lagged on 2014 phones ran smoothly on 2016 phones.
But the device fragmentation was severe. A game written for Chrome on Android 5.0 might not render correctly on Chrome on Android 6.0. The operating system changed rendering APIs. The game developer had to account for this.
NetEnt handled this by setting a minimum device spec: Android 4.4 or higher. Older devices were not supported. This excluded perhaps 15% of the potential user base, but the 85% who could play had a acceptable experience.
Operators made the calculus: support 85% of players on modern hardware, or support 100% of players with separate codebases and separate bugs. They chose 85%.
The Battery Problem
Flash games on Android drained battery. Users could play for 2-3 hours before the device died.
HTML5 games initially drained battery faster. The GPU was running constantly. The CPU was not idle. JavaScript did not sleep well.
Optimizations came gradually. First: frame-rate reduction. If nothing is changing, reduce from 60fps to 30fps. If the game is idle, drop to 10fps. The visual difference is imperceptible. The power consumption drops by 70%.
Second: offscreen rendering. If the user is not looking at the app, reduce render quality. The game still works, but the phone is not wasting GPU cycles rendering at full quality to a dark screen.
Third: asset compression. Early HTML5 games shipped assets uncompressed. A single game was 50MB. Loading took 60 seconds on 3G. Modern games compress to 10MB. Loading takes 15 seconds.
Between 2016 and 2018, these optimizations converged. By 2018, HTML5 games on mobile consumed less power than Flash games had.
The Edge Case Problem
HTML5 runs in a browser. The browser is a sandboxed environment. The game cannot directly access device hardware (camera, microphone, phone number, et cetera).
Flash games could request hardware access. Users would grant permission. The game could, in theory, abuse that access.
HTML5 can request access through the browser's permission system. The browser controls what the game can do. This is a security advantage.
But it is also a constraint. A game that needed low-latency access to the device microphone for some reason could not get it in HTML5. Flash could.
Operators chose security over features. This was the right choice.
The Real Innovation
HTML5 did not make games faster or prettier. It made games portable. A developer could write once and deploy to 20 platforms instead of writing twice and deploying to 2 platforms each.
This cost reduction changed the economics of game development. Smaller studios could compete. The barrier to entry dropped. More games were made.
Pragmatic Play went from releasing 30 games per year in 2015 to 90 games per year in 2018, largely because HTML5 allowed them to develop faster.
The Present State
By 2024, HTML5 is the standard. Flash is dead. The games are written in JavaScript or TypeScript, often using game engines like Phaser or Babylon.js.
The fragmentation problem still exists, but it has shifted. Instead of iOS vs Android, it is now device capability variance. A 2024 flagship phone renders games differently than a 2020 mid-range phone.
Operators solve this through adaptive quality: the game detects the device capability and scales the render quality automatically. The gameplay is identical. The visual quality varies.
This is the endpoint of the HTML5 evolution. The game plays the same on every device. The experience varies based on hardware. This is acceptable because the RTP is identical regardless of rendering quality.
