
Safari Vs Chrome iOS JavaScript Benchmark - dkokelley
http://pastebin.com/gaZp1rjp
======
mtgx
What is the point of UIWebView, if it's meant to help developers write
Javascript "native" apps, and yet it's 3x slower than a web app would be
inside Mobile Safari? Doesn't that kind of defeat the purpose of UIWebView
existing?

I'm pretty sure Apple is leaving this as it is on purpose so Javascript apps
don't start to compete on performance with ObjectiveC apps, and the security
excuse they give is just the lazy one to get them off the hook, just like
Microsoft is saying "WebGL poses security issues, so we won't even try to add
it".

Well guess what. A lot of stuff poses security issues. But you have to balance
that out with the features and usability you want to give to the user, and if
there are some good and "logical" features you could add like setting other
browsers as default, or letting UIWebView apps be as fast as web apps in
Safari, then you just have to add them and make sure the security is as tight
as possible. Add a sandbox if necessary and so on. Don't take the easy way
out.

~~~
danilocampos
> What is the point of UIWebView, if it's meant to help developers write
> Javascript "native" apps

I'm not sure I buy the premise here. UIWebView is a class to help developers
show web content in an app. That's all it was ever about.

> I'm pretty sure Apple is leaving this as it is on purpose so Javascript apps
> don't start to compete on performance with ObjectiveC apps

Why? Apple doesn't need to worry about this. Their platform-specific features
mean that native apps will always win on user experience, regardless of
performance. They don't need to hobble performance. Conspiracies sound cute to
write about, and are fun to cook up, but it's much likelier that Apple just
has better stuff to worry about.

They have a successful, widely-adopted solution for developers to create great
apps for their platform.

They have a solution for users to have a great, fast browsing experience.

That's about all they need at the moment, in a world with finite time and
resources. It's not Apple's goal to make every single nerdy desire or business
model possible. It's their goal to sell a shitload of hardware by making users
happy.

My mom isn't asking for super fast performance on a third party browser. She
just wants her internet to work. Apple's already giving her that. QED.

~~~
mgurlitz
> I'm not sure I buy the premise here. UIWebView is a class to help developers
> show web content in an app. That's all it was ever about.

I'm pretty sure it's still the case that when you add a HTML5 app to your home
screen (so your users see the icon instead of a bookmark in Safari) all of a
sudden it doesn't get run on the Nitro JS engine anymore.

~~~
danilocampos
> I'm pretty sure it's still the case that when you add a HTML5 app to your
> home screen (so your users see the icon instead of a bookmark in Safari) all
> of a sudden it doesn't get run on the Nitro JS engine anymore.

It is not the case.

[http://arstechnica.com/apple/2011/06/ios-5-brings-nitro-
spee...](http://arstechnica.com/apple/2011/06/ios-5-brings-nitro-speed-to-
home-screen-web-apps/)

------
structAnkit
While third-party browsers won't be able to compete with Safari on iOS due to
the technical limitations, I still prefer Chrome on my iPhone because it ties
in with my Google account, syncing everything for me. The loss in per-page
performance is somewhat mitigated by the fact that I have to load fewer pages
than before thanks to features such as Chrome to Mobile and syncing of tabs,
bookmarks, and passwords.

Also, Chrome is so well designed for mobile as on my Galaxy Nexus that it is
difficult to switch to any other browser. The way they handle tabs is the best
I've seen. Incognito mode also offers an easy way to simulate a second browser
session without switching to another browser app, something I as a web
developer cannot live without.

~~~
clutchrockwell
I am also happy to take the performance hit in stride in exchange for the sync
features. The "request desktop version" feature is also nicely implemented.

------
ltcoleman
These benchmarks are not surprising. The UI however is the biggest turn-on.
Chrome for iOS was very well done even though it is NOT Chrome.

------
jcampbell1
Can someone explain how an application developer with access to webkit+Nitro
could cause problems? Would the developer have to write a malicious app, or
would a maliciously crafted webpage be able to exploit the OS?

~~~
Xuzz
iOS code signs all code that runs on the system. Compared to most other
operating systems, this is a huge security win: without another exploit in
that system, even a standard remote code execution vulnerability is useless.
Nitro generates code at runtime, so it (by definition) needs to run unsigned
code. With Safari, Apple can audit all the code necessary, but with third
party apps, it would be easy for a developer to have their app exploited or
even use the unsigned code ability to download new, possibly malicious code
after the App Store review process.

~~~
lucian1900
Except there are always exploits in signed code on that platform, in the form
of jailbreaks.

It's a weak argument at best.

~~~
Xuzz
So far, there have been two userland exploits of the iOS browser (Safari)
since Apple implemented code signing in 2008, at JailbreakMe.com. Both of
those required tons of extra work compared to what they would have required
otherwise.

It's not a "weak argument", it's _the reason_ why iOS is one of the most
secure platforms out there, and way more secure than Android, Windows, (most)
desktop Linux, and OS X. Other preventative technologies (e.g. ASLR, DEP/w^x,
etc) are on those platforms, but none of them have the same kind of pervasive
code signing that you see on iOS (and often video game consoles).

~~~
lucian1900
Code signing is _the reason_ why iOS and game consoles are closed platforms,
so only the first party controls what you can run on it. They're just
protecting their profits.

It has yet to be shown that code signing helps significantly to improve
security. It relies too much on the competency of those that write said signed
software. Measures like sandboxing are much more effective.

~~~
uxp
> It has yet to be shown that code signing helps significantly to improve
> security.

Hah! I needed a good laugh today.

No, Apple has not blacklisted a developer's certificate that we know of to the
extent that pre-existing apps on an arbitrary user's phone will stop working
due to validation failure, but they have revoked certificates from developers
that effectively prevent them from ever submitting another app to the
store[1]. You're right that sandboxing is a stronger security measure in a
general sense, but security isn't a black or white thing you can throw a
single buzzword at and have all your problems taken care of. Code signing is
an additional layer of protection for the average user so he/she doesn't
download a fake AV program that grinds their device to a halt while offering
to get rid of itself for the low price of $39.99. Yes, code signing also
ensures that the manufacturer of the device can also get a cut of the profits
of other people's hard work, but that is not it's only reason for existence
and it doesn't always have to be employed as a revenue stream.

[1]
[http://www.forbes.com/sites/andygreenberg/2011/11/07/apple-e...](http://www.forbes.com/sites/andygreenberg/2011/11/07/apple-
exiles-a-security-researcher-from-its-developer-program-for-proof-of-concept-
exploit-app/)

------
conradev
I think a Chrome engineer at I/O summed it up best, from the Campfire session
for Chrome/OS:

There's raw performance, and there's usability. Both determine how fast you
get your content. Where Safari wins out in performance due to restrictions on
iOS, Chrome wins out in usability. The Omnibox, for example, recognizes my
favorite sites after I type just a few characters. Plus, syncing.

------
dchest
Does WebKit on iOS ships with LLInt? I think not, so there's a room for
improvement for unJITted version.

<http://trac.webkit.org/changeset/108309>

[http://wingolog.org/archives/2012/06/27/inside-
javascriptcor...](http://wingolog.org/archives/2012/06/27/inside-
javascriptcores-low-level-interpreter)

------
mschalle
It looks better and feels snappier, so these tests are surprising...

~~~
dkokelley
It wouldn't surprise me to discover that Google's team did lots of their own
performance tweaking and tuning to compensate for their disadvantage. I do
love the responsiveness. Now their Gmail app on the other hand was painful for
me to use.

~~~
urbanjunkie
The latest update to the GMail app for iOS is vastly improved.

~~~
bballdeo
How does it compare to Sparrow?

------
amosel
V8WebView?

------
wedtm
...

Chrome on iOS is using the native iOS render, IIRC. So wouldn't this test be
testing the same thing?

~~~
jasonlotito
No, not exactly.

Chrome is using the web view without JIT compiling for JavaScript that Safari
can take advantage of. That being said, it's not something that's surprising.
It's a known issue.

