Crashlytics
iPhone
crash report
issue
troubleshooting

Crashlytics is not sending Crash report from iPhone

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Introduction

When Crashlytics seems silent on an iPhone, the cause is usually not the crash itself. Most failures come from incomplete Firebase setup, testing with a debugger attached, missing symbol files, or expecting the report to appear before the app is launched again.

Verify the Firebase and Crashlytics setup

Crashlytics only works after Firebase is configured during app startup. In a SwiftUI app, a small AppDelegate bridge is still the clearest place to do it:

swift
1import SwiftUI
2import FirebaseCore
3
4final class AppDelegate: NSObject, UIApplicationDelegate {
5    func application(
6        _ application: UIApplication,
7        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]? = nil
8    ) -> Bool {
9        FirebaseApp.configure()
10        return true
11    }
12}
13
14@main
15struct DemoApp: App {
16    @UIApplicationDelegateAdaptor(AppDelegate.self) var appDelegate
17
18    var body: some Scene {
19        WindowGroup {
20            ContentView()
21        }
22    }
23}

Also confirm that the correct GoogleService-Info.plist is included in the app target. A plist from another Firebase project, or a plist added to the project but not to the target, is a very common cause of missing reports.

Test the full reporting flow correctly

Crashlytics does not always upload immediately at the instant of the crash. In many cases, the report is finalized and uploaded on the next launch. That means the right test flow is:

  1. Launch the app on a real device.
  2. Trigger a deliberate crash.
  3. Reopen the app.
  4. Wait a few minutes for the report to appear in Firebase.

A minimal test button looks like this:

swift
1import SwiftUI
2
3struct ContentView: View {
4    var body: some View {
5        Button("Force Crash") {
6            fatalError("Crashlytics test crash")
7        }
8    }
9}

Do this on a device build where Crashlytics collection is enabled. If you are attached through Xcode, behavior can differ from a normal user launch, so it is worth testing once directly from the Home Screen after installation.

Check data collection and build configuration

Some apps disable Crashlytics collection until the user grants consent. If that is your setup, make sure collection is actually enabled at runtime:

swift
import FirebaseCrashlytics

Crashlytics.crashlytics().setCrashlyticsCollectionEnabled(true)

Also inspect your Info.plist and build settings for flags that suppress reporting in debug or development builds. Teams often add these intentionally and forget they exist later.

Another detail is internet access after the crash. If the device is offline, on a restrictive VPN, or killed before the next clean launch, the report may remain pending.

Do not ignore dSYM upload

A missing dSYM usually does not prevent report delivery, but it does make reports appear incomplete or unsymbolicated, which often gets misread as "Crashlytics is broken." If you use CocoaPods, the standard Crashlytics run script in Xcode should be present in the target's build phases:

bash
"${PODS_ROOT}/FirebaseCrashlytics/run"

You can also confirm that a dSYM exists for the app build:

bash
xcrun dwarfdump --uuid MyApp.app.dSYM

If Firebase receives the crash but cannot symbolicate it, you have a build pipeline issue, not a transport issue.

Device-specific checks

If reports arrive from simulators or test devices but not from one iPhone, focus on that device:

  • make sure the app is actually running the expected build
  • verify the phone is not stuck offline
  • check whether the app is being force-closed before relaunch
  • confirm the app is not crashing so early that Firebase never finishes initialization

Early startup crashes are especially tricky. If the app dies before FirebaseApp.configure() runs, Crashlytics has nothing to work with. In that case, move configuration as early as possible and simplify startup logic until reporting works.

Common Pitfalls

  • Expecting the crash to appear before relaunching the app. Many reports upload on the next launch.
  • Testing only under the Xcode debugger. Also test an installed build launched normally from the device.
  • Forgetting to add GoogleService-Info.plist to the app target.
  • Disabling collection in code or Info.plist and then assuming Crashlytics is active.
  • Missing the Crashlytics build-phase script, which leads to unsymbolicated reports and confusing diagnostics.

Summary

  • Initialize Firebase at app startup and verify the correct plist is bundled.
  • Test with a deliberate crash on a real device, then relaunch the app.
  • Make sure Crashlytics collection is enabled for the build you are testing.
  • Check dSYM upload separately from report delivery.
  • If one iPhone is affected, inspect network access, app lifecycle, and early-startup crashes on that device.

Course illustration
Course illustration

All Rights Reserved.