Analysis of the Facebook app for iOS | Hacker News Reader

Analysis of the Facebook app for iOS

blog.timac.org

125 pointsAaronn53 comments

This is really unacceptable and so easy to solve, had they even bothered.

But it has been known for years that Facebook just cannot (or will not) manage its application development process. I remember reading somewhere that they developed build tools that take multiple versions of the same static library and mangle the symbols so that all versions can be linked into a single binary and there are no symbol collisions - all this to allow developers to use whatever version they started of, and god forbid, require some sort of review or cooperation between developers.

It is very sad to me that so many companies (start up or otherwise) aspire so much to have the same work methodologies as this company.

It takes just a little discipline, but nobody wants to do it. You're completely right - it's a shame how often products are made without any sense of deliberateness.

The fact that you think this third-party analysis has discovered an incredibly easy way to radically reduce the size of the Facebook app - but that Facebook has not "discovered" the same "fix" - reveals an oversimplified perspective of iOS, app development, and large tech companies.

I absolutely guarantee that this analysis is missing some significant complexities, and that Facebook understands what's actually going on under the hood.

Lol +1 here. I guarantee LeoNatan25 that the situation is MUCH more complicated than he/she is giving credit

It's funny, because there seems to be a lot of effort to get exactly the right version of asset in every circumstance. I'd wager showing an old version of the thumbs up really would get someone fired.

It's so much funnier though, that the solution is to just keep throwing in more and more copies of the images.

I feel kinda bad for the poor developer responsible for keeping all of those copies up to date. Very much 'i pass butter' kind of programming.

I wouldn't assume anyone is responsible for keeping them up to date.

This could just be the build tool looking at dependencies and including them multiple times in seperate frameworks. No different to how in big Java apps you often will see duplicate code amongst shaded JARs.

It's not code though. In this case a resourceBundle would solve the duplicate image problem in java.

Hashing resources is like an intern problem, technically at least. Facebook must have some crazy politics to incur the image dedupe problem.

As far as objective c binaries go, all I can think of are static variables for coroutines, but I'm probably forgetting something. Java doesn't dedupe, but it's not that hard. C has to worry about flag state, so I kind of understand why they don't dedupe binaries.

I'm sure someone would get fired if one subsystem showed the wrong image, but I'd agree it's likely no one person has that in their job description.

Otoh, it's only a couple hundred wasted terabytes, and FB doesn't pay for them, so who cares?

I would not bet on it. Last I heard a bunch of FB app code was generated and they did not bother to remove unused parts.

Has nobody worked on a decent sized, agile project before ?

