Introduction

Disabling Crashlytics in development is a common practice to avoid polluting production crash dashboards with debug-only failures. The key is to disable collection in debug builds while keeping it fully enabled in release builds.

You should implement this with build-type aware configuration, not manual toggling in local IDE settings. This ensures predictable behavior across teammates and CI pipelines.

Core Sections

1. Android build-type configuration

In Firebase Crashlytics for Android, disable collection for debug at runtime.

1class App : Application() {
2    override fun onCreate() {
3        super.onCreate()
4        FirebaseCrashlytics.getInstance().setCrashlyticsCollectionEnabled(!BuildConfig.DEBUG)
5    }
6}

This guarantees debug builds do not send reports.

2. iOS environment-based configuration

For Apple platforms, use Info.plist or runtime configuration to disable in debug.

1#if DEBUG
2Crashlytics.crashlytics().setCrashlyticsCollectionEnabled(false)
3#else
4Crashlytics.crashlytics().setCrashlyticsCollectionEnabled(true)
5#endif

Keep this close to startup initialization.

3. Validate behavior in logs

Do not assume toggles work; verify collection state during app launch and inspect Firebase dashboard to ensure debug events are not appearing.

Log.d("Crashlytics", "enabled=${FirebaseCrashlytics.getInstance().didCrashOnPreviousExecution()}")

Use controlled test crashes in release-like staging builds only.

4. Separate dev and prod Firebase projects

For larger teams, route debug builds to a separate Firebase project. This isolates analytics and crash data completely and reduces accidental leakage.

5. Build a repeatable validation checklist

Once the implementation is in place, create a deterministic validation checklist for Crashlytics environment gating. At minimum, include one baseline scenario, one edge-case scenario, and one failure-path scenario with expected outcomes documented in plain language. This prevents knowledge from staying implicit and reduces the risk of regressions during dependency updates or refactors.

A useful checklist also captures runtime assumptions: framework versions, SDK versions, configuration flags, and environment variables required for a successful run. Many teams skip this because the setup seems obvious during initial development, but those hidden assumptions are usually what break first when code moves to CI, staging, or another developer machine.

1validation checklist
2- baseline case with expected output and key fields
3- edge case with constrained or unusual input
4- failure case with expected error handling behavior
5- recorded runtime and dependency assumptions

Keep this checklist versioned with code. If behavior changes, update the expected outputs in the same pull request so future debugging has an authoritative reference for what changed and why.

6. Operational hardening and maintenance

Long-term reliability for Crashlytics environment gating requires observability and explicit ownership. Add targeted logs and metrics around critical steps so incident responders can quickly identify whether failures come from input quality, environment drift, external service dependencies, or code regressions. Without these signals, most incident time is lost reconstructing context instead of fixing root causes.

Define maintenance routines for upgrades and compatibility checks. Libraries and platforms evolve continuously, and subtle behavior changes are common. Lightweight smoke tests should run regularly, not only during feature work, to catch drift before it reaches production.

# example recurring check command
make smoke-test

Finally, document rollback criteria in advance. If a deployment changes Crashlytics environment gating behavior unexpectedly, teams should know when to roll back immediately versus when to hot-fix forward. This converts operational response from guesswork into a controlled process and improves overall system resilience.

Common Pitfalls

• Disabling Crashlytics manually in local IDE without version-controlled config.
• Forgetting to re-enable collection in release builds.
• Sharing one Firebase project across debug and production telemetry.
• Testing crash capture only in debug and assuming release behavior is identical.
• Logging sensitive debug data into crash reports without scrubbing.

Summary

Disable Crashlytics during development through build-type-aware startup configuration, not ad hoc manual steps. Verify the toggle behavior and prefer separate Firebase projects when possible. This keeps production crash metrics clean while preserving reliable monitoring in release environments.