Live data from Hacker News

Firefox for iOS on GitHub

github.com

121–130 of 145 posts

Re: Firefox for iOS on GitHub

#121

Earlier quoted context omitted.

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…

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.

Re: Firefox for iOS on GitHub

#122
post #97

Earlier quoted context omitted.

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.

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…

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.

Re: Firefox for iOS on GitHub

#123
post #121

Earlier quoted context omitted.

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.

Re: Firefox for iOS on GitHub

#124
post #122

Earlier quoted context omitted.

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…

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…

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

Re: Firefox for iOS on GitHub

#125
post #121

Earlier quoted context omitted.

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.

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

Re: Firefox for iOS on GitHub

#126
post #121

Earlier quoted context omitted.

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.

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.

Re: Firefox for iOS on GitHub

#127

Earlier quoted context omitted.

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.

Re: Firefox for iOS on GitHub

#128
post #121

Earlier quoted context omitted.

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.

Re: Firefox for iOS on GitHub

#129

Earlier quoted context omitted.

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.

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.

Re: Firefox for iOS on GitHub

#130

Earlier quoted context omitted.

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.
Post reply on HN