Skip to content

feat(apple): Add duration of app hangs #12682

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Feb 17, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/platforms/apple/common/configuration/app-hangs.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -139,7 +139,7 @@ This feature is experimental and may have bugs.

</Alert>

As of version 8.39.0-beta.1, you can enable AppHangsV2, which is available on iOS and tvOS. The main difference is that AppHangsV2 differentiates between fully-blocking and non-fully-blocking app hangs, which you might choose to ignore. A fully-blocking app hang is when the main thread is stuck completely, and the app can't render a single frame. A non-fully-blocking app hang is when the app appears stuck to the user, but can still render a few frames. Fully-blocking app hangs are more actionable because the stacktrace shows the exact blocking location on the main thread. Non-fully-blocking app hangs can have a stacktrace that doesn't highlight the exact blocking location, since the main thread isn't completely blocked.
As of version 8.39.0-beta.1, you can enable AppHangsV2, which is available on iOS and tvOS. The main difference is that AppHangsV2 differentiates between fully-blocking and non-fully-blocking app hangs, which you might choose to ignore, and since version 8.45.0 measures the duration of app hangs. A fully-blocking app hang is when the main thread is stuck completely, and the app can't render a single frame. A non-fully-blocking app hang is when the app appears stuck to the user, but can still render a few frames. Fully-blocking app hangs are more actionable because the stacktrace shows the exact blocking location on the main thread. Non-fully-blocking app hangs can have a stacktrace that doesn't highlight the exact blocking location, since the main thread isn't completely blocked.

To enable the feature:

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@ Do you want to try some new experimental features? On the latest version of the
- Enable <PlatformLink to="/profiling/#continuous-profiling">Continuous Profiling</PlatformLink> to get full coverage of your app's execution.
</PlatformSection>
- If you use Swift concurrency, stitch together stack traces of your async code with the `swiftAsyncStacktraces` option. Note that you can enable this in your Objective-C project, but only async code written in Swift will be stitched together.
- Enable <PlatformLink to="/configuration/app-hangs/#app-hangs-v2">AppHangsV2</PlatformLink> to get more detailed app hangs. The main difference is that AppHangsV2 differentiates between fully-blocking and non-fully-blocking app hangs.
- Enable <PlatformLink to="/configuration/app-hangs/#app-hangs-v2">AppHangsV2</PlatformLink> to get more detailed app hangs. The main difference is that AppHangsV2 differentiates between fully-blocking and non-fully-blocking app hangs and measures the duration of app hangs.

<Alert>
Experimental features are still a work-in-progress and may have bugs. We
Expand Down