sond813's comments

sond813 | 3 years ago | on: We reduced our iOS app launch time by 60%

Apple recommends 400ms for startup time because that's how long the app open animation takes. It's also hard to tell from just one flamegraph how long it will really take in prod, that's why the percentages are nice to use. I've mostly used percentiles like p95 to track and prioritize mobile perf work. 600ms on one phone could be 2s on older hardware with other factors slowing it down, but it depends on the distribution of doordash users.

sond813 | 4 years ago | on: I shaved 187MB off United Airlines' 439MB iOS app

We've seen this happen with system fonts as well, apps sometimes bundle the San Francisco font with an app instead of relying on a system font. There may be some reasons to include the font or sound file, such as if it changes in different versions of the OS. Of course that would make the app inconsistent with the rest of the OS, which may not be the best behavior. We discuss some other tradeoffs with bundling these system resources on our blog post which covers the Spark app: https://www.emergetools.com/blog/posts/7AppsThatCouldSaveYou...

sond813 | 4 years ago | on: I shaved 187MB off United Airlines' 439MB iOS app

I tried it out with Yelp and Twitter, both had a lot of bloat due to not stripping binaries. You can see this in the large "String Table" in both screenshots.

Yelp also has a large exports section for the main app binary, that's usually a sign of a problem because the main binary doesn't need to export any symbols, only frameworks do that.

Twitter has a handful of 4MB images, much bigger than images you'd expect in an app. I took a look at a few of these and they are just gradient background images that could have been drawn with something like core graphics to completely eliminate the need for an image.

Twitter: https://emergeassets.s3.us-west-1.amazonaws.com/Screen+Shot+...

Yelp: https://emergeassets.s3.us-west-1.amazonaws.com/Screen+Shot+...

sond813 | 4 years ago | on: The Surprising Cost of Protocol Conformances in Swift

Building up the cache at launch/dynamic link time does have a performance hit of a few ms, but if you know it will save you many runtime checks it can be worth it. Definitely makes sense for the runtime to have the lazy behavior built in. Hopefully the dyld cache will help get the best of both solutions by persisting a cache across multiple launches.

sond813 | 4 years ago | on: How iOS 15 makes apps launch faster

The mach-o format supports a “fat binary” that contains multiple architectures and then the App Store can only deliver one of those architectures to a particular device. Bitcode lets Apple recompile a different architecture slice using this format. However, since this change is unrelated to the architecture it can’t take advantage of this format.

sond813 | 5 years ago | on: How Uber Deals with Large iOS App Size

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.

sond813 | 5 years ago | on: How Uber Deals with Large iOS App Size

Starbucks has a separate China app. I suspect a part of this is due to app size because there are regions specific SDKs. Another is likely security. Regulations in some countries require data to be shared with the government and they don't want SDKs that collect this data to be included in more privacy focused regions.

sond813 | 5 years ago | on: How Uber Deals with Large iOS App Size

Google encourages this with feature modules and app bundles. Apple doesn't allow it because they've always been against downloading executable code that doesn't go through app review. Same reason they don't like game streaming or downloading react native at runtime.

I'd like to see them open up this possibility in a controlled way one day. Something like a review process for feature modules that could be updated in a similar process to full apps.

sond813 | 5 years ago | on: How Uber Deals with Large iOS App Size

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-...

page 1