Hacker News Reader

Comment by irrational | Hacker News Reader

Apple killed Flash by not allowing it to run on iPhones and iPads. It seems to me that Apple is doing the same thing with the features usually associated with PWAs.

It is interesting that Apple devices are far from having a monopoly in the mobile market. Yet their influence is so great that they can kill platforms just by not supporting them.

View on HN

> Apple killed Flash by not allowing it to run on iPhones and iPads.

This old chestnut? This many years on and people still say this?

Adobe killed Flash through their own engineering incompetence, not Apple through policy. Apple's policy merely reflected the liability that the Flash plugin posed.

Adobe could not deliver a version of Flash on mobile that didn't chew up CPU cycles. They tried on Android, it was rubbish, and Adobe themselves deprecated it in 2012. That's only two years after Steve Jobs published Thoughts on Flash.

For Flash content to make any sense on mobile, with its lack of mouse pointer and persistent keyboard, developers could use Adobe AIR, a separate SDK from that used to make Flash web applets. One of the earliest apps ported from Flash to AIR, Machinarium, was a memory and battery hog — not even a new runtime could let Flash content from running unacceptably on iOS.

And all this in addition to Flash spinning up fans on desktops and laptops due to its inefficiency, let alone mobiles. Not to mention the security vulnerabilities in the Flash plugin and renowned instability that caused it to be the major source of browser crashes in Mac OS X.

Between Adobe deprecating their own mobile Flash plugin for running applets in Android browsers, the abysmal performance of Adobe AIR apps, I'm quite happy to say the one to kill Flash was Adobe, not Apple.

Can we put this one to rest at last?

> Yet their influence is so great that they can kill platforms just by not supporting them

Well, aside from not supporting a platform from a vendor that can barely support it themselves, I'd say Apple is more responsible for the rise in adoption of HTML 5 features (WebKit invented <canvas>, iPhone and Android together accelerated websites to display video in HTML players rather than depend on Flash/Silverlight, etc.) than the killing of something that was already dead.

Apple merely saw the writing on the wall. Perhaps they did contribute to making it happen quicker but it would always have happened.

Apple was particularly hostile to Flash.

When Adobe shipped an AIR-based cross-compiler for iOS, Apple amended the App Store terms to disallow building with anything but Obj-C or WebKit.

There was certainly more pettiness there than "Steve didn't think Flash was performant enough."

That particular change to the iPhone Developer License Agreement happened in April 2010. It was relaxed, or rather reverted, in September 2010. The latter version of the agreement actually allowed limited support for running scripts on-device.

> There was certainly more pettines there than "Steve didn't think Flash was performant enough."

It's important to distinguish between Apple not wishing for Adobe to create a meta-platform atop UIKit (which started just prior to the release iOS 4, roughly the start of 2010) and not bundling or allowing the Flash plugin (since day one, mid-2007). Thoughts on Flash reflected criticism received against Apple for that three year run.

It wasn't performant in 2007. It wasn't performant in 2008. It wasn't performant in 2009. It wasn't performant in 2010. It certainly wasn't performant in 2011 when Adobe killed it for Android.

It's not that anybody, let alone Steve Jobs, thought it wasn't performant enough; it wasn't performant enough. Anywhere. On anything. Full stop.

And to say Adobe's technologies made for a lesser experience when used on iOS wasn't entirely unjustified. Reviews for Adobe AIR games released in 2010 and 2011 all centred around one major point: they were CPU hogs that chewed up battery life noticeably worse than other games at the time.

True. Apple is currently the biggest threat to the free and open web as (they even force their own browser engine on their users and ban anyone who tries to use anything else). The EU should step in and force them, just like they forced Microsoft in the past, to allow multiple browser engines on their devices.

There's a huge difference between the EU vs Microsoft antitrust investigations involving Internet Explorer. This was at a time when Microsoft was still the dominant player in the market and IE had a stranglehold on the browser market.

By contrast, Apple doesn't have a monopoly on the mobile device market, the browser market is dominated by Google's Chrome, and the majority share of browsers use Chrome's Blink engine.

'PWA' is a Google-invented term to describe technologies already implemented in their own browser; none of it constitutes a single standard unto itself. Apple not fully implementing Google's standard, made not for the benefit of the open web but to make ChromeOS a little more functional than a glorified web browser, is only a threat to those who've forgotten that coding for one browser is what got us stuck in the code-only-for-IE mindset and halted progress for browsers for about a decade.

Apple isn't the biggest threat to the free and open web. Google is. Everybody's using Google's browser, based around Google's own standards designed to force people to stay using Google, to access Google's search which displays Google's ads above Google's curated AMP results.

iOS safari users have made up at least 50% the traffic of the last few sites I’ve launched. In the US at least they effectively have veto power on new browser features.

They haven’t vetoed any features. Google added a lot of features without implementation (and security) in mind. The last parts of “PWA” are its most vulnerable, and with apple having such small safari team, they don’t have the same capacity to help google do it’s job, since they rushed all the features without presenting to W3C.

Push notifications are the most obvious example of a feature webapps need to compete with native apps that Apple has so far refused to implement on iOS. They’re also much aggressive about wiping out local storage data.

Whether you agree with these decisions or not Apple is clearly and deliberately using its influence to limit what a web app can do.

Apple is clearly and deliberately using its influence to limit what a web app can do, in many cases to protect users against features that are poorly designed and harmful to privacy.

I don't see how supporting push notifications for native apps is any different than PWAs. The user would still have to explicitly enable them for the installed PWA, and could revoke it at anytime. Safari for desktop actually supports push notifications [0]. So why not mobile Safari? Even the their aggressive deletion of local storage could be handled with a permission request. Once you've installed the PWA it could ask the user to store data for longer. Basically what I'm getting at is that Apple already has a robust permissions system that could easily be extended to support PWAs and the necessary features, but they seem to choose not to do so.

[0] https://developer.apple.com/notifications/safari-push-notifi...

Push notifications are just one example. Bluetooth is another - which clearly has privacy issues.

As to why not mobile Safari, perhaps Apple doesn’t want to be tied to limitations of the design?

Apple’s push notifications on mobile have evolved significantly over time.

Just because they could do something, doesn’t mean it is a good design.

Bluetooth does have privacy issues, but again, that's no different than a native app. If I install a native app, it doesn't get free reign over BT or any other device feature. In order to use any hardware feature a native app has to request permission to use it. I don't understand how a web app is any different in that regard. A PWA could specify the features it wants to use in the manifest.json just like a native app does with the Info.plist. Then iOS could prompt the user in the exact same way. If the iOS permission system isn't a good design (I think it is) then why do they keep using it and expanding it for native apps but not use it for PWAs.

Apple has the ability to remove apps which abuse their permission requests, e.g. by lying to the user about what they are going to use the permission for.

Not so with websites. The bar for including new functionality in browsers is way higher than it is for native apis because there is no way to police abuse.

There's nothing stopping apple from blocking app installs from specific domains/subdomains.

Blocking on a per-domain basis is nothing short of an eternal game of cat and mouse.

If they did that, Chrome would become the single browser everywhere, and google would "encourage" iPhone users to stop using Safari entirely.

As it is, developers and management recognize that Chrome !== Browsers, which means that they also budget in Safari, and sometimes FF.

The biggest threat to the open web is Google and Chrome. Apple couldn't imagine being a threat on this scale in their wettest dreams.

https://news.ycombinator.com/item?id=25591824

Reply on news.ycombinator.com