For Doordash I'd say it doesn't matter if the app opens in 700ms or 7000ms. Hungry people are willing to wait a little to order their food.

But then again: How did this get so bad in the first place? I mean, yeah, premature optimization and stuff ... but ...

>One of the biggest immediate standouts was the time we spent on Swift protocol conformance checks (checking if a type conforms to a protocol), but why?

Correct: But why? Why would you do this in a static typed language? Conformance checks should be a rare exception.

>Architectural principles like the single responsibility principle, separation of concerns, and others, are key to how we write code at DoorDash.

Oh, OK, architecture astronautics at play, I guess. Sorry, but you can separate concerns and all that other stuff without ending up with what looks like a dynamic typing system.

/rant (I'm hungry)

Yeah 600ms to 300ms is noticeable, if you play online games 200ms lag gets killed by 50ms everytime

But that's exactly the poster's point. You don't get headshot in doordash. Slightly slower performance doesn't actually change anything about your use of the app, until it becomes slow enough to make you stop using it (thus, the threshold).

Optimizing startup performance is respecting your user’s time.

“It’s not slow enough to make someone give up” isn’t a performance metric that puts your users first.

This is such a weird thread. The question was essentially about optimization having diminishing returns at some point. Yes, we can spend 10,000 dev hours getting another 50ms off the start time because that's respecting the user's time... but if nobody is going to leave because of that extra time, why not do something else with that labor?

It’s a weird thread and not comparable in any meaningful way. Latency to actions performed multiple times per second to a one shot event is not useful due to it being an entirely different context.

Slow enough to notice is slow enough to annoy somebody out there. Yes certainly there are diminishing returns, but if you can be noticeably faster than your competitors, that makes a really good impression.

Yes, and specifically because I believe startup time to be a rare occurrence when using an app.

According to a talk I found [here](https://developer.apple.com/videos/play/wwdc2019/423/): there are three types of launches; cold, warm, and hot. Warm is what's typically profiled and occurs when the app has been run at least once but has been closed since, while hot launches are what occur when bringing an app to the foreground. I assume warm launches are what are being profiled.

I don't have any statistics, but my observation is that most people do not exit out of apps and instead just background them, which suggests warm launches are relatively rare if my understanding of which state triggers which type of launch is correct.

There are also prewarm launches, where iOS goes through part of the launch path on your behalf when it thinks you are likely to use the app.

Apps get killed when memory runs low so it gets cold starts after a day or less depending on usage.

Ok, maybe I misrepresented what a good threshold is. I certainly don't expect developers anywhere to target "minimum viable load time". But the comment I was responding to was totally off the mark, so I was explaining that.

> I certainly don't expect developers anywhere to target "minimum viable load time".

Is this not the job of your performance team?

You misunderstand. I said target, meaning their goal would be the slowest time they could get away with. That is not an acceptable goal; an app should be faster than that.

Online multiplayer video game latency and app launch latency are very different things and perceived very differently, though.

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.

Using dlopen is generally not a performant option unless you are doing it off the startup path.

I generally lead teams to move quickly to get products usable, deliver the most important features to feed the business, then go back and start optimizing things like launch times.

The DoorDash app is feature stable as far as I can tell as an infrequent user. It makes sense to have the team invest into small optimizations for experience and speed. Much better than letting idle hands start redesigning things that aren’t broken or doing new features for the sake of doing more things.

Also, a 600ms launch time on a high-end phone could be a 5s launch time for someone using a cheap, old phone. Optimizations are most noticed by the lower end of your userbase’s hardware.

> I'm curious about what metrics mobile developers use to prioritize tasks.

This is a very MBA take. Task priority should always be considered beforehand, but whenever there is some leeway (including "20% time") I contend that performance tasks should be given some preference. There is almost no end to the ill effects of slow software.

Given the performance of most mobile phones, hitting below 400ms to launch and be usable feels like a low bar to cross.

Depends on what you consider important. Do you want to reduce churn? Optimizing startup performance is one of the best ways you can do that.

There are some tried-and-true principles that have worked since the dawn of computing.

For example, if response time is less than 0.1 sec, whatever the user is doing is "interactive" and does not disrupt the flow of the task.

I remember there were similar statistics for web page response time (number of lost views as response time increased). These seem like they might be similar to app launch speed.

That said, I wonder if this "ios spp launch time" post was something that management pursued in a data-driven way, or some engineer getting annoyed and scratching an itch (or something in the middle)