Pre-warming technically executes in UIApplicationMain, not main, so if you're gathering metrics before that you'll be affected.

Is that true? Maybe I'm misunderstanding. According to docs:

Prewarming executes an app’s launch sequence up until, but not including, when main() calls UIApplicationMain.

It would definitely be the other way around. Unless they re-wrote the way the kernel works recently, UIApplicationMain could be circumvented for prewarming, but not main since that's the defacto entry point executed by the kernel to boot up a new process.

Perhaps I phrased it confusingly: to be clear, what I mean is that iOS will call your main, including all the code you have in your main above UIApplicationMain. Then, you'll call UIApplicationMain and UIKit will check whether it needs to suspend inside of that.

We've set up our measurement to capture the time between main is called (we record mach_absolute_time in the first lines of main) till specific points in launch process like hitting AppDidFinishLaunching, hiding system splash screen etc.

You're correct assuming we convert the Int64 returned by mach_absolute_time similarly to how it is done in those docs:

func durationBetween(_ first: UInt64, _ second: UInt64) -> Double {
    // gets timebase info
    // ...
    let nanoseconds = ((second - first) * UInt64(info.numer) / UInt64(info.denom))
    return Double(nanoseconds / NSEC_PER_MSEC)
  }

Even with the setup as outlined above we're seeing "large durations" reported as early as for "appDidFinishLaunching" event. The twitter thread you linked below is very helpful and sheds some light on what may be happening. This sadly does impact our current strategy of assessing startup performance quite a bit as it seems that our current metrics (main -> some signpost) will no longer be useful with pre-warmed apps.

Our MetricKit implementation just landed and it is integrated into our internal analytics pipeline. I'll follow up as soon as I get a chance to run some queries against those events.

I've just checked our MetricKit data and we only have 0.1% of startup events that are larger than 35s (which is our definition of "unrealistically large durations" for now). It looks like it's handling pre-warmed apps correctly then.

Note that MetricKit reports only the time till system splash screen is hidden so it's not very useful, at least for us.
Looking forward to your findings @cwalo.

@michalkalinowski- Quick correction, if memory serves, MetricKit measures from the moment you tap the app on the springboard (before main or your process is called) until applicationDidFinishLaunching has finished executing. The OS regards everything up till that point as part of the launch sequence.

After seeing the same issues with our startup measurement, we are rolling out the metric kit as well.
@cwalo @sberrevoets @michalkalinowski Are you guys analyzing the MXHistogram that comes from the MXAppLaunchMetric?
is there a different way to get a single value (maybe avg.) launch time?

If you support tvOS then sadly using MetricKit and XCTApplicationLaunch is not an option.

• MetricKit is not available on tvOS (FB13476055).
• XCTApplicationLaunchMetric is not reported for tvOS (FB11811540)

The good thing is that pre-warming is not present on tvOS, meaning using custom measurements is viable.

One more thing to note is that MetricKit is supported on visionOS. So, Apple TV is the only Apple platform (not taking watchOS into account) missing the support.