TL;DR
- iOS error tracking has six requirements that cross platform posts skip: dSYM symbolication, TestFlight crash report integration, App Store Connect crash data, SwiftUI vs UIKit error patterns, Swift/Objective C mixed stack trace handling, and watchOS/tvOS coverage.
- Crashlytics handles dSYM upload automatically via upload-symbols Xcode run script phase. The gap is two way Jira sync and ownership routing.
- Sentry handles all six and provides sentry-cli for dSYM upload in CI, plus Sentry Cocoa SDK supports Swift concurrency stack traces (async/await) which Crashlytics sometimes truncates.
- Apple's built in crash reporting (Xcode Organizer + App Store Connect + MetricKit) is free and covers all users, but has a 24-48 hour delay and no alerting, no Jira integration, and limited grouping.
Where Drizz fits:
- Drizz runs E2E tests on real iOS devices in CI, catching crash inducing regressions before build ships to TestFlight or App Store.
- The Jira/Linear integration creates tickets from failed test runs with device model, iOS version, video recording, and PDF report prefilled.
- Drizz doesn't replace production crash monitoring. It's upstream gate that reduces volume Crashlytics and Sentry handle post release.
For a cross platform feature comparison beyond iOS specific capabilities, see best mobile error tracking tools . For Android counterpart, see best error tracking tools for Android.
iOS specific comparison
What does Firebase Crashlytics handle for iOS?
Crashlytics is fastest path to iOS crash reporting. Here's what it covers for six iOS specific concerns:
- dSYM symbolication: upload-symbols run script phase in Xcode Build Phases automatically uploads dSYMs on every archive build. For builds distributed via Fastlane, upload_symbols_to_crashlytics action handles it
- TestFlight crashes: Crashlytics SDK runs in TestFlight builds same way it runs in production. Crashes from beta testers appear in Firebase console with no additional configuration
- Swift/Objective C stack traces: handles mixed codebases, but Swift concurrency (async/await) stack traces are sometimes truncated. The continuation frames that connect async caller to crash site can appear as incomplete or missing
- SwiftUI crash context: provides stack trace and basic breadcrumbs but doesn't capture SwiftUI view hierarchy or state at time of crash
- watchOS/tvOS: dedicated SDKs for both platforms. The watchOS SDK is lightweight and tracks crashes and non fatal errors
- Jira: one way only (Bug issue type), no custom field mapping, no ownership routing, no Linear support
- Price: $0, no event limits, no seat limits
iOS developers on r/iOSProgramming discussing what tells them a release went wrong consistently cite Crashlytics velocity alerts as first signal, but note that 24-48 hour delay before App Store Connect data confirms same spike means Crashlytics is real time layer and App Store Connect is verification layer.
The limitation that pushes iOS teams to Sentry: Crashlytics doesn't provide suspect commits, ownership based auto assignment, or two way ticket sync. If your workflow depends on Jira ticket auto resolving when fix ships, you need Sentry or a Cloud Function workaround.
What does Sentry handle for iOS?
Sentry's Cocoa SDK is strongest option for iOS teams that need automated triage, Swift concurrency support, or deep debugging context.
- dSYM symbolication: upload via sentry-cli debug-files upload in CI or via Fastlane sentry_upload_dsym action. Sentry also supports automatic dSYM download from App Store Connect via Sentry UI (Settings, then Debug Files, then Connect to App Store Connect)
- Swift concurrency: Sentry Cocoa 8.0+ captures full async/await stack traces including continuation frames that link async caller to crash site. This is where Sentry pulls ahead of Crashlytics for Swift concurrency heavy codebases
- SwiftUI crash context: breadcrumbs capture view transitions and user interactions leading up to crash. Combined with view hierarchy attachment (available via SentryOptions.attachViewHierarchy = true), you get more context than a stack trace alone
- TestFlight: SDK runs identically in TestFlight builds. Beta crashes appear in Sentry with same detail as production crashes
- watchOS/tvOS: supported via Sentry Cocoa SDK. Same crash reporting, breadcrumbs, and session tracking as iOS SDK
- Jira: two way sync with custom field mapping, ownership routing via codeowners, suspect commits linking crashes to specific PR. Linear, GitHub Issues, and Asana also supported
- Price: free tier at 5K errors/month (1 seat, 30 day retention), Team at $26/seat/month
Teams on r/Observability evaluating mobile observability platforms at scale note that Sentry's async/await stack trace stitching (intercepting Swift runtime's executor contexts to reconnect parent Task frames) is what separates it from Crashlytics for Swift concurrency heavy codebases. The older SDKs would show swift::runJobInEstablishedExecutorContext instead of your actual code; Sentry Cocoa 8.0+ resolves this.
Sentry also supports automatic dSYM fetching from App Store Connect, which eliminates CI upload step entirely for App Store builds. Configure it in Sentry's project settings under Debug Files, and Sentry pulls dSYMs directly from Apple after each release.
What does Bugsnag handle for iOS?
Bugsnag's iOS SDK captures Swift and Objective C crashes with auto detection. The stability score is its strongest iOS differentiator.
- dSYM upload: bugsnag-dsym-upload command line tool handles upload in CI. Fastlane integration is available via upload_symbols_to_bugsnag action
- Stability score: crash free session percentage per release version, tracked across adoption curve. Apple doesn't publish a specific crash rate threshold like Google's 1.09%, but apps with persistently high crash rates risk App Review rejections and reduced App Store search ranking
- Swift concurrency: partial support. Async/await traces may appear incomplete for deeply nested concurrent code
- SwiftUI: basic stack trace, no view hierarchy capture
- watchOS: supported. tvOS: not supported
- Jira: two way with Bugsnag Team ($22/seat/month). Free tier (7,500 events/month, 1 seat, 7 day retention) excludes Jira
- No ownership routing, no suspect commits, no Linear support
What does Instabug handle for iOS?
Instabug's value for iOS is strongest during TestFlight beta testing. The in app feedback loop captures what stack traces miss.
- Shake to report: beta testers shake device to submit a bug report with automatic device metadata, network logs, console logs, and sequential user steps attached
- Pre crash recording: 60 second screen recording before crash, reconstructing user's journey without requiring video replay infrastructure
- dSYM upload: manual (via dashboard or API), no Xcode build phase script or Fastlane action for automatic upload
- Swift concurrency: limited async/await trace support
- watchOS/tvOS: not supported
- Jira: two way via Atlassian Marketplace add on with custom field mapping. No free tier; pricing starts at $100+/month
Developers on r/iosdev warn about Instabug pricing trap: teams integrate free trial during early testing, then find pricing spikes sharply once they need Jira or Slack integrations. The consensus is that Instabug is worth cost only for teams with funded beta programs, not for solo developers or side projects where native TestFlight feedback is sufficient.
The gap: Instabug's crash reporting depth is thinner than Sentry or Crashlytics. The value is user feedback layer on top, not crash reporting itself.
What does Embrace handle for iOS?
Embrace is built for mobile specific observability. For iOS, session level debugging and startup crash handling are strongest differentiators.
- Session timeline: every network call, app lifecycle transition (foreground, background, suspend, terminate), memory warning, and user action leading up to crash, reconstructed as a structured event timeline
- Startup crashes: Embrace captures crashes that occur during app launch before other SDKs have finished initializing. For apps with complex dependency injection or heavy didFinishLaunchingWithOptions work, this catches crashes that Crashlytics and Sentry sometimes miss
- dSYM upload: handled by Embrace upload script in Xcode build phase
- Swift concurrency: supported, captures async/await continuation frames
- watchOS/tvOS: not supported
- Jira: not native, wire via webhooks. Alerting integrates with PagerDuty and Opsgenie
- Price: free tier at 1M sessions/month, paid plans are contact us
SREs on r/sre evaluating client side monitoring highlight that Embrace captures 100% of user sessions (unsampled), while Sentry and Crashlytics sample sessions to reduce cost. For iOS apps where rare edge case crashes on specific device/OS combinations matter, unsampled capture prevents those crashes from being lost in noise.
Embrace's OpenTelemetry investment also lets teams export mobile telemetry to existing backends like Grafana or Datadog without vendor lock in.
What does Apple's built in crash reporting tell you?
Apple provides three layers of crash data at no cost and with no SDK required: Xcode Organizer, App Store Connect, and MetricKit. Together they cover all users, including those who opted out of third party analytics.
- Xcode Organizer: shows crash logs from TestFlight and App Store users, grouped by crash point. Symbolication uses dSYMs from your local archive. Available within hours for TestFlight, 24-48 hours for App Store
- App Store Connect: crash free rate, hang rate, and launch time metrics in App Analytics section. The data covers all users on all iOS versions with a 24-48 hour delay
- MetricKit: framework that delivers daily crash and performance diagnostics to your app's delegate. Starting with iOS 16, MXCrashDiagnostic provides on device crash reports that your app can forward to a custom backend
- Coverage: ground truth for your crash free rate. If your Sentry/Crashlytics numbers diverge from App Store Connect, your SDK is missing crashes (usually startup crashes or crashes in extensions)
Apple's crash reporting has no alerting, no Jira integration, no real time spike detection, and limited grouping. Use it as executive dashboard and your error tracking SDK as engineering debugging tool.
How do you set up dSYM upload in CI?
Every iOS release build produces dSYM files that map memory addresses to readable function names. Without uploading them, your crash reports show hex addresses instead of PaymentProcessor.processCard().
Crashlytics (Xcode build phase)
Add Firebase Crashlytics run script phase to your Xcode project's Build Phases, which runs after every archive build and uploads dSYMs automatically. For Fastlane users, add upload_symbols_to_crashlytics to your lane.
Sentry (CLI, Fastlane, or App Store Connect)
Three options: sentry-cli debug-files upload --include-sources in a CI post build step, Fastlane sentry_upload_dsym action, or connect Sentry to App Store Connect and let Sentry pull dSYMs automatically after each release.
The App Store Connect integration is lowest maintenance option. Configure it once and forget CI upload step for production builds entirely.
Bugsnag and Embrace
Bugsnag provides bugsnag-dsym-upload for CI and Embrace provides an upload script for Xcode build phase. Both also support Fastlane integration.
If your CI pipeline archives build, dSYM upload should be a post archive step. Verify it works by checking tool's dashboard for dSYM UUID matching your release build.
One common pitfall from r/iOSProgramming discussions about crash reporting migrations: teams that relied on Fastlane's download_dsyms action to retrieve App Store processed symbols often find it failing or timing out because Apple's App Store Connect API no longer processes Bitcode (deprecated in Xcode 14). Uploading your locally generated dSYMs during CI build (as shown above) is now required approach to guarantee a match.
How does Drizz complement iOS error tracking?
Every tool above detects crashes after real users encounter them. Drizz catches crashes before build ships by running E2E functional tests on real iPhones and iPads as a CI gate.
When a test encounters an unhandled exception on a real device, Drizz captures device model, iOS version, failing step, video recording, and PDF report. The Jira/Linear integration creates a ticket with all context prefilled.
The simulator gap matters for iOS: simulators run x86/ARM translation on Mac hardware, not actual A series or M series chip in user devices. Memory pressure behavior, GPU rendering paths, and hardware specific crashes don't reproduce on simulators, which is why Drizz runs on real devices to surface these issues before release.
The honest scope: Drizz catches crashes in flows your tests cover. Crashes in user paths you haven't automated still need Crashlytics or Sentry in production.
Choose by scenario
FAQ
What is best error tracking tool for iOS apps?
Firebase Crashlytics is best free default with automatic dSYM upload and TestFlight coverage. Sentry is better choice for teams that need two way Jira sync, Swift concurrency stack trace support, ownership routing, or suspect commits.
How do you upload dSYMs for iOS crash reporting?
Crashlytics uses an Xcode run script phase that auto uploads on every archive build, while Sentry supports sentry-cli, Fastlane, or automatic fetching from App Store Connect. Bugsnag and Embrace provide their own CLI tools and Fastlane actions.
Does Crashlytics support Swift concurrency (async/await) stack traces?
Crashlytics sometimes truncates continuation frames that connect async caller to crash site in async/await code. Sentry Cocoa 8.0+ captures full async/await stack traces including continuations.
Which iOS error tracking tools support watchOS?
Crashlytics, Sentry, and Bugsnag all provide watchOS SDKs. Instabug and Embrace do not support watchOS.
How does Apple's App Store Connect crash data compare to third party tools?
App Store Connect covers all users (including those who opted out of analytics) with crash free rate and hang rate metrics, but has a 24-48 hour delay with no alerting, no Jira integration, and limited grouping. Use it as a ground truth alongside your error tracking SDK.
What's best iOS crash reporting tool for TestFlight beta testing?
Instabug is strongest for beta user feedback (shake to report, pre crash recording, device state snapshots). For crash reporting depth during beta, Crashlytics or Sentry with SDK included in TestFlight build provides better stack trace and breadcrumb data.
How does MetricKit work for iOS crash reporting?
MetricKit delivers daily crash and performance diagnostics to your app's delegate starting with iOS 14. MXCrashDiagnostic provides on device crash reports that your app can forward to a custom backend, giving you crash data from users who opted out of third party SDKs.
How does pre release testing on real iOS devices reduce production crashes?
Simulators run on Mac hardware and miss memory pressure, GPU rendering, and hardware specific crashes that only reproduce on actual A series/M series chips. Running E2E tests on real iPhones in CI catches these device specific crashes before build reaches TestFlight or App Store.
