Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: How is Facebook's iOS app 491MB?
201 points by x0054 9 months ago | hide | past | web | favorite | 156 comments
This is just insane. Photoshop takes less space than that, most fully functional desktop apps take less space than that. If you work for FB, or know someone who does, can you enlighten us as to what in the hell is in that HALF a GB (!!!) app?



I started at Facebook a month ago. Honestly, I was wondering the same thing as you: how does this app which seemingly is a couple of UITableViews contained in a UITabBarController end up taking so much space?

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


Are you saying after a month there, you’re sure it’s not just a bunch of unused legacy code that engineers are smart enough not to delete because they’re not really sure what it does and the original authors have cashed out and are kickin’ it counting their money? Especially all that Objective C they’ve been madly trying to pave over with Swift?


Well, there is also facebook lite.


Come on - 491Ms are 514'850'816 bytes => if you distantiate yourself from the SW and all its potential layers (and keep only the endresult in mind) then you have to admit that that "mass" is reaaaaaaaally huge. Pure logic must be max some KB/MBs, but the rest has to be garbage or UI-stuff, no? If not, then everybody would have to publish a 500MB-website, or?


I don't know if this qualifies, but aren't there strict restrictions on bypassing the AppStore for updates? Would downloadable binary blobs (code logic, not assets) like this be allowed by Apple?


I think (not 100% sure, I don’t work actively on iOS apps anymore) that Apple’s current policy is to allow code downloads if they are executed on an OS-provided runtime. That means JavaScriptCore in practice, and React Native passes that bar.


Since June 2017, an app can also run the downloaded code on its own interpreter, and it can be any language, not just JavaScript.


Only for apps that let the user see/write the code. You can't download code that changes the app's functionality.

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.

https://developer.apple.com/app-store/review/guidelines/


Only if the app allows the user to view the code, if I remember correctly. It was to encourage programming / teaching apps on the ipad and the like.


React native apps are written in JavaScript & HTML, but they are compiled to native code. They have access to APIs that a browser wouldn’t, and can even link to native libraries.


What's curious to me, in the light of your explanation, is why the app size didn't slowly build to 500MB over time, but jumped from 200MB to 500MB within the span of weeks/months.

What could have added 300MB to the total so quickly?


That excuses like 256MB, tops.


> this app which seemingly is a couple of UITableViews contained in a UITabBarController

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.


so you explained 4 megabytes, now explain the other 487


Facebook is not good at mobile. Uninstalling the app is the single best thing you can do for your phone battery life.

Just use the mobile site with safari. It’s blazing fast and doesn’t slurp your address book or location and drain your battery.


Uninstalling it is the best thing you can do for YOUR life!


The fact that so many people on HN, people who should know the best how malicious this company and their business model is, are still using FB is worrying. How are normal people supposed to quit?


I deleted FB and it had zero impact on my life, for better or worse. I really question people who say it does. My guess is that they're repeating what other people say because it makes you sound forward thinking.


And also move to mbasic.facebook.com for even more blazing fastness!


Mobile site was fine but messages, maybe the most important part, have been disabled and instead you're pushed you to download their app. I've been using FaceSlim [1] since messages stopped being available. It is actually a wrapper to the normal website but resembling the mobile site. Thus it is light, has messages and clean interface.

[1]: https://github.com/indywidualny/FaceSlim

(Only on Android though...)


Can confirm. Uninstalled the app and its spyware friend, the messenger app, years ago. Feel like my phones spies just a little less on me every day, and saved about 750mb of space.

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.


Yup thats what i do for both insta and Facebook


You get to choose whether it gets to ‘slurp’ your address book or location. You can just say no.


They “made mistakes” in the past that bypassed those preferences.


All I could find was apps that downloaded users’ address books without proper permission, which prompted Apple to add controls. Do you have links to these “mistakes”?


was that part of the FTC's consent decree, concerning Facebook's deceptive privacy practices?


