Firefox for iOS on GitHub | Hacker News Reader

Firefox for iOS on GitHub

github.com

207 pointsdanabramov142 comments

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

It's not redundant. You wrote an awesome browser and many people, including me, a very eager to get their hands on the new version. Keep up with you awesome work! It's not just that competition like this is important, but this project is also something that you can show around and impress people with it (at e.g. job interviews).

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

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

I don't use your browser, but I'll check it out.

Also I hope the dev of iCab reads HN and can get some benefit from your code - he's not added support for new FF sync yet.

Why is there so much Google Analytics tracking in your app?

https://github.com/graetzer/Foxbrowser/commit/a5ab03e91c06e1...

I just got the 3.0 update on my phone and connected it to my Firefox account. Unfortunately, after the initial sync completes the app goes into a constant crash loop, making it unusable.

This is on an iPhone 5S running iOS 8.1.1, with about 200 bookmarks. If there are any crash logs I can provide, let me know.

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.

Firefox sync and some of the other bells and whistles are nice. Since I use Firefox on all my devices right now, and lean heavily on sync, having a 'Firefox' browser on iOS would be pleasant just for that, even if it's still running WebKit under the hood to satisfy Apple.

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

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

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.

an utterly pointless distinction, since a "rendering engine for content that contains JavaScript" is a browser. so like the guy before you said, on iOS you don't build a browser, you build a skin.

> the rendering engine for content that contains JavaScript

Right. So, a browser. You just proved my point. Apple allows exactly one browser on iOS. Theirs.

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/

[2] https://blog.mozilla.org/blog/2014/10/14/play-awesome-indie-...

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

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.

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.

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.

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.

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.

97% of mobile malware is on Android: http://www.forbes.com/sites/gordonkelly/2014/03/24/report-97...

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.

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

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.

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.

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.

Why exactly is a website more trustworthy with your javascript engine than your app?

What does this even mean? The restrictions are on what runtime you are allowed to use to run downloaded code.

Android is vastly less secure than iOS, which is why there are millions of android devices participating in botnets, and millions of users having money stolen from them by malware on Android.

Apple is cautious about allowing their consumer products to run downloaded code for this reason - it provides a clear and undeniable benefit for customers.

Of course some people want to trade this benefit for the benefit of more flexibility. That is one of the reasons for choosing Android.

Pretending that the iOS approach is just about stifling competition is ignoring the facts.

Also your claim that Chrome uptake was just about speed is unsupported. It was installed as part of the flash installer on many people's machines, and pushed on the Google homepage. Some people may have chose it for technical reasons but many people did so because it was marketed heavily, or installed with another product.

The Android and iOS devices running malware are nearly all doing so due to the built-in security measures being disabled by the end user to enable the addition of apps not from their respective app stores. Specifically, Android devices with side-loading enabled or iOS devices that are jailbroken. Pirated versions of paid apps and games will often contain malware. There are numerous examples for both platforms. As to the numbers, there are a lot more Android phones where the user has enabled side-loading or rooted than there are iOS devices that are jailbroken.

Anecdotally, I don't know a single person in real life on either iOS or on Android that's gotten malware.

Anti-competitive behavior to keep apps that compete for Apple's customer data and money off of iOS provides a clear and undeniable benefit for Apple. It's not like this is unusual or new behavior for them: http://www.digitaltrends.com/music/apple-deleted-non-itunes-...

You have proven the point. If Apple allowed sideloading or rooting, nobody would accuse them of anti-competitive behavior.

Therefore you are asserting that what you are calling 'anti-competitive' behavior is precisely what limits malware on iOS vs Android.

Bear in mind that all of the major vendors, including Google have been convicted of wrongdoing and anti-competitive behavior, so linking to breathless headlines demonstrates nothing.

I still wonder why hasn't anyone sued Apple for anti-competitive behavior...

Anti-competitive behavior is often legal. It's often only illegal when a monopoly as Microsoft was when the US and the EU leveled previous decisions against them. Apple has 42% of the smartphone market in the US, its largest market, and far less everywhere else.

