Are view load spans intended to include the animation duration?

[Aquilosion]

Describe the bug

Based on the documentation and the manual instrumentation code sample on the same page, as well as some preliminary results I'm seeing, it seems that any reported view controller loads will include the time taken to animate that view controller into place, as loadView() is called before any animations, and viewDidAppear(_:) is called after.

My concern is, if sometimes view controllers animate in, and sometimes they don't (because it might e.g. be a root view controller or be added in as a child of another view controller, and possibly motion accessibility settings can affect the duration as well), they might produce misleading results?

[mclack]

Hi @Aquilosion

We do intend to include animation durations in spans, as the basic focus of our Performance solution is on end user experience. If your animations lengthen the time it takes for a view to be ready, then we feel this should be included in the aggregate.

We display breakdowns of spans for you to view, and before viewDidAppear happens, we also report viewDidLoad and viewWillAppear. Hopefully these breakdowns can give you a clearer view on why certain spans took the length of time that they did.

It’s worth noting that if you would rather define a different endpoint, you are free to manually instrument some or all view controllers: https://docs.bugsnag.com/performance/integration-guides/ios/#instrumenting-view-loads

Does this help alleviate some of your concerns? Please let us know if you have any further questions!

[Aquilosion]

Thanks for the reply! Yeah the only reason I mentioned it is that I occasionally have some view controllers which sometimes animate in and sometimes don't, and I was foreseeing that it would potentially result in difficult-to-understand aggregated data.

In the end I did just disable automatic reporting in favour of a custom implementation based on startViewLoadSpan etc. for key view controllers, which I'm happy with.

[mclack]

Hey @Aquilosion

We’re glad to hear you’ve managed to use your own custom implementation which gives you results you’re happy with! Given this particular issue seems to be resolved, I’m going to go ahead and close this out.

As always, please feel free to reach out again if you ever have any questions or need assistance. You can either open another issue or contact us at support@bugsnag.com