Hacker News Reader

Comment by abalone | Hacker News Reader

It's tempting to be cynical but there are good reasons for this. The main good reason is power efficiency. As the seller of the device Apple is the chief party held accountable for poor battery life. You or I or other technical folk might point the finger at particular apps but the typical consumer will just bemoan the "poor battery life on my phone". Apple takes ownership of that outcome and if that means forcing it to be a priority for all browsers, so be it. It's what lets them advertise the battery life for web browsing that they do.

Additionally, I would like to challenge the unsupported notion that WebKit is "stagnation of web browser tech". While there may be issues here and there, my impression is that Apple is overall committed to pushing the envelope[1] and adding compelling features.[2]

[1] https://webkit.org/blog/7122/introducing-riptide-webkits-ret...

[2] https://developer.apple.com/library/prerelease/content/relea...

View on HN

This makes zero sense. You can install 3rd party apps that can do whatever they want (within the limitations of the platform) power-wise. But for some reason Apple needs to limit the special case of apps that are browsers?

I think the most charitable explanation possible is that Apple doesn't want any kind of "open with..." choice ala Android Intents because they aren't very usable. For the same reason they don't allow you to set the maps application or the phone application.

As a person who has done a lot of platform design, I can definitely relate to that desire. OTOH, as a user who prefers Chrome and Google Maps, it drives me crazy that the default is always to open Safari and Apple Maps.

> You can install 3rd party apps that can do whatever they want (within the limitations of the platform) power-wise.

The key phrase being "within the limitation of the platform." Apple's been pretty consistent in designing (and limiting) key developer APIs to be power efficient. And they're willing to ship later to achieve it. I mentioned WebKit. A more obvious example of this is their approach to multitasking. Android let apps do more or less whatever they wanted and they supported multitasking first. Apple waited until iOS 4, but the more structured and regulated set of APIs they came out with was much more battery friendly.

> I think the most charitable explanation possible is that Apple doesn't want any kind of "open with..." choice

Yet iOS 8 added a bunch of extension APIs.[1] You can literally open content in other apps via the system share dialog, including third party mapping and voip apps. The stated reasons for waiting until iOS 8 were that they needed to do a bunch of architectural work first.[2]

[1] https://developer.apple.com/library/content/documentation/Ge...

[2] http://www.imore.com/our-full-transcript-talk-show-wwdc-2016...

Your argument is still not making much sense. I don't see how the power efficiency of the APIs is relevant. The point is that they currently allow tons of applications (E.g. Candy Crush) that drains the battery. What's the reason for making the browser a special case? It's just rendering to the screen like any other application.

One argument I could see being made is that the browser is used more than others and thus warrants tighter control. But even that is weak. People are draining their batteries all day long playing games as it is.

I believe that the real reason is that Webkit needs privileged APIs and unique executable memory regions for the jit. Giving third-party developers that access would make jailbreaking a simpler process.

Anything that makes jailbreaking simpler also makes it easier for the device and data to be compromised.

Apple might have walled garden motives, but the security story is compelling on its own.

> The key phrase being "within the limitation of the platform." Apple's been pretty consistent in designing (and limiting) key developer APIs to be power efficient.

Which I applaud. But those APIs constrain all applications equally.

So if Apple allowed browser applications to include their own rendering engines, their APIs would naturally constrain those applications too.

Now it could be that Apple does not want to enable applications other than WebKit access to APIs that would allow jit compilation. OK, that is reasonable. But in that case, why not allow browsers to provide their own rendering engine but just mandate that only JSC is allowed to run JS?

Or why not just say that only Apple apps can jit and let the market figure it out?

