Emergency Fixes for Critical Mobile App Bugs
Payment stops working for 15% of users after updating to iOS 17.4. Or the app crashes on Android 14 when opening notifications—and it worked yesterday. These are critical bugs: they block key user scenarios, and every hour without a fix means lost conversions and growing negative reviews.
What Counts as Critical
Not every bug requires a hotfix. Criteria for emergency fixes:
- Crash affects >1% of sessions in the last 6 hours
- Payment, authorization, or core functionality is blocked
- Security vulnerability with potential data leak
- ANR rate exceeded 1% on Android (risk of Google warning)
A bug showing wrong date in profile—not critical. Crash when trying to place an order—critical.
Hotfix Process
Diagnosis (First 30–60 Minutes)
Check Crashlytics: OS version of affected devices, OS, specific stack trace. If crash started after a specific release—git diff between versions narrows down the search. If it started without a release—look for backend changes (API response, data format, new endpoint).
Typical scenario: backend returned null in a field the mobile client didn't expect—NullPointerException or force-unwrap in Swift (Fatal error: Unexpectedly found nil). Client-side fix—defensive parsing:
// Was—crashes on null
val price = response.price.toDouble()
// Now—graceful handling
val price = response.price?.toDoubleOrNull() ?: 0.0
Development and Testing
Hotfix branch from current production tag, not main. Only minimal change—no "let's refactor while we're at it." Test on real device with OS version where crash reproduces.
For Android: can release hotfix via staged rollout—first 10%, watch crash-rate in Play Console in real-time, then expand.
Publishing
App Store: emergency review takes 24–48 hours with standard queue. In real critical situations, Apple accepts Expedited Review requests through Resolution Center—decision within hours. Justification must be specific: "crashes for 100% of users on iOS 17.4 during payment."
Google Play: staged rollout 10% → 50% → 100% with 1–2 hour steps if metrics are stable. Full rollout to all users—within a day.
Remote Kill Switch
For critical situations where a fix isn't ready quickly—pre-implement feature flags via Firebase Remote Config. Disable problematic feature without release:
// iOS: check flag before showing feature
let config = RemoteConfig.remoteConfig()
let isPaymentEnabled = config["payment_enabled"].boolValue
If the flag wasn't implemented in advance—this is an argument for adding it after resolving the incident.
After the Fix
Post-mortem: what exactly broke, why tests didn't catch it, what to add to regression suite. Not to blame—to ensure the next similar bug is caught on staging, not in production.
Timeline Estimates
Diagnosis and minimal standard crash fix—2–8 hours. Problem related to OS behavior change or third-party SDK change (e.g., AVFoundation changes after iOS update)—up to 2 business days. Cost calculated individually after situation analysis.