Posts

Post not yet marked as solved
2 Replies
436 Views
Greetings, We have observed an alarming number of crashes exceeding 1 million across various operating systems and devices. These crashes consistently point to a PAC failure in the specialized PreferenceNode.find<A>(key:) + 16 (PreferenceList.swift:146) function. The stack trace is exclusively a system-level stack, lacking any application-level stacks for us to go on. This makes it rather impossible for us to debug within our own application, since we do not have system-level context. Our analysis suggests that this issue may stem from either a compiler bug or an incorrectly implemented virtual-function in the AttributeGraph framework, resulting in a pointer-authentication failure in the SwiftUI framework. Lastly, if it helps, based on our own logs, we have determined that the problem primarily occurs when users return from being in the background for more than 60 minutes. However, despite numerous attempts, we have been unable to reproduce the issue ourselves. We kindly request your guidance on the most effective approach to address this matter confidently.
Posted Last updated
.
Post not yet marked as solved
1 Replies
1.3k Views
histogrammedOptimizedTimeToFirstDraw and histogrammedTimeToFirstDraw are both described as the "time taken to launch the app" with/without pre-warming. But, after we measured these values in production, we found them to be very similar, maybe a few hundred milliseconds apart. We expected the pre-warmed, or hot launches, to be far faster than the cold launches since the docs state that pre-warmed builds execute an app’s launch sequence up until, but not including when main() calls UIApplicationMain(). Which leads me to ask, what do these values truly represent? When in the launch cycle of an app are they captured? Thank you!
Posted Last updated
.