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?

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.

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.

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.

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.