Engineers Detail Extensive Efforts to Rewrite Facebook iOS App

Friday August 24, 2012 1:16 PM PDT by Jordan Golson
NewImageFacebook employee Jonathan Dann has written a blog post detailing how the company's iOS engineering team designed earlier Facebook for iPhone apps and the extensive coding that was required to rewrite the new Facebook 5.0 app.

The post is a bit technical in parts, but is worth a read for developers and others interested in how one of the most popular iPhone apps gets made.

An excerpt:
One of the biggest advantages we've gained from building on native iOS has been the ability to make the app fast. Now, when you scroll through your news feed on the new Facebook for iOS, you'll notice that it feels much faster than before. One way we have achieved this is by re-balancing where we perform certain tasks. For example, in iOS, the main thread drives the UI and handles touch events, so the more work we do on the main thread, the slower the app feels. Instead, we take care to perform computationally expensive tasks in the background. This means all our networking activity, JSON parsing, NSManagedObject creation, and saving to disk never touches the main thread.

To give another example, we use Core Text to lay out many of our strings, but layout calculations can quickly become a bottleneck. With our new iOS app, when we download new content, we asynchronously calculate the sizes for all these strings, cache our CTFramesetters (which can be expensive to create), and then use all these calculations later when we present the story into our UITableView.

Finally, when you start Facebook for iOS, you want to see your news feed, not a loading spinner. To provide the best experience possible, we now show previously-cached content immediately. But this introduces a new problem: If you have a lot of stories in your news feed, UITableView throws a small spanner in the works by calling the delegate method -tableView:heightForRowAtIndexPath: for each story in your news feed in order to work out how tall to make its scrollbar. This would result in the app loading all the story data from disk and calculating the entire story layout solely to return the height of the story, meaning startup would get progressively slower as you accumulate more stories.

The solution to this particular problem has two main parts. Firstly, when we do our initial asynchronous layout calculations, we also store the height of the story in Core Data. In doing so, we completely avoid layout calculation in -tableView:heightForRowAtIndexPath:. Secondly, we've split up our "story" model object. We only fetch the story heights (and a few other things) from disk on startup. Later, we fetch the rest of the story data, and any more layout calculations we have to do are all performed asynchronously.

Top Rated Comments

(View all)

Posted: 29 months ago

Hate to see if they had to work on a game or some other app that really required good coding skills.

I guess making an app to download cat pics and "I'm going to bed now!" messages was tough work.



Michael


Do you have programming experience?
Rating: 19 Votes
Posted: 29 months ago
Hate to see if they had to work on a game or some other app that really required good coding skills.

I guess making an app to download cat pics and "I'm going to bed now!" messages was tough work.



Michael
Rating: 13 Votes
Posted: 29 months ago

It's marginally better. Completely rewritten, huh? So instead of making actual improvements on the UI in the process, they kept the same limited capabilities and just made the app start up a little faster.

Still no way to share posts.


I don't use the facebook app, but I'm pretty sure I'd like a decent, usable app that's missing a few features, rather than a terrible, laggy app.
Rating: 13 Votes
Posted: 29 months ago

Nah.... just how I have earned my living for the last 11 years. That's all lol.


Sorry, it's just that your comment makes it seem like you have never coded anything of quality. Just because it can display cat pictures doesn't make it trivial. I would expect anyone with experience to respect the work that went into this app, especially after reading the linked article.
Rating: 9 Votes
Posted: 29 months ago
It's always great to see real-world hard-won experience doled out like this.

To those mad there aren't more changes, rebuilding is hard. New features are hard too. Don't do both at once. Rebuilding makes future changes easier.
Patience. Mobile users barely make Facebook money anyway.
Rating: 7 Votes
Posted: 29 months ago

Hate to see if they had to work on a game or some other app that really required good coding skills.

I guess making an app to download cat pics and "I'm going to bed now!" messages was tough work.



Michael


Never coded before, have you? Games are difficult but nowhere near the most challenging.
Rating: 6 Votes
Posted: 29 months ago
tl;dr: We did some shtuff and now it's faster. Enjoy.
Rating: 5 Votes
Posted: 29 months ago

Nah.... just how I have earned my living for the last 11 years. That's all lol.

HTML and Javascript do not count as software development.

Have you written anything for the consumption of end users in any of the following languages:
C/C++, C#, Java, Perl, Python?

I have been working as a software developer for almost 15 years and I have written mission critical software using each of those languages in my career.

I also dabbled in web development which included both client side and server side code but if someone only dealt with client side scripting and layout then they really could not rightly call themselves a "developer".
Rating: 5 Votes
Posted: 29 months ago

But if you want to believe the Facebook app is some kind of impossible to code "app" go right ahead.


There is no impossible to code "app". But to say the Facebook app is trivial is quite insulting to the people who worked on it, be it the HTML5 cross-platform version or the current iOS native port.

Database programming ? I guess now we know why you think Facebook is trivial, you don't know the half of it beyond the SQL join used to extract the data from the database, "cupcake". :p
Rating: 5 Votes
Posted: 29 months ago

As for me, optimizing simple processes that shouldn't have been intensive in the first place is not something I am impressed about. :cool:

That's what I got out of his remarks too. :) Facebook isn't rocket surgery. Sounds like they have a bunch of green programers trying to reinvent the wheel.

Kudos to their infrastructure and backend for handling the insane amounts of traffic but not so much for the front end design.

You obviously have not spent much time coding for iOS. Doing the type of optimizations this post discusses is difficult, and a lot of the solutions they have come up with (for example, caching the table view cell heights) are very clever.

Just because something looks straightforward does not make it a "simple process" or "not rocket surgery" (whatever that means?) If you think you can do it better, go ahead, but your comments clearly indicate that you do not have a deep technical understanding of what's going on here.
Rating: 4 Votes

[ Read All Comments ]