I've come to realize that Facebook is sort of a global operating system for communities. Your Windows installation includes all the pieces to connect to an Active Directory enterprise network, even if all you'll ever do is play games from Steam. Facebook is like that: there's so much stuff you'll never see when you only use it to follow a bunch of old college friends.
Should those things be downloaded as needed? Maybe. But it would have a negative impact on metrics: if "New Feature X for Latin American Teenagers" takes 30 seconds to start up, it's not going to take off. It's easier when everything is already there. Besides, the effort of rearchitecting a 491MB app would be crazy. Of course Facebook has major public initiatives like React Native which could eventually allow parts of the native apps to be dynamically downloaded more easily (I don't know anything about whether that's planned, just stating the obvious).
2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps.
Educational apps designed to teach, develop, or allow students to test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the Application completely viewable and editable by the user.
Is it even that? The Facebook app’s UI is sufficiently different than the standard system controls that it seems to me that they might be completely custom.
What could have added 300MB to the total so quickly?
Just use the mobile site with safari. It’s blazing fast and doesn’t slurp your address book or location and drain your battery.
I've had "background updates" disabled every since the option became available in iOS, and location updates only when i use the app, and yet somehow Facebook manages to stay running in the background for 3x longer than it's been on screen.
We're talking 10 minutes on screen and 30-40 minutes of background activity. I realize some of it is notifications etc, which would trigger background activity, but that can hardly explain all of it.
After watching Facebook eat 30% of my battery every day, i finally uninstalled it and use the mobile interface. Besides making by battery last a whole day longer between charges, it also has the added benefit of not receiving notifications, meaning less stuff to disturb me.
Pro Tip: if you need messenger on mobile, set your browser to "desktop site" to avoid facebooks insistence on installing its spyware pile of poo.
[1]: https://github.com/indywidualny/FaceSlim
(Only on Android though...)
Are there fundamental differences between Android apks and iOS application bundles that cause these size differences? It seems to be a pattern that iOS apps are just bigger:
- Facebook on Android is 70MB while on iOS it is 491MB
- Twitter on Android is 74MB while on iOS it is 178MB.
- Spotify on Android is 104MB while on iOS it is 164MB.
- Dropbox on Android is 112MB while on iOS it is 228MB.Also note that both platforms do delta updates but generally show the total size in the UI. So every update you aren't actually downloading that much over the wire.
Source: I used to manage the Android and iOS release engineering teams at Facebook
Not to be rude, but you are literally talking to someone who was in charge of this, looked at the graphs daily, and made the call when we went over the OTA limit on iOS. When I say multiple-apks are a large reason for the discrepancy, you should give me the benefit of the doubt. It's not the only reason mind you.
As far as I was aware, the comment you were responding to was broadly accurate, but now I don’t know and have no additional information.
Christan Legnitto, working at FB on release engineering, see his submission of this article in 2013.
Your original claim was that OP needed to substantiate their credentials; it was done (regardless of who).
HN Guidelines suggest we reply to the strongest argument being made and to give the benefit of the doubt, and that doesn't seem to be your approach.
Edit: I can't believe I'm defending FB or anyone that caused their increase in usage.
Its purposely designed that way to encourage conversation. Its not like at work where you may fear challenging someone at a higher level than you.
Ouch. Hope this isn’t how you managed your teams.
Each of the products is implemented by their own team. I wouldn’t be surprised if there are literally thousands of engineers commuting changes to the iOS app on a regular basis. If you are on a small team you can make a lot of headway against bloat on your own. For an app like Facebook it would be incredibly difficult to understand the entire thing, let alone make much of a difference.
Technologies like React Native are supposed to address bloat. It’s much more efficient to ship incremental features in JS (can even be done over the network), but React Native doesn’t solve every use case, and Facebook has a lot of legacy code.
Simple - Feature Creep[1]. Facebook's iOS app shows no restraint when it comes to features. Take for example when you have the word 'congratulations' in your status, when you then click on the word after posting it we are shown a big elaborate animation. Something like that may be at least 10MB of code - just for a silly animation.
For reference, the Linux kernel can easily be made to fit in 10MB.
I don't understand how it can possibly be code, it has to be assets.
I think it is a combination of not caring - everybody working at FB has the newest phone and the fastest connections - and maybe not the best developers. Or maybe the developers are really top notch 10x developers that you would expect at a silicon valley megacorp, but they are incentivised wrong and have to push out new features as quickly as possible...
[0]: "App thinning" https://developer.apple.com/library/archive/qa/qa1795/_index...
Edit: sorry, just saw you're not the person I replied to.
App thinning does not compress the app; it just pulls out stuff that doesn’t match the device the app is being installed on. And keep in mind that most application binaries are far from random data.
This was gold:
@interface FBSearchModule : FBNativeAppModule_DO_NOT_USE_OR_YOU_WILL_BE_FIRED
Somehow it me feel better about the things I produce.
Heck, I've got a debugging routine I use on one of my projects that's called panic_on_the_streets_of_london().
Is it affecting app installs? Is it leading to a reduction of usage? No -> Don't fix.
As an outsider, that would be my guess of how the app can grow to be so large, without knowing the reason why.
A Windows CAD/CAM app I've developed, with very advanced algorithms and visuals, takes about 300k lines of code (45% C++, 45% C#, 10% others), has 3.7MB download size. That 3.7MB installer includes both 32 and 64 bit binaries.
Couple general things how to achieve that.
Be very conservative about third-party libraries. Not only they inflate size, you have to support every line of third-party code you've brought to the project.
Prefer vector graphics over raster, and you'll get hi-dpi support for free.
Stuff like XML or DDS can be compressed by 50% or more, other stuff like JPG or PNG is almost in-compressible. Distinguish these 2 resources, compress first with e.g. gzip but not the second it'll be a waste of CPU bandwidth.
I did. I think it's about developer professionalism.
If you have business goal to make small bundle but don't have professional developers who understand what I wrote in previous comment, it won't be small.
I think someone should reach out to them and let them know that they just have to gzip their XML!
BTW I’ve wrote much more than 1 app in my life, I’ve been programming for living for 18 years already. Mostly desktop software, some mobile, videogames, and embedded. I haven’t developed web apps but I’ve interacted with many people who did, I think they have slightly different mindset, the areas are just too different.
What I think might have happened, FB hired people based on the criteria dictated by their main product, facebook.com web site, then told them to write that iOS app.
And you should definitely not postulate on their ability to develop software based on that utter lack of knowledge.
I know what they did. They’ve made an 0.5GB mobile app that downloads some data from a server, and displays it with a nice 2D rich GUI. I’ve wrote a few similar apps, both for iOS and WP.
> the constraints they had
Again, I know most of the constraints they had. Unlike PCs or especially lower-level platforms like game consoles or embedded Linux, at least 50% of these constraints are dictated by Apple and should be known by every developer with the access to iOS SDKs. Other constraints are dictated by internationalization, Asian languages and RTL layouts indeed complicate a few things, but not enough to justify the size. Same for multi-platform development, data caching, and security & privacy constraints.
The only thing I don’t know about these constraints is their client-server protocol (not because I don’t work in FB, it’s possible to reverse-engineer with a sniffer, I just never cared). But if it’s network-related code that’s so complex, I would consider making a server-side proxy, to expose mobile-friendly protocol. BTW I did that too, when I was working on mobile bank clients.
> or the kind of people they hired while developing it
I agree with you on that. I don’t know anything about FB, I‘ve just guessed about it.
That's the problem. You and I both have no clue. Do you really, in your heart and hearts, believe that writing an app for the number of markets Facebook has, with all their weird quirks and all the features they support would have 50% of the constraints imposed by Apple?
Look, I do get your point and there are nuggets of truth to them, but overall your argument is like someone saying: "pfft, Google runs millions of servers? I've written assembly, they could run their whole infrastructure on 10 servers if they just knew how to write proper software".
I hope you can see how patently ridiculous that is.
Yes I do. The client functionality is relatively simple, even with all these per-market quirks and features combined.
And Apple did excellent job providing stable hardware & software environment, and deprecating old hardware. Per-user quirks are almost non-existent on iOS. This is unlike PC platform, for that CAD app I had to spent significant time implementing various workarounds for users on old PCs, Intel breaking GPU drivers, and many other strange things.
> I hope you can see how patently ridiculous that is.
Scaling web apps is relatively hard. A system running on 1M servers is way more complex than similar system running on 5 servers.
An FB user however only has a single iPhone in their pocket, with 4-6 cores and 2-3GB RAM. The mobile software doesn’t and shouldn’t care how many servers FB has in their datacenters, or how many petabytes of data are stored on these servers.
However, facebook didn't wrote the ios app overnight. They got to this point because of a long trajectory of lots of tradeoffs, some heavily related to the human, organisation, social side of software development - its hard to coordinate an effort across probably dozens of teams.
You're commenting on a 10ton freight train travelling at 50km/h saying you can build a faster car. Well, they probably started with a car, too but built a train along the way. I'm sure if they rewrote it it would be much better but that's just how things are in software. Doesn't mean we shouldn't look at the app size, but don't forget the trajectory instead of looking at the last data point.
I agree with you on that, but hard ≠ impossible.
I was fortunate to work in a couple of large companies with good technical management. The companies did OK even for large software with 10+ years of legacy C++ code. It indeed required significant effort to coordinate teams and people. But if you’re a technical lead in a software company, it’s exactly your job to accomplish that.
If user wants to travel by a car and a company’s telling them “you can ride our awesome freight train instead”, it might mean the company has failed to manage the software development part of their business. It’s even possible the developers were top-notch professionals, but technical management wasn’t, and the management prevented developers from doing their job well.
Absolutely nothing.
I think the more accurate way would be that scale has absolutely everything to do with it, from the way you develop your systems at the very lowest layer (architecture, code layout, optimisations) to the very highest (the UI).
Designing software for 1,000,000,000 users is an entirely different ballpark than for 1,000. Different trade offs, different restrictions, different everything.
There is a reason Google had to invent their own freaking database (using atomic clocks to handle transactions no less) to get to their scale, and it's not because they were a bit bored and fancied giving it a go.
This is in part what I meant by different mindset.
For web developers, dealing with the complexity caused by massive scale is inevitable, and yes, for them it’s different everything.
Desktop and mobile developers are essentially shielded from that complexity by slow networks. It’s technically possible to VPN into DC and write mobile apps as they were a server app, but even ignoring security considerations, this is usually wrong approach. Within DC you have 0.5ms latency, over mobile Internet it’s 200ms best case. These 2-3 orders of magnitude make great difference on how you should design software.
Because it's not an important constraint to them.
I figured I'd just use facebook.com on the browser, and I happily did until they removed chat from the mobile site.
Now I use mbasic.facebook.com, which is incidentally much better because there's no bloated JavaScript (afaik).
I'm sure they'll discontinue mbasic soon too; it'll be a shame because Messenger is all I use Facebook for.
I think they are worried about apple or android removing access/throttling FB as they do not control the underlying platform (apple controls the devide, google controls the OS, and FB is the most deployed app across either platform)
It doesn't seem to be available for ios? https://itunes.apple.com/ca/developer/facebook-inc/id2848822...
`NTNativeTemplateHackyWorkaroundBecauseNSMapTableIsBuggyContainer`
https://blog.timac.org/2016/1018-analysis-of-the-facebook-ap...
https://blog.timac.org/2017/0410-analysis-of-the-facebook-ap...
How did their app balloon nearly 2.5x in size in such a short time- with no noticeable change in the app itself?
Wouldn’t this potentially restrict themselves from anyone who’s phone is their primary computing device and don’t bother to have home internet?
Differential updates are pribsbly much smaller.
1. Have you worked at Facebook as an engineer before? Do you first hand know that most engineers working on FB iOS app lack the experience and interest?
2. Have you reverse engineered the FB app and verified that the app lacks signs of proper system or application development?
There could be a good enough reason as to why the app re-wrote core iOS libraries - most popularly performance and missing features. Also, tens of thousands of classes don't directly translate to increased binary size - its usually the dependencies of the code that results in such large binary sizes.
Overall, if Facebook wanted to optimize its app size to be less than 491MB, they would have.
Maybe its on their roadmap, maybe they decided most of their userbase have the ability to download 491MB and it isn't impacting the growth funnel, heck maybe some of the engineers actually wanted to work on optimizing the app size but it was shot down by management. Slamming engineers who work at Facebook and calling them inexperienced is just mean.
Have you? The size of the core Facebook application binaries disagree with your statement of “tens of thousands of classes don't directly translate to increased binary size - its usually the dependencies of the code that results in such large binary sizes”.
I'm simply "speculating" that a large number of reimplemented classes might not be the reason for the increased binary size from anecdotal experience of building similar app binaries for iOS.
FWIW, I think this comment gives a pretty good reason for why the binary size is large - https://news.ycombinator.com/item?id=17996161
Legally, if you are in the USA (or some other country surrounded by water) get on a boat, take it 5-10 miles out, and start (also when on a flight over an ocean would give you some coverage).
The comment you referred to (thank you) makes perfect sense.
I have never signed a contract with Facebook. Does that mean I’m free to reverse engineer it?
I thought this was 'hacker' news not 'let us study the click through EULA and respect the terms and conditions entirely' news.
If you can't or won't reverse engineer a binary file, you're a share cropper not a computer owner.
The real answer is that Facebook does A LOT. Especially the main app. Facebook also serves A LOT of different audiences in a lot of different regions.
Just consider that there is an entire YouTube worth of functionality inside of the main Facebook app. And that's just one vector of functionality that they offer.
They're predominately right out of school and don't understand systems engineering. If single schizophrenic man can create a complete 64-bit real-time multitasking operating system that can be distributed completely in a 2MB distribution, one of the highest valued tech companies in the world can make a glorified version of their website fit in under 20MB.
Think how many lifetimes are wasted each day waiting for Facebook to load or update.
I just uninstalled it about a year ago because I was so disgusted with it. Now, I get ads begging me to come back.
The late Terry A. Davis.
And that's not just theoretical: I have 16GB and I'm always scraping for storage
Not many these days; the last iPhone that shipped with this configuration was the 5c four years ago (I had one; 8 GB sucked).
That whole line of reasoning is just antisocial laziness. You pay for it so I don’t need to bother.