Or just disabling background updates for the app.


In theory that would help, but Facebook appears to use all kinds of "clever" (dirty) tricks to stay running to slurp all that beautiful metadata up.

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.


Really bizarre, I don't have that problem at all. It doesn't even make a dent in my battery charts (when compared to things like Phone).


I noticed iOS still reports massive battery use with background refresh disabled.


Hmm... I rarely open Facebook and it doesn’t show up near the top of my battery usage charts. Odd.


May I add a follow-up question? Why is their Android app 'only' 70MB?

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.


Yes, Android has apk splitting ( https://developer.android.com/google/play/publishing/multipl...), which enables different packages for different devices. This means an mdpi arm6 device in India doesn't need to download and install a package with xxhdpi assets and arm7 code, leading to a smaller effective package for each user.

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


iOS has app thinning, which does essentially the same thing. However this only reduces the app size a bit, since most of the actual size comes from the app binary which is shared across devices.


App thinning is not the same and not nearly as effective.

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.


In a pseudo-anonymous forum you must provide facts - not rely on credentials. The answer to your “Do you not realize who I am” post is No, we have no idea.


https://m.facebook.com/notes/facebook-engineering/update-on-...

Christan Legnitto, working at FB on release engineering, see his submission of this article in 2013.


Comments should stand on their own. Nobody learns anything with a “because I said so - just trust me” comment.


This a text book example of moving the goal posts, and I don't care to see it on HN. Android obviously allows more freedom to app developers than Apple, including the freedom to raid the cookie jar numerous ways.

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.


No, you misunderstand the whole point. Credentials don't matter in an anonymous setting. That's the whole point, people can converse on equal terms. The only "credentials" in common display is whether or not your account is new.

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.


If you disagree with that, it might be good to provide a bit more context than “shut up I know what I’m talking about”.

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.


This was the reason for my downvote as well. “No it isn’t” is not very much to go on and saagarjha’s post didn’t merit pulling rank.


> you are literally talking to someone who was in charge of this

Ouch. Hope this isn’t how you managed your teams.


I am aware that app thinning is not as effective, but to my knowledge it does the same thing: strip out unneeded architectures from the binary and remove unused assets. I'm sure you have more to share, so I'm all ears on what the differences are.


If you enable Bitcode, each device will get their own binary though? Or does that only apply if they later change their architecture?

https://help.apple.com/xcode/mac/current/#/devbbdc5ce4f


IIRC it's per architecture. So there will be a separate slice for ARMv6, ARMv7, ARMv7s, ARMv8, etc.


Are you looking at the iOS size as listed in the app store? They don't show the 'thinned' size - the actual download size for your device can be much smaller. For Android, developers have to generate separate builds, which already have the final size.


Swift bundles?


That was my guess also, Swift apps are much heavier.


Facebook is all Objective-C++, if I recall correctly.


I just checked: On my iOS phone the Facebook App (Version 189.0) is 315MB. Plus 111MB of stored local data.


The Facebook app includes a massive amount of functionality. Open up the hamburger menu and you’ll see a subset of what it does: feed, groups, profiles, video, marketplace, events, camera app, search, crisis response, etc. Each of these has a very deep level of functionality. Facebook are also very data driven, which means they’re probably testing multiple versions of most features at any given time.

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.


Facebook doesn’t NEED any of that. I wish I worked there so I could rip all of that shit out of there and cut the whole company down to its proper size.


> How is Facebook's iOS app 491MB?

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.

[1] https://en.wikipedia.org/wiki/Feature_creep


I still don't understand it. WeChat, the Chinese messaging app, is the definition of feature creep, and still "only" 290.1 MB. It not only includes messaging and social network functions, but banking, shopping, taxi hailing, dating, and tons of other features. It's been compared to an OS of its own, you don't live in iOS or Android, you live in WeChat.

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


As far as I can tell with my limited use of WeChat while in China, most of the extra features are created by third parties and are hosted as third party web apps inside of a web browser. I could be wrong though.


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


all those layers of abstraction where JS is translated into native calls should take up some considerable weight. I believe they use a variation of React Native to share code between their Android and iOS apps. Magic always comes with a price


Keep in mind that the size of the app listed on the App Store is not actually the size of the app on device. Apple automatically removes unneeded assets [0] from the bundles based on the device that's downloading it. I just downloaded Facebook on my iPhone X and the app size came out to 314.5mb [1].

[0]: "App thinning" https://developer.apple.com/library/archive/qa/qa1795/_index...

[1]: https://imgur.com/a/lTJhMbx


That's not a significant difference...


Tbh that is a significant decrease. Find me a compression algorithm that can compress already compressed binary data by 30% and I'll give you a million dollars (after I make a few million dollars myself).


Please, it’s a big drop in terms of percentage, but it’s absurdly large for what the app does.


Oh I completely agree it's bloated as fuck, but your statement that it's not a significant decrease is untrue.

Edit: sorry, just saw you're not the person I replied to.


No worries :) and yeah, i just don’t get it. I oversaw the development of a high ranking app for the last 6 years and it was a massive focus of ours to keep it small for as long as possible. We saw that conversion dropped as the app grew, we assume as the size grew it encouraged people to wait for wifi or their next months data before they would start the download.


