Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

iOS at Facebook [pdf]

static1.squarespace.com

Post reply on HN
Print view View original

81–90 of 111 posts

Re: iOS at Facebook [pdf]

#81

Post by dgallagher »

dmishe wrote: post #76
chuckcode wrote: post #68

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 abo…

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.

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

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

Re: iOS at Facebook [pdf]

#82

Post by s73v3r »

micampe wrote: post #11

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

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.

Re: iOS at Facebook [pdf]

#83

Post by azsromej »

dgallagher wrote: post #81
dmishe wrote: post #76

Earlier quoted context omitted.

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.

Apple has introduced App Thinning in iOS 9 apps which should cut down on their size: https://developer.apple.com/library/watchos/documentation/ID...

The feature was recently delayed, but it should help once it's ready

Re: iOS at Facebook [pdf]

#84

Post by gorkemyurt »

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

Re: iOS at Facebook [pdf]

#85

Post by s73v3r »

phn wrote: post #4
spydum wrote: post #2

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

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.

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.

Re: iOS at Facebook [pdf]

#86

Post by buffoon »

pja wrote: post #69
buffoon wrote: post #58

Earlier quoted context omitted.

Debian was a complete dick on my old ppc g4. It sort of put me off. The was going to try FreeBSD but I have to persuade the wife to let me buy a g5 yet as they're large, noisy and entirely unnecessary. I just want one to play with and go ooh and aah and stuff :) I did the same with old SPARC kit a number of years ago too.

PPC Debian runs just fine on my old Mac Mini. I could replace the thing, but it just keeps chugging on.

Time to have another bash I think. She might take to a G4 Mac Mini over a full sized G5 as well ;-)

Re: iOS at Facebook [pdf]

#87

Post by buffoon »

alexpersian wrote: post #57
randomsearch wrote: post #46

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 do…

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.

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

Re: iOS at Facebook [pdf]

#88

Post by s73v3r »

phn wrote: post #36
Touche wrote: post #14

Earlier quoted context omitted.

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.

They don't call it debt. It is simply their way of keeping their agility with a huge number of developers. If the flip side is junk that mostly impacts install space, I don't see it as a bad trade-off. What alternative way would you suggest to keep your mega team productive and shipping features?

1. Having a core team who's job it is to maintain the app and clean up the debt.

2. I seriously have to question that they absolutely need that pace. I don't buy it for a second that any of this is necessary or better than the alternative.

Re: iOS at Facebook [pdf]

#89

Post by brazzledazzle »

xenadu02 wrote: post #52

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.

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

Re: iOS at Facebook [pdf]

#90

Post by davnicwil »

kevinchen wrote: post #74
paulojreis wrote: post #10

Earlier quoted context omitted.

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.

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.

Yes indeed. From a slightly different perspective, assuming every good dev tries to be as efficient as they can be, even assuming they are, but with varying degrees of success due to various factors, a big company can hire lots of good people and only needs to get lucky and hit the mark occasionally. A small company on the other hand has to get lucky pretty much every single time.
Post reply on HN