sond813
Joined 13 years ago
Karma
192
Submissions
40
Member since
Oct 19
Recent submissions
Comment · 3 years ago
Congrats on the launch!
Comment · 3 years ago
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.
Comment · 4 years ago
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...
Comment · 4 years ago
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+...
Comment · 4 years ago
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.
Comment · 4 years ago
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
Comment · 5 years ago
Looks like a great improvement to my workflow, does it require write access to GitHub or can it be read only? Any plans to support GitLab?
Comment · 5 years ago
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
Comment · 5 years ago
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.
Comment · 5 years ago
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?