I couldn’t get the releases to build, but I was able to build and take screenshots of the February 18 pre-release.
I assume they’re using WebKit and not Gecko, as Apple still requires that, last I checked. Either they are, in which case this points to a shift in Mozilla’s policy about using other web engines (they used to be strongly against it), or they decided that it’s fine to write an app and not put it on the App Store, making it just available for Devs and Jailbreakers (which was previously not the practice of mainstream organizations).
I will eat my hat (or a hat, at least; I like all my hats) if Mozilla ship a thing called Firefox without their web engine in it. So if they’re doing an iOS version, it’ll be for jailbreakers. Can you point your built version at something which identifies what it is? And perhaps @gerv can comment?
A brief look at the source reveals a reference to WKWebView, a WebKit-related class, suggesting that they’re using WebKit.
I don’t really see a problem with this - it gives Firefox users an official app that they can use to sync their data with, which, on its own, has some utility. Also, although I like Firefox overall as a browser for other reasons, I never liked their web engine. Apple’s is open source, and is better in a lot of ways - why not use it?
Blimey. Mozilla have been very seriously against the idea of a Firefox shell around a non-Gecko engine. This is a pretty serious shift in approach from them…
It does use WebKit. I’m not sure if a final decision on what it’s going to be called has been made. But if we do call it Firefox, I look forward to @sil eating what I will call the “Paddy Ashdown” menu at our next dinner together:
Homburger with Baked Beanies and Stuffed Mushroom Caps
Really? Dammit. I shall find a hat and eat it, as a mark of how the mighty are fallen. Is not clear to me that Firefox with a WebKit renderer is in any meaningful sense Firefox
If they do call it Firefox won’t that mess up the user agent string? If so, that would mean javascript folks would have to start testing for “mozilla/gecko” and “mozilla/webkit” to deal with browser specific issues.
In Apple’s walled garden browsers can only innovate based on higher-level services: Firefox Sync, Google Sync, iCloud, etc. Everything else is essentially the same from the user’s perspective.
You see my point, though. A web browser is an open door to all the glory of the web. Making the door handle pretty is nice, but the goal of a door is to be walked through, not to be cool in itself. In the old days, the thing eveyone hated was Netscape 4, followed by IE; now, the browser in which sites you want to use won’t work, is… well, it’s still old versions of IE, a bit, but the real issue is Android 2.x, followed increasingly by iOS Safari. Firefox and Chrome and Opera are great, except on iOS where they’re just iOS Safari and sites increasingly don’t work.
I agree completely with the importance of the rendering engine, but IMO, WebKit is better than Gecko, and Mozilla should adopt it anyway, rather than continuing to develop their own engine, while still possibly providing a little legacy support for Gecko where they can.
Obviously, this opinion is radically pro-apple and is not going to happen any time soon, but because of it, I don’t see what Mozilla (or anyone) has against WebKit.
Are there specific sites that you’ve found to not work well with WebKit?
“Sites that don’t work well with WebKit” is hard to answer without a clarification. Safari uses WebKit. Chrome and Opera use a WebKit fork called Blink. I promise I’m not trying to be needlessly picky here; if your question is whether there are sites which only work well in Firefox, then indeed there aren’t many because it doesn’t have a big enough market share to exclusively target. If I can include sites which work in Blink and Gecko but not WebKit, then anything which uses webrtc or ogg vorbis audio or service workers, such as talky.io. If we can include sites that only work in Chrome, then increasingly the first release of anything complex done by Google counts too (Inbox, Tone, etc).
Abandoning Gecko would basically be saying “Here, Google and Apple, you can decide what direction the web goes in, in the future. I’m sure you’ll be wonderful and benevolent dictators, with no conflicts of interest at all. After all, Microsoft did a great job of being steward of the web back when everyone used IE 6, right?”
This is precisely why I feel a bit questionable about Firefox on iOS. The Chrome people are already in the position of saying “Chrome now supports some great new thing” and then having to put * except on iOS after everything. Seems weird that Firefox would do so too. I understand that the deficits here are possibly outweighed by the problem that Firefox has no presence at all on 50% of the world’s mobiles, and perhaps that’s what’s driving the decision, though.
Even though I hate Apple’s position on this (but it’s not like freedom 0 exists on iOS), and dread the coming monoculture – I think we’re at least approaching a world where the rendering engine is the least interesting thing about a browser. As long as sites look OK and work OK, who cares?
For lack of a better term, the browser is the “chrome”, it’s performance (or lack thereof) , and the ecosystem of add-ons and services (like Firefox bookmark sync).
Basically, anybody who wants a site to do a thing that the browser manufacturer is resistant to. Example: WebRTC for real-time video and audio chat, which is a great thing to have but a challenger to Facetime and hasn’t shown up in iOS Safari yet (whether these last two points are connected is a matter for discussion). Rendering engine monoculture leads fairly obviously to stagnation, as we’ve seen in the past; in order to drive forward progress there needs to be active competition; for two engines to be competing they must differ in some way, even if only temporarily; therefore there will be some things that work in one engine and not another, even if only temporarily; therefore rendering engines are important.
