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:
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:
- Launch the app on a real device.
- Trigger a deliberate crash.
- Reopen the app.
- Wait a few minutes for the report to appear in Firebase.
A minimal test button looks like this:
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:
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:
You can also confirm that a dSYM exists for the app build:
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.plistto the app target. - Disabling collection in code or
Info.plistand 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.

