It's because there's nothing magical about HTML that makes it more battery efficient than Flash was. Quite the opposite really - Flash is a compact binary format designed specifically for high graphics performance in an era when HTML4 thought floating menus was cutting edge.

The Jobs Flash memo was crystal clear about why Flash was being booted off his platform. It was to avoid "a third party layer of software coming between the platform and the developer".

Flash didn’t have to be inefficient, but Adobe’s implementation certainly was. I remember the Mac version of Flash pegging the CPUs of PPC G5 and Core 2/Core 2 Duo based machines, turning them into space heaters until the user navigated away from the page containing flash elements. For the vast majority of what Flash got used for, that was in no way justifiable, particularly on devices like laptops and smartphones.

HTML5 by and large didn’t have this problem. Was it possible to write a grossly inefficient HTML5 site? Yes, of course, but it wasn’t the default state, as evidenced by how much happier those same machines mentioned in the last paragraph were when running e.g. the HTML5 YouTube player instead of the flash one.

There’s nothing “magical”, but Safari uses a lot less battery than Chrome.

Safari developers optimize for battery life whereas Chrome developers seem not to care about client-side resource use.

Right, yet, Chrome has an enormous number of Mac users. Apple argue that battery life is a topic so important it's worth banning competitors for but clearly when given the choice users disagree. There are other things more important to them.

My impression is that most computer users have a limited sense of which software applications are churning through battery, and instead just blame the computer vendor.

That is, if Chrome churns through battery on a Mac laptop, the typical user is going to just think “Apple laptops have poor battery life”, never realizing that switching to Safari would make a significant difference.

SWF is a compact format, but that doesn't get you an efficient Flash Player. Apple put in a lot of work to make HTML battery efficient and usable on a phone, and Adobe didn't[0] do the same with Flash. In fact, Apple more or less begged Adobe like four times to make Flash work well on phones! Adobe wanted to push that work onto their customers instead of putting work into making every Flash movie ever authored work good on a phone.

The real bullshit about the Jobs Flash memo wasn't that it was justifying not shipping Flash Player on phones, but that it was justifying banning apps that used any third-party developer tool. Adobe had decided to just ship a packaging tool that let you stick a SWF and Flash Player into an iOS app; which Jobs considered to be a way to pollute the App Store with garbage apps. Except this wasn't a ban of one specific developer tool, it applied to everything that wasn't entirely C, C++, Objective-C, or JavaScript[1]. This only lasted about 3 months because...

1. A lot of mobile game developers were already using scripting tools that violated the new rule, and the games they were shipping were not garbage

2. The FTC was threatening to sue Apple

After that, Apple caved completely. In fact, if you've played iPhone games, you've probably already used Flash Player on iPhone. Jobs' fear was mostly unfounded because developers absolutely could make performant mobile games in Flash and ship them as apps. The problem was that they had to work around all of Flash's legacy crap to get there.

[0] Safari has several UI affordances for mobile web usage that Flash never got. Notably, those "cutting edge floating menus" still work because Safari treats finger touches as either a hover or a click, and picks between the two based on how the page changes when it simulates a hover.

Furthermore, browsers around this time were moving to GPU compositing internally, but Flash has always been built around a particularly quirky scanline renderer. Getting that to work on GPUs was apparently too much for Adobe, and even Ruffle has rendering problems caused by it.

[1] The language in the developer agreement was "originally written", so no, transpiling doesn't get you out of this.

People who don't know conflate Flash as a browser plug-in with all AS3 (e.g. Air apps that run in a native container). You couldn't expect a browser plugin at that time to have GPU access, but Air apps sure did and we used it all the time to make our games run smoothly.

The same people will say Flash was slow by default. I remember running canvas vs flash rendering tests in mobile Safari when the plugin was still available, and Flash blew canvas rendering away. Of course it was all about what you chose to do with it... no one was writing really complicated behaviors in canvas at that point, and wasm didn't exist, so if you wanted special animation or complexity you used Flash. The appropriate thing would have been to have Flash off by default until someone tapped an embed to load it.

Adobe expecting Flash authors to make versions optimized for mobile wasn't particularly crazy though, was it? That's exactly what browser makers expect mobile site developers to do. A non-mobile optimized site mobile is an awful experience.

W.R.T. compositing, browsers took a long time to move to even just GPU based compositing, and full GPU based rendering took longer still. Certainly, if Flash hadn't been killed off so prematurely it seems reasonable that either they'd have done the work to keep up, or users would have organically abandoned the platform.

Indeed, you make a good point that it was really a fight over forcing devs to use Objective C and nothing else. Flash was just roadkill in that fight.

>> Adobe expecting Flash authors to make versions optimized for mobile wasn't particularly crazy though, was it?

It took a few years for plain old HTML/JS sites to be optimized for mobile, and not many of them were then. Given some time, Flash devs would have too. I'd already optimized my own and was optimizing a Flash-based gaming site for mobile when Apple pulled the plug.