[sond813]

I’m the founder of a YC company in the current batch focused on solving this exact problem! https://www.emergetools.com

We parse Obj-C and Swift runtime metadata to determine size contributions of individual types and functions in your app. We use this analysis to post PR comments with granular size diffs to help devs write smaller, better code.

I tried it out on the Uber app and immediately noticed a disproportionate impact from their code-gen dependency injection framework, Needle. The codegen is responsible for over 30k classes in the app binary, and contributes over 10mb! In general codegen is a common problem with Swift binary sizes, and the fewer reference types generated the better, it even helps with startup time!

We’ve written a blog post with case studies about how 7 of the most popular iOS apps could reduce their size: https://medium.com/swlh/how-7-ios-apps-could-save-you-500mb-...

[rememberlenny]

"The Lyft app has hundreds of duplicate files, the largest consumer of space is a single asset catalog copied 73 times in separate bundles. Another asset catalog that is virtually identical except for the timestamp at which it was created is copied 67 times. Each of these contain nothing but 482 colors (colors can be stored in asset catalogs to simplify management of dark mode). With each one taking ~250kb these quickly eat up 35mb."

I read this as: Lyft installed Dark mode for 35mb. I can only imagine what my JavaScript modules are doing behind the scenes.

[trevor-e]

My biggest complaint with iOS development is how confusing Xcode's build system is. Extracting code out to shared frameworks is a confusing process and I can understand how so many of the top apps get it wrong. Also, it's clearly not a priority for Apple because they don't provide easy inspection tools. Best case for them is the user buys a new phone with more storage.

[sond813]

Yep this is exactly the problem I'm trying to solve! A lot of large app companies have switched from Xcode to third party build systems like Buck or Bazel. This can make things faster but even more confusing. I've found analyzing the actual build products to be the best solution to make sure nothing unintended is happening.

[tomasreimers]

Interesting! Are you interested in going back into the build process to try and thin the app directly? Or just in helping developers identify the sources of app size?

[sond813]

Currently identifying sources and offering suggestions for how to make improvements. For many apps this can reveal a lot of opportunity!

[saagarjha]

I agree that it's not necessarily the most straightforwards, but I would think that in the hundreds of engineers they have at least some have figured out how it works to the point to which they can do this…

[rememberlenny]

I’m curious - does React Native/Expo do any better job at this, with tree-shaking and package building?

[jamil7]

Expo produces ridiculously huge bundle sizes. I Would steer clear of it.

[dang]

Discussed here:

Launch HN: Emerge (YC W21) – Monitor and reduce iOS app size - https://news.ycombinator.com/item?id=26014180 - Feb 2021 (44 comments)

[wodenokoto]

My first thought reading the headline was “wasn’t there recently a show HN about this exact problem?”

Glad to see it near the top - saved me a search.

[rrdharan]

Is the name a nod to Gentoo's emerge? (https://wiki.gentoo.org/wiki/Portage#emerge)

Just curious.