Not so much for iOS as on Android, because Apple doesn't sell devices with nearly zero space; some people are constantly out of space -- you don't want to be listed high on sort current apps by size.


Our research indicated the issue was more around data transfer and access to wifi, less around storage.


Well, bloated af before, bloated af after... I guess you can argue about the definition of significant but at that point I think you’ve lost the argument by default.


> Find me a compression algorithm that can compress already compressed binary data by 30%

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.


I know, I'm just using compression as an argument to show how significant 30%+ is.


I would say so; it's more than a third smaller than the figure quoted in the OP's title.


It's still the same order of magnitude, which is still way higher than is reasonable.


It's well over half again larger than any other app on my device, even after "thinning". Yes, it's a big savings, but it's still ludicrously large. At that point, I think it meaningfully falls into the "distinction without a difference" bucket.


Still way larger than reported Android `.apk`.



Thanks for that link. All the defenders of Facebook should read it.

This was gold:

@interface FBSearchModule : FBNativeAppModule_DO_NOT_USE_OR_YOU_WILL_BE_FIRED

Somehow it me feel better about the things I produce.


Honestly I think it's funny and I appreciate a sense of humor from coworkers.


I'm not disparaging it.

Heck, I've got a debugging routine I use on one of my projects that's called panic_on_the_streets_of_london().


New Moore's Law: Every year Facebook's iOS app doubles in size.


Unless it's a business concern (i.e. affecting one of the metrics the business is measuring and reporting), it's not on management's mind and therefore won't be prioritized as something worth improving or prevent from getting worse.

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.


The app size hovered below 100MB for a log time, because that was Apple’s threshold for non-WiFi installs. Once they blew that budget it seems to have got out of hand.


I just checked the App Store, it appears to have breached the 500MB barrier now: https://imgur.com/a/9LOrq1K


For myself and friends and family, I maintain a Linux distro. It contains Chrome, LibreOffice, GIMP, Inkscape, Skype, not to mention a full OS and video drivers etc. And it's smaller than the iOS Facebook app.


Because they don't know how to develop software. At least not desktop/mobile software.

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.


Developers of an app used by over a billion people do not know how to develop software because you wrote a small CAD app one time? Right.

I think someone should reach out to them and let them know that they just have to gzip their XML!


No, not just because of the size. I’ve used that app on iOS (some time ago, on iOS 5-7), and as a user, I didn’t like the quality.

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.


I think it's extremely arrogant to assume that you have any clue what they did, the constraints they had or the kind of people they hired while developing it.

