6 ms·

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 ap

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.

brian-armstrong 10y ago
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.
lazzlazzlazz 10y ago
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.
- mazerackham 10y ago
  Lol +1 here. I guarantee LeoNatan25 that the situation is MUCH more complicated than he/she is giving credit
  - jfoutz 10y ago
    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.
    - threeseed 10y ago
      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.
      - jfoutz 10y ago
        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?
      - deleted 10y ago
        [deleted]
- rimliu 10y ago
  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.
- threeseed 10y ago
  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).
  - LnxPrgr3 10y ago
    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.
    - chii 10y ago
      > 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!
      - LnxPrgr3 10y ago
        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.
- CJefferson 10y ago
  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.
- eeeeeeeeeeeee 10y ago
  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.
  - LeoNatan25 10y ago
    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.
notacoward 10y ago
> 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.
askvictor 10y ago
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.

brian-armstrong 10y ago

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.

lazzlazzlazz 10y ago

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.

mazerackham 10y ago
Lol +1 here. I guarantee LeoNatan25 that the situation is MUCH more complicated than he/she is giving credit
- jfoutz 10y ago
  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.
  - threeseed 10y ago
    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.
    - jfoutz 10y ago
      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?
    - deleted 10y ago
      [deleted]
rimliu 10y ago
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.
threeseed 10y ago
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).
- LnxPrgr3 10y ago
  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.
  - chii 10y ago
    > 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!
    - LnxPrgr3 10y ago
      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.
CJefferson 10y ago
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.
eeeeeeeeeeeee 10y ago
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.
- LeoNatan25 10y ago
  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.

notacoward 10y ago

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

askvictor 10y ago

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.