IDK how it is now, but Apple used not to allow e.g. alternative Javascript engines in apps—you had to use Webkit's.

Having developed an app-building engine for Android in the days when some vendors shipped different engines to supply webview functionality (is that a thing? I actually don't know if they ever stopped) I can say I'm extremely in favor of this part of their policy. God that was a pain in the ass.

Ostensibly, this is a fine position to have. But would this not more than likely not just result in Chrome having near total dominance of both the mobile and desktop rendering engine market. From a completely practical point of view, it seems that Safari on iOS is the only thing stopping Chrome's engine from having total market dominance.

I don't want to say that Webkit's dominance of iOS is a good thing, but it appears to be the lesser of two evils. I'd rather have Webkit dominate iOS, than Google and Chrome dominate everything. Google being the only major player in web standards is good for nobody but Google.

I know. I meant across platforms. It's obviously the best on in iOS.

>Few users could tell any difference between native app and web app running in a browser that has modern appy capabilities, provided there is same quality of implementation. The only thing that can make the experience subpar is precisely the lack of capabilities.

For one, a web app adds the extra burden of a JS VM and DOM over native code. This rules out all kinds of graphic and CPU intensive apps. Actually, for any app that's not just a glorified content screen / database view, there's not even a comparison between a web and a native implementation.

Even for basically text-based content consumptions apps, like Flipboard, they had to jump through all kinds of hoops to get smooth 60 fps scrolling within a web view.

And of course there's the battery life, that's a real killer with web apps.

A future based on web apps for mobile is a regression over even 2005's state of the art in the desktop. And it's an experience similar to cross-platform apps -- that is, a "lowest common denominator" across mobile platforms.

I know, I already covered all that.

>They only change how apps are deployed. Hence, your whole point about "better quality apps by banning PWAs" is completely wrong.

I didn't say banning PWAs will result in better quality apps in general. I said:

(1) "Add to home screen PWAs" are not that used in the first place.

(2) "PWAs wrapped as native apps" are, but iOS encourages native apps more.

(3) Giving more parity to PWAs (going the opposite route of the current removal) will encourage them to be used more, which I don't particularly like, for the same reason I don't like Electron (including iOS wrapped-PWAs).

>As for Mobile Safari, it took several years for Android browsers to come close...

>suggested to developers they make their own web apps in lack of a native SDK, most dissed those...

>Safari is not exactly some bad browser holding those apps back...

>do you see many people watching Netflix on Android Chrome...

Absolutely none of these points are arguments against having the option to have an alternative browser rendering engine. Not sure why you think they are.

Not sure why you think they were intended to be.

Those weren't "arguments against having the option to have an alternative browser rendering engine".

Those were arguments about "Apple not having an alternative rendering engine" is not about sabotaging some imaginary web app revolution, just about Safari having its own timeline and priorities.

Regarding that, not how there's no such web-over-native-app trend in Android either, where Chrome IS available. Most still prefer native apps.

If you think, you could also think them as "arguments not against, but as to why it's no big deal to not have an alternative browser rendering engine".

It feels totally upside-down that Safari for iOS has a better extensions story than Chrome for Android. For this reason one of the first things I grab when setting up a new Android device is Firefox.

In theory yeah, in practise it looks a bit murky to me right now due to the state of the web. Apple is under a lot of fire right now (quite rightly) but I have a suspicion if other browser engines are allowed to run on iOS there will effectively be no incentives to develop for any other browser engine and we'll start seeing "Works best / only in Chromium" type websites and apps (I've already experienced this a fair bit using Firefox).

That actually work on the platforms I choose. There are many apps that only work on iOS/Android that I want to run on my desktop or a more pure linux phone. I just want to be able to consume a service from a platform that clearly have the technical capabilities to do so, but no, it has to be a "app".

> Notorious for tracking abilities

And a lot easier to chose/disable them. This summer many apps (including stuff like spotify) would not even start on iOS because the facebook SDK crashed. On the spotify web player I can choose to block calls to recaptcha, facebook and similar with umatrix. Do you think that apps on average have less tracking or just that you tend to pay for apps but not for webapps and therefore get higher quality apps?

> data storage tied to the browser

Great! Data storage on the client should either be treated as unreliable or the only storage (for stuff where there is no "cloud" or privacy is critical). Tying storage to a single vendor (like icloud or google drive) is a very, very bad idea. Web browsers also have a well defined interface for you to inspect the data saved locally if you want.

> performance lower

For the majority of apps this does not matter. The reason webapps are usually slow is not that the platform is slow, it's that companies copy websites that are stuffed with tracking (if you block that they tend to be much quicker). They suck because the people who made them made them suck.

Most chat, mail, news, or any other form of text/image/video app could easily be performant enough as a webapp. Hell, amazon even made their real time game streaming service a webapp. The platform is not the problem.

> data consumption unpredictable

Not sure what is different here from native apps? Both can auto-update, both can download assets at-will, right?

> identification tied to web technologies

Yes please! That means it's portable and not tied into google/apple!

This is almost certainly true now, but the rules predate their big services push. The main thing that prevents other browser engines is:

- Apps cannot run arbitrary code. So an emulator that bundles a fixed set of games is fine (providing the copyright is kosher), but an emulator that allows you to supply your own games is not. This of course also rules out executing JavaScript on web pages.

- iOS apps cannot mark memory as executable, i.e. no dynamic compilation. This alone would tank the performance of any competing engine even without the above restriction.

Lame rules, imo. I understand their origin, but it’s one of many things holding the platform back.

They allow competing browsers but they have to use the OS-provided JavaScript engine. I guess one could make an argument that allowing third-party engines would encourage innovation in the browser space but at the same time, there is a strong security argument for very narrowly limiting the JIT-code execution entitlement.

