6 ms·
Why the Facebook iOS Application is so large
- jafitc 11y agoI've never seen an iOS application quite like this. I wonder how they even manage it. Tons of subprojects perhaps?
- kenOfYugen 11y agounneeded complexity
- giarc 11y agoBoth the app and that webpage.
- kenOfYugen 11y agoto my dear downvoters, "Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it." Alan Perlis
- codeshaman 11y agoLots of money, lots of employed engineers, everyone needs to do something. That's the case with a lot of tech today - it's done for the sake of letting people do something. Which, I guess, is not that bad, in the end things are brought to perfection, even though they're not strictly 'needed' in the product. The fast CPUs and enough RAM take care of the added complexity and everyone's happy.
- mehrzad 11y agoI hope that's not the case, considering there are much more interesting things Facebook employees could be working on (not necessarily even for the betterment of society).
- ethanbond 11y agoIt seems to definitely be the case for designers (300+?), I wouldn't be surprised if it's the same for engineers. 10,000+ people to keep the service running?
- moonchrome 11y agoI heard about something similar to this once on a project a friend was working on (it wasn't of this scale) - it was actually when a designer was the lead on the project and he insisted on customizing random tiny bullshit and the engineers didn't have the power to say no (to cut on the added complexity). Don't know if this applies in FB case.
- untog 11y agoI mean, sure. Most apps have that. The question is what internal structures led to it being this way, and whether they're worth the cost. Of course, we have no idea about any of that stuff so we sit outside and say "lol Facebook are so silly".
- zanny 11y agoAnd its all Objective C code! Reading through just some of the classes they have it looks like they have everything from packet readers to image manipulation to RSS feeds to web page embedding to video playback in there. Its literally an OS unto itself.
- jafitc 11y agomy favorite ones though: FBWhichApplicationAreWe_DO_NOT_USE.h FBProfileSetEventsCalendarSubscriptionStatusMutationOptimisticPayloadFactoryProtocol-Protocol.h FBStoryCreateInputDataAttachmentsLifeEventExtrasEducationInfoEndDate.h FBReactionAcornSportsContentSettingsSetShouldNotPushNotificationsMutationCall.h
- delinka 11y agoChrome asks to kill the page after a bit. Does this content exist in a cleaner state?
- jafitc 11y agohere is a summary + a gist: https://news.ycombinator.com/item?id=10066530 https://news.ycombinator.com/item?id=10066530
- dynomight 11y agoI opened it in the opera version of chrome and it loads no problem. The browser isn't the best at everything but sometimes it works when everything else fails.
- aaronbrethorst 11y agoI was expecting a bit more nuance and insight than '18,000 classes, lol, FB is dumb.' At the very least, it'd be interesting to note what the size of the app might be after app thinning goes live next month.
- pests 11y agoDetails on app thinning?
- crgt 11y agoIn brief, a new feature of iOS 9 that allows app resources to be delivered on a device specific basis..meaning that, for example, a user with an iPhone 5 will no longer need to download assets meant to support the 6+ or iPad. More here: http://arstechnica.com/apple/2015/06/app-thinning-will-be-a-major-boon-for-8gb-and-16gb-iphones-and-ipads/ http://arstechnica.com/apple/2015/06/app-thinning-will-be-a-...
- NoCulturalFit 11y agoNot just assets, but also the compiled binary will be for that architecture alone. ARM6, ARM7 etc. Really cool stuff.
- 0x0 11y agoNot at all before iOS 9.0 general release.
- dshankar 11y agoIf you're having difficulty loading this webpage, it's because the author decrypted Facebook's iOS binary and listed all 18,000 header files. Yes, this webpage is merely a list of 18,000 headers.
- jafitc 11y ago1. The article gives the insight that the binary is sooo big, not just assets as one would think. 2. It shows how the classes are extracted 3. It presents the classes for you to browse. The word "merely" is downplaying the information being shared by the author.
- mynameisvlad 11y agoBarely does 1 and 2 since 3 causes browsers to actually slow down to a crawl. The second that 18k list started to load, my browser turned ridiculously slow.
- jafitc 11y agoI agree that the inline HTML code block is not optimized for such a use-case. You can read the content here: https://news.ycombinator.com/item?id=10066530 https://news.ycombinator.com/item?id=10066530 Still my point was about the content being simply a list, which it is not (for better or worse in this case, I know :-)
- toyg 11y ago> causes browsers to actually slow down to a crawl. some browsers. FF 40.0 on my 2012 rMBP barely breaks a sweat.
- pllbnk 11y agoI opened it with FF on my phone - no problem loading or scrolling it whatsoever.
- lewiseason 11y agoFine on Chrome 44 running on a fairly ancient Core 2 Duo
- 64mb 11y agoTL;DR Facebook app has 18k classes, if you want to know what they are look here: https://gist.github.com/quellish/473f513fbd1310233a8e https://gist.github.com/quellish/473f513fbd1310233a8e FB App is 114MB in size, but loading this page in Chrome will use a good 450MB, idk how they managed that.
- jafitc 11y agoyeah the website presents it in bloated HTML unfortunately. Here is the content: ------------------------------- How on Earth the Facebook iOS Application is so large Recently someone on reddit asked “How on earth is the Facebook app size so large ?”. The person asking the question realized that the ~100Mb compressed App Store archive wasn’t all assets - a very large portion was the application binary. How do you answer that question? You quickly reverse engineer the application! 1 Download the binary to a jailbroken device from the App Store 2 Find the application on the device. SSH into the device and find the application container on the filesystem: find / -type d -iname "SomeApp*.app" 3 Decrypt the binary Install dumpdecrypted on the device. Follow the instructions for using it. 4 Get the files off the device using scp or rsync. In most cases you will want the application container, the decrypted binary, and the application data container (i.e. what it writes out to the filesystem). At this point you have the decrypted binary and it’s files. You can now run class-dump on the binary and output a directory of header files for all the classes in the binary, or you can use a disassembler like IDAPro or Hopper to easily see all the classes, symbols, etc. In the case of the Facebook application, there are more than 18,000 classses in the application: [... list of all the classes ...] https://gist.github.com/quellish/473f513fbd1310233a8e https://gist.github.com/quellish/473f513fbd1310233a8e There is a LOT of crap in there. Even a “FBFeedAwesomeizer” - which alone is a collection of 74 classes and protocols. This is why the application binary itself is over 114Mb.
- nolok 11y ago> FB App is 114MB in size, but loading this page in Chrome will use a good 450MB, idk how they managed that. Comparing the size of the binary with the size of the memory used by the live program is apples to oranges. The two metrics don't have any correlation whatsoever.
- mahouse 11y agoMakes me remember of that time they had to cheat on Dalvik because they hit the 65k methods limit 8-) https://news.ycombinator.com/item?id=8162342 https://news.ycombinator.com/item?id=8162342 (blog link is dead) Anyway, I find this to be pointless, when the majority of that size is probably taken by assets.
- Namrog84 11y agoBut then they can say. In 2.0 we improved performance 50%!! And repeat this process of headline news several times!
- sovande 11y agoThis so called "investigation" of the Facebook app can be done much simpler. Locate the app in iTunes, rename the .ipa file to .zip, unzip and run otool and nm on the binary. The author list 18,000 header files which is not much of an investigation nor much interesting. Though the staggering number of classes does admittingly somewhat explain the enormous size of the FB app. I do not use the FB app, but generally it can be equally illuminating to look in the Resources/ folder of an app if you wonder where the size came from.
- jafitc 11y agoHe didn't claim it to be an investigation. It seems to be an insight. As for being interesting, it's quite subjective. Might not be interesting to you, but it makes other people wonder.
- mh- 11y agoclass-dump[0] is handy too. >This is the same information provided by using ‘otool -ov’, but presented as normal Objective-C declarations, so it is much more compact and readable. [0] https://github.com/nygard/class-dump https://github.com/nygard/class-dump
- 0x0 11y agoNo. You have to jailbreak and "crack" the app to get at the code segment, which makes this more of an effort than you make it out to be. Unless you know something I don't?
- conradev 11y agoThe symbols themselves are not encrypted, so you can still list those without cracking the app.
- vbezhenar 11y agoThat's what I call a fat client :)
- wruza 11y agoSeems to me that huge part of this was auto-generated (and auto-structured), and each .m/.h contains very few lines of code. I don't know what FB app does, but with 18000+ fully functional non-excessive handwritten modules you can just win the internets. Oh wait~
- revelation 11y agoTheir binary alone is 118MiB? Even with all the auto-generated crap in there (I hope no human chose those names), how do they manage that? I wonder how long it takes for an iPhone to even load that thing into memory before it starts executing any code..
- geon 11y ago> I wonder how long it takes for an iPhone to even load that thing into memory before it starts executing any code.. I takes my iPhone 4s about 5-10 seconds to start it.
- natch 11y agoThey are obviously very lost and reinventing wheels, rather than learning and applying the right design patterns for Apple platforms. I talked to a Facebook iOS person on here recently who was under the impression that GCD offered no help with concurrency problems.
- klapinat0r 11y agoI hope it's a mechanism to make it possible for new employees to actually work on this app. Perhabs someone with experience on large complex applications can share some insights? Otherwise, I pity the FB employees who gets assigned to this project. "Here you go, fix that button, here's 18k files to digest". Surely they must've decoupled it into oblivion in order to have a class that manages "just that", so 1. new employee can work in an "isolated" context (although he really isn't) 2. can locate where to write and debug in this complex codebase.