
Firefox for iOS on GitHub - danabramov
https://github.com/mozilla/firefox-ios
======
graetzer
I think it's great that they are going to officially support iOS again.

Coincidentally I submitted a new version of my own browser app to the
AppStore, on the same day they made the announcement. I added support for the
new Firfox sync protocol - it took me forever to get it working and now it's
kind of redundant :-/

Anyway, if someone is interested in the source:
[https://github.com/graetzer/Foxbrowser](https://github.com/graetzer/Foxbrowser)

~~~
valisystem
Your version is out, their is not, it's whole lot of a difference. Thanks a
lot and I'm installing it right away !

~~~
graetzer
Thanks, just to clarify: the new version is still in the review process, the
version in the AppStore only works with older Firefox versions.

You will have to install this from source to get the latest version

------
darklajid
I'm a Mozilla and Firefox fan, running Aurora on my desktop, tablet, mobile.
Love the project and it's the best browser out there for me.

That said.. As far as I understand the 'real meat', the engine, is now webkit.
Which defeats the process for me. The UI was always what Firefox was lacking
in and even the very latest design decisions are - well - not quite my cup of
tea at least and potentially questionable.

I would like to understand what Mozilla gains here (if this is mostly a 'skin'
around webkit/a web view control) and why iOS users would install it (I'm on
Android - dipping my toes into FirefoxOS every couple of weeks).

Edit: Thanks for reminding me of Sync as a great use case for a Firefox
browser, even if it's using a different engine.

~~~
k-mcgrady
>> "I would like to understand what Mozilla gains here (if this is mostly a
'skin' around webkit/a web view control) and why iOS users would install it
(I'm on Android - dipping my toes into FirefoxOS every couple of weeks)."

On iOS you use WebKit or you don't make a browser. They don't have a choice.
As for why you would install it, probably sync. If you use Firefox on desktop
presumably you can now access your bookmarks, history etc on iOS.

~~~
JohnTHaller
On iOS you don't make a browser. Period. You get to make a skin for Safari.
That's all.

~~~
gress
False. You can build any UI you want, as well as any feature you like.

The restriction is that you must use WebKit as the rendering engine for
content that contains JavaScript.

~~~
bad_user
It's not only WebKit, but also the Javascript engine and to make matters
worse, on iOS last time I checked the web view that you could use in apps
wasn't using the same Javascript engine that Safari was using, which means
that an alternative browser is slower than Safari by default. From what I've
been hearing, lately developers can use the same engine as Safari inside those
web views, but the functionality is still buggy.

And this matters, because the main features that browsers compete on is speed
and new features (in HTML5 and Javascript). This is what made people switch to
Chrome, making it gain a whooping 40% (or is it 50%) in market share. This is
also what made Firefox gain market share from IExplorer.

And if your browser is slower than the default one, then you cannot compete
with that default. If your browser cannot be a platform (for add-ons or apps,
like what Firefox is doing on Android), then you cannot compete with the
default. Chrome on iOS is only a shadow of what it is on the desktop.

And Firefox on Android is the only one that allows me to use useful add-ons,
such as AdBlock Plus, HTTPS Everywhere and LastPass. Do you know how awesome
that is? And this doesn't work on iOS (i.e. having add-ons) because of Apple's
restrictions.

And yes, I'm even rooting for Gekko (instead of WebKit), because it is Firefox
that brought us Asm.js [1], I even bought the Humble Mozilla Bundle [2] and
they made everybody optimize for it, including Microsoft. And now they are
working on SIMD.js as well [3].

I received an iPhone 6 as a gift 3 weeks ago and I sold it - yes it's nice,
but it doesn't run Firefox and apparently Apple kicked VLC out of the app
store as well. And personally I couldn't picture myself living with such
restrictions so I sold it - now I'm waiting for my Nexus 6 to arrive :-)

[1] [http://asmjs.org/](http://asmjs.org/)

[2] [https://blog.mozilla.org/blog/2014/10/14/play-awesome-
indie-...](https://blog.mozilla.org/blog/2014/10/14/play-awesome-indie-games-
directly-in-firefox-including-the-award-winning-ftl/)

[3] [https://hacks.mozilla.org/2014/10/introducing-simd-
js/](https://hacks.mozilla.org/2014/10/introducing-simd-js/)

~~~
JohnTHaller
Apparently on iOS 8, Apple finally ended the anti-competitive restriction that
made all Safari skin apps (aka "browsers" on iOS) slower than Safari itself.

~~~
gress
Or, more sanely put, Apple's multi-year investment in engineering allowed
WebKit to be secured sufficiently for all apps to benefit from the Jit.

All this talk of anti-competitive restrictions doesn't reflect the reality of
engineering for security.

~~~
JohnTHaller
Put another way: iOS' app sandbox is so poorly made it can't handle any app
that includes a scripting engine. (I'm kidding, of course)

Realistically, Apple is about as anti-competitive as they come behavior-wise.
And the 'engineering for security' bit has more to do with their marketing
than their actual technology.

~~~
gress
Given all the malware on Android, including giant botnets, it would seem that
poor sandboxes are the current state of the art.

The difference is that Apple is willing to recognize this and protect their
customers from the shortcomings.

Android's million node botnets and thousands of pieces of malware are not
Apple's marketing. They are the reality of what Apple's policy has succeeded
in protecting it's customers from.

~~~
JohnTHaller
It's funny that you keep referring to 'all the malware' on Android but not
referring to the malware on iOS. It exists on both. Even botnets exist on iOS
thanks to the automatic tools used to exploit the same iOS vulnerabilities
used to jailbreak enabling drive-by installs of malware on iOS devices.

There was only one very large botnet ('up to' a million nodes) on Android and
it wasn't on proper Android. It was on Android in China. So, no Google Play
store and proper Android setup like you get on every phone in the US, Europe,
etc. The botnet spread through... you guessed it... stolen games on unofficial
'app stores' of pirated software.

Comparing Apples to Apples, Google Play Android devices and un-jailbroken iOS
devices, malware is virtually non-existent.

~~~
gress
97% of mobile malware is on Android:
[http://www.forbes.com/sites/gordonkelly/2014/03/24/report-97...](http://www.forbes.com/sites/gordonkelly/2014/03/24/report-97-of-
mobile-malware-is-on-android-this-is-the-easy-way-you-stay-safe/)

If you are pretending that the level or risk of malware on iOS is comparable
to that on Android, you are either misinformed or dishonest.

Android is open by design. Alternative app-stores are part of that. If you
discount the malware that results from people taking advantage of Android's
openness, you must also discount any advantages you claim a lack of
restriction would bring to iOS, or you are guilty of misrepresentation.

~~~
JohnTHaller
Because a ton of phones in China shipped with a random 3rd party app store
that specifically contains pirated apps with malware, you're going to paint
all of Android with that brush? Because Android allows an advanced end user to
disable certain security precautions and purposely install stolen software
that contains malware? That's either disingenuous or outright misleading.

The simple fact it, both Android and iOS, when used as shipped an intended,
don't get malware for the average consumer. They both pass the 'mom test'.

There are 3rd party app stores available for Android that include malware
infected pirated apps. These app stores are not sanctioned or approved by
Google.

There are 3rd party app stores available for iOS that include malware infected
pirated apps. These app stores are not sanctioned or approved by Apple.

If your rather lame attempt at painting all of Android as insecure is due the
fact that you can run a 3rd party app store with malware, then it should also
be true for Apple.

The simple fact is that it's incredibly easy to avoid malware on either
platform. Don't hack it. Don't install apps outside of the app store (Google
Play or Apple App Store).

~~~
gress
Your claim rests on the idea that Android malware only propagates via 3rd
party app stores, and not the Google play store, or any other vulnerability.

This is false.

You also claim that only Android 'sanctioned by Google' counts as Android.
Also false, according to Google's own statistics and documentation.

~~~
JohnTHaller
I never claimed Android malware only propagates via 3rd party app stores. Nor
did I claim that iOS malware only propogates via 3rd party app stores. I'm
unsure why you continue to make up things I have said to use as strawmen to
knock down.

Both Android and iOS have had issues with badware getting into their app
stores and with drive by downloads due to insecurities... the same
insecurities used to jailbreak/root the devices in many instances. These
issues are publicly documented.

As no one here in the US or in Europe or anywhere else (except China) is
buying an Android phone with one of the malware-ridden app stores shipped in
China on it, there are simply zero concerns about it when you walk into AT&T
or T-Mobile and buy an Android phone. Why on earth would someone here care
that some non-Google Android phones shipped with a pirated software app store
get malware? By that logic, used iOS devices that contain malware in the US
would make you leery of buying a new iOS device in a legitimate store. Except
that that isn't the case, nor should it be.

Based on the way you continue to argue against points I never made and seeing
similar things in your HN comment history, I'm going to bow out of this
conversation at this point.

~~~
gress
So because your attempt to dismiss half of android as being irrelevant because
it's 'not sanctioned by Google' failed, you now decide that Android devices
outside the U.S. don't count? I guess this is the closest you'll come to
conceding that you were wrong.

------
bla2
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
They have no other choice; Apple won't accept apps with custom web rendering
engines.

~~~
fekberg
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?

~~~
Cthulhu_
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
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
It may be a power grab, but it also provides protection from malware that
customers value.

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

~~~
gress
This one has both.

------
flyosity
And it's all written in Swift! This is probably the largest application
written in Swift so far, and definitely the largest one on GitHub that I've
seen. If you're looking to make the transition from Obj-C to Swift (or from
any language to Swift) this is probably a solid example to learn from.

~~~
k-mcgrady
According to the GitHub language stats it's only 17% Swift. Nearly 70% C and
6% Objective-C.

~~~
ndomin
100% of the C code is openssl

edit: [https://github.com/mozilla/firefox-
ios/search?l=c](https://github.com/mozilla/firefox-ios/search?l=c)

------
0x006A
\- How far away from a release is this?

\- Given that Apple does not allow other render engines. What makes this
Firefox?

~~~
micampe
_> What makes this Firefox?_

I think that's an interesting question. Is a browser defined by its rendering
engine or by its features and UI?

When Chrome used WebKit, it was clearly understood by everyone to be different
from Safari, even though the rendering engine was the same (I know, the
differences were big), but a Firefox browser that uses WebKit seems to not be
considered Firefox.

Personally, while I understand the philosophical and political differences, I
think the browser is defined by its features, not the rendering engine: the
user wants their bookmarks to sync between the phone and the computer, they
don't care whether the two programs use the same library to draw the page on
the screen or not, just like they don't care which malloc() implementation
they use.

To put it in fewer words: Chrome on iOS is still Chrome, not Safari, because
it has Chrome's features.

(This would not have been true a decade ago, but rendering engines
compatibility is much less of an issue now)

~~~
maxmcd
I feel like whenever I read discussions about this on HN it's all about the JS
engine.

Chrome was on webkit but used V8. And unless something has changed all non-
safari browsers and webviews use an inferior JS engine.

Edit: (Something has changed, WKWebView now has the Nitro JS Engine, cool
beans)

~~~
oscargrouch
Also, when Chrome was launched, it was the only browser with a multi-process
approach to a multi-tab browser world.. Also their approach to threads were
right from the beginning, and that converge into a awesome no-lock and no-
glitch browsing experience.. After that, every other browser followed them.

So, to be fair, Chrome was much more than V8 (which was also a part of its
voodoo)

~~~
bgarbiak
_Also, when Chrome was launched, it was the only browser with a multi-process
approach to a multi-tab browser world.._

Nope, IE8 was: [http://blogs.msdn.com/b/ie/archive/2008/03/11/ie8-and-
loosel...](http://blogs.msdn.com/b/ie/archive/2008/03/11/ie8-and-loosely-
coupled-ie-lcie.aspx)

~~~
ClashTheBunny
Chrome still crashes a few tabs for every process crash. And it feels random
the ones that are threads of the same process.

------
misiti3780
Here is an interesting comment: (KeyPayload.swift)

We should also call super.isValid(), but that'll fail: Global is external, but
doesn't have external or weak linkage! Swift compiler bug #18422804.

~~~
LeoNatan25
Yes, that is a known bug. Swift and its development toolset is still very much
a work in progress and definitely not ready yet, despite the embracing of many
developers. Like anything related to iOS 8, such as Xcode 6, Swift, Watchkit,
OS frameworks, services, it's good six months to one year work away from being
actually ready.

~~~
holygoat
We're certainly finding interesting Swift bugs, that's true.

------
misiti3780
Looks like a great Swift reference! Nice work!

------
owenwil
Anyone manage to get it to build? Lots of errors, assumably very far away from
being usable.

~~~
aclissold
They're mainly just warnings stemming from dependencies—it compiles just fine
in Xcode 6.1.1 after running git submodule update --init and force-unwrapping
a bunch of optionals.

Interestingly, it appears to do everything BUT display web pages at this
point! Looks very preliminary.

[https://www.dropbox.com/s/o5kmot2fg6i7wmx/Screenshot%202014-...](https://www.dropbox.com/s/o5kmot2fg6i7wmx/Screenshot%202014-12-04%2020.48.10.png?dl=0)

~~~
Yoric
Without entering the details (which I don't have anyway, I'm not involved in
this version of Firefox), yeah, it's very preliminary.

------
ZanyProgrammer
Since one of Firefoxes selling points for the desktop is its plethora of
extensions, will those be available on iOS? If not, what's the difference with
this and Safari?

~~~
JohnTHaller
They won't be available nor can they be. Firefox on iOS will be a Firefox UI
over Mobile Safari, like all other browsers on iOS. Firefox's extensions are
made to work with the rendering engine in proper Firefox as you'd use on
Windows, Mac, Linux, and Android. Platforms where you can install your choice
of browser.

~~~
akshayaurora
IMHO, 1Password extension injects JavaScript into web page. Would be
interesting if addons are possible.

------
TazeTSchnitzel
I'm glad Firefox is coming back to iOS. I remember they used to have a similar
Safari wrapper supporting sync, but they must've gotten rid of it.

~~~
JohnTHaller
It's still a Safari wrapper with sync support. Not sure what they'll call it
yet. I really hope they don't just call it Firefox since it definitely isn't.

~~~
rimantas
Is Chrome on iOS Chrome? If it is, why Firefox cannot be Firefox? Or should
they ditch "Firefox" and just call everything Gecko, because you think that's
the most important?

~~~
JohnTHaller
Nope. It's a skin that can sync passwords and bookmarks to Google with some
Google Chrome branding on it over Safari. Google's Blink engine, which powers
Chrome on Windows, Mac, Linux, Android, Chrome OS, etc can't be used on iOS.
Because Apple.

~~~
holygoat
John, you really don't know what you're talking about. Give it a rest.

Chrome on iOS does way more than you think it does -- e.g., it uses its own
network stack.

~~~
JohnTHaller
Richard, I'm aware Chrome does some interesting backflips on iOS to attempt to
get around all of Apple's anti-competitive rules. I was keeping things brief
for a comment. Chrome on iOS does some rather creative things like the
networking stack you mentioned. It's impressive, really.

Still, the actual rendering engine bits _have_ to be Safari. Heck, the whole
reason Google built their own networking stack was because of those absurd iOS
restrictions so they could implement a subset of the features that Chrome on
Android has. So, the app will always be artificially hobbled because of the
restrictions. And it simply can't be as fully functional as it is on other
platforms due to those limitations.

None of that takes away from the fact that overall it's a good thing for
Firefox to be in front of iOS users. I honestly do think it is. That way,
Firefox remains a viable alternative for those users in Apple-land so they can
sync between Mac OS X and iOS.

At the same time, I'm sad. Because a Firefox UI around the Safari rendering
engine just feels wrong. It may sound silly, but it does feel like a little
piece of what Firefox stands for fell with this decision. And I've been
promoting Mozilla since its creation and packaging and promoting Firefox since
before it hit 1.0.

------
akshayaurora
Can we expect Mozilla Stumbler geolocation crowdsourcing also on iOS?

~~~
kbrosnan
No. iOS would require a jailbroken phone from the initial investigation.
[https://groups.google.com/forum/#!topic/mozilla.dev.geolocat...](https://groups.google.com/forum/#!topic/mozilla.dev.geolocation/6qbJAat60pk)

------
0x006A
is this a mirror or did the main development move to github?

~~~
fabrice_d
That's the main repo. It was private before.

~~~
0x006A
So Firefox repos are moving to github instead of hg.mozilla.org or
git.mozilla.org?

~~~
JohnTHaller
Firefox for iOS won't be part of the main Firefox repos because it won't be
using the Firefox underpinnings. It can't use the gecko engine due to Apple's
restrictions. Since it's Firefox mostly in name only, it makes sense to have
it in an entirely separate repo.

~~~
holygoat
That's not true.

We're using GitHub for ease of integration with CI systems, convenience, and
the ability to move more rapidly. We'll move into m-c if and when it suits the
needs of the project.

~~~
JohnTHaller
Ah, I wasn't aware of that. Thanks for the correction. I just assumed it made
more sense to keep it separate since it won't be sharing any existing Firefox
code since it doesn't use gecko or XUL and will be written in Apple's Swift
language. Twas a silly assumption. Voted up.

