Skip to content

fix(Apple): Updates in-app frames page to reflect reality #13918

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.

Sign up for GitHub

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 2 commits into from
Jun 4, 2025
Merged

fix(Apple): Updates in-app frames page to reflect reality #13918

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
1950d0e
updates in-app frames page to reflect reality
kahest Jun 4, 2025
c011aa1
adds note on why content is commented out
kahest Jun 4, 2025
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
10 changes: 8 additions & 2 deletions docs/platforms/apple/common/usage/in-app-frames/index.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,13 @@ description: "Learn about how your SDK marks frames as in-app."
sidebar_order: 40
---

The `sentry-cocoa` SDK always marks public frameworks such as UIKitCore, CoreFoundation, GraphicsServices, and so forth as `not inApp`. If you're using a version of our SDK that's older than 7.0.0, all private frameworks and the main executable inside the application bundle will be marked as `inApp`. If you're using version 7.0.0 and up, the SDK will only set the `inApp` flag for frames originating from the main executable by using the [CFBundleExecutable](https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleexecutable). For private frameworks such as Sentry, dynamic and static frameworks will differ.
The main executable and frameworks inside the application bundle will be marked as `inApp`, while well known and public frameworks such as UIKitCore, CoreFoundation, GraphicsServices, and so forth will be marked as `not inApp`.

To fine-tune this behaviour, define [Stack Trace Rules](/concepts/data-management/event-grouping/stack-trace-rules/#stack-trace-rules) for your project. This will alow you to mark specific frameworks as `inApp` or `not inApp`, depending on whether you consider them part of your business logic, or third party dependencies. For reference, you can read up on the [default stack trace rules](https://github.com/getsentry/sentry/blob/20b05fc91a4ad6783bff1875327f4570bcfb5d00/src/sentry/grouping/enhancer/enhancement-configs/newstyle%402023-01-11.txt#L4).

{/*

NOTE: commenting out the below for easier reference: once we tackle a more mid-/long term solution discussed in https://github.com/getsentry/sentry-cocoa/issues/5252 this will become relevant/correct again

If you're not familiar with these terms, you can learn more:

Expand Down Expand Up @@ -47,4 +53,4 @@ SentrySDK.start { options in
## Static Frameworks

Because static frameworks end up in the main executable, if you're using one, the Sentry SDK won't be able to detect if a frame of the main executable
originates from your application or a private framework and will mark all frames as `inApp`. To work around this, tell Sentry which frames should be marked as `not inApp`, using [Stack Trace Rules](/concepts/data-management/event-grouping/stack-trace-rules/#stack-trace-rules) on the server.
originates from your application or a private framework and will mark all frames as `inApp`. To work around this, tell Sentry which frames should be marked as `not inApp`, using [Stack Trace Rules](/concepts/data-management/event-grouping/stack-trace-rules/#stack-trace-rules) on the server. */}
Loading