iOS at Facebook [pdf]

https://static1.squarespace.com/static/5463eca4e4b09c644a61f99a/t/55fa801ae4b008853e3de038/1442480154751/SimonWhitaker.pdf

by GarethX • 11 years ago

160 109 11 years ago

static1.squarespace.com

spydum• 11 years ago

So, FB app is bloated because they choose to be sloppy is what I read. Wonder how sustainable this is over the long term?

phn3• 11 years ago

Sloppy?! Those guys have needs the majority of us will never need to deal with. Did you read the presentation?

If anything they're the opposite of sloppy.

Touche2• 11 years ago

The parent is not referring to those needs (which are legitimate). The presentation talks a lot about the hacking culture; how there is a lot of duplicate code, a lot of dead code, a lot of "temporary" code.

We call these things technical debt. But it sounds like they just never fix them. Refactors never happen.

rimantas2• 11 years ago

If the were not sloppy they wouldn't have to deal with those needs too.

jonknee5• 11 years ago

Their needs don't explain all the redundant and unused code. It's slop, plain and simple.

s73v3r3• 11 years ago

Their needs are because they're sloppy. Having an overarching Core team who's job is to maintain the app and guide the architecture would cut down on what they need immensely.

applecore• 11 years ago

This strategy was hugely successful for Microsoft since the early days of Windows NT 3.1: “What Intel giveth, Microsoft taketh away.”

The performance advancements on the hardware side of the platform are almost entirely consumed by the ever-increasing complexity of the most popular app on the software side.

mwcampbell• 11 years ago

That may be successful for the software companies. But pity the user who's stuck with old hardware and wants to know why used computers don't last as long as used cars. Maybe when Moore's Law finally becomes invalid...

paulojreis• 11 years ago

It's not sustainable.

But since software developers have been dealt a good hand (demand-wise) in these decades, we get away with it. And call it "hacker culture", so it sounds hip and even correct.

kevinchen• 11 years ago

Actually, I'd counter that it is sustainable -- for Facebook. They have so much user data and so much ad revenue that they can afford to throw engineers and money at the problem. Big companies can work hard and make things work, smaller shops have to work efficiently out of necessity.

Apocryphon• 11 years ago

Product-wise, it's likely that in the long term they're going to break up the FB app into a federation of related apps. They already did that with Messenger.

randomsearch3• 11 years ago

This is truly a superb read. Don't just read the comments!

m4tthumphrey• 11 years ago

This was an awesome read. Thanks Simon!

shyber• 11 years ago

FYI when Sun owned the FB HQ building the address was 1 Network Drive :)

joeblau4• 11 years ago

It seems like with such a strong engineering team, Facebook should have really built their own phone. It's impressive that they re-wrote a lot of the major components the iOS development process and optimized them for their scale. I think a Facebook style development platform on it's own hardware would be an interesting contrast to Google's and Apple's solutions. One challenge with learning this type of development stack is that you're almost not even learning traditional iOS development so your skills aren't truly transferrable.

artmageddon• 11 years ago

It seems like with such a strong engineering team, Facebook should have really built their own phone.

They actually tried not too long ago... [0]

[0] http://www.cnet.com/news/heres-why-the-facebook-phone-floppe...

canistr• 11 years ago

I'd say Facebook's emphasis on developer tools shows they'd be more committed to go down the route of building custom hardware for their devs like mouses, keyboards, laptops, workstations, etc. As opposed to building hardware for end-users.

JamesBaxter2• 11 years ago

Very interesting, even as a fan of native apps I can see the thought process behind doing it web based when you have to build so many tools for each platform.

miguelrochefort2• 11 years ago

Except it's mostly not web based.

Synaesthesia• 11 years ago

Yes interestly enough there was a period when the front-end for mobile was html5 based but they since ditched that for greater (native) performance, in fact as this article reveals, a number of implementations!

JamesBaxter2• 11 years ago

As Synaesthesia notes, it was. I meant with processes and tools like the post describes building once sound like a good idea...

micampe• 11 years ago

This didn't really tell me why Facebook needs 400 people to work on the iOS app and 75 commits per hour.

miguelrochefort2• 11 years ago

Surely most of these commits are either automated, or similar in nature (i.e., adding some static resources to some file).

jonknee5• 11 years ago

Here are the stats for the week starting 24 August this year.In that week: 429 unique contributors 2823 total commits

Right below it:

Doesn’t include commits to bump version numbers, add translated strings etc - actual number is over 4,000

Any way you slice it that is a chaotic pace of change.

onewaystreet2• 11 years ago

Facebook doesn't have a dedicated iOS team, rather each product team (feed, photos, search, messages, etc.) commits code to the app. This allows updates to be made faster and more consistent since there aren't multiple product teams for each product for each platform, but it also leads to having a large number of contributors, commits and duplicate code.

joeblau4• 11 years ago

What's crazy is that WhatApp has 4 Android engineers and 1 billion downloads.

themartorana• 11 years ago

I would suggest that WhatsApp does a whole lot less.

avinassh• 11 years ago

What's crazy is that WhatApp has 4 Android engineers

Interesting. Any source for this claim? And also what's the full size of Whatsapp team?

s73v3r3• 11 years ago

I doubt they have 400 people dedicated to the iOS app. I think it's more that 400 people happened to have touched the iOS app.

rckrd• 11 years ago

Some sidenotes: I'm surprised to see so many custom libraries for Paper, an app which I had forgotten about. And another reminder that a lot of companies at scale are choosing mercurial over git.

bsdpython• 11 years ago

tl;dr Software engineering at extreme edge cases of performance and scalability can look very different than your typical use cases. Don't do this at home (until you have to). Interesting none-the-less.

mnem• 11 years ago

extreme edge cases of performance and scalability

That gave me a chortle :)

cableshaft3• 11 years ago

