Hacker News Reader

Comment by nblgbg | Hacker News Reader

In short, they are using a third party library (they have not named it though) that accounts to 40% of the app launch time and they deferred loading of this library to later point!

View on HN

Thanks, it's astonishing how many teams make this mistake, simply putting some hungry library into the code to solve some story without thinking much further about the overall implications

I don't know if it's still the case, but some third party libraries are required to run on launch.

I worked on a an app where the Facebook login library took 600ms to load, and was required to run on launch.

I'm like 90% confident that it's their crash tracking or analytics library :P

Edit: It's a framework from Salesforce called "ServiceCore". In case you were wondering it decided that it was necessary to request a list of all frameworks in a static constructor so it could find one that contains a certain class of theirs that does bundle-relative image loading. Pro tip, don't do this.

How can you tell which framework it is?

I pulled open the app and looked for frameworks with approximately 9 static initializers, one of which called into NSBundle. ServiceCore was the one that matched.

If it's a crash manager, you have to load it early if you want to catch early crashes. Still, only the Mach exception handler really needs to be installed. I wrote an in-house crash reporting SDK based around PLCrashReporter and the whole thing loads in under 20 ms on a modern device.

200 ms is insane for an SDK, any SDK. Our company had that as its target cold start time to first interaction across all of our apps and it's something we watched religiously as part of launching new app versions.

Most work on making things faster is to give a shit.

Reply on news.ycombinator.com