Quite sure that's what I said... However I guess it all depends on your definition of 'browser'. Is it the rendering engine or the UI+features. I think for most people it's the latter. Even for me it's the latter actually. Most rendering engines are good enough now that the differentiation of done through features like syncing of bookmarks and history, auto generation of secure passwords, autofill of address/credit cards etc.

On iOS you use WebKit or you don't make a browser

Remember the days when software choice was a thing, and Microsoft were condemned for merely including a browser with the OS, not banning all software competition? Maybe in about a decade the competition authorities will wake up to this.

There's also the marketing reasons, of course - being present on all major operating systems (and iOS / Android are probably bigger than desktop OSes nowadays in terms of users) is a definite boost. You know, like placing your brand in movies.

Firefox is still a non-corporaty project. I mean, I know they take money from Google, and now Yahoo, and stuff. But the point is that they simply want to make the web a better place, rather than make it a better place for Google users or Apple users and so on.

Also, I don't know how this works, but I'm guessing that some of the revenue they make goes towards supporting the Mozilla Foundation? These guys put out a lot of really awesome stuff, especially evangelizing web programming in impoverished communities in India and such.

Well, I don't mean to appeal to charity. But its just one of the results of this project and experiment. At my last job, we used their open source JS library for handling video content to make a really awesome training application.

Seeing as how it has been so useful, just yesterday I set up a recurring donation of $10/month. I figured, well, I pay that much for Netflix anyways, and use Firefox so heavily. So, it made perfect sense to show my support this way.

On behalf of Firefox developers everywhere, thank you very much :)

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.

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.

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.

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.

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

100% of the C code is openssl

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

That's true, but we're also still learning, and things are changing as Swift and libraries evolve.

- How far away from a release is this?

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

Well according to tweets, not very far.

And with the release of WKWebView, I guess it makes it a skin.

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

It's a huge issue on mobile. Multiple rendering engines requiring the world to write software to a spec is what prevents people from writing code dependent on a particular browser or, in this case, a rendering engine. You see it all the time in the mobile web: plenty of sites just plain don't work when using other rendering engines.

And the fact that web developers then actually can't develop just for one rendering engine and claim that "it's enough" is a very good thing for me. I refuse to use Chrome and I'm extremely hit by all the sites developed "for Chrome only" on the desktop. The web shouldn't be "what's on the developer's machine and not more."

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)

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)

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

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

Chrome's WebKit wasn't 100% compatible with Safari's WebKit. They released from different branches.

You put the rendering engine and features in opposite corners, which is false. Blink and Gecko have features that WebKit does not. Like WebRTC.

I think he refers to features like Bookmark sync, developer tools, and so on.

Finest HN nitpicking. Chrome on Android is missing some features from Chrome desktop (extensions, Flash, NaCl), is it not Chrome anymore?

No, because they chose to exclude those features.

Yup. Good job nitpicking and completely ignoring the point.

Maybe this will be for the jailbroken platform (probably not though :/)

I wouldn't count on it.

iOS SDK forbids one even to build any other browser legally (which is glaring example of of lock-in insanity). At least that's how the license looks like. Are there any alternatives way to build code for iOS?

> iOS SDK forbids one even to build any other browser legally

Really? Can you provide a link?

> Are there any alternatives way to build code for iOS?

http://iphonedevwiki.net/index.php/Compiling_iOS_application...

No restrictions there.

I researched it a while ago, may be the SDK license changed since then. That's what I found then:

License: http://www.wired.com/images_blogs/gadgetlab/files/iphone-sdk...

Relevant parts (emphasis in italics):

-----------------------

3.3 Program Requirements for Applications

Any Application developed using this SDK must comply with these criteria and requirements, as they may be modified by Apple from time to time: ....

3.3.2 An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple's Published APIs and builtin interpreter(s).

-----------------------

Combine the above with this:

-----------------------

3.2 Use of the SDK

As a condition to using the SDK, You agree that: (a) You will only use the SDK for the purposes and in the manner expressly permitted by this Agreement and in accordance with all applicable laws and regulations;

-----------------------

TL;DR (at least how I understood it and IANAL) you can't even legally build any browser which uses its own engine and can run JavaScript code from the network (which is virtually any browser) if you use iOS SDK from Apple.

Of course you can simply ignore this sick level of insanity and build whatever you want, but we are talking about that Apple attempted to legally ban you from building certain applications (it's not even about accepting them in the store, it's about building in compliance with the SDK license!).

Such kind of stuff makes me have zero respect for Apple in general.

I think you are splitting hairs. What would be the point of "legally" allowing you to build an app that could not be submitted to the App Store? The only way to distribute it would be to "illegally" jailbroken devices.

> What would be the point of "legally" allowing you to build an app that could not be submitted to the App Store?

Simple, you can use it personally, or for example submit it to Cydia or any other place without Apple's censorship. Just post it as a download after all. There is nothing illegal in distributing for jailbroken devices.

But that's really irrelevant. The license here doesn't even get to that part - it forbids you to build the browser, regardless of any of your further plans how to use or distribute it. It's completely sick.

I think that part was removed, here's the latest one

http://www.apple.com/legal/sla/docs/xcode.pdf

I lightly skimmed the iOS SDK part and ctrl + F'ed for key words (executable, SDK, Javascript, code) and nothing like those paragraphs you referenced showed up

I see. They put that restriction in another agreement here:

https://developer.apple.com/programs/ios/information/iOS_Pro...

And hooked it from the SDK agreement with this:

-----------

2.2 <...> You understand and agree that Applications developed using these SDK materials cannot be installed or used on an iOS Product or submitted to the App Store unless You enter into a separate iOS Developer Program Agreement with Apple and comply with the Program Requirements. Information regarding the iOS Developer Program Agreement and the Program Requirements is available within the iOS Developer Program website at http://developer.apple.com/programs/ios/information/index.ht...

------------

And that brings almost all the same restrictions like before. It's marginally better since now actual building process is not declared illegal, but installation and running the result is. Which doesn't make any practical difference anyway.

App Store Guidelines:

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

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

This is not about the store guidelines but about the license of the SDK itself really.

> What makes this Firefox?

The icon and a bit of UI design. That plus the ability to sync bookmarks and passwords with Firefox Sync. Otherwise, it's Firefox in name only. It's just a skin over Safari, like all other iOS browsers as per Apple's rules.

It comes from a non-profit organisation and it's the only major browser that's completely open source.

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.

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.

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

Looks like a great Swift reference! Nice work!

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

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

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

They are probably trying to get the bookmark synchronization to work first.

Displaying web pages is easy with the build in UIWebView (or WKWebView) component

Yeah, this pull request fixes all of the actual errors that prevent building:

https://github.com/mozilla/firefox-ios/pull/30/files

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?

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.

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

Probably not, unless the UI itself is rendered in a webview, and extension scripts can be injected into the page during runtime.

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.

The previous iOS app was called Firefox Home, first released in 2010:

https://blog.mozilla.org/blog/2010/07/15/get-firefox-home-on...

Development stopped in 2012:

https://blog.mozilla.org/services/2012/08/31/retiring-firefo...

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.

Oh, I realise.

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?

> Is Chrome on iOS Chrome?

It's not, and just because Google also caved in to Apple's tyranny doesn't make it right for everyone to do it.

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.

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.

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.

Can we expect Mozilla Stumbler geolocation crowdsourcing also on iOS?

No. iOS would require a jailbroken phone from the initial investigation. https://groups.google.com/forum/#!topic/mozilla.dev.geolocat...

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

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

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

Not the main gecko repository, no.

Firefox for iOS won't be based on the main Firefox repo ("mozilla-central"), which remains on hg.mozilla.org.

A lot of Mozilla projects have their main repos on GitHub, including Rust, Servo, and Firefox OS.

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.

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.

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.

Reply on news.ycombinator.com