[HN Gopher] Launch HN: Emerge (YC W21) - Monitor and reduce iOS ...
___________________________________________________________________
Launch HN: Emerge (YC W21) - Monitor and reduce iOS app size
Hi everyone! 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 has
come up in your development process, we'd love to hear about how
you handled it. We're always looking to improve and grow our
product and we're especially excited to hear feedback from the HN
community! Thanks, Noah + Josh [1]
https://docs.emergetools.com/docs/what-is-app-size [2]
https://docs.emergetools.com/docs/strip-binary-symbols [3]
https://medium.com/swlh/how-7-ios-apps-could-save-you-500mb-...
Author : sond813
Score : 63 points
Date : 2021-02-03 15:03 UTC (7 hours ago)
| LeicaLatte wrote:
| Very interesting! Congrats.
| joshspankit wrote:
| What do you say to people who argue that users have more than
| enough space for large binaries, and if they don't they are not
| ideal customers (because otherwise they would have the money and
| desire to upgrade to the bigger size)?
| sond813 wrote:
| Good question! Many apps are trying to expand around the world
| and have a global presence. This is actually what originally
| inspired the idea for Emerge. App size is crucial if you are
| trying to break into new markets where users might not have the
| latest iPhone or be on 5G. Generally, we don't think companies
| want to exclude users because of a technical issue, and
| engineers are motivated to build the most performant apps they
| can. A healthy app size is also a good indicator of a high
| quality app since it affects other metrics such as download and
| app launch time.
| joshspankit wrote:
| Awesome, that makes a lot of sense thank you
| ashishb wrote:
| Bigger apps kids load slowly as well.
| bberenberg wrote:
| Definitely cool from a tech standpoint, but what is the value
| proposition here? I get that smaller = better, but why should I
| invest my engineers time in optimizing size using the results you
| output vs delivering new features or bug fixes to customers?
| enos_feedler wrote:
| Not sure whether they will tackle Android as well, but I know
| there are strict limits on APK size to be eligible for Play
| Store features like Instant Apps.
| sond813 wrote:
| Android support is definitely on our roadmap!
| nicoburns wrote:
| People with small capacity phones (a lot of people) won't
| install your app, and may actually uninstall it if it's too
| big. That may not be priority #1, but it certainly deserves
| some consideration.
| sond813 wrote:
| Exactly! Emerge aims to make it as easy as possible to fix
| app size issues, so you can prioritize it similar to other
| bug fixes. With our pull request comments alerting you to
| size increases right when they happen you can easily see why
| size increased and remedy it all before the change makes it
| to users.
| colejohnson66 wrote:
| I mean, Facebook is a quarter of a gigabyte for God knows
| what reason. Many apps are similar. There's a reason the base
| capacity is 64 GB: apps keep getting bigger.
|
| However, the cellular size limit is now 250 MB IIRC, so
| Facebook seems to stay just under that.
| sond813 wrote:
| It's 200mb now before a prompt shows warning users of the
| size they are about to download.
| nicoburns wrote:
| Indeed! Our app (a shift management app) at work is ~20mb,
| and I felt like that was quite a big commitment to expect
| people to have on their phones!
| aripickar wrote:
| There are limits based on the size of the binary that apple
| will allow on the app store. In addition, here's a really
| interesting story about how uber had to fight to downsize the
| app cause they realized that staying under the cellular data
| limit made people able to download the app when they were on
| the go:
| https://twitter.com/StanTwinB/status/1336890442768547845
| neilk wrote:
| I used to run an iOS testing-as-a-service thing. Few of our
| customers came close to the App Store limits. The ones that
| did were games and they are definitely not looking to
| optimize apps for the long term. We did have some unicorn
| customers but they weren't doing 2GB downloads, for the
| reasons you mention.
|
| 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.
| ellis0n wrote:
| Looks interesting What about the image/video transcode to a
| smaller size?
| sond813 wrote:
| Thanks! We have some docs on image optimizations here:
| https://docs.emergetools.com/docs/optimize-images Emerge will
| automatically compress images as jpg and convert to HEIC and
| report the size diff do you. We aren't doing automated video
| optimizations yet but if this would be useful for you please
| reach out!
| bluesign wrote:
| When you say 'size', you mean on disk size or ipa size?
| sond813 wrote:
| Emerge is designed to help you reduce both! We go into detail
| on the differences between them (and other ways of measuring
| size) in our docs: https://docs.emergetools.com/docs/what-is-
| app-size
| milch wrote:
| I believe the command you give to check if bitcode is enabled
| is not entirely correct. I was recently debugging an issue
| where bitcode was not generated for a framework I was using,
| and my build failed complaining about the framework missing
| bitcode. While that framework did have `__LLVM` segments,
| there was no `__bitcode` subsegment.
|
| There's some discussion around that on this SO question:
| https://stackoverflow.com/questions/32808642/how-to-check-
| if... (but also no definitive answer)
| sond813 wrote:
| Interesting thanks for sharing! It looks like __bitcode is
| used for static but not dynamic libraries so it might not
| always be reliable. I've also found that apps can include
| bitcode for frameworks but not the main app binary, but if
| it's included for the main app it is required to be
| included in frameworks. That's why Emerge checks for the
| presence of bitcode only in the main app executable.
| edf13 wrote:
| $499/month! That seems expensive - is it a big problem when Apple
| does a lot with App thinning? Big enough of a problem for
| $499/month?
| Grustaf wrote:
| Yeah that's a lot. Engineers could spend several hours a month
| on app size and it would still be cheaper.
| sond813 wrote:
| App thinning goes a long way if you're supporting multiple
| architectures, but if your app has a lot of code it can still
| get very big, very fast. There are many companies that have
| dedicated teams to trying to handle app size, but we've found
| that our tooling offers more without the maintenance and eng
| resource cost of building it internally. To support independent
| developers and small startups we offer a free Growth plan and
| have significant discounts available for higher build volumes.
| We think this is a fair alternative to having a development
| team or even one engineer focused on this problem.
| bluesign wrote:
| App size is a problem, but as far as I know only challenge
| there is cellular download size. (thats why in your examples,
| dropbox and ebay doesn't care about install size)
|
| 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.
| sond813 wrote:
| Definitely! We want to reduce cellular download size as
| well. In the particular case of Dropbox, their download
| size is around 100mb right now. I just did a quick test by
| deleting the duplicate localizations in their Frameworks
| and zipping the .app which reduced compressed size by ~17mb
| (17%) so these optimizations would help significantly. This
| is one of the reasons I prefer to just measure install
| size. It's difficult to reason about all the combinations,
| but by reducing install size you're always on the right
| track to an overall smaller app.
|
| 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.
| jondwillis wrote:
| I have been using bitrise.io for iOS CI/CD for a few years. I
| noticed that they added a new step that seems to at least tackle
| the app size monitoring side of this.
|
| 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.)
| sond813 wrote:
| That's great to know! This integration is helpful for just
| knowing the size of an app and being alerted if it goes over a
| threshold, but it doesn't provide any insight into where that
| size actually comes from. Adding a Bitrise integration for
| Emerge is definitely on our roadmap though!
| daleebz wrote:
| this looks incredible! Awesome job y'all
| readmimusic wrote:
| whoa this is so sick, nice job guys!
___________________________________________________________________
(page generated 2021-02-03 23:01 UTC)