zlacker

>>dochtm+(OP)
I think it's bizarre to conflate Apple's refusal to allow other webkits on iOS with the fact that Safari remains a viable alternative engine. They're far from heroes here. I think it's great they maintain a Chrome alternative kit that mostly works but let's not pretend they're saints or kid ourselves about the reasons for it. The only reason they disallow Chromium and Mozilla is they want their users locked into their environment and they want to leverage that substantial locked-in user base to dictate terms. It's only being one of the richest companies in history that gives them a seat at the table. If they're afraid of having to open the platform, that's because they're not keeping up.

It's not that they're one judgment away from that day. They know that. It's just that they want to get as much mileage as they can before they too abandon Safari and first allow, then switch to Chromium. That will happen in the next 5 years.

What might come of it all would be a reset where new branches form and new innovators get to introduce new proposals. Standards aren't a bad thing if they're open. If Safari dies then Google will be next in the line of fire for antitrust action anyway... things will fragment again. I'm personally pissed at the number of great technologies left as litter along the road, not least AS3, just to get to this shitty middle ground / cold browser war between two companies I hope die and one that won't help itself. Let the standards win and let's have a standard platform to innovate on top of.

>>noduer+Zd
> The only reason they disallow Chromium and Mozilla is they want their users locked into their environment and they want to leverage that substantial locked-in user base to dictate terms

That's one reason, but not the only reason. Security is another big one in that the WebKit process is running with privileges that Apple does not want to award to any other app process on the platform, much less a third-party one.

They also want to make sure that if they fix the next security flaw what will undoubtedly be reported in WebKit, that all the apps with an embedded browser will get the fix and won't continue to be vulnerable due to them not updating whatever version of Chromium they were embedding.

Of course, between sandboxing and not allowing JIT compilation, those vulnerabilities couldn't do do much harm, but that embedded Chromium also wouldn't be much fun to use.

Which means, if you let me make a prediction of the future, that when Apple is forced into allowing other browser engines, articles will be written about how Apple is complying by the letter of the law but not the spirit by "seriously hampering 3rd party engines" compared to their own by now allowing JIT compilation.

If they had to then also allow those 3rd party engines to do JIT compilation and bypass the sandbox in means that browser engines need to, then we'll be in a much worse position security wise.

We'll see how this is going to play out, but I'm pretty sure exerting control is not the only reason for Apples' stance.

>>pilif+Wi
Having a smartphone battery that lasts more than an hour is also a pretty good reason.

It’s like the skepticism over the Steve Jobs “Flash” memo… why do nerds have such a hard time accepting that Apple might actually be sincere about wanting to make a decent product?

>>Eric_W+Fz
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".

>>native+NB
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.