Launch HN: Emerge (YC W21) – Monitor and reduce iOS app size
We’re Noah and Josh from Emerge (https://www.emergetools.com). Our company is building a monitoring and analysis tool to help iOS developers reduce their app’s size.
You might have heard about app size challenges faced by large iOS apps, particularly those with Swift codebases. I was an iOS engineer at Airbnb for 4.5 years and personally worked on their size reduction efforts.
App size is tricky to quantify. The size users most commonly see (what’s on the App Store page) is the install size thinned for their device. This is the size measured after stripping out assets like images and other media not needed for your screen size, or code that doesn’t run on your device’s architecture. However, this isn’t the only size metric out there, there’s also download and universal size (read more about this in our docs [1]).
Our tool makes app size easy to understand by visualizing the size contribution of every file in your app, from localized strings to machine learning models. To better our understanding, we even reverse engineered compiled asset catalogs and Mach-O binaries to show size contributions of original images, source files and Swift modules. With this perspective we often see files that don’t belong or are suspiciously large.
While testing our tool we analyzed and learned from over 150 iOS applications and found that keeping app size in check is really hard— even for industry leaders. Here are some of our more interesting findings.
Dropbox (https://www.emergetools.com/apps/dropbox) From the visualization, you can clearly see why Dropbox’s iOS app is 270 MB— it’s 35% localization files. These files are duplicated from the main app into 7 different app extensions and they all include comments that provide translators with context for the strings. Just removing these comments from the production app could save 46 MB.
eBay (https://www.emergetools.com/apps/ebay) This is an interesting architecture because although the main app’s executable is only ~150 KB, 86% of the app’s size comes from executables, the biggest one (32 MB) being EbayApp.framework. When building a Swift framework, the binary contains symbols which are not needed in the build uploaded to the App Store. These symbols can be stripped using the method described in our docs [2]. Stripping binary symbols would reduce Ebay’s app size by over 40%. Emerge can generate a script to add to your Xcode build phase to strip symbols for you.
Spark (https://www.emergetools.com/apps/spark) About 1/10th of Spark’s ~230 MB app is font files. 10 MB of those font files are duplicates found in an app extension. After a closer look, the fonts duplicated are all SF-Pro-Text, look familiar? These have been system fonts since iOS 11 (the minimum version for Spark). If the system font was used directly, 10% of the whole app could be deleted!
If you want to dive in a bit deeper you can check out our Medium post which goes into detail on some other popular apps [3].
Our analysis consistently shows that without guardrails in place, app size can get out of hand very quickly. Emerge wants to help developers reduce their size and keep it that way. Our continuous monitoring and binary size profiling prevents regressions by alerting developers of size changes in their pull requests, helping teams build better, smaller apps.
We offer a free Growth plan designed for independent developers and small startups. Our paid plans start at $499/month, you can view more details here: https://www.emergetools.com/pricing.
If app size h...
45 comments
[ 0.36 ms ] story [ 92.1 ms ] threadThere’s some discussion around that on this SO question: https://stackoverflow.com/questions/32808642/how-to-check-if... (but also no definitive answer)
Main approach to this problem in industry is when you approach cellular limit, you optimize.
I also agree that it is big engineering investment sometimes. But the problem is you are targeting low hanging fruit (stripping comments from localization, stripping symbols, optimizing images etc) or stuff that doesn't effect download size ( deduplicate files )
Those fixes are good for small startups, which you are giving away for free.
The main engineering problem for big companies is binary size, optimizations like "reordering of the build optimization passes" etc.
I would buy this as a tool, but as a service it is a hard sell for me.
In my experience working on large apps like Airbnb we try to get ahead of the problem even before approaching the cellular limit, since a smaller size helps acquire and keep users, and we want to avoid architecture decisions that would become a problem down the road.
It's not too rare for one of these low hanging fruit optimizations to be accidentally introduced in a large company, with testing on every PR you can catch them before they‘re introduced. Binary size is definitely what changes most often at these large companies and that's why our continuous monitoring lets developers know exactly the granular binary size affect of a PR. With a lot of code, things like exposing Swift functions to Obj-C which introduce new metadata can frequently be mistakenly added. For enterprise companies we also track the biggest modules in their binary, so eng managers can get a better understanding of where the size is coming from.
This price feels wrong, and I think part of it is the pricing of the other similar sorts of service we use for our app, and that I suspect others use.
Ultimately this service and the others are about improving reliability and quality in some sense, so while different markets I think they are comparable as teams can opt to focus on quality in different areas.
- CI, we pay $100-200 for this, and it obviously consumes a lot of compute resources and needs to regularly. Price feels ~reasonable.
- Crash reporting, we pay <$100 for this. It scales with user base, and while low cost per user this does feel like it has some scale to it. It's also essentially user-facing, so very high uptime requirements.
- Code coverage, $5. It's basically a few database records behind an API with a special interface. Feels like it's worth very little, but fantastic price, worth it. Also coverage is similar metric to app size – a small change is probably ok, but long term trends are an issue, so in a way it provides a similar type of value.
- And then we come to this. $500. The analysis is a complex bit of code I'm sure, and the company should be able to charge for that, but there isn't compute, (significant) storage, or high SLAs as a necessary part of the product. It feels "wrong" next to these other services.
I think all of these feelings roughly boil down to intuition around the cost of goods sold (COGS). Logic that has already been written has a low COGS, and while that doesn't mean it should be free at all, it does make it hard to justify over being, say, a standalone piece of software that one buys once. Perhaps a way to circumvent this is to go hard on the constant evolution of the platform as Apple changes their technologies.
Maybe this is all from the viewpoint of someone who would likely be on the free plan! And so maybe this is a non-issue, but we'd happily pay for this, it just feels like it's a $50/mo service not a $500/mo one.
Other than builds being dog slow (fine for me), I couldn’t be more happy with the service and the price ($40/mo. for the single dev plan.)
However, the cellular size limit is now 250 MB IIRC, so Facebook seems to stay just under that.
These older phones are way more common outside of the US and even just outside of the SFBA where not everyone buys a new $1000+ phone every 2 years.
So how many customers could this startup conceivably get? Unless you're a game with lots and lots of graphical assets, you have to be the kind of company with more ability to employ developers than to coordinate them (i.e. a unicorn).
It's also a moving target as limits are continually revised upwards. I assume they have done some diligence about their TAM, but I don't get understand the plan just yet.
Sure, everyone loves a rewrite, but perhaps Swift wasn't ready for it.
Ignoring performance comes at a cost to you (server side resources) and your users (device resources). This is why generation after generation devices get more powerful and slower (from user point of view).
It is up to you to find out which point in the performance vs new feature/bugfix tradeoff gives you maximum value.