Troubleshooting Missing Crashes
Find out why iOS crashes show in Xcode Organizer but not in Luciq, and fix late SDK start, conflicting crash handlers, and debugger-attached testing.
If crashes appear in Xcode Organizer, App Store Connect, or another tool but are missing from your Luciq dashboard, the cause is usually one of these:
Luciq is started too late.
Another SDK has taken over crash handling.
The app was running with the Xcode debugger attached.
This page explains how to find and fix each cause.
Why Only One Crash Reporter Works
iOS lets an app have only one active handler for each type of crash. When another SDK installs its crash handler after Luciq, it replaces the Luciq handler. Luciq only receives the crash if that SDK passes it on to the previous handler. Many SDKs don't, so the crash never reaches Luciq.
This isn't limited to crash reporting tools. Ad and social SDKs such as Google Mobile Ads and the Meta (Facebook) SDK ship their own crash reporting and install handlers without telling you.
Quick Checklist
Start Luciq Early
Luciq only captures crashes that happen after Luciq.start runs. If you start it late, crashes during launch are lost. Common examples of starting too late:
After a remote config fetch
After the user logs in
Inside an
asynctaskInside a view controller
Call it first in application(_:didFinishLaunchingWithOptions:):
For SwiftUI apps, start Luciq as the first line of your App struct's init():
Don't start Luciq in a view's init or onAppear. Views are created and recreated throughout the app's lifetime, so anything that crashes before the first view appears is missed.
Launch Crashes
For crashes that happen during app startup, also enable Capturing Launch Crashes.
Remove Other Crash Reporting SDKs
If your app also uses a dedicated crash reporter such as Firebase Crashlytics, both SDKs compete for the same handlers, and whichever registers last wins.
We recommend removing the other crash reporter from your project.
Disable Crash Reporting in Third-Party SDKs
Some SDKs that aren't crash reporters still install crash handlers. Disable their crash reporting before you start them.
Google Mobile Ads
MobileAds.shared.disableSDKCrashReporting()
Meta (Facebook) SDK
CrashHandler.disable()
Google Mobile Ads
By default, Google Mobile Ads replaces the app's uncaught exception handler when it starts, and it doesn't forward exceptions to the previous handler. If it starts after Luciq, uncaught exceptions never reach Luciq.
Call disableSDKCrashReporting() before you start the Google Mobile Ads SDK:
Older Google Mobile Ads Versions
On Google Mobile Ads SDK versions earlier than 12, the Swift API is GADMobileAds.sharedInstance().disableSDKCrashReporting().
Meta (Facebook) SDK
The Meta SDK installs its own crash handler through FBSDKCrashHandler. Disable it at launch, before you initialize the Meta SDK:
For more details, see FBSDKCrashHandler.h in the Meta SDK repository.
Recommended Startup Order
Putting it together, your application(_:didFinishLaunchingWithOptions:) should follow this order:
Check Whether Luciq's Crash Reporter Is Active
To confirm that no other SDK replaced Luciq's crash reporter, check crashReporterState after all your SDKs have started. It returns nil if Luciq hasn't started yet.
To find out which SDK took over, compare state.currentHandlers with state.luciqHandlers. Each one lists the signal handler and the uncaught exception handler, including the binary they belong to.
Run this check without the Xcode debugger attached. While debugging, the result doesn't tell you whether crashes will actually be captured.
Test Without the Xcode Debugger
When your app runs from Xcode with the debugger attached, the debugger catches crashes before any in-app crash handler sees them. The app pauses in Xcode and no crash report is created. This is expected behavior, not an SDK issue.
To test Crash Reporting:
Build and run the app from Xcode.
Stop the app in Xcode (⌘ + .).
Launch the app from the device or simulator home screen.
Trigger the crash.
Relaunch the app. Luciq sends the crash report on the next launch.
You can also turn off the debugger for your scheme: go to Edit Scheme > Run > Info and uncheck Debug executable.
Verify the Integration
Add a temporary test crash, run the app without the debugger, relaunch it, and check your dashboard. Test both crash types, since each one uses a different handler.
Trigger one of these at a time, relaunching the app in between. Code after the first crash never runs, so putting both in the same place only tests the first one.
Uncaught Exception
This tests the uncaught exception handler:
Signal Crash
This tests the signal handlers:
If the signal crash shows up but the NSException crash doesn't, another SDK is most likely replacing the uncaught exception handler. See Disable Crash Reporting in Third-Party SDKs.
Still Missing Crashes?
Contact our support team at support@luciq.ai and include:
Your Luciq SDK version
The full list of third-party SDKs in your app and their versions
Your
application(_:didFinishLaunchingWithOptions:)code, showing the order SDKs are started inA sample crash from Xcode Organizer that is missing from Luciq
Last updated