

Facebook Plans to Speed Up its iPhone App - devinfoley
http://bits.blogs.nytimes.com/2012/06/27/facebook-plans-to-speedup-its-iphone-app/

======
kevincennis
Facebook's current app isn't slow because it's written predominantly in HTML5.
It's slow because it takes forever to retrieve assets from their servers.

There's nothing magical about Objective-C that's going make the HTTP requests
quicker.

The whole "native vs web view" performance debate is about things like
animations and scrolling and rendering, not about the speed of retrieving
assets from a remote server. And that's what's terrible about the current iOS
app.

~~~
jcromartie
User perceptions play into performance more than you'd think. If the HTML app
can't scroll or transition smoothly, or it's spinning up new WebViews and you
have to wait (there is an inherent delay in loading _any_ content in a new
UIWebView), then users will say it's slow. Not to mention memory usage of HTML
elements, and managing that whole mess (the "rococo pandemonium" of HTML CSS
and JavaScript, as Tim Bray put it) of objects in (usually) one giant
container...

I've never found a situation where a WebView-based app is better than native.

~~~
kevincennis
I completely agree with that - but I'd argue that the overwhelming majority of
"slowness" felt with Facebook's iOS app revolves around lengthy requests, not
a lack or responsiveness on user interactions.

~~~
scott_s
Personally, it's both. The application stutters for me constantly. I use my
thumb to scroll, and the application does not respond for a second, then
quickly catches up to what I did. _That_ I assume will be fixed by going
native.

~~~
kevincennis
I'd imagine that the average, non-HackerNews-reading user is far more
sensitive to "this takes FOREVER to load" than "this scrolling is choppy".

~~~
scott_s
I imagine both bother them about equally, but that they don't distinguish
between them. They're both just the app being "slow." To be clear, the
scrolling isn't just a little choppy. It's a delay of a full second sometimes.

------
RoyceFullerton
I think the bigger problem is still iOS's webview from within native apps, not
that it has to pull most of the assets from the server. If you go to
m.facebook.com in Safari it is much faster than using the native application
and most of it is the same HTML5 code that is running within the webview of
the native app. The twitter app is also painfully slow when clicking a link
and it opens up the resulting page in a webview.

~~~
wonnage
I've noticed this as well, and it seems to be a recent phenomenon - it's
gotten to the point where I just open links in Safari when possible. Any idea
why?

~~~
RoyceFullerton
One reason:

"...performance of UIWebViews is less than in mobile Safari. This has a lot to
do with the absence of the new Nitro JavaScript engine in UIWebViews,
apparently for security reasons. I ran some tests on my iPhone 4 with iOS
5.1.1, the JavaScript benchmark Sunspider running in Mobile Safari was 3 x as
fast as running in a native app with a UIWebView. Also, to communicate from
the UIWebView to the native app, a JavaScript bridge is needed. This is tricky
stuff, slow and not really thread safe."

[http://blog.mobtest.com/2012/05/heres-why-the-facebook-
ios-a...](http://blog.mobtest.com/2012/05/heres-why-the-facebook-ios-app-is-
so-bad-uiwebviews-and-no-nitro/)

~~~
raganwald
This.

IIRC, the reason is that the Nitro engine compiles directly to native code,
which is then executed. This requires writing to memory as data and then
executing the data. However, Apple doesn’t allow third-party applications to
execute data for any reason. This would violate security policies. Thus, any
and all third-party scripting—be it JavaScript in a Webkit view or something
else—must be interpreted. The best a third-party application can do is compile
to byte codes and then interpret the byte codes.

------
MattRogish
I think the biggest problem here is that iOS/Android WebViews are incredibly
sensitive to memory and CPU, and if you just take an otherwise amazing desktop
or backend developer and throw them in mobile webview, you're setting them up
for failure.

The webview is a whole different ball of wax (my last gig was PhoneGap
development on iOS and Android) and if you are not, from day one, incredibly
focused on performance (CPU and Memory) you're gonna have a bad time.

Knowing what I know about making PhoneGap apps, there's nothing inherent in
what FB is doing that the WebView is incapable of doing. It's just really hard
to get it right, much harder than a native app.

~~~
marknutter
No harder than getting it right in native code on 3 different platforms.

~~~
MattRogish
Depends on what you mean by "hard". Although it's time consuming to learn
different platforms, there are not a whole lot of gotchas you have to discover
on your own. It's all been done before and well documented.

PhoneGap development is hard inasmuch as there are tons of gotchas you don't
know about and haven't been clearly and extensively documented.

~~~
jetz
Hard as in writing code in three different languages. Apart from that I think
tech community giving too much credit for Apple and especially Google. They
could have fixed this native vs html5-js-css thing two versions ago.

~~~
flatline3
Three different languages that provide vastly superior runtime libraries and
tooling that facilitate implementing first-class applications on the target
platform.

I agree that supporting multiple platforms is suboptimal, but instead choosing
a suboptimal common platform isn't any better.

We already tried that once with Java desktop applications, and Java at least
_tried_ to provide a viable common widget/platform toolkit.

~~~
marknutter
No, we tried it once with web applications, and it worked brilliantly.

~~~
flatline3
When did that happen? Are we reading the same article?

~~~
marknutter
Sorry. What I meant was, web applications have been a successful cross
platform way of delivering software for the past 10 years. I don't see any
reason why it can't continue on mobile, especially now that the hardware is
catching up.

------
zaidf
I have tonnes of emails saved in my iPhone Notes app of people I met, tried to
unsuccessfully find on facebook using the app, and later found them using the
facebook.com from a normal computer.

I'm starting to feel that facebook purposely broke its iPhone app to limit
use. There is simply no other explanation why the most basic feature of
finding and adding a new friend would be so terribly broken.

------
anuraj
There is no excuse for using HTML5 when the native platform offers you so much
more and the user base is substantial. Only cheapos try to get away with it.
Web is dead, welcome to app economy!

~~~
marknutter
Are you trolling? If you go native you have to write and maintain a different
codebase for ever platform you want to support. With HTML5 you can update code
without going through Apple's lengthy update process, and you can share that
code across as many platforms as you like. HTML5 also allows you to tap into a
much wider pool of developers.

~~~
flatline3
None of what you covered provides any advantage whatsoever to your users. It's
all about making web developers happy.

~~~
marknutter
In the case where you only have the resources to make an iOS version of your
app, you certainly are thinking of your users when you use a cross-platform
solution so that Android is supported.

~~~
duaneb
Perhaps, but the better thing to do would be to write native apps for both
users.

------
lbarrow
Jeff Atwood said it best: performance is a feature.

[http://www.codinghorror.com/blog/2011/06/performance-is-a-
fe...](http://www.codinghorror.com/blog/2011/06/performance-is-a-feature.html)

~~~
cpeterso
Unless you are Chrome for iOS.

------
glhaynes
Excellent news. I know it says that the design isn't really changing, but I
hope that a few things get cleaned up, too — say, like the way comments views
sometimes show Likes and sometimes don't. That one's baffling to me.

------
Timothee
"the company had chosen to build its apps predominantly using HTML5 so that it
could take advantage of reusing programming code across multiple mobile
platforms"

This is certainly a benefit, but at Facebook's scale, it made sense to
dedicate engineering efforts to have the best experience on the iPhone. I'm
glad they're finally going in this direction. However, I think that one of the
benefit that is not mention here is the easiness to change the UI at any
point, which they've been doing all the time.

That being said, I would think that it would still be possible to modify a
native UI without going through an App Store review, since more or less
everything can be created and customized programmatically: so you can send
some kind of file that describe the UI tweak. Surely, it can become a mess
pretty fast, but it's an option.

~~~
marknutter
That would violate Apple's terms. Apple allows updating of HTML/JS/CSS without
going through the update process but not the updating or changing of any
native code.

~~~
anuraj
Don't really understand what you are saying. What prevents you from changing
the JSON data that you display within a native screen at any given time? HTML
is not the only way to transfer data out there and interpretation is totally
upto the app.

~~~
marknutter
Meaning, you can replace code wholesale so long as it doesn't change the
original intention of the app and it's just html/css/js you're changing. So if
you're using a javascript framework to build an application, for instance, you
could send an update to that app over the web rather than go through the app
store update approval process.

------
programminggeek
Having done some PhoneGap dev lately, it is possible to make a great app using
HTML5, but to make it perform well and have the right look and feel requires a
ton of work, and the tooling around it still leaves something to be desired,
especially on the UI side.

Libraries like Kendo UI or Sencha Mobile help a lot, but if I were Facebook,
I'd spend the dev time to do it right and make it awesome.

Whether that means optimizing the crap out of their HTML 5 or going native is
a judgement call.

~~~
jcromartie
I've had a hard time finding a really convincing "great app" that is largely
HTML5. Can you mention what it was?

~~~
inerte
Linkedin's app is mostly web tech. While I personally have used it a few
times, I think most people enjoy it.

~~~
jcromartie
LinkedIn's app on the iPhone has a lot of native views. There are some
telltale signs that indiciate native components make up everything but the
"leaf nodes" of the app's UX.

~~~
mehrzad
He/she meant the iPad app.

