Fix end time of app start

[philipphofmann]

Description

Currently, the end of the app start is when the OS posts UIWindowDidBecomeVisibleNotification, which doesn't mean that some proper content is rendered for the user. When looking at an app start transaction, we can see that the initial frame render ends before the initial display span even starts.

Instead, the end of the initial frame render span and the app start should be the same as of the end of TTID. The SDK reports TTID when the app draws the next frame after loadView of the UIViewController is called, which correctly reflects when the user sees the first frame of proper content.

Strictly speaking, this should be handled as a breaking change, as this fix will prolong app start times.

[armcknight]

Is this example reporting that TTID == TTFD? It's a bit confusing because I expect TTFD to always come after TTID, even if they're equal, but that's not what the frontend is showing here.

[philipphofmann]

No TTFD is shortly after TTID. You should call SentrySDK.reportFullyDisplayed once your UIViewController has done all the heavy lifting. This might occur before TTID because we report TTID once the next frame is drawn. If you have a UIViewController doing very little, and you manually call SentrySDK.reportFullyDisplayed, that can happen. I also see this in our iOS-Swift sample app. We could highlight this in the product to state that this view was rendered on time.

[armcknight]

TTFD is shortly after TTID

Definitely seems like there's a bug in the frontend since in your screenshot it shows TTFD and then TTID. That should never happen IIUC.

[philipphofmann]

Ah you are talking about this ?

Yes, that seems like a bug. I created an issue for this #3471.

[philipphofmann]

We could also implement this for theperformanceV2 option, and maybe we decide for Mobile Starfish to actually start sending exclusive app start transactions.

[armcknight]

I'm still a bit unclear as to what we expect to see in the screenshot. It seems like TTFD should be at the end of ui.load.full_display, is that right?

This might be breaking in the sense that the aggregates are going to be weird once a customer goes live with this update, but they will even out after some time. I'm not sure that's really a breaking change w.r.t. the SDK, this is a bugfix because we weren't correctly reporting the timestamps, IIUC.

If it really is the case that we are currently misreporting times, I don't think we should gate the change behind what is effectively a feature flag, and force the customer to consider the tradeoff of possibly continuing with bad data. That makes configuration more complicated for customers, and code maintenance and customer support more complicated for us.

Existing customers are going to have to reckon with the data inconsistency regardless at some point, and new customers will have a higher barrier to entry with this. We should note the issue in the changelog, and explain how to use dashboard filters to avoid mixed results, like filtering by their app version, and that they can't compare between app versions before and after taking this update, but rather will need two releases with this update before seeing differences in TTFD.

[philipphofmann]

@armcknight, I agree. We will fix the TTID/TTFD spans and measurements in a non-breaking change without a feature flag in #3471.

I'm still unsure if the app start duration change is breaking. In our weekly sync, we (@brustolin, @kahest, and me) agreed that it is. The plan for this issue is to prolong the initial frame render span until the next frame is drawn after UIWindowDidBecomeVisibleNotification was posted, which will extend app start duration statistics, but it's the right thing to do. The downside is that this could confuse users a bit.

[philipphofmann]

I made this change in #3530 in a non-breaking way behind a feature flag, performanceV2. When we update to the next major, we only need to make #3530 the default behavior.