Hacker News Reader

Comment by LeoNatan25 | Hacker News Reader

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.

View on HN

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.

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.

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.

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

Reply on news.ycombinator.com