Eyes Above The Waves

Robert O'Callahan. Christian. Repatriate Kiwi. Hacker.

Sunday 7 December 2014

We Aren't Really Going To Have "Firefox On iOS"

Whatever we decide to do, we won't be porting Firefox as we know it to iOS, unless Apple makes major changes to their App Store policies. The principal issue is that on iOS, the only software Apple allows to download content from the Internet and execute it is their built-in iOS Webkit component. Under that policy, every browser --- including iOS Chrome, for example --- must be some kind of front-end to Apple's Webkit. Thus, from the point of view of Web authors --- and users encountering Web compatibility issues --- all iOS browsers behave like Safari, even when they are named after other browsers. There is some ability to extend the Webkit component but in most areas, engine performance and features are restricted to whatever Safari has.

I certainly support having a product on iOS and I don't necessarily object to calling it Firefox as long as we're very clear in our messaging. To some extent users and Web developers have already acclimatised to a similar confusing situation with iOS Chrome. It's not exactly the same situation: the difference between iOS Chrome and real Chrome is smaller than the difference between iOS Firefox and real Firefox because Blink shares heritage and still much code with Webkit. But both differences are rapidly growing since there's a ton of new Web features that Chrome and Firefox have that Webkit doesn't (e.g. WebRTC, Web Components, ES6 features, Web Animations).

In the meantime I think we need to avoid making pithy statements like "we're bringing Firefox to iOS".

Comments

pop2.pete@xxl.de
Do you really think that an end user cares about the underlying rendering engine? Firefox is a brand, a UI concept and a rendering engine. Firefox for iOS would be 2/3 of the list above and nobody would care about the engine. It's like a BMW with an engine from Mercedes. For the driver, it'll still be a BMW.
Robert
Browser engines are not as interchangeable as car engines. When a Web app works in one engine but not another, users care.
pop2.pete@xxl.de
Give me one example from the mass / consumer market where something is working with Gecko and not with Webkit. But I agree with you on a completely different level: Let's assume you'll ship Firefox for iOS with Webkit and maybe Firefox for Win 8 with IE (trident?), then you'll sooner or later hear the question why do you develop Gecko at all. And that's the strategy Apple and friends is using to get competition out of the market.
Robert
A browser named Firefox on iOS will lack the most important feature, Independence. So many times the Firefox brand has been promoted as one where the user has the control, where the community can define where it goes, what standard will it propose and follow. Using another engine is not the problem, the problem is to use one you can't enhance, that is tied to the device manufacturer wishes. That is the worst way to tarnish the Firefox image, destroy its independence. I think Firefox should revive the old Firefox sync application for iOS and not ship another webkit shell. It doesn't win anything to the user to waste time on something they will not gain much, they already have the webkit engine. They can even set a default browser or open links with another browser, Safari is always used by default. If this is a movement from people inside Mozilla that love their locked down devices and want a fake Firefox for them too, then management is wrong to think that building something for iOS is a good decision. I don't think that liking Apple product a lot is bad, but I see a pattern emerge, bashing Android every time they can (some Mozillians) but saying nothing about Apple rules about browser engines because they like Apple, at the same time bash Miscrosoft when they tried to do the same. You can love company X products, but you should not base the your principles on that. Another Robert just in case Blogger mixes both aliases :)
Robert
"They can't even set a default browse" not can
Robert
Apple only started supporting WebGL in iOS Safari recently. Until then, Web games like the Humble Web Bundle worked in Firefox and not iOS Safari. I guess some of the games still don't work in iOS Safari, but I can't test since I have no iOS device.
Anonymous
follow opera mini path
Patrick McManus
a split browser (i.e. *-mini) is a pretty scary path from a privacy point of view - the browser-operator is now a new party to all the data.
Paul [sabret00the]
The more I think about this, the more fundamentally opposed to this I am. We're already spread incredibly thin in regards to resources. We're knee deep in e10s on desktop and on Android our UI is a whole Android release cycle behind where it should be (we've just released some, not even all of our Jellybean changes and here's Lollipop while we've not even got any mockups or open dialogue going as to how we'll meet the new Android design language). However that aside, I wouldn't be against something like an Firefox Mini, something that's cross-platform and not quite Firefox but doesn't pretend to be. Something we could utilise our sync capabilities with and compress pages. But obviously do that properly, we'd actually have to get around to fixing bugs like https://bugzilla.mozilla.org/show_bug.cgi?id=771278 My thoughts on a Firefox Mini are only after we've got some of the backlog sorted. I'd also much rather we were able to bring Thunderbird to Android first. But I do feel that any endeavour we took with Webkit would essentially be a nail in the coffin of open web standards.
Anonymous
We really cannot afford to do this as I understand it we will have less QA in 2015 and yet were expanding the amount of work we do. If we do this we really need to consider increasing head count. Our people are overworked already.