And you should definitely not postulate on their ability to develop software based on that utter lack of knowledge.


> arrogant to assume that you have any clue what they did

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.


> Again, I know most of the constraints they have.

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.


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

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.


I believe you are falling in a trap that some people fall when they do this kind of analysis; I don't doubt that you (and lots of other users on this forum) are completely capable of doing a facebook-like app that is much more efficient in terms of space and performance.

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.


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

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.


Fair enough, I think I understand what you mean. FB, as an app, could be much better.


What does number of users have to do with software development know how?

Absolutely nothing.


Well, sure, thats one simplistic way of looking at it. Code is code.

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.


> Designing software for 1,000,000,000 users is an entirely different ballpark than for 1,000. Different trade offs, different restrictions, different everything.

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.


Correct, but with a few users you can get away by cutting corners, with lots of users you will have MxN potential corner cases you will have to deal with. More users -> more bugs.


Of course they know how to develop software. They just don’t have a goal of a small app bundle size.


My client (if I worked in that company he would be my manager) didn't care about installer size either.

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.


Yep. Connections are fast, bandwidth is cheap and storage is capacious. Developers on the other hand are expensive.


Everyone I know is out of space on their phones.


Because they write a lot of code. Because they experiment between a lot of experiences. Because there's a lot of legacy code.

Because it's not an important constraint to them.


And there's Facebook Lite app.


Unfortunately not available in US iOS app store, though. Wish they would provide it everywhere.


And this doesn't include Messenger does it? The last time I had the misfortune of installing the app, they forced me to install a separate app for that.

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.


For reference, messenger.com is a standalone FB Messenger web app that works great -- my use-case for FB is largely the same as yours.


How are you using messenger.com on mobile? I use it on the desktop, but on mobile, the website just links to the app.


If you select the Share option, one of the options on the bottom bar is actually "Request Desktop Site".


Messenger Lite works pretty well on Android. I don't know whether it's available on iOS or not.


I think this is due to the fact they refuse to use the underlying APIs for DNS, TCP, etc and reimplement all that functionality within the application.

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 seems silly. If platform X implements function A, and you're worried they might change how function A works, just wrap function A in an adapter class/interface. If they change it, you can then re-implement it the way you want.


Can you run a separate network stack on iOS? How would that make network requests without using private APIs or accessing hardware directly, both of which Apple forbids?


The size you see on the App Store isn’t necessarily what the size will be when you install it to a device either. For example, on my iPhone 8 Plus is 307.3MB.

https://imgur.com/a/VwkFvxg


Yes, due to app thinning. But 300 MB is still an insane size for an app like this.


The app does a lot, it’s huge, it even has a built in live game show.


It also has something like 18000 classes in it, many of which are not used. While it may do many things, most of the app is just bloat.


The below links provide great analysis of facebook app. They have ridiculous long class and method names. I have seen many classes which are too long. Most of the app space took by these strings and third party libraries etc. Some thing like this can be seen in whole code base:

`NTNativeTemplateHackyWorkaroundBecauseNSMapTableIsBuggyContainer`

https://blog.timac.org/2016/1018-analysis-of-the-facebook-ap...

https://blog.timac.org/2017/0410-analysis-of-the-facebook-ap...


They released Facebook Lite for this reason I believe it's like 10 MB. Tried it but could not keep using it because it has no Authentication Code Generator... Which seems like a pretty big oversight if you ask me, but who cares I'd much rather watch Facebook slowly fade away in the meantime.


Facebook Lite is 1.3MB for my phone.

It doesn't seem to be available for ios? https://itunes.apple.com/ca/developer/facebook-inc/id2848822...


I don't know if iOS has the equivalents but I personally use the "lite" versions of fb and messenger. Tempted to remove fb at some point and just use the browser tbh.


Unless it's a KPI you won't get an OKR to address it


It probably is at least partially autogenerated, contains tons of legacy code, code for different markets, code for yet unreleased features, NSA tracking code...


