What are these apps that have 50+ MB in code built with? Or what counts as code in that regard?

Snapchat for example is 95MB, 77MB code, and on my phone (Android, so not directly linked, but probably similar) the most unresponsive, crashy and painful-to-use app right along with Skype.

I was amazed to find a C++ "Hello, World" program was several megabytes. It turned out that it was due to statically linking in all of Unicode support. In the particular build environment it was invisible to the programmer; i.e., you wouldn't even realize it unless you went looking for it.

I'm wondering if the same kinds of things happen with Facebook, Skype, etc. It's not the actual Facebook or Skype code that's so huge, but that they've been around for so long and so many people worked on them that they have a very complex build procedure and they're linking in all kinds of unnecessary junk, but no one has the responsibility or desire to go prune it.

Thank you, that's a good point, actually. Keeping things lean can be quite tedious and tricky in some cases.

The first thing I had in mind was frameworks like PhoneGap, Exponent and the likes. I wonder if these have a big impact on app size.

But it's certainly true that it's not always extra stuff to slap on that makes things bloated. Could just as well be the stuff you don't go out of your way to keep out.

It's a pretty cool break down you do, but you should consider not including hearthstone in your demo, as most of its image, video and audio assets are placed in the "other" category. So it is a bad example of how your service can help me understand my app, since your demo doesn't help me understand this game.

When I got my first smartphone, the guy in the shop installed Whatsapp for me without really asking. It was around 80mb, and chewed through a fair chunk of my data allowance on the first day. Made me paranoid to use the data connection for the first few weeks.

Facebook Messenger is 130MB. That's the very definition of "kitchen sink".

Maybe someone can clear this up for me. I'm struggling to understand why it is that size. I'm not going to be silly and say it would it be a simple app because I don't know enough about mobile to make that assumption.

However, I see plenty of other apps that appear to have way more complexity than the Facebook app. They are all significantly smaller. I don't understand what's happening there that requires that much bloat. The UI appears fairly minimal. From an outside perspective (probably an ignorant one), it just appears to be making API calls and throwing out the data.

Genuine question. Where is this bloat coming from? Is it just a pile of thrown on band-aid fixes and kitchen sinks, or is there something that I'm missing. Even third party applications do the same job, yet treat my battery and storage with respect. They seem to be fully capable of the same things that the official app is capable of.

Part of me wants to assume it's the whole, "move fast and break things" approach.

Facebook is known for having fairly bad code standards in their mobile apps. It's mostly a product of overengineering and feature creep.

This is a good blog post about it: http://www.darkcoding.net/software/facebooks-code-quality-pr...

And Facebook's own blog post about their Dalvik hacks and how clever they are, which speaks volumes of their development culture: https://www.facebook.com/notes/facebook-engineering/under-th...

I read in ghacks that they released lite version of apps for countries with poor internet connection.

http://www.ghacks.net/2016/10/04/facebook-messenger-lite-wha...

Yep. And its web links, notification links, and bug reporting were all failing for me until I upgraded to iOS 10.

What gives?

We're dealing with linking to/from apps now - on iOS it is a HUGE mess, littered with edge cases. They basically made like 5 breaking changes from iOS 8 until 10. And nothing is compatible with the other. Some of the "link" websites (for like marketing etc) even have to have tables where it says "this link will work in this webview, but not in this app, and sometimes in that app depening on the moon position".

This seems like a very "woo woo" theory, because few users know how big their apps are, or what a "good" size or a "bad" size for a particular app is.

So, let's assume Segment is right and there's a causal relationship between app size and downloads. What am I missing?

User has device at 95% capacity. User tries to download app. If the app is under lets say 40mb, it installs. If app is over 40mb, user gets "please make room for app" alert. User loses interest, app is not installed. I know I have done this before, has anyone else?

I've just lost interest in installing silly apps for everything all together. My phone is basically a phone/email/imessage device at this point.

@CharlesW we mostly focused on the facts and running as controlled of an experiment as possible without bias or drawing conclusion on exactly why heavier apps get downloaded less. Though my personal guess from working years in the mobile app space is that users are surprisingly conscious of data & disk usage. Not everyone has unlimited data or 128GB storage iPhones.

If you are not modeling causality, then why do you have an "Impact on Installs" metric next to each asset size?

Impact can exist regardless of the underlying cause for impact. It may be because someone's device is full, or does not want to download over cellular, or any other myriad of factors. But you'll still lose an install statistically speaking.

Can you disclose what the limits of that experiment are, and highlight on the website when they are exceeded?

For example, I assume if you tested apps sized 0mb-200mb, the data does not extrapolate as far as Hearthstone, which clocks in at a sizeable 1.2gb!

The largest size we tested was 150mb, that's why the x-axis of the graph ends at that point :)

They might not know how big an app is but if an app takes too long to install they might cancel and try another one.

Would like to see this for web apps.

There is some good research already on how page load times can impact conversions.

https://www.quora.com/How-do-page-load-times-affect-e-commer...

I'd like to see that for desktop apps too. Particularly browsers and productivity ones.

Oh my gosh - this so, SO much. I think there's a lot of 'designers' thinking they're 'developers', I've seen that first hand and that's how you get rubbish like Drupal.

This is the second or third time in about a month that a site posted to HN has been blocked by my ad blocker.

According to Wikipedia, segment.com's sole purpose is to aggregate data for marketing and advertising. Not a company I want to give page views to.

Is there something I'm missing here? Why wouldn't a larger app take longer to install?

Install rate is referring to the percentage of users who install the app at all, versus those who choose not to because the app is too big.

I think "rate" refers to install rate, as in how many users install the app, not install speed.