6 ms·

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 "

by bla2 12y ago

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.

JoshTheGeek 12y ago
They have no other choice; Apple won't accept apps with custom web rendering engines.
- fekberg 12y ago
  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?
  - mkozlows 12y ago
    Microsoft was a monopoly. Apple is a niche player. Antitrust laws don't apply to companies with 20% of the market.
    - spigoon 12y ago
      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-but-remains-top-dog/ http://www.cnet.com/news/android-loses-some-us-market-share-...
      - cyborgx7 12y ago
        There are other markets than the US and the antitrust laws were employed against Microsoft in the EU.
        jfaat 12y ago
        The US antitrust case[1] referred specifically to browser vendor lock-in. [1] http://en.wikipedia.org/wiki/United_States_v._Microsoft_Corp http://en.wikipedia.org/wiki/United_States_v._Microsoft_Corp.
        orbifold 12y ago
        As did the European case, ultimately forcing them to give a choice to the user which default browser to download, if I recall correctly.
      - JohnTHaller 12y ago
        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.
  - chj 12y ago
    I am equally surprised.
  - Cthulhu_ 12y ago
    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.
    - colordrops 12y ago
      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.
      - gress 12y ago
        It may be a power grab, but it also provides protection from malware that customers value.
        walterbell 12y ago
        Some restrictions do. Some restrictions have economic benefits for Apple.
        gress 12y ago
        This one has both.
    - walterbell 12y ago
      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.
- eclipxe 12y ago
  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.
  - shadowmint 12y ago
    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)
    - eclipxe 12y ago
      Not all content created with web technologies and renderable with an HTML/CSS rendering engine require Javascript
  - air 12y ago
    > 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/ https://developer.apple.com/app-store/review/guidelines/
    - eclipxe 12y ago
      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.
      - bzbarsky 12y ago
        Right, rendering HTML is fine. As long as you don't download it from the internet on-demand, or so.
MBCook 12y ago
> 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.
- Touche 12y ago
  They have a choice, they can not release a browser for iOS.
  - andyidsinga 12y ago
    they could release a firefox with gecko that works on jail broken ios ( or maybe it exists?)
    - nnethercote 12y ago
      There was one made about four years ago. Hardly anybody used it because hardly anybody jailbreaks their phones.
      - Aissen 12y ago
        AFAIK, they never did. They did a launcher application that was sync-compatible to access all you bookmarks, etc.
        nnethercote 12y ago
        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.
        12y ago
JohnTHaller 12y ago
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.
- rimantas 12y ago
  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.
  - JohnTHaller 12y ago
    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.
blub 12y ago
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.
- LeoNatan25 12y ago
  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.
  - blub 12y ago
    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.
    - LeoNatan25 12y ago
      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.

by bla2 12y ago

JoshTheGeek 12y ago

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

fekberg 12y ago
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?
- mkozlows 12y ago
  Microsoft was a monopoly. Apple is a niche player. Antitrust laws don't apply to companies with 20% of the market.
  - spigoon 12y ago
    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-but-remains-top-dog/ http://www.cnet.com/news/android-loses-some-us-market-share-...
    - cyborgx7 12y ago
      There are other markets than the US and the antitrust laws were employed against Microsoft in the EU.
      - jfaat 12y ago
        The US antitrust case[1] referred specifically to browser vendor lock-in. [1] http://en.wikipedia.org/wiki/United_States_v._Microsoft_Corp http://en.wikipedia.org/wiki/United_States_v._Microsoft_Corp.
        orbifold 12y ago
        As did the European case, ultimately forcing them to give a choice to the user which default browser to download, if I recall correctly.
    - JohnTHaller 12y ago
      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.
- chj 12y ago
  I am equally surprised.
- Cthulhu_ 12y ago
  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.
  - colordrops 12y ago
    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.
    - gress 12y ago
      It may be a power grab, but it also provides protection from malware that customers value.
      - walterbell 12y ago
        Some restrictions do. Some restrictions have economic benefits for Apple.
        gress 12y ago
        This one has both.
  - walterbell 12y ago
    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.
eclipxe 12y ago
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.
- shadowmint 12y ago
  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)
  - eclipxe 12y ago
    Not all content created with web technologies and renderable with an HTML/CSS rendering engine require Javascript
- air 12y ago
  > 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/ https://developer.apple.com/app-store/review/guidelines/
  - eclipxe 12y ago
    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.
    - bzbarsky 12y ago
      Right, rendering HTML is fine. As long as you don't download it from the internet on-demand, or so.

MBCook 12y ago

> 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.

Touche 12y ago
They have a choice, they can not release a browser for iOS.
- andyidsinga 12y ago
  they could release a firefox with gecko that works on jail broken ios ( or maybe it exists?)
  - nnethercote 12y ago
    There was one made about four years ago. Hardly anybody used it because hardly anybody jailbreaks their phones.
    - Aissen 12y ago
      AFAIK, they never did. They did a launcher application that was sync-compatible to access all you bookmarks, etc.
      - nnethercote 12y ago
        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.
        12y ago

JohnTHaller 12y ago

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.

rimantas 12y ago
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.
- JohnTHaller 12y ago
  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.

blub 12y ago

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.

LeoNatan25 12y ago
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.
- blub 12y ago
  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.
  - LeoNatan25 12y ago
    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.