So? JavaScript apps already run faster with in Browsers with faster JS VMs or for different users on faster hardware and different devices e.g. Smart Phones vs iPads vs TVs vs Desktops. Safari in iOS had a much faster JS implementation than Android or even the WebView in iOS apps, this doesn't make slower devices useless or stop users from viewing websites in different apps than Safari or even stop other browser vendors from developing alternative browsers for iOS.

Having a faster implementation doesn't make every other device or browser useless.

> Why would anyone run a slower JS implementation of an app, when Chrome gives them wings?

Why should the web be shackled to the limitations of JavaScript? This same reasoning could apply when V8 was first released which was 100x faster than other JS engines at the time. This just made every browser vendor care deeply and invest more in JavaScript performance. This is the same as impl-driven defacto standards like Canvas and WebGL, new experiences open up more categories and encourage other vendors to follow suit - A rising tide lifts all boats.

The core Dart Team is driven by trying to improve the web as best they can, just as they've done with V8 they want all their work to be freely used and used to encourage new innovations on the web.

> A large body of source code isn't as adoptable as you imagine. You need the people who are embedded in the evolution of the platform, or you are always going to lag.

Not true. A valid implementation of a language spec precisely means that source code in that language can be run on any implementation, just like existing Java code could run on Android's Dalvik and ART VMs. When a language has a specification it makes it easier to create different implementations (http://en.wikipedia.org/wiki/List_of_Java_virtual_machines). It's also possible when a language doesn't have a specification as seen with Ruby VMs (https://github.com/cogitator/ruby-implementations/wiki/List-...) but it's much easier to implement when there's an unambiguous spec to follow.

Also because Dart (like V8_ is both open source and embeddable, no-one needs to reimplement it, they can embed it as-is or port it.

> You need the people who are embedded in the evolution of the platform, or you are always going to lag.

The developers of Node, didn't have to work on V8 team to embed V8, neither does anything else that embeds, compiles or ports V8.

> Not true. As an example, for a long time Mono's GC was much slower than .Net's.

You're contradicting yourself and disproving your own point. A GC is not in the language specification, it's an implementation detail which the Mono team had to re-implement themselves precisely because it wasn't Open Source.

None of this applies with the Dart platform or team whom are developing a truly open platform and embeddable VM who are actively encouraging other users and vendors to adopt.

> The lessons from the 90s and early 2000's were very clear. We need to learn from them.

It seems at least they're not as clear to you - none of your comparisons are valid, nor have you cited the ones that were.

That would not remotely be a practical Web browser in 2015.

> Language interpreters are forbidden to download any code from the internet, so you cannot use JS found on a web page in your own interpreter.

Which is a business decision.

I don't understand why this is controversial; it's well-established that many of the iOS restrictions are business-related. Note that I'm not even arguing here that those business-related restrictions are a bad thing.

The word 'also' doesn't belong here. Browsers on iOS don't tend to use core iOS components (WebView) : they are forced to. Your statement really isn't a counter point.

I think iOS users would disagree - if there was no demand for these APIs, there wouldn't be users using them in the first place and API creep wouldn't be an issue. But it seems that, for whatever reason, on iOS there is an incredible demand for like-native experiences that don't leverage Apple's first-party APIs.

Maybe, just maybe... if the native app experience was closer to Mac or Windows then users wouldn't feel the need to use their browser like a native runtime. Crazy, I know!

This is something that works just fine for me over on Android, in Firefox mobile. Actually, i assume that the mobile browsers would offer all of these capabilities, assuming apple allows access to, and documents their apis appropriately.

Why is it that we somehow defend apple having proprietary/exclusive Apis that nobody else has as good? It's essentially the same game as it was with internet explorer.

I think if apple just opened up their eco system the other browsers would support these features before long, or app developers would include them in their apps instead of relying on browsers.

It's not like apple is the only one with capable engineers, they just stop everyone else from using their stuff to the fullest

Majority of the content on these apps is native and not html/js. They have a small amount of content on the settings screens in html/js but all of the main view code is native. For an app with complex layouts and content like facebook, html/js scroll performance would be far too slow. You can easily verify this by running the application with UIAutomator turned on which will show you the widgets being used on screen.

Native is faster because it's not layout and control agnostic. So you get controls like recyclerview which recycle view elements while scrolling large lists to keep animations smoooth. Sure, you can implement that in javascript too, but the javascript can't beat a native c++ implementation which is also GPU accelerated. This is also the reason why frameworks like React Native and Flutter were born. They use javascript/dart but render all UI content natively which allows them to maintain smooth 60fps animations.

To be honest, I wouldn't like mobile going the html/js way at all. Html/js has moved to desktop with electron and the results aren't that great. They take up huge amounts of memory ( gmail web on chrome takes up 500mb of ram on my machine, also slack is a noteworthy mention). Native desktop apps take up a fraction of that memory. For the sake of accessibility we have significantly sacrificed performance. I can't wait for webassembly to be widely adopted so that the browser can move away from html/js. Google has a nifty tool called ArcWelder which allows android apps to run in chrome. Apple has already announced support for running iOS apps on Mac. Would people really want to use html/js apps if they have native and more performant apps available on their platform?

I really don't want to have multiple browsers installed on my phone & swap between them because some web app works in one browser, but not another. Mobile browsing is already pretty shitty, I don't think fragmentation will make it any better.

In the context of forums though, its entirely true and accurate.

If we were talking about apps, as in things that require more than an internet connection to work, I would agree with you.

Just because you can make it an app, doesn't mean you should.