From having used the Facebook iOS app for the last four years or so, I assumed that they had taken the agile methodology to the extreme. They keep adding more and more features to the app until it's unusable, and every now and then throw the whole thing away and start from scratch.
Granted, I've had an iPhone 4 the whole time, so the experience has gotten worse and worse as time's gone on. But there's definitely been performance booms and busts throughout that time, with the performance getting a lot better whenever they release a version that's been completely redesigned.
Also, the app can get very kludgy at times. When you come across a rarely used feature, you'll often find you get the mobile site in a web view (which has a noticeably different interface) instead of an in-app implementation. Polls in Groups are the last one I remember coming across.
>A: Facebook app has such different priorities than other developers, that Apple's development ecosystem has 'unreasonable' expectations and assumptions.
Facebook wants to be (and seems to like being) a "clowntown" (as the author puts it) where anyone and everyone can write up a duplicate library to anything and ship it. Any and all code will ship, it just can't make the app dip below 60fps. To meet those strange goals, they 'hacked' together their own GUIKit (at least three of them, actually), their own IDE, their own animation kit, their own debugger, etc. A general theme seemed to be that this was done in order to get everything off the main thread and onto background threads. By only depositing the very smallest amount of work onto the main thread from a gigantic soup of background threads you could keep the app snappy without needing to prune any code.
Seems to me to be a silly way to differentiate one's self.
I was going to read your comment but I felt like I had a better way to do it so I just wrote my own. I think it's better but I didn't do any benchmarks because I have to ship it now. Oh well, onto my next comment.
I work on a multitude of apps that have huge customer bases. Obviously no where near Facebook but, definitely a couple million users. The largest app has maybe 200K lines of code? And we are always able to find sections of the app to refactor or find dead code to cut.
I understand why the backend is different between such user bases, but shouldn't the complexity of the app be a function of features, not number of users?
Wow, At least that is a start, I have been shouting and even parking for an answer as to why some of the Apps are huge. May be next time i should ask that on Reddit to finally get an response.
To be honest performance wise Facebook app is great. Butter smooth, but there is no reason a 20MB App cant be butter smooth either. Feedly App, is only 18MB.
And it seems large app isn't just Facebook, twitter is 60MB. QQ is 130MB, or We Chat, etc..... Many apps seems to be be way bloated.
So are we implying all these apps are over engineered?
19 comments
[ 3.0 ms ] story [ 51.0 ms ] threadGranted, I've had an iPhone 4 the whole time, so the experience has gotten worse and worse as time's gone on. But there's definitely been performance booms and busts throughout that time, with the performance getting a lot better whenever they release a version that's been completely redesigned.
>A: Facebook app has such different priorities than other developers, that Apple's development ecosystem has 'unreasonable' expectations and assumptions.
Facebook wants to be (and seems to like being) a "clowntown" (as the author puts it) where anyone and everyone can write up a duplicate library to anything and ship it. Any and all code will ship, it just can't make the app dip below 60fps. To meet those strange goals, they 'hacked' together their own GUIKit (at least three of them, actually), their own IDE, their own animation kit, their own debugger, etc. A general theme seemed to be that this was done in order to get everything off the main thread and onto background threads. By only depositing the very smallest amount of work onto the main thread from a gigantic soup of background threads you could keep the app snappy without needing to prune any code.
Seems to me to be a silly way to differentiate one's self.
-- Facebook dev
I work on a multitude of apps that have huge customer bases. Obviously no where near Facebook but, definitely a couple million users. The largest app has maybe 200K lines of code? And we are always able to find sections of the app to refactor or find dead code to cut.
I've worked for places that average 2-4 million users/per day 40+ million a day, they're an order of magnitudes different in every single way
http://www.koszek.com/blog/2015/09/08/copyright-screen-of-fa...
To be honest performance wise Facebook app is great. Butter smooth, but there is no reason a 20MB App cant be butter smooth either. Feedly App, is only 18MB.
And it seems large app isn't just Facebook, twitter is 60MB. QQ is 130MB, or We Chat, etc..... Many apps seems to be be way bloated.
So are we implying all these apps are over engineered?