This was pretty interesting. It would have never occurred to me that XCode, Git, etc. couldn't handle as much as you throw at it, but it kind of makes sense how they explain it here. Still, I don't think I would like to actually work in that environment where the codebase changed so much so often and had so much dead and redundant code, so I guess I'm glad my interview with them didn't go terribly well (got asked questions by non tech-type person who was looking for keywords to obscure concepts as answers and didn't understand my conceptual but keyword-less responses).

manmal• 11 years ago

I've worked with clients that had all their code in one repo at Github, and it took me 5 tries to even pull it down initially. You need not operate at Facebook scale to overwhelm git :)

ch82302• 11 years ago

What keywords do you think the interviewer was looking for? Was it along the lines of "disruptive", "game-changing", "innovative", etc.?

cableshaft3• 11 years ago

I don't remember what all of them were, but I specifically remember one of them had the words "Toll Booth" in it, like "Toll Booth Blah", where blah is the key word I can't remember. It's some networking/communication concept, I think. The phone interview person had a fairly difficult accent too so I don't think I even heard the whole answer.

I've only ever encountered the term once online since. I just tried to Google for it again and I can't find the write combo of terms to find it ("toll booth networking? no.... toll booth computer science? no.....")

So I tried to answer that question with what happens on a concept level, and the person on the line said "No. The answer is 'Toll Booth Blah'. 'Toll Booh Blah'" and moved on to the next question. Like she was Alex Trebek and there was only one way to answer the question.

Meanwhile Google thought I was good enough to fly over for an in-person interview at around the same time, so I just wrote Facebook off as being terrible at hiring and moved on.

To date it's still the worst phone interview experience I've had, and I've had some awful ones.

jonknee5• 11 years ago

Apple uses XCode to make iOS (and OS X and even XCode!), so it obviously can handle more than Facebook.app, but it doesn't fit their culture. Same with Git frankly.

gorena3• 11 years ago

Or they could just modularize into frameworks and use Carthage?

But, whatever, rewrite Xcode I guess.

btmiller• 11 years ago

got asked questions by non tech-type person who was looking for keywords to obscure concepts as answers and didn't understand my conceptual but keyword-less responses

Simple fact of the matter is that you're going to run into those type of questions by non-technical people at any big software company with which you interview. It's on you to be able to smell out what they want and answer with something that demonstrates your abilities and gives them what they're looking for.

buffoon6• 11 years ago

"Done is better than perfect"

"Move fast and break things"

I'm glad they're not holding any critical data like our personal information, what we do, what we think and where we are then!

If this set of slides embodies 'hacker culture' which it claims to, I am not a hacker, neither are my colleagues and I'm proud of that.

The whole thing stinks of arrogance hiding incompetence. I'm not putting anything near facebook, ever.

asdfqwe1• 11 years ago

To be fair, most of these specific signs have been removed now/changed (I was an intern there fall 2013). They actually talked about how that used to be a slogan, but breaking stuff isn't really acceptable anymore because facebook is so big. They still wanted us to move really fast though...

iLoch• 11 years ago

Facebook's new slogan is "Move fast with stable infrastructure."

zeeshanm• 11 years ago

From what I have heard they are now expecting their employees to still move fast, break stuff, but be ready to be penalized for it if you do. So, really, they are encouraging their employees to move at a steady pace with occasional hack nights when there is an upcoming release in the near-term. Facebook is growing old.

vinceyuan• 11 years ago

This post is very interesting. News reported Facebook would create a simplified Android app for low end phone owners in Africa. I think They should do it for iOS too.

untog• 11 years ago

They already have, it's called Facebook Lite. You can't get it from the Play Store in the US, but I download an APK. It's nice.

I only really downloaded it so that I could get notifications, and now m.facebook.com can send them from Chrome, so I'm very happy to totally app-less.

rabino• 11 years ago

The unnecessary bashing of PHP, the lame justification for a sloppy architecture, the immense ego... I don't think hack culture should be used to justify asshole-ery.

emanuelev2• 11 years ago

Can't even imagine the amount of crap in their code-base. I bet that amount of commits is necessary to continuously correct the shitload of mistakes coming from their "Hacking" culture.

onewaystreet2• 11 years ago

They deal with this with automated code review tools like their Infer static analysis tool (http://fbinfer.com) as well as abstracting away the Objective-C with React Native.

emanuelev2• 11 years ago

Yeah that might work for programming mistakes, but not sure it can help with bad design choices.

bjano• 11 years ago

So the main purpose of most of the 18000 classes is to make it possible for the app to scale up to 18000 classes? :)

zacblazic• 11 years ago

Partly! The tools they mentioned (IDE, Mercurial) don't impact the app itself though. Which makes them irrelevant and doesn't factor into why their codebase is massive.

0x4a42• 11 years ago

They are relevant if you take them for what they are: examples that explains, in a general way, why FB has large codebase. Because when something doesn't fits their needs they will write their own version.

So I guess with iOS they wrote/rewrote some part of the system functionnalities to better fit their needs.

sabujp• 11 years ago

what is fb doing for iOS builds and compiles?

aaronbrethorst2• 11 years ago

https://github.com/facebook/xctool

rimantas2• 11 years ago

which is just a wrapper around Apple's xcodebuild.

randomsearch3• 11 years ago

It's interesting to note that this presentation strongly contradicts the advice of "The Pragmatic Programmer" and "Clean Code", which are highly respected by many. Does this mean that those books are wrong, or does it mean that Facebook will eventually come to regret their philosophy? Or maybe writing this kind of code is somehow fundamentally different, so the usual wisdom and rules of thumb don't apply.

I really don't know the answer, but find it fascinating and can't wait to see what Facebook is doing in 10 years time.

alexpersian• 11 years ago

I think what it means is that as it stands now, there is no definite good/bad way to make successful software. There are just opinions.

buffoon6• 11 years ago

There are definite bad ways. I've watched a few companies go down the shitter using known bad ways.

icefox• 11 years ago

It also depends on your definition of successful.

To be successful does software need to (check off what you think would matter):

* Make money directly

* Make money in-directly

* Be used by at least 1 user (not including dev + dev friends and family)

* Be alive and working in 6 months

* Be alive and working in 2 years

* Be alive and working in 10 years

* Simply ship so dev gets a positive yearly review

* Be bug free

* Only crash N% of the time (who cares just re-run it and don't do the bad thing)

* Quality / features don't matter as long as marketing is talking about it and people play with it so it looks successful.

* Simply exist, but be subsidized by some one or something so devs keep hacking on it even if no one uses it.

* Still be useful when there are zero devs working on it.

thrusong2• 11 years ago

They probably have a while to go before they hit the ceiling, if Google's news last week about holding over 2 billion lines of code in one repository means anything.

SRC: http://www.wired.com/2015/09/google-2-billion-lines-codeand-...

xenadu02• 11 years ago

It's all a bunch of bored engineers looking for ways to be clever but without anyone to take ownership of the codebase.

There is absolutely no reason for the Facebook app to be so large and have so many classes. The app itself doesn't do that much.

gorena3• 11 years ago

Yeah, the difference between Facebook and Instagram or Twitter is incremental. They basically do the same stuff, Facebook does a little bit more (although, they entirely removed direct messages). Why is the Facebook app so huge?

Narretz• 11 years ago

I wouldn't be surprised if all the messages code is still in the app.

brazzledazzle• 11 years ago

It's all a bunch of bored engineers looking for ways to be clever but without anyone to take ownership of the codebase.

You couldn't think of a more charitable interpretation? I'm not one to care about rules but the hn guidelines on commenting are important for making sure the community doesn't eat itself alive like reddit did/does.

The app itself doesn't do that much.

Right, but in the presentation he made it clear that it was less about what the app does and more about the number of engineers making changes to it. Given the size of their teams all making their own changes to the iOS codebase, doesn't it make sense to modularize it so they aren't tripping over each other breaking the application constantly? They don't have a dedicated iOS team and having one would bottleneck the other teams.

jonknee5• 11 years ago

Right, but in the presentation he made it clear that it was less about what the app does and more about the number of engineers making changes to it.

Well if it doesn't do that much, why are so many engineers working on it? Perhaps they have so many people working on it because they are all redoing the same stuff and not working together?

bsaul• 11 years ago

So i guess maybe Apple didn't code their ios and ios apps using xcode, xcode-git, autolayout and coredata after all. Because their scale seems pretty big too.

colinbartlett• 11 years ago

I loved the anecdote starting on page 41 where he accidentally "memorializes" his Facebook profile thus triggering an email to his wife about his death.

chuckcode• 11 years ago

Would be interested to see some comparison with the Android app which seems to have most of the same functionality at 1/4 the size with 25MB [1] compared to the 100MB of iOS. Seems like either iOS team at FB has significant cruft laying around or iOS doesn't scale as well as Android and FB is hacking around that. Possibly a bit of both but think it would be an interesting comparison in addition to the war stories about hacking their entire tool chain.

[1] https://gigaom.com/2015/01/26/facebooks-new-android-app-goes...

dmishe2• 11 years ago

iOS apps are shipped as fat binaries, so for one, part of that 100mb app is duplicated slices of binaries for armv7, arm64 and possibly, but not likely, armv7s.

Android apps enjoy bytecode that is getting JIT-ed on install.

dgallagher• 11 years ago

Apple has introduced App Thinning in iOS 9 apps which should cut down on their size:

https://developer.apple.com/library/watchos/documentation/ID...

notNow• 11 years ago

Is there any technical justification for this or it's purely economical/financial?

brodd• 11 years ago

Am I reading this right, there are interns and engineers running PHP in a debugger on production data? How else would he be able to memorialize his own account and trigger the email?

randomsearch3• 11 years ago

That is a good point, how did no-one else pick up on that???! It reminds me of engineers where I used to work, who would run through a £0.01 transaction on their credit card to check the changes to the charging system were still working...

thrusong2• 11 years ago

I've seen talks with engineers that say this is this case. I think the one in particular was from @Scale. They've had the occasional issue with an intern dropping a table in production, but they said they haven't really run into issues with granting access to production data.

gorkemyurt2• 11 years ago

(Another post about React Native)

Facebook engineers keep telling everyone that React Native is not used in the main Facebook app. I always wondered what is stopping them from start using it. Perhaps app size is a massive concern? Maybe all this tooling around their app is not really compatible with React Native?

Its interesting that they have a ton of legacy Obj-c code (considering that companies started to build apps not very long time ago, and they already re-wrote their app several times) I wonder if any other company is a situation like this well other than Apple.

zghst• 11 years ago

It would probably be a huge pain to migrate all 18,000 classes, tests, tools, etc., over to a React Native app. Also JS has less fine grained tooling for performance profiling (try stepping through JS bytecode for performance analysis, it's a PITA). One day it might get there, but not today. If it works, why change it?

gorkemyurt2• 11 years ago

I am not talking about migrating the whole app but how about for new features? I noticed that they redesigned their friends request page, why not build that with react native?

iOS at Facebook [pdf]

Related Stories