Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Ipadonly1

macrumors regular
Original poster
Jun 8, 2023
134
90
Why do we have such variation in sizes of apps? I get some of is to do with code efficiency, but the variation still seems big and even similar apps from the same developer (Apple) have wildly different sizes.

For instance:
- Monzo ~(550mb) versus Chase (~240mb) both do literally the same thing
- Apple Podcasts with no dowloaded episodes (~700mb) vs Apple TV (~27mb)
- The Storygraph (<10mb) vs Rippple (~150mb). Rippple really is a great app though, no shade, just confused as it’s calling an external database just like The Storygraph

The wildest one for me is always Apple’s Podcast app…
 
Code bloat is one reason, but assets (images/audio/etc) are a source of large app sizes. If an app has lots of custom images, it will be much larger than an app that only uses default symbols built-in to iOS.
Apple Podcasts is <40MB on my device, fwiw.
 
  • Like
Reactions: Ipadonly1
It's a combination of many things, this is an interesting blog post about how so many apps are unnecessarily large. Some excerpts:
  • duplicate localization files
  • duplicate fonts, particularly those that shouldn't even be included
  • unnecessary swift symbols
  • More than half of it is the LINKEDIT segment containing the symbol table. Since this binary isn't a dynamic framework, we can be more aggressive with symbol stripping and even remove the global symbols.
  • [not] using some image compression techniques
  • 18% of the app is debugging symbols
  • The Lyft app has hundreds of duplicate files, the largest consumer of space is a single asset catalog copied 73 times
Basically, developers are leaving duplicate assets in, not stripping symbols or compressing assets. And that's not even touching the hundreds of megabytes worth of tracking frameworks from google and facebook, etc.
 
  • Like
Reactions: Ipadonly1
I wish every iOS app had to mandatory build in a feature to clear cache as some apps (like your Apple Podcast app) become bigger and bigger.

Some developers do build in such a feature themselves such as: Hydra (Reddit client), CloudBeats.
 
  • Love
Reactions: Ipadonly1
From my experience in app development the initial install size will balloon for any app until the developer(s) realize that small app size is an important feature and should be treated that way. Banks on the other hand know you'll have no choice but to use their app, so why should they spend time on what they see as minor issues. Tragedy really. I think some sort of metric like minutes app is used / storage space used should be kept by apple and displayed in the app store.
 
I’ve been thinking a lot about app size, especially with cache bloat. It made me wonder why cache cleanup is so often a manual process. Why not make the default behavior automatically clearing cache items older than x days, which is adjustable for the user. This keeps the data you actually use, which is likely being refreshed anyway. With current internet speeds, re-fetching is still pretty quick. There are exceptions of course but I feel like this could be an approach for a lot of apps.
 
  • Like
Reactions: 01cowherd
Code bloat is one reason, but assets (images/audio/etc) are a source of large app sizes. If an app has lots of custom images, it will be much larger than an app that only uses default symbols built-in to iOS.
Apple Podcasts is <40MB on my device, fwiw.
I envy your 40mb. I deleted the app and redownloaded it. It instantly took up 110mb. Then, with nothing in my library, I started playing one episode. Instantly up to 570mb…. 😰
 
It's a combination of many things, this is an interesting blog post about how so many apps are unnecessarily large. Some excerpts:
  • duplicate localization files
  • duplicate fonts, particularly those that shouldn't even be included
  • unnecessary swift symbols
  • More than half of it is the LINKEDIT segment containing the symbol table. Since this binary isn't a dynamic framework, we can be more aggressive with symbol stripping and even remove the global symbols.
  • [not] using some image compression techniques
  • 18% of the app is debugging symbols
  • The Lyft app has hundreds of duplicate files, the largest consumer of space is a single asset catalog copied 73 times
Basically, developers are leaving duplicate assets in, not stripping symbols or compressing assets. And that's not even touching the hundreds of megabytes worth of tracking frameworks from google and facebook, etc.
Very interesting. I wish some devs would take greater care.
 
From my experience in app development the initial install size will balloon for any app until the developer(s) realize that small app size is an important feature and should be treated that way. Banks on the other hand know you'll have no choice but to use their app, so why should they spend time on what they see as minor issues. Tragedy really. I think some sort of metric like minutes app is used / storage space used should be kept by apple and displayed in the app store.
Yes as the article linked by someone above mentioned, people are just going to not update your app or uninstall it in greater numbers if your app size increases.

You are right about banks too of course.

That would be a great metric to have.
 
I’ve been thinking a lot about app size, especially with cache bloat. It made me wonder why cache cleanup is so often a manual process. Why not make the default behavior automatically clearing cache items older than x days, which is adjustable for the user. This keeps the data you actually use, which is likely being refreshed anyway. With current internet speeds, re-fetching is still pretty quick. There are exceptions of course but I feel like this could be an approach for a lot of apps.
Definitely and I agree with someone above that this should be mandatory, because otherwise development teams (unlike certain conscientious individuals) just won’t be bothered to implement it.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.