(I'm going to drop the thing about 'open with...' because it was a distraction and ancillary to my main point, which is that Apple is doing this because they want to control progress of the web platform on iOS)

>This makes zero sense. You can install 3rd party apps that can do whatever they want (within the limitations of the platform) power-wise. But for some reason Apple needs to limit the special case of apps that are browsers?

This objection makes zero sense. You cannot install any 3rd party app, just those that got approved. And a power hog or whatever app can always be de-approved.

Not so much with web apps.

They could de-approve browsers if they were inefficient too. Webkit on iOS is extremely conservative in terms of energy use, but it does not make it impossible to create a webapp that would drain your battery.

Yeah na. Facebook app have been a power hog for years and they allowed it because it's popular. Let's face it, Apple just does whatever Apple wants.

And they get away with it because they're Apple.

See also: removal of the headphone jack, massive backlash, everyone still bought the fucking thing

Yep. I hear "we can't do anything about it" all the time. Politics, economics, demographics. But the thing is, people have a voting bulletin they can use every day, the bank note, and that is always listen to. And they don't use it to vote.

Facebook is very privileged by Apple, for instance see React Native which somehow is allowed to circumvent the usual "no download of code". It's the exception that proves the rule.

Um, no. Just look at sites like caniuse.com and see how much farther ahead Chrome and Firefox are than Safari iOS. Safari iOS has become this generations IE 6. It is seriously holding back the web. And worst of all it really only gets one update a year!

It is possible for one's utility function on web browsers to weight speed and power consumption more than standards compliance.

WebRTC and many other major features are still missing from Webkit on iOS, whereas in Chrome & Firefox I can have a full WebRTC client on mobile.

That's consistent with the parent comment. They're working on WebRTC.[1] Possibly they're making it power efficient first and then shipping, as opposed to shipping and then making it efficient.

[1] https://webkit.org/status/#specification-webrtc

And Chrome is reportedly more of a battery hog on macOS[1][2] and Windows[3]. So there you go: different priorities.

[1] http://www.techrepublic.com/article/browser-wars-is-chrome-o...

[2] http://www.theverge.com/2015/4/10/8381447/chrome-macbook-bat...

[3] https://www.extremetech.com/computing/230583-microsoft-claim...

[1] is not good article, no test, no numbers. [2] neither is this. no info about the test other than the results. just knowing that chrome rendered flash by default at the time of this article, i know its irrelevant. [3] claims 70%...

False. From [2]: "The native Safari made the new Retina machine look good: 13 hours and 18 minutes. Google’s Chrome, on the other hand, forced the laptop to tap out at 9 hours and 45 minutes."

Anecdotally, Chrome uses dramatically more memory and CPU than Safari for me (note: I typically have 100+ tabs open at once), and gives me somewhere between half and two thirds the battery life, for the same type of use. I have flash turned off for both and most ads blocked via /etc/hosts, so there shouldn’t be anything especially unfair in the results.

Google web apps (gmail, google maps, etc.) seem to be a particular offender.

It's not holding back the web, settle down! It can still render websites perfectly fine and will continue to do so.

Seriously, what horse are you backing where iOS Safari is compared to IE6?!? What oh-so important feature you simply must-have, that would even begin to signify that iOS Safari is "holding back the web"?

The web dev world is absolutely mental at the moment...

There are a lot of quirks with Safari that are similar to the way IE6 eventually stopped following standards.

That fact that localstorage doesnt work in private mode is 1 example.

Where is the W3C standard for private browsing mode?

There isn't one, that's why it should behave like a normal browser (from the web dev perspective) even while in private mode.

That doesn't follow. If it literally behaved like a normal browser that would break the privacy guarantee of private mode. In fact you could argue that browsers that implement localStorage in private mode are the ones who are not standards compliant.

From the Web Storage spec: "[localStorage] is designed for storage that spans multiple windows, and lasts beyond the current session."[1] Thus if a browser is discarding localStorage prior to the end of the current session, it's explicitly against the spec.

This is more than academic. If apps aren't written to explicitly use ephemeral storage then they may not function as expected in private mode, like, say, unexpectedly causing data loss.

[1] https://www.w3.org/TR/webstorage/

I can see why that'd make someone cross, but it seems in line with how localstorage works + how browsers define their "private browsing" features. On Chrome, for example, when in Incognito mode, you can't undo-close-tab a tab after closing it. Effectively, every tab you open in these "private browsing" modes will sooner-or-later "self-destruct", including all its cookies, localstorage, etc. (iOS?) Safari just chooses "sooner" rather than "later."

If your site relies on using localstorage during the lifecycle of an individual page, you can always replace it with an in-memory mock polyfill if you notice it's missing. There's probably an NPM package for that.

The point of standards for browsers is that you shouldn't need a polyfill just to support a feature (localStorage) in one browser. Ideally, it would just destroy its contents after your private browsing session is done, just like the way (I believe) all browsers treat cookies in private browsing mode.

Sure, what I'm saying is more that localStorage doesn't have the standards equivalent of an SLA guaranteeing it'll work for the "within the lifecycle of one page" use-case. Apple, I think, are just being opinionated (and pushy) here: they think the right way to tell a web-app "your localStorage won't save" is to undefine the API, making trying to write to or read from localStorage raise an exception, so that your app is then forced to decide whether it can go on without localStorage (by handling the exception, or by using a polyfill which does the same) or that it can't (by just telling the user "don't use this page in Private Browsing mode, doofus!" and stalling out.)

It's certainly not the approach everyone would be happy with, but it allows developers much more flexibility than the contrary case, where private browsing is a silent effect that might make apps do very stupid things (like, say, downloading the same huge asset bundle into localStorage over and over.)

> downloading the same huge asset bundle into localStorage

This would happen anyway no matter what storage or cache is used since all data is cleared after private browsing session is over.

Breaking localstorage (with an over-quota error) is not the way to deal with this. Polyfills are just more crap in complexity and downloaded bytes to compensate for a browser's issues.

It would be much better to have a navigator.isPrivate flag enabled so apps can check the environment accurately, not guess based on whether certain APIs work or not. It's not about SLAs but supporting standards. Deleting client-side data is all that private browsing needs to do.

That's not sooner vs later. That's breaking functionality.

Private mode means deleting the data, not disabling the functionality. Chrome and the rest handle it correctly.

Web components, Progressive Web Apps, Fetch, etc.

I'd pay top $$$ if someone could show me how to let a mobile Safari user record audio on their microphone and submit it. iOS doesn't permit this in any way, whether it be with getUserMedia or media capture forms. The only way to do audio recording is to build an iOS app just so I can get this one simple feature which is exactly what they want. Repeat this story for a dozen other features as well.

Apple's total opaqueness on what their plans are for the future functionality of their browser certainly doesn't help either.

This is a feature I would really like to have.

I tried to circumvent it a while ago when I was playing with the Web Audio API by allowing an iOS user to "upload" a video, from which I would then extract the audio using decodeAudioData. Unfortunately it returned an error on callback in iOS.

Perhaps it could still work by processing said video on the server and sending back the audio, but keeping everything client-side was my requirement.

Web pages that can access the microphone sounds like an absolutely insane idea to me, but then like I said, web dev is absolutely mental at the moment...

get off my lawn etc.

So Safari doesn't hold the web back like IE6, because the ways it's hold the web back doesn't count because you don't want those features.

Not buying it.

I'm suggesting that the web is fine - its stupid nonsense like javascript access to the microphone that gives the illusion that the web is moving forward, and that some people are freaking out proclaiming the end of days because some ridiculous feature hasn't been implemented.

How is it ridiculous just because it's a feature you don't use?

There are plenty of uses for newer standards, that's why they're created, but it only works if the browsers carry their weight and implement them consistently. Safari doesnt, and is thus holding back the progress, just like IE6+ did.

Web development relies on browsers. There is nothing mental about this.

Service workers are another example of a feature that is missing in Safari. And an important one for offline support.

Yeah, can't wait for web apps to drain my battery when I'm not using them too.

Web should be just HTML/CSS, no JavaScript at all, so no need for service workers.

Service Worker!!!!

Its absence is a crippling limitation.

+1. This is the main problem right now, especially since web workers are a workaround for anything blocking the main thread, like some local storage.

Safari has so much better HLS video streaming support on iOS then chrome. Chrome has caught up a little bit but the documentation still sucks.

Uh, duh? That's because HLS is not a web standard and never will be so nobody else is going to bother building it into their browsers. The standard (ISO/IEC 23009-1:2012) way to do adaptive bitrate streaming is MPEG-DASH.

Microsoft Edge and Chrome on Android both support HTTP Live Streaming.

Not sure if you're serious about 1 update per year...iOS has ~4 major releases per year. (9.0, 9.1, 9.2, 9.3). Safari receives updates in each one. iOS 10.3, which is in beta, comes with tons of Safari changes.

>Safari iOS has become this generations IE 6

Yeah, the kind of "IE6" that beat Chrome and Firefox last year to be the first to fully support ES6 for example.

https://twitter.com/webkit/status/728643624464883712

Check http://caniuse.com/#compare=chrome+59,safari+TP yourself, and you see the differences in scores is mostly because they give 1 point to every API, however non-important it is. Meanwhile, Chrome supports some good ones (File Storage, WebRTC, Pointer Events etc), but Safari supports some good ones that Chrome doesn't too: MathML, HTTP Live Streaming, Video and Audio Tracks, SVG fonts. But Chrome also tries to push various proposals of (mainly) theirs, down everyone's throats.

MathML has been dead for years. HTTP Live Streaming (HLS) is not part of the spec and never will be. What is part of the spec is MPEG-DASH. But, File Storage, WebRTC, and Pointer Events? Those are actually useful for modern web development.

"But Chrome also tries to push various proposals of (mainly) theirs, down everyone's throats."

Never experienced that with chrome, but I developed a kind of hate towards mozilla, for forcing IndexedDB and IndexedDB ONLY and refusing for anything else and therefore killing FileAPI and WebSQL

Non-browser apps can kill your battery just as much. Why would it make sense only to restrict browsers in this way?

It doesn't restrict just browsers, but every app that uses a WebView. This also isn't the only thing they're doing on that front.

It seems unlikely that a non-browser app would embed some other engine. I don't think I've ever seen that done on the Mac, for example.

What about every Electron app?

Does it count if it's not being used to actually browse the web? I believe Apple would allow that even on iOS.

In the case of Electron, the application is the webpage. Apple allows web apps built with Cordova on iOS, but warns that they may be rejected in the approval process if they run too slow.

I kind of doubt it. My understanding of the rule is Apple will not allow any alternate web renderer on their platform. You might be able to get away with the old opera mobile thing of having another server render the image and just serve the image on the phone, but no one wants to actually do that.

I'm puzzled at how this reply coexists with the other, older reply next to it pointing out an example of where Apple does allow exactly that.

Allowing a custom web browser is different than allowing a system wide custom WebView... Since you can't currently do anything similar that's a weird complaint.

For example, I have Google Maps installed, but if I make an app and add an MKMapView it is the same old Apple Map it is everywhere.

"Just as much" is a bit of an overstatement considering how primary web browsing is. I mentioned one reason: it's what lets them advertise the battery life for web browsing that they do. Web browsing is a distinctly primary use case for a wide range of people and a fundamental value proposition of the iPhone from day 1.

Another thing that makes browser engines special is that they can be used to build "native" apps. Apple famously banned Flash. But if they allowed you to use any old web engine they could run into the same problems with poorly optimized apps on their platform. So Apple's not just forcing other browsers to adhere to their efficiency-first priorities... it's forcing all apps.

They could easily stick a "* using Safari" on the battery life claims if it was about advertising.

Apps are free to be inefficient. You can use some horribly slow JavaScript engine and build all your code that way. You can use Python or Ruby. Another comment mentions that Cordova apps are allowed, so it doesn't seem like the WebKit requirement even applies when building "native" apps.

No one cares, no one reads asterisks. There often useful/important, but they might as will not be on boxes. Either that or they signal a lie. Like the old windows laptops that used to advertise great battery life is long as you didn't actually move the mouse or do anything and had the display brightness at zero.

The other commenters are right. If people bought an iPhone, downloaded Chrome (the REAL Chrome), and use their phone and got six hours of battery life who do you think will get blamed? Apple.

People here all sorts of stories about how Apple doesn't have good battery life in the use chrome on their computer and it doesn't cause their computer to have five hours of battery life (even though Chrome is a known battery hog) so it must be Apple's fault. Blame the $900 phone.

For battery reasons alone I completely understand Apple's decision. There are plenty of other issues, such as keeping things updated with the latest iOS API is that are needed by the default browser, although some of that could be worked around with large third parties like Google.

I know they were missing features the people are absolutely clamoring for here on HN, but every time I asked they never seem to be something that I care about. I don't really care about web RTC, I don't remember the last time I wanted to have a webpage record audio, the fact that local storage doesn't persist across private browsing tabs is a FEATURE to me.

I think this fits well with the other article that's currently on the front page. Lots of people here in another text sites trounced Apple for their computer updates this year, but normal users seem to be very happy with them. A lot of these positions seem to just be too far out of Main Street (and there are so many iPhone sold that mainstream is GIGANTIC).

And when they download Clash of Clans or whatever the hot new game is, and the battery lasts 90 minutes, Apple doesn't get the blame? If it was about ensuring battery life stayed high even when the user is clueless, they'd be doing more than they are.

The only thing I can say is games are different. People seem to have a since the games can use a lot of power and be willing to accept that. And you're definitely not wrong, many of them are written terribly and destroy battery life unnecessarily.

But the other thing is it's obvious when I play a game. Where is I don't really think about using Safari, but I'm sure I use it dozens and dozens of times a day. So I'm very conscious of the fact that Pokémon go or whatever else I'm playing eats my battery, but all the little interactions with the web browser eating an extra 20% probably wouldn't raise a flag for me; I'd just think my phone's battery life got a lot worse.

That's my best guess anyway

> And when they download Clash of Clans or whatever the hot new game is, and the battery lasts 90 minutes, Apple doesn't get the blame?

Correct. If it lasted 90 minutes they would clearly attribute it to playing the game. If however a regular mix of typical daily activities gets low battery life, that's just the phone's fault.

But I would add that Apple has done a lot of work to make their game APIs power efficient. Metal is a perfect example of a more proprietary approach that achieved significant speed and battery life gains.

You're right, they have done a ton of work. Unfortunately, you can't make developers use it. So you find some games that don't seem to do too much but waste your battery, and others that are very impressive and barely touch it.

I'm looking at you Pokémon GO.

Note: I see that "no one cares, no one reads asterisks" sounds really harsh, if anyone is taking issue with that, and wasn't aimed at the GP. I simply meant that people (including myself) don't tend to take them into account so I don't believe it's a good solution to the problem.

Sometimes it is wise to be cynical, especially when dealing with companies which pride themselves on their profit margins while keeping their users at a tight leash. Doing anything else is not only bad for your budget but also rather illogical, knowing that those profit margins depend on keeping users' noses pointing in the 'right' direction.

So, yes, there are good reasons for Apple being very determined over what you can, and more importantly can not do with Webview and Safari on iOS: they do not want iOS to become too good a host for web-based apps for fear that they might out-compete appstore-bought apps as Apple does not make a cent off the former. This is also why Apple does not allow other 'real' browsers on iOS as those could be used to circumvent these restrictions. That thing about power consumption goes just as much for other apps as it does for web browsers so it is rather easy to defeat that argument.

"stagnation of web browser tech": why do you think Blink became a thing in the first place? Also: Progressive Web Apps and Web Components are not fully there yet on Safari (WebUSB, WebMIDI, etc...Look it up). It is not in their interest to move App developers to the web and AFAIK, they didn't start moving again until too many made fun of them, calling Safari the new IE6.

Safari has one of the best Web Components implementations, with excellent Shadow DOM and Custom Elements compliant to the latest spec in the Safari 10.1 beta. These are the two most essential Web Components specs.

By comparison, Edge doesn't have either, and Firefox has no Shadow DOM and old out-of-spec Custom Elements.

How is it that Safari is holding the web back in this area?

(WebUSB and WebMIDI have nothing to do with Web Components, they are hardware-specific device APIs.)

> My impression is that Apple is overall committed to pushing the envelope and adding compelling features.

Have you used WebKit? I'm running into issues with bugs that were reported 2+ years ago.

All browsers have these sort of bugs. This is not unique to WebKit. All browsers have "quirks". All browsers have parts of standard APIs that they implement incompletely or slightly different. None of this is unique to WebKit.

I think it is really simple. I don't think it has anything to do with power efficiency. If anything resemble notable cause, then Apple simply wanted to be the sole API provider. Apple doesn't want Mozilla / Microsoft / Google / Opera etc implement their own browser engine and demand or even dictate Apple's iOS implementation roadmap. It's better off the have the full control of what developers can do on iOS.

> but the typical consumer will just bemoan the "poor battery life on my phone"

There's a quote:

"Make a system that even a fool can use, and only fools will use it."

Except it isn't true in this case. Which is unfortunate because developers should know better: supporting only a single brand is bad for competition, and will turn computing into a monoculture.

> The main good reason is power efficiency.

It would be great if there was competition so that other browser developers could try to improve power efficiency even more.

When Chrome stops trying to melt peoples computers, I'll give them more of a chance. It's been well known for years the chrome is very hard on battery life compared to Safari, and while they seem to be working on it they're still WAY behind. It doesn't seem to be a high priority for them (relative to new features), so I don't see why they even try.

It doesn't have to be Chrome. It could be Edge, Opera, Firefox or some other browser that's yet to be invented. Currently none of these will ever exist on iOS.

Forcing Webkit on errybody might be mainly a security thing. Also, depending on what counts as security, maybe Apple doesn't want analytics on everyone's web browsing experience sent to Google.

> You or I or other technical folk might point the finger at particular apps but the typical consumer will just bemoan the "poor battery life on my phone".

You don't give people a lot of credit for even minimal logic with that statement. I've dealt with a large number of low-tech users and every. single. one. of them has understood the relationship between battery life and the applications they run.

They also understand what having GPS, active WiFi and watching a couple of hours of video will do to their batteries. The only ones that have a problem with this are the ones that pay $800 for a device that struggles with normal 2-day usage because thin trumps mAh.

Reply on news.ycombinator.com