Personally mandating a single WebView on iOS ends up being a good thing for iOS Users: a fast, responsive, quality rendering engine that has the same experience everywhere and gets updated with each major iOS release - dramatically reducing the permutations of rendering engine versions that needs to be tested against and supported.
One of the liberating things when first developing a Web App for iOS was only having to support a single modern browser, allowing usage of advanced features which weren't crippled by having to gracefully support old IE versions. Only having to target a single platform with limited resolutions is also one of the few benefits I see with native iOS development.
Apple have always put the end Users Experience before Developers, so it's primarily focused on maintaining a fast, fluid browsing experience on iOS which is the most used browser for tablets and smart phones and IMO still continues to provide the best browsing experience on any mobile device.
So it doesn't follow the feature-mill factory pushed by other browser vendors, I still prefer iOS's performance focus, yearly upgrade cycle which thanks to iOS's fast upgrade adoption, iOS Web Developers get to enjoy adopting new features long before Android Web Developers who have to support the old browsers shipped on JellyBean.
Actually really agree with this. As someone who develops for Android I can't tell you much potential "mental damage control" you have to be prepared for with implementing stuff. Accommodating the different support packages, APIs, device & hardware specifications - it's a headache sometimes. But I think that's part of why I love it too, the freedom and "openness" relative to iOS eco system.
That being said - Apple might be closed and all the rest, but make no mistake: they know their customer and they are willing to defend them. Even if it means pissing people off. Which is kinda nice.
Happiness in slavery? It is easier to develop for a single target, as always, but in this case the single target is starved for both features and bugfixes. I'm not sure what you developed, but in the last few months alone, we've run into bugs that have apparently existed and been known about for years. There really is no excuse.
That's an absurd statement. Maybe your argument has merit, maybe it doesn't, but let's not suggest that our smartphones browsers are anything akin to slavery.
It's an idiom from "Story of O". The comment was toward being happy under forceful limitation. But gosh, sometimes discussing things on HN feels like trying to talk about poetry with Vulcans. "ILLOGICAL, DIDN'T READ THE REST"
Speaking of talking about poetry with Vulcans, do you want to cite those bugs? I'm curious, because I've developed against Mobile Safari for years, and never actually had any particular difficulty; granted this has been mostly personal projects and little of it has entailed the use of bleeding-edge web technologies, but I'm still rather curious about this "antiquated, buggy monster" side of Safari that you seem to be seeing.
It's rather obvious (even if you're unfamiliar with the source) that he/she's not comparing browser choice to literal slavery of the user. The only absurdity here is your choice to take the most outrageous possible interpretation of his comment and then write a comment entirely focusing on this imaginary transgression.
No. It's the same hyperbolic and emotive language that is used in these discussions. It adds nothing and riles people up, which I'm going to guess is the desired result. The way it is delivered is basically pseudo-intellectual bullshit.
I suppose that's a fair point. My perspective on people getting unnecessarily riled up by the use of metaphor is usually that those people need to re-examine the level of maturity with which they're approaching the discussion. But to your point, the fact that it's someone else's "fault" doesn't change the fact that using language like that can provoke emotion that derails the conversation.
> quality rendering engine that has the same experience everywhere and gets updated with each major iOS release
That's the problem. Google can regularly update Chrome without updating the OS. Apple can't because it's a system app.
> Apple have always put the end Users Experience before Developers, so it's primarily focused on maintaining a fast, fluid browsing experience on iOS
Not really. They actually started backtracking on most of those. They even allow third party keyboards now, most of which are slower and harder to use than the stock iOS keyboard. Considering keyboard is a more integral part of the OS, it seems weird they still do not allow third party browsers.
Apple can push a iOS point release that just includes an update a single system app (they've did it before for the 5S's compass bug, so there's precedence even) and users will actually get to download it quickly and there's no specially carrier approval bullshit that forced Google to go with a downloadable browser app pushed through the Play Store. Being forced to use the Play Store for system functionalities has not only destroyed the "open source" nature Android once had, but also delivers bugs to users faster than ever, since they push Play Services updates damn near monthly and with far worse QA than system updates.
> Apple can push a iOS point release that just includes an update a single system app
Which is inefficient and inconvenient. Google updates Chrome every 6 weeks while you are sleeping, as with all other Play Store apps. With an iOS system update, you have to click 5 different dialog boxes and go through several steps such as rebooting.
> and users will actually get to download it quickly and there's no specially carrier approval bullshit
Chrome updates don't go through carrier approval. Since Google does not need to update Android to be able to update Chrome, it's hard to understand your point here.
> that forced Google to go with a downloadable browser app pushed through the Play Store.
Chrome did not replace AOSP browser. Android still has its own browser.
> Being forced to use the Play Store for system functionalities has not only destroyed the "open source" nature Android once had
Chrome is not a "system functionality". It's an optional app you can download from the store. Android still has its own open source browser.
> That's the problem. Google can regularly update Chrome without updating the OS
If you're referring to Chrome on iOS, it uses Apple's Webkit/Webview as the rendering engine. The only thing Google is updating with app updates is the logic behind interaction with that webview, not the rendering engine itself.
I think the reference was to Chrome on Android, which (like most of the core Google apps) is treated as a separate app and updated independently and rather more frequently than OS updates, and contrasting that with iOS Safari, which is updated as part of the OS.
>One of the liberating things when first developing a Web App for iOS was only having to support a single modern browser
I can imagine that it is liberating just as it would be liberating to develop exclusively for any other browser. But what is the use case for that? I wasn't even aware that "iOS Web Developers" exist.
I think the point was that iOS as a platform presents far fewer challenges to web developers than Android does because of the multitude of different browsers people use on Android. PPK has written at length about the problem with all the different versions and forks of Chrome that exist on Android here:
I get that, but if I create a web app, I have to support all kinds of different browsers anway, so how does it help to know that iOS users are only going to be using Safari? I'm not aware of any website that is exclusively used by iOS users.
Yes, excactly. Since you have to support all the browsers, you should be thankful that there aren't more of them. On iOS you only have one browser to test against and you're done. OTOH it's practically impossible to exhaustively test on Android. Being a web developer I know which of those two platforms I wish were more like the other.
Fair enough, but how are you defining that web platform? W3C seems like a reasonable bet, but many of the features developers want remain fairly far from recommendation level.
One of the liberating things when first developing a Web App for iOS was only having to support a single modern browser, allowing usage of advanced features which weren't crippled by having to gracefully support old IE versions. Only having to target a single platform with limited resolutions is also one of the few benefits I see with native iOS development.
Apple have always put the end Users Experience before Developers, so it's primarily focused on maintaining a fast, fluid browsing experience on iOS which is the most used browser for tablets and smart phones and IMO still continues to provide the best browsing experience on any mobile device.
So it doesn't follow the feature-mill factory pushed by other browser vendors, I still prefer iOS's performance focus, yearly upgrade cycle which thanks to iOS's fast upgrade adoption, iOS Web Developers get to enjoy adopting new features long before Android Web Developers who have to support the old browsers shipped on JellyBean.