Facebook Plans to Speed Up its iPhone App | Hacker News Reader

Facebook Plans to Speed Up its iPhone App

bits.blogs.nytimes.com

59 pointsdevinfoley63 comments

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.

I agree. Sometimes it's fun to think of the limiting case: all data on the device locally and displayed in the simplest viewController. Then step towards the real app and you most likely come to your conclusion. Only corner case I can think of is the previous engineers went overboard on the networking code on the device. In theory the facebook apis are plenty fast but the networking code on the device is a c or c++ mess and the current engineers are using higher level objective-c libraries.

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.

Download LinkedIn's iPad app. It's a situation where a WebView-based app is as good as native.

Sorry, but I'd disagree. The transitions aren't very smooth and often times you're faced with a blank screen while waiting for assets to load.

I was actually very hopeful that the app would feel as good as native after I'd read about it, but I was disappointed.

It may have to do with the hardware. On my iPad 3 it feels exactly as good as native.

That hasn't been my experience. "It's as good as native" seems more driven from hope than reality, or more generously, ignorance of the differences that would stick out like a sore thumb to someone intimately familiar with the native platform.

I note that you're a web developer. Full disclosure, I work in the native mobile development space.

I do native development as well as web development. It's easier to get a performant native app than an HTML5 app, no question. But you can create a native feeling HTML5 app that really only the trained eye of a developer would be able to notice the difference of. Most people don't even know the difference between a native and an html5 app. Devices will continue to get faster, and just like on the desktop native applications will be relegated to hardcore apps like 3d games and content creation programs like iMovie, etc.

Completely agreed that a well-optimized native app will outperform a well-written HTML5 app every time. I do think, though, that the difference is getting smaller - especially for apps like Facebook, which are almost entirely content-driven. Things like games are obviously a totally different story. Even five or ten years out, it's hard to imagine HTML5 games with WebGL or whatever seriously competing with native apps.

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.

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.

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

And yet Apple spent a ridiculous amount of time and money to make sure scrolling would be glassy smooth.

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.

Can't native apps be smarter about caching assets than UIWebViews?

You can override the default caching when you're using a UIWebView as well.

Yes however for users Interface speed = speed. Native apps have more leeway in faking the feeling of speed because even if you're waiting for a request you can still fill out the rest of the interface and start using it. HTML5 can feel sluggish because even a 100ms delay is noticeable to the user.

But again: the latency is coming from downloading the assets... you are not going to get a 100ms latency from using a web view unless you are doing something wrong. I use web views in my app, and the views that can be built from local or cached content are honestly native performance (if you feel spinning up a webview itself takes a while: just keep a pool of them, it really isn't that hard), but the things that require talking to a server are considered slow (to which I respond "duh").

This is one thing I've wondered wrt the current FB Apple app. I wonder if they pool/cache their UIWebViews or if they're instantiated each time.

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.

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?

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

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.

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.

How much alike or different are the tweaks required for optimizing for webviews between platforms?

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

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.

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.

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.

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

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

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.

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.

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!

It's not that the web is dead, but the technology stack on the front end side of things is crappy. There's a lot of hype about front end development of course(yes I expect the downvoting by posting it here on HN), but it is not that the tools are superior, but rather because of the necessity of the web.

I agree .. what I meant when I said 'web is dead' is the new web is made of services accessed through apps. Crappy front end technology and mega monolith browser are no longer required.

> There is no excuse for using HTML5 when the native platform offers you so much more and the user base is substantial.

Sure there is - the ability to push rapid updates to the UI, without needing to go through the Apple review process each time.

It's unlikely that the cost of the review system outweighs the costs involved in going non-native for most use cases.

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.

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

I think that this is one of those instances where the needs of the company were prioritized over the needs of the user. Not to say this isn't uncommon in any industry, however, in prioritizing maintenance cost minimization they made the user experience markedly worse for the end user.

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.

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

Do you think it matters to a company with a substantial mobile user base - and tons of money? HTML5 is for cheapos.

In Facebook's case, it wasn't about money, lord knows they had plenty of that. It was about being more agile. With HTML5 they could play with a lot of different views without having to push a monolithic update to their users every time. HTML5 works better for some apps than native languages do; for instance, I'll bet dimes to dollars you're consuming Hacker News via the web, not a native app.

Monotouch provides an interesting alternative. You still have to do custom UI for each platform, but you can reuse all the other code and still get native performance.

Agreed 100%!

HTML is for documents, not Frankenstein coded applications.

Jeff Atwood said it best: performance is a feature.

http://www.codinghorror.com/blog/2011/06/performance-is-a-fe...

Unless you are Chrome for iOS.

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.

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

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.

I'm not saying changing the native code, but with the same native code building a different interface from some kind of description file that could be updated remotely.

Maybe Apple would not be happy about that, but I don't know if they'd be able to tell you're going to do that during the review process.

You still can not dynamically download anything that needs to be 'interpreted' on the device application.

Your 'UI Description' file most likely will fall under that category.

No, that would be ludicrous. It would be impossible to fill a UITableView with data from a server if that were the case. The rule is really about linking interpreters into an app and then having them run code fetched over the net.

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.

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.

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.

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

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

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.

He/she meant the iPad app.

Linkedin's mobile app is a hybrid, but their iPad app is 100% HTML5 and runs beautifully.

I'm also pretty sure that Google's Gmail iPhone app is 100% html5 as well as I've seen it re-render the entire interface occasionally as if it were an app in a UIWebView.

Reply on news.ycombinator.com