This page describes how to enable and customize Session Replay on crashes for your iOS apps.
Session Replay on crashes gives you additional context for crash analysis in the form of video-like screen recordings that replay the user actions immediately preceding a detected crash.
Ensure that your system meets the following requirements:
Starting with OneAgent for iOS version 8.281, Dynatrace stopped supporting iOS 11 and Xcode 14. We only support iOS 12+ and Xcode 15+.
Also, be aware that Apple app submission guidelines will restrict support to applications built with a minimum of Xcode 15 and iOS 17 SDK starting April 2024.
See Technical restrictions for Session Replay for web applications for more information.
If you haven't done so already, complete all steps described in the instrumentation wizard.
OneAgent for iOS version 8.249+
If you've already instrumented your SwiftUI app, you can additionally enable Session Replay for such a mobile app.
To enable Session Replay for your instrumented SwiftUI app
Complete all the steps of the Enable Session Replay instruction above.
Set the DTXSwiftUIEnableSessionReplayInstrumentation
configuration key to true
in your project's Info.plist
file.
<key>DTXSwiftUIEnableSessionReplayInstrumentation</key><true/>
We support Session Replay for the following SwiftUI containers:
Dynatrace doesn't instrument the following SwiftUI containers:
Equatable
protocolSession Replay on crashes comes with three predefined masking levels:
To see what data Session Replay masks and what parts of the screen are captured, use the Session Replay screenshot debugger.
By default, OneAgent applies the Safest masking level. To change it to the Safe or Custom level, use the API to configure OneAgent. If you've opted for the Custom level, see Configure custom masking for details on how to set which application components or views should be masked.
Import the DynatraceSessionReplay
framework to the class.
Set the required masking level and apply the masking configuration.
If you set the data masking level to Custom, you can use additional API methods to decide which app components or views should be masked. You can:
You can enable or disable rules globally or for the selected components, such as text fields, images, labels, web views, and switches.
If you remove all masking rules, Session Replay won't mask anything. If you enable all masking rules, it's equivalent to the Safest masking level.
You need to apply the custom masking configuration for it to take effect. See Change masking level for the example code snippet.
accessibilityIdentifier
You can enable or disable masking of the selected views based on their accessibilityIdentifier
.
You need to apply the custom masking configuration for it to take effect. See Change masking level for the example code snippet.
You can also mask a view by adding the data-dtrum-mask
masking tag to the view's accessibilityIdentifier
. A view with this masking tag is always masked.
You can enable Session Replay logs the same way as for OneAgent. See OneAgent for iOS debug logging for more information.
Session Replay records only certain events. You can additionally capture custom events that are not supported by default. You can capture a custom event with an included screenshot of a specific view, specific screen region, or full screen.
All methods for capturing custom events can throw a TrackCustomEventError.notInMainThread
error if you try to capture a custom event from a thread that is not the main thread. We suggest that you include a do-catch clause until everything works properly; then you can replace the clause with a simpler version that, even in case of an error, just doesn't capture the custom event.
With OneAgent for iOS version 8.239, we deprecated the following methods for capturing custom events:
trackCustomEvent(name:withFrame:)
trackCustomEvent(name:withView:takeScreenshot:)
takeScreenshot()
Use the following new methods for capturing custom events:
trackCustomEvent(name:view:) throws
trackCustomEvent(name:frame:) throws
trackCustomEvent(name:) throws
OneAgent for iOS version 8.239+
Capture a custom event with a screenshot of the specific view.
OneAgent for iOS version 8.239+
Capture a custom event with a screenshot of the specific screen region.
OneAgent for iOS version 8.239+
Capture a custom event with a screenshot of the full screen.
You can use this method instead of the deprecated takeScreenshot()
method.
OneAgent for iOS version 8.237 and earlier
name
is the custom event name shown in the timeline during the user session replay.withView
is an optional value referring to the UIView from which OneAgent takes the image. By default, OneAgent takes the application window.takeScreenshot
is an optional boolean value used to define if a custom event has a screenshot or not.Alternatively, you can take a screenshot of the view. In this case, a custom event named "Custom Screenshot" is shown in the timeline during the user session replay.
By default, all data—information on captured events and images—is sent over any connection. However, you can opt to transfer images only when the users are connected to Wi-Fi to save their mobile data.
OneAgent for iOS version 8.239+
The Session Replay screenshot debugger allows you to see when the screenshots are taken, which parts of the screen are captured, and what data—text fields, images, labels, web views, and toggles—is masked.
You can use the Session Replay screenshot debugger when running your mobile app in the simulator, so you don't have to wait until the session is closed and uploaded to Dynatrace.
After you enable the Session Replay screenshot debugger, you can see the corresponding keys in your project. Note that these keys are not sent to the app code for release or archive compilations, so they are never included in the production code. These keys are used only for debug runs.
To enable the Session Replay screenshot debugger
In Xcode, select Edit Scheme from the Scheme menu to change your application scheme.
From your application scheme settings, select the Run action, and then switch to the Arguments tab.
Under Environment Variables, add one or both of the following keys:
DTXDebugMasking
. This key shows screenshots taken by Session Replay, including masked content and UI controls. For each captured screenshot, you see a brief flash.DTXDebugFrameHighlight
. This key highlights the captured part of the screen with a red frame so that you can know exactly what part of the screen is captured.1.0 DEM unit per user session captured with Session Replay.
We've set hard limits of 300 KB per session and 10 MB for all sessions. Anything exceeding these limits gets trimmed down to the limits as mentioned above.
When recording a user session, Dynatrace may consume up to 10 MB of the user's mobile device storage. However, Dynatrace won't send a session that's more than 300 KB.
No. Session volume depends on a variety of factors, including the application size, session duration, and users' interactivity with the application.
No. To record sessions, Session Replay on crashes takes screenshots of the mobile app screen and its parts.
The data is sent one time. This is performed in several requests according to the data collected.
If you've changed the transmission mode to Wi-Fi, the images are sent only when the users of your app are connected to Wi-Fi.
Currently, there is no time limit for storing images; only the 10 MB hard limit mentioned above is applied. However, in emergency stop situations, everything is deleted.
It is difficult to answer this question precisely as the final size of the Session Replay framework depends on several factors.
Multiple architectures are included in a fat-framework binary: ARMv7
, ATM64
, i386
, and x86-64
. The ARM
slices are used by physical iOS devices, while i386
and x86-64
parts are used by Simulator and removed from your app during the build and archive process. Moreover, when users download your app from App Store, they receive only the architecture that their device requires.
We also have bitcode, which is an unoptimized intermediate code representation. It is included for ARM architectures but does not affect the final size of your application. Apple uses bitcode for potential recompilation and re-optimization of your app binary after you've submitted your mobile application to App Store.
Due to all these factors, the best way to estimate the Session Replay framework size is to compile your app without this framework and generate an IPA file; then do the same but with the framework included and compare the sizes of these two IPA files. The difference is the Session Replay framework size.
For our test application, the Session Replay framework size is around 500 kB compressed.
Data is sent only when the user reopens the app. However, if the user does not open the app within 10 minutes, the data is deleted.