Facebook updates their iOS app on a pretty regular cadence which means it is quite likely that removing duplicate assets (if it's even an issue) could simply have trickled across to the next sprint. You just can't make broad generalisations based on a particular snapshot in time.

But I suspect it isn't even an issue anyway. It seems clear they have one lightweight framework that is required during startup and another which gets dynamically loaded later (FBNotOnStartupPathFramework).

I did not buy 64GB of flash storage so Facebook could be lazy. I bought 64GB of flash storage to store media that gets noticeably better, to a point, when you throw more bits at it.

Things that are smaller than Facebook's iOS app:

- Windows, through at least Windows 95, if you count stuff written to disk during install

- The Java Runtime Environment

- Eclipse IDE

- Google Chrome for OS X (beware—updater leaves old versions in the app bundle)

- Firefox for OS X

- Pokémon Go

- A two-disc set encoded in 256kbps AAC

And to add insult to injury, Messenger is another 155MB, and is a separate app for some reason, probably with a second copy of that bigger-than-the-JRE-by-itself FBSharedFramework.

And while the sudden almost 300MB is new, the "I can't believe this is a Web service front-end and not an experimental operating system" bloat has been with us for a while.

> I did not buy 64GB of flash storage so Facebook could be lazy.

then vote with your wallet, and remove the app. If you can't tear yourself away from facebook, the web is the "right" app to use!

Fair enough. But people will decide not caring even slightly about binary size is admirable (move fast and make users buy new phones, I guess) and eventually everything will be huge. Already the number of sub-60MB apps is dwindling and the 100-and-up club is growing, if my recent updates list is any indication.

Unfortunately, on android facebook purposefully disables parts of the website (chat in particular) to force oyu to install the app.

Chat can still be accessed through mbasic.facebook.com.

What other parts are disabled?

That's intentionally awkward. If I tap the messages icon on Facebook.com on mobile, I get redirected to a page telling me to download the app. Similarly, messenger.com points me to the App Store.

I didn't know about that website. Thanks.

On the contrary: You can even enable push notifications with Chrome for Android. Chat included. I haven't touched the native apps for ages and everything works just fine.

Chat is also disabled in the app. You have to download Facebook Messenger to get it.

I suspect that decision to split the app comes from equal parts marketing and software engineering incompetence.

> Has nobody worked on a decent sized, agile project before ?

> Facebook updates their iOS app on a pretty regular cadence which means it is quite likely that removing duplicate assets (if it's even an issue) could simply have trickled across to the next sprint.

Somebody already expressed this idea more concisely in comment section on the original site:

> This is what happens when your development team is too big and you have a policy of updating your app every two weeks for no particular reason.

What? I'm sorry, normally I defend "you don't understand the complexity", but in this case, it's the same file, and it's fixed!

I'm not saying it would be a 5 second job, but not duplicating files on a read-only filesystem is not a difficult job -- I would never accept it from a student project, never mind one of the biggest tech companies in the world.

I'm no ios dev but my thinking was that it was done this way for flexibility. So one internal framework could be developed entirely separate from the other app code. And maybe one framework gets updated with a new dependency before the others.

Either way, this "analysis" seems pretty superficial. I can run a "du" of almost anything and it won't tell me much. And this author misleads intentionally by giving no explanation, but the implication is very clear from the post that Facebook is lazy and sloppy with disk usage.

The use of frameworks is a good practice, no one is arguing against that. The improper duplication of resources and code is the problem. Any development process that requires resource duplication in order to be flexible is broken at the core, and developing such systems are enables of bad practices.

> all this to allow developers to use whatever version they started of

That sounds like exactly the same reason everybody's crazy about containers ... and I do mean crazy, because it's a maintenance and security nightmare, but the whole industry seems hell-bent on going that way.

I guess one question to ask is 'does it matter if the app is inefficient?' i.e. are these problems going to stop people from using Facebook? I'd argue that the platform is way too big and too sticky for this to be a concern; they could ship an app that crashes every hour and people would still use it.

There must be a lot of people out there with 16GB iPhones that are constantly out of space. I don't think Apple publishes stats, but I guess >50% buy the cheapest model. The Facebook app also likes to use 500 MB for cache with no way to clear it other than deleting the app.

Lots of apps are like this and I don't understand why. They should be using the caches folder and "the system may delete the Caches/ directory to free up disk space". However I have never seen this happen. When my phone runs out of space I have to manually delete these apps. Are they not using the correct folder, or is the system not deleting the caches?

I am one of them :(

I have a 16GB iPhone 6 and the Facebook app was the first I culled from my phone ~2.5 years ago. At that time I was getting annoyed that the app had slowly creeped up in size from between ~60MB and ~80MB to over 100MB. I have no intention of ever installing it again as I don't think FB have any interest in reducing the size back down to that level.

Why do you have to download all localizations? Isn't it possible to download only the required one after install? As far as I know Waze does this, for example. (Honest question, I'm not a mobile developer)

Sure you can! Downloading the localizations is a large extra complexity in development though, while simply bundling them all is a minor bother in increased download size, for the customer.

because the complexity of development will increase many fold by doing so.

I thought our apps were fat, this is ridiculous. But clearly they belong to the school of never rewrite just keep adding more and more and more. Eventually you wind up having no idea what you are shipping and the quality goes in the dumpster. At least you can use the web if you hate the mobile app (I do).

This is a side-effect of the current app business model, which sacrifices software quality to deploy it fast to the market... who expends 1 month optimization while a new app comes every 6 months ?

> DO_NOT_USE_OR_YOU_WILL_BE_FIRED

What could possibly be in there?

We use it as a joke name for functions/modules that are deprecated or dangerous, or that otherwise should be avoided. It works pretty well even though it's (probably) an empty threat.

Thanks for the info :D

If I may ask, what's the "internal joke" (https://twitter.com/legneato/status/650491741343084545) about?

Also, I take it that the described duplication is due to isolation and compartmentalization (which I can appreciate). I'm curious if some kind of "final dedupe" could be tacked onto the end of the build process that just runs a bunch of fixed algorithms on the assets to find and remove duplicate resources - and maybe even code fragments, like Courgette (https://www.chromium.org/developers/design-documents/softwar...) does.

FWIW, doing something like this would probably take a lot of pressure off the dev teams and make everyone's lives easier. On the current track, the app will be 300MB in a few months. lol

And anyone got fired yet?

Why not just remove them instead?

The same reason why you otherwise deprecate stuff. Because it's still used. As for React, they have such a variable to allow interop with the react dev tools.

It could be from React: https://github.com/facebook/react/blob/master/src/fb/ReactFB...

That or it's a shibboleth common to Facebook projects.

It was already a running joke at FB when we brought it to React.

Reminds me of "clownshoes" at Mozilla describing a hack or other piece of code that ends up sillier than it should be.

I once saw python code

    if 'i_know_what_im_doing' not in kwargs:
       raise ...

    that_function(i_know_what_im_doing=False)

In a twisted kind of way, I'd call that a feature.

If you're aware you don't know what you're doing, but still want to do it, that's kind of ok. Problem is when you're not even aware you're about to jump into some pretty hot water.

JUnit ships with this method:

  void _dont_implement_Matcher___instead_extend_BaseMatcher_()

I know this because I wrote it.

If you're interested in why: https://www.reddit.com/r/programming/comments/nlt5x/i_believ...

I find it fascinating that they managed to get to this much disk footprint so soon without any of us having much of an idea about what is going on below the good.

Despite weekly updates with nonsensical generic descriptions we still don't have actual features like support for devices like the iPad Pro.

Especially with all the frequent A/B testing bull they're pulling recently, the quality and usability of their software is dropping on a weekly basis. It just seems like a bad combination of everything on a level Microsoft at their worst couldn't even come up with.

Is there a privacy analysis of the Facebook app that anyone knows about?

This is exactly what happens when you don't bother to have any coherent architecture.

And is why you shouldn't get a job at Facebook if you really care about what kind of work you do.

The funny part is even if you do interview at Facebook, they only ask algorithm whiteboard questions. So it doesn't really matter if you have the sort of aesthetic values that cause this horrible app or not. If anything they might be actively selecting for it by filtering out experienced hires.

Are these files not compressed on disk? I'd imagine duplicate data like this compresses very well.

That's assuming the on-disk compression deduplicates. ZIP does not and 7z only does in 'solid' mode. Compression is not a silver bullet for this either - if you have a repeated 8MB sequence in 8 different parts of a 250MB file, whether or not the sequence gets deduplicated depends on the compression algorithm, dictionary size, speed setting, etc.

The solution to all the duplicated files is to dedup at build time.

New PM?

Reply on news.ycombinator.com