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.
I actually came across the 400ms number in a 2019 WWDC talk while researching the topic! It said 100ms of that time was delegated to the iOS system for setup, leaving 300ms for whatever your app does.
Granted the 100ms section included System Interface - DYLD3 (dynamic linking) as part of it, which includes the 200ms portion that was optimized in tfa so I don't know how accurate that 100-300 breakup is.
The talk also says to avoid dynamic library loading during launch to improve time which is interesting, as it suggests there's an alternative, which may or may not be what Doordash did here.
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...
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.
They're probably shipping their org chat. Artists and engineers are on separate teams, and when the artists want to redesign the look of the app it is easiest to photoshop a bunch of images.
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.
It’s ms, that slow because every protocol conformance in every dylib needs to be checked. When this gets to 100k+ like in many large apps it takes multiple milliseconds
The CLI does not require any access to Github, and if you want to start doing code review on the platform, we ask for write access just so we can post comments and reviews :)
Gitlab is actively on our roadmap; we currently have a few CLI users that have made it work, but feel free to reach out if it's blocking you.
There’s also a linker flag that lets you use this format on older OS versions. It seems to work (I tested as far back as iOS 13.4.1) but couldn’t find any documentation to guarantee it won’t cause issues https://developer.apple.com/forums/thread/683596
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.
I always had trouble getting notified when a release was blocked from App Store review since it required getting an email and then logging into App Store Connect to find the reason for rejection. Does Runway help surface rejection reasons into other tools?
Part of what we’re trying to do with Runway is to consolidate all the various sources of information about your release.
We do currently notify your team in Slack of any changes to your review status in App Store Connect. Providing further detail about your rejection reason is 100% something that’s on our roadmap for the “App Review” step, along with making it clear who owns the task of responding to rejections if needed.
