Table of Contents

• Introduction
  • Example: UI Event Interception (Code, Stack Trace)
• Best Practices: Determining Whether a Crash Originates from the SDK or the App
  • When the crash is likely to originate in Blue Triangle SDK
  • When the crash is unlikely to originate in Blue Triangle SDK
• Summary

Introduction

The Blue Triangle SDK captures and reports crashes and errors to help correlate user-experience issues with business impact. Because of this, you may see Blue Triangle SDK methods appear in a crash stack trace. This does not necessarily mean the SDK caused the crash—only that it detected the crash and was in the call chain when it reported it.

Example: UI Event Interception

To track user interactions such as taps, the Blue Triangle SDK intercepts UI events before they reach the application own code. This technique is common across analytics and monitoring SDKs.

As a result, if your app crashes during a user interaction—such as a tap—the SDK may appear in the stack trace even when the root cause is entirely within your app.

Consider the following example, where tapping a button triggers an exception:

private lazy var checkoutButton: UIButton = {
   let action = UIAction(title: "Checkout") { [weak self] _ in
       // This will crash because the array is empty
       NSArray().object(at: 99)
   }
   return UIButton(primaryAction: action)
}()

When the user taps this button, the app will crash inside the button’s action. However, because the SDK intercepts the tap to record it, the crash stack trace will show SDK methods above the line where the exception occurred.

Sample Stack Trace

Below is an example crash log from Xcode. The crash originates in RootViewController within the app code, while the SDK appears higher in the stack due to intercepting the event:

-[__NSArray0 objectAtIndex:]: index 99 beyond bounds for empty array
0 CoreFoundation 0x0000000186ed50cc 67585043-7292-3D09-AF17-CDF8DFF2152A + 1155276 
1 libobjc.A.dylib 0x000000018436dabc objc_exception_throw + 88 
2 CoreFoundation 0x0000000186ed7f80 67585043-7292-3D09-AF17-CDF8DFF2152A + 1167232 
3 Example-UIKit.debug.dylib 0x000000010569e56c $s13Example_UIKit18RootViewControllerC16causeNSException33_EB4E99E189F14B8C928068E07EE9D213LLyyF + 80 
4 Example-UIKit.debug.dylib 0x000000010569b260 $s13Example_UIKit18RootViewControllerC11checkoutButton33_EB4E99E189F14B8C928068E07EE9D213LLSo8UIButtonCvgAGyXEfU_ySo8UIActionCcfU_ + 160
...
15  Example-UIKit.debug.dylib   $sSo13UIApplicationC12BlueTriangleE18swizzled_sendEventyySo7UIEventCF + 2676
16  Example-UIKit.debug.dylib   $sSo13UIApplicationC12BlueTriangleE18swizzled_sendEventyySo7UIEventCFTo + 76
...

Best Practices: Determining Whether a Crash Originates from the SDK or the App

When the crash is likely to originate in the Blue Triangle SDK

A crash can potentially be attributed to the BlueTriangle SDK if the initial frames of the crash’s stack trace include the name BlueTriangle or reference any BlueTriangle classes—such as BTTimer, ANRWatchdog, BTTTimerManager, or BTTScreenTracker.

Example:

Crashed: com.apple.root.utility-qos
0  libobjc.A.dylib               objc_retain_x0 + 16
1  libobjc.A.dylib               objc_retain + 16
2  YourApp                       ANRWatchDog.makeTimerRequest(...) (BlueTriangle.swift:172)  <-- ROOT CAUSE
3  YourApp                       closure #1 in ANRWatchDog.uploadReports(...)
4  YourApp                       thunk for @escaping @callee_guaranteed () -> ()
5  libdispatch.dylib             _dispatch_c

To determine whether a crash originated from our SDK, locate the thread labeled “Crashed” in the stack trace. Review the first several frames beneath it. If any of them reference BlueTriangle or its classes, then the crash originated from the BlueTriangle SDK.

When the crash is unlikely to originate in Blue Triangle SDK

A crash is not caused by the BlueTriangle SDK when the top frames of the “Crashed” thread point to your app’s code or another third-party library, and BlueTriangle only appears deeper in the stack trace. In these cases, BlueTriangle is simply part of the call flow—not the source of the crash.

Example:

-[__NSArray0 objectAtIndex:]: index 99 beyond bounds for empty array
0   CoreFoundation                 ... + 1155276
1   libobjc.A.dylib                objc_exception_throw + 88
2   CoreFoundation                 ... + 1167232
3   Example-UIKit.debug.dylib      RootViewController.causeNSException(...) + 80
4   Example-UIKit.debug.dylib      RootViewController.checkoutButton(...) + 160
...
15  Example-UIKit.debug.dylib      UIApplication.BlueTriangle.swizzled_sendEvent + 2676
16  Example-UIKit.debug.dylib      UIApplication.BlueTriangle.swizzled_sendEvent + 76
...

In this scenario, the crash originates from your application logic (objectAtIndex: on an empty array). Although BlueTriangle appears later in the stack, it does not indicate an SDK-caused crash.

Summary

When investigating an app crash:

• Start by reviewing the crash in the Error Explorer within the portal. There, you can see details such as the device, OS version, application version, and SDK version. If you have session replay enabled, you can also view the user’s actions leading up to the crash. Together, these details can help narrow down the root cause.

• Share the crash information—including app details, the stack trace, and any other relevant context—with Blue Triangle’s customer support team for further assistance.