Hacker News Reader

Comment by keehun | Hacker News Reader

Is this using the Safari view? It doesn't mention anything about using another renderer than the one Apple allows.

Its actually using WKWebView

https://github.com/mozilla/firefox-ios/search?utf8=%E2%9C%93...

Which is actually very fascinating - last I heard Chrome for iOS is still using UIWebView as there were blockers with WKWebView. Wonder how Mozilla got around them?

There are always blockers. UIWebView has blockers and WKWebView has blockers.

I think Chrome on iOS has the option of some kind of mobile compression proxy that runs through Google's servers, so perhaps that's been part of the problem?

Hard work, mainly :)

It has to use some form of Webkit. Mozilla is not allowed to use any renderer except for the ones Apple provides.

Now i wonder if they support webrtc even if they have to use webkit to render i have to try it out. The restrictions on browsers on ios could turn the ipad pro into the worlds most expensive paper weight.

WebRTC isn't supported as iOS WebKit has no support for it.

There might be extremely elaborate workarounds possible to get it working anyway: https://bugzilla.mozilla.org/show_bug.cgi?id=1200791

That would be awesome. I'm working on a project that requires WebRTC, and iOS is my biggest problem at the moment, if I could point out to a browser and tell people to download it, it would be huge.

Edit: AFAIK, the Ericsson bowser no longer works / isn't supported anymore.

Are other browsers not allowed to implement their own rendering engines or is their some other reason that Chrome and Firefox both use the web view?

Only the iOS webview is allowed to render web content.

Additionally only Apple's JavaScript engine is allowed to use a JIT compiler.

The only benefit is whatever extra features they might offer, like bookmark synchronization.

> Only the iOS webview is allowed to render web content.

This is quite shocking. I wonder how a platform with such policies could be universally accepted and praised by the tech community. Microsoft didn't achieve this level of closedness but become universally hated.

There is actually a fair amount of people who do not accept such a policy and use Android instead. Apple's super locked-down ecosystem is why I use Android, despite iOS being (imo) a better OS. You tend not to hear from us because... we don't use iOS.

>You tend not to hear from us because... we don't use iOS.

Seriously? we hear from the non-iOS tech crowd all the time about how locked down iOS is.

> "could be universally accepted and praised by the tech community"

Apple's reputation in the tech community is very far from being universally accepted and praised.

The sheer number of backlit white apple logos on display at most tech conferences I've ever visited (ones surrounding open source projects!) would seem to imply otherwise.

Mac laptops are useful for web developers as they offer a good blend between open-source development tools (GNU tools, etc...) and commercial tools (Photoshop, etc...).

However, if you've not seen any criticism of Apple in the tech community, then Google for it, it won't take long to find critical voices about Apple (and I'm not referring to trolling, well thought out criticism is easy to find too).

I am forced to use Mac hardware at work but run Linux as the OS on my Macbook Pro :) Not all of us are hardcore Mac peeps!

I had a Mac before the iPhone came out but after Lion I switched to Linux.

On one of the Debug[1] podcasts (I can't remember which one now), Don Melton[2] claims the decision to not allow other web rendering engines or Javascript implementations is because they don't know how to allow those and keep iOS secure, and that is the reason behind a lot of limitations enforced in iOS.

Apple is certainly more closed than Microsoft ever was. The difference in perception is likely because Apple has never had a monopoly. There are more Android phones than iOS.

[1] http://www.imore.com/debug [2] http://donmelton.com/about/

Personally I don't have a problem with that.

What I think is happening is that the hipster generation that grew with Mac OS X and helped save Apple is just discovering the Apple of yore.

The old Apple was quite proprietary, but they needed to sell an history to save the company.

So with NextSTEP adoption and increase of UNIX culture at Apple, they tried to cater a picture of standards adoption and welcome feeling to UNIX devs.

I value more cool tech than openess, but to each its own.

Chrome on iOS embeds its own network stack, which it touts as being faster and more fully-featured than Safari’s.

The Safari network stack is actually pretty good. It has good SSL/TLS support and does SPDY pretty well.

It still uses the IP iOS stack, right?

I’d guess so. The original Chrome for iOS announcement [1] said:

it’s been challenging to re-use critical Chromium infrastructure components. That said, there is a lot of code we do leverage, such as the network layer, the sync and bookmarks infrastructure, omnibox, metrics and crash reporting, and a growing portion of content.

[1] https://groups.google.com/a/chromium.org/forum/?fromgroups#!...

Until your battery goes flat. Oops.

Precisely the reason I don't care that the other big browser engines can't be ported to iOS. Their concern for battery life/power drain is so low that there's zero chance I'd use them anyway. I don't even use them on the "desktop" (laptop) anymore, for that reason.

> Additionally only Apple's JavaScript engine is allowed to use a JIT compiler.

Can you elaborate? I was under the impression that as of iOS 8, if a developer implements WKWebView in place of UIWebView they would have access to Nitro.

This is true, but what pjmpl was saying is that Mozilla couldn’t port their JITted JS engine to iOS and expect it to get through the app store review – they have to use Apple’s.

> Additionally only Apple's JavaScript engine is allowed to use a JIT compiler.

I'm not intimately familiar with the iOS API, but I believe that this is no longer the case, courtesy of WKWebView[0], which was released in iOS 8.

0: https://developer.apple.com/library/ios/documentation/WebKit...

The WKWebView is just a newer API for a WebKit webview, which replaced the older and slower UIWebView. Still Apple's WebKit that you're forced to run.

True, but JIT should now work for both Chrome and FF.

Actually I think the javascriptcore restriction is the main thing. I'm not sure that, say, the kindle app has to use a web view (for example)

All apps on iOS are forced to use the built-in webkit engine. Think of it as if every browser on Windows was forced to use the IE engine and Chrome, Firefox, et al never existed, just a ton of IE skins.

It's not allowed. From Apple's guidelines:

> Apps that browse the web must use the iOS WebKit framework and WebKit Javascript

Yes, there's a rule which prohibits anyone from implementing their own renderer.

Yes, it does.

When you think that Microsoft was accused of abusing its monopoly when they shipped IE with Windows. You cannot even install another true browser on iOS, just some sort of chrome around safari/Webkit.

You answered your own question. Microsoft abused their monopoly; since neither Apple nor Google have a monopoly on mobile that set of rules does not apply.

It would require a new set of laws to have anti-trust apply to ecosystems rather than only industrial/sector/field monopolies. At the moment Apple is free to do as they please.

Why not allow competition in software?

Probably because Apple is very concerned about providing a secure experience for their customers. By requiring that all app developers use Nitro they can rest assured that those apps are at least as secure as mobile safari when it comes to browsing the web. If Google was use their own JIT compiler in Chrome for iOS and there was some serious security exploit that affected users as a result do you think users would blame Apple or Google? As far as most non-technical users are concerned, they would likely blame Apple because that's who they bought the phone from.

There is competition in software, btw. You can buy an Android or Windows phone and get a completely different web browser in them.

That's what the app sandbox is for. As long as the sandbox holds up, it doesn't matter what security vulnerabilities are in the app within. And if the sandbox doesn't hold up, you've probably lost the game regardless. There's plenty of room for security vulnerabilities in an app like Chrome even if they're not using a custom browser engine.

App sandbox is just one layer of the security model that iOS employs, and another is not allowing JIT'd code, in case someone finds a way to drop a payload into W&X memory. There's no reason to increase your attack surface if you don't need to.

Is the restriction on JITs really a security thing? That seems so completely far out there on the list of concerns compared to common stuff like buffer overflows which Apple does pretty much nothing to prevent. It always looked to me to be a technological means of enforcing their rule that you weren't allowed to download new code to run (on purpose).

It's very much a security thing, there've been lots of exploits that work by dropping a payload into a W&X marked area in browsers (usually dropped in by buffer overflows).

Apple also doesn't like unsigned code, and JIT (or self modifying code, or whatever falls into that category) is inherently unsigned code.

Yeah, but Apple doesn't like unsigned code because they want to maintain control over everything, not because of security.

Forcing the use of a single rendering engines also minimizes memory usage (the code for the engine can be mapped in shared memory) and thus allows Apple to ship devices with less RAM, slightly decreasing power usage. It also speeds up the launching of applications that use a renderer (the code for the browser, its JavaScript engine, the font renderer, etc. will already be in memory)

I think that effect could be fairly large if Apple would allow applications to contain their own web engine, not because it would mean a second engine, but because it easily could mean a third, fourth, etc. engine, given that not all applications get updates at the same time. Imagine app #1 shipping with Firefox's webview version X, app #2 Firefox version X with bug fix Y, app #3 with Firefox version Y, etc.

Apple allows Unity and Unreal Engine, all of which are just as big if not bigger than WebKit. Leaving the realm of games, they also allow Mono/Xamarin, which is a similarly enormous framework.

The restriction is plainly a business decision, not a technical one.

Because it doesn't benefit them, and it might hurt them.

Won't boxing out competition mean that developers can't trust Apple? Why play if they can change rules whenever?

There is: Android, Windows Phone, Blackberry, even Firefox OS and Jolla...

As significant as Apple is in the mobile market, it doesn't have anything like the control MS had of the desktop market at that time.

Using something else if is a viable option for most people that currently use Apple products, where it wasn't for many in the case of Windows back then.

The thing is Apple doesn't have a monopoly on the mobile market, specially when the worldwide market share is taken into account.

Until then, Apple is free to control 100% what comes into their platform.

The same way any other vendor is free to do (e.g. games consoles), when not covered by monopoly laws.

When they reach a size that falls into what the law considers a monopoly, then the game changes, as they have increased responsibilities towards the market.

When iPhones reach 90%+ market share this will indeed turn into a problem. I believe they are in the 10-15% range right now.

No, it is a problem before that. When it becomes a problem bad enough to warrant government intervention is another question.

That depends on national laws. In the UK, for example, > 25% market share makes you a monopoly.

Is that if no competitor also has 25%? Android and iOS must both be above 25% in the UK, which of those are considered a monopoly?

Don't think about the laws in terms of a single monopoly. The laws should be more accurately described as anti-trust or competition laws.

A handful of large players, each with less than 50% market share, can also distort the market and engage in anti-competitive tactics.

https://en.wikipedia.org/wiki/Competition_law

Reply on news.ycombinator.com