Hacker News Reader

Comment by bla2 | Hacker News Reader

It's a bit sad that Firefox is caving in and shipping a browser using WKWebView. The rationale is that by using WKWebView they now get Nitro, and they have to "go where the users are" -- but a few years ago, it was a lot less clear that Android would be more prevalent than iOS.

Also, iOS seems like a fairly hostile environment for 3rd-party browsers since it's not possible to change the system browser -- that's probably why mobile Safari has such a large usage share on iOS.

View on HN

Besides having access to JIT, being multiprocess, getting the backward/forward swipe for free and finally having a decent way to estimate progress, WKWebView is actually worse than UIWebView and less customizable. UiWebView, as slow as it is permits you to do stuff like saving pages for offline viewing, ad blocking, cookie control and so on.

If they use WKWebView I'm not even sure they can implement the features of a plain old browser, never mind include addons/extensions.

Some of your concerns are true, others are not. Cache and cookie control is currently impossible with WKWebView. However you can retrieve the contents of the page and load them just as you can with UIWebView, as well as ad block using the new user scripts features, which are a much better framework than what was available before.

Can JS really block requests to a server or is it more ad hiding than blocking? I suppose WKUserScriptInjectionTimeAtDocomentStart could be used to inject something that will e.g remove ad-related DOM nodes, although this is more theoretical than a reality I guess. UIWebView can drop connections based on URL matches and also content analysis OTOH, and that's a pretty well understood way of doing things.

One more plus for WkWebView that I forgot - the history list and moving backwards/forwards in it. I agree it has some really nice pluses, but at least for my use cases (and the use cases I would be interested to see implemented in iFirefox) it doesn't seem to be the right choice.

I think it's also important to remember that this is a very much 0.5 release, very much not ready for prime time. In a year or so, likely the state of WKWebView will improve greatly.

They have no other choice; Apple won't accept apps with custom web rendering engines.

How can Apple get away with that? I am genuine interested! Sounds pretty much like the same thing Microsoft did with Internet Explore back in the day, except they didn't force you to use their rendering engine, but shipped the OS with their browser as default?

Microsoft was a monopoly. Apple is a niche player. Antitrust laws don't apply to companies with 20% of the market.

Actually, iOS has 42.4% of the smartphone market in the U.S. according to http://www.cnet.com/news/android-loses-some-us-market-share-...

There are other markets than the US and the antitrust laws were employed against Microsoft in the EU.

The US antitrust case[1] referred specifically to browser vendor lock-in.

[1] http://en.wikipedia.org/wiki/United_States_v._Microsoft_Corp.

As did the European case, ultimately forcing them to give a choice to the user which default browser to download, if I recall correctly.

Still, Android has ~52% of the market. The antitrust laws used against Microsoft were due to the fact that Windows was nearly all of the market, both home and business. Plus, people using Apple now can switch off of it, unlike Microsoft at the time which had no viable options.

I am equally surprised.

Because their platform, their rules? IDK, I think it's perfectly acceptable to limit what you can do on someone's platform, since after all allowing anything on your platform will cause a lot of crap to appear - like a lot of stuff on the Android platform before it changed to the Play Store and Google started being a bit more strict about using their platform.

Restricting what developers can and cannot do on a platform allows Apple to give more guarantees and reliability in terms of performance and battery usage, as well as security and stability. Those are the primary reasons behind Apple's restrictions on the iOS platform.

You are only partially correct in your analysis. Yes, controlling the platform can lead to a better user experience. But how does banning browser engines lead to better app quality? It doesn't. If you look at the history of app store restrictions, you'll find that any app that provides an open platform or programming environment has been banned. That is because it takes the control out of apple's hands. It's a power grab.

It may be a power grab, but it also provides protection from malware that customers value.

Some restrictions do. Some restrictions have economic benefits for Apple.

This one has both.

What are the performance, security and stability benefits of removing native print-to-PDF functionality from iOS? It was supported by Apple in early iOS releases.

Rendering engines are okay. Its the Javascript execution engine that is not allowed.

You can render all the HTML you want, you just can't allow untrusted code to be executed.

Well, since you can't use the native javascript engine with a separate rendering engine, there's not much difference though is there?

(if you could, everyone would just do that to get dynamic behavior using javascript in their apps as a scripting language)

Not all content created with web technologies and renderable with an HTML/CSS rendering engine require Javascript

> Rendering engines are okay. Its the Javascript execution engine that is not allowed.

No, they must use WebKit:

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

https://developer.apple.com/app-store/review/guidelines/

You can render HTML content with a custom rendering engine - for example ePub ebooks are essentially bundled HTML + CSS content - there are several HTML rendering engines that read ePub ebooks but don't use Webkit.

Also, you can build a UI using web languages and render to native controls, all without using WebKit if you'd like.

Right, rendering HTML is fine. As long as you don't download it from the internet on-demand, or so.

> It's a bit sad that Firefox is caving in and shipping a browser using WKWebView.

They don't have a choice, I'm glad to see them do something pragmatic here. On iOS you can ship a WKWebView browser or nothing. Given how big mobile has become it's sad that it took them 6+ years to do this. Lots of people use Chrome on iOS but that only came out 2 years ago. It could have been Firefox.

They have a choice, they can not release a browser for iOS.

they could release a firefox with gecko that works on jail broken ios ( or maybe it exists?)

There was one made about four years ago. Hardly anybody used it because hardly anybody jailbreaks their phones.

AFAIK, they never did. They did a launcher application that was sync-compatible to access all you bookmarks, etc.

It was built. Yesterday I was in the same room as the guy who built it. It was never officially released, however, due to the jailbreaking requirement.

Officially, there was Firefox Home, which was just a bookmarking thing and not a full browser.

It was barely gecko being ported. It had nothing close to a usable mobile UI.

It isn't sad. I'm happy that instead of caving into the demands of Apple they stuck out for as long as they did.

They still caved. It's just Safari with a Firefox skin on it. Just like all other iOS browsers. Mozilla had wanted to build a REAL Firefox browser for iOS, but Apple wants to lock everyone into Safari.

Oh yeah, I know that they caved and that Apple doesn't allow any other browser engines on iOS. I was just pointing out that they held out for a pretty long time.

There is much more to a browser in 2014 than just rendering HTML and running JavaScript.

True. But can a browser without its own rendering engine really be called a browser? To me, Firefox without gecko just isn't Firefox. But, to an end user that just wants their bookmarks to sync and doesn't care about choice, it doesn't really matter.

Ditto here. But I suppose you have to have something available for the iOS folks who still don't understand that every single browser is Safari with a different UI. I do think they should differentiate it name-wise since this absolutely won't be a real Firefox browser.

By this account Chrome and Opera are also Safari with different UI. (Yes, I do know that engines are really the forks, not the same WebKit). My point is, that we should be able to tell the difference between a browser and a rendering engine.

Yes, Chrome and Opera on iOS are just skins over Safari... unlike on Windows, Mac, Linux, Android, etc where they're real browsers. On iOS you can have Safari, or Safari, or Safari. All controlled by Apple.

Reply on news.ycombinator.com