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.
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.
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.
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).
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.
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 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.
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 ?
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.
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
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.
Readit News
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.
I absolutely guarantee that this analysis is missing some significant complexities, and that Facebook understands what's actually going on under the hood.
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.
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.
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).
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.
What could possibly be in there?
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
If you're interested in why: https://www.reddit.com/r/programming/comments/nlt5x/i_believ...
That or it's a shibboleth common to Facebook projects.
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.