I’m sure part of it is A/B tests for tons of things. Doubled or tripled resources and code but any given user only sees one variety of them.


I am also very confused by this. Just a few months ago it showed as requiring 215MB on my iPhone. An update from this week shows 515MB (which is what the size is listed as in the app store as well).

How did their app balloon nearly 2.5x in size in such a short time- with no noticeable change in the app itself?


Does this mean you have to be on WiFi the first time you download it because it’s over 150MB?

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.


I'd really like to give them the benefit of the doubt, but at this point it's sheer incompetence. It's been pointed out in the past, and it's still growing.


I would be much more interested in details of the tech they use to bring iOS apps to Windows. Messenger for example looks like a direct port.


They acquired a company a while back called Osmeta that basically reimplemented parts of iOS.


No, it's actually 0 MB since I deleted that bloated ____.


They employ a bunch of coders who are really good at solving textbook CS problems and whiteboarding medium/hard leetcode style questions but lack the experience, interest, and in some cases ability to stretch beyond that into, say, proper systems or application development. There are far too many of these individuals who are able to "contribute" to the application code base more or less without the supervision of properly experienced and qualified engineers (there was some article, I think on Reddit, about how the app used to have thousands or tens of thousands of classes, re-wrote large bits of iOS core libraries, etc.).


I think this is a totally baseless comment.

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 reverse engineered the FB app and verified that the app lacks signs of proper system or application development?

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've not reverse engineered the FB app. I also don't think I'm legally allowed to.

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


It is contractually you aren't supposed to, due to terms & conditions.

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 bet the overwhelming bulk of reversing work done on everything, including iOS app is not done on planes or boats. Quite a bit of it is done in the US, to boot.


> It is contractually you aren't supposed to, due to terms & conditions.

I have never signed a contract with Facebook. Does that mean I’m free to reverse engineer it?


I guess he means the T&C you agree to when downloading the app from apple and fb


Who cares what you're 'legally allowed' to do on your own computer.

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.


This seems like an implausibly detailed level of knowledge of Facebook's workforce, especially if derived from something you maybe saw on Reddit that was about something else.


This is an awful take and doesn't reflect the truth in any way whatsoever.

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.

danmg 9 months ago [flagged]

This is the truth.

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.


Out of curiosity, who is the schizophrenic man you refer to?


https://en.wikipedia.org/wiki/TempleOS

The late Terry A. Davis.


iOS can't handle their scale


Nope, considering that their app loads fine on most iOS devices…


All dem tracking hacks... Need to be sure.


Why does it matter? Modern smartphones have more than enough space.


Not really, a lot of phones are 8GB. Once you remove the OS and the pre-built apps that's about 5GB left. Just the FB app takes about 10% of that? That's not really acceptable.

And that's not just theoretical: I have 16GB and I'm always scraping for storage


16GB only nets you about 20 of bloatware balloons like the Facebook app.

That whole line of reasoning is just antisocial laziness. You pay for it so I don’t need to bother.


> Not really, a lot of phones are 8GB

Not many these days; the last iPhone that shipped with this configuration was the 5c four years ago (I had one; 8 GB sucked).


Favebook’s app is so large that they load code in dynamically so they can stay under the 20 second startup time limit imposed by iOS. Do you not see a problem there? Just loading the app into RAM means that you’ve consumed a substantial portion of it.


If you want to post something complaining about how fat the FB app is and perhaps solicit comments from people who know about it, you should do that. It's not much of a 'Ask HN', though, because it's Ask HN, not 'spit take FB'.


Instead of complaining, how about you fetch the package and reverse engineer it so you can answer your own question.


This is not possible to do without a jailbroken device, which not everyone has.


You don't need to jailbreak in order to do that.


How do you remove FairPlay without a jailbroken device?


You are the kind of guy that goes about writing writing a web server in assembly




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: