Crash Reporting Nedir?
Uygulama çöktüğünde (crash) otomatik olarak hata raporunun sunucuya gönderilmesi ve geliştiricinin bu raporları analiz etmesidir. Production'daki sorunları gerçek zamanlı görmek için kritik bir araçtır. 2026 itibarıyla crash reporting, mobil uygulama geliştirmenin olmazsa olmazıdır.
Neden Önemli?
- Kullanıcının %70'i crash yaşadıktan sonra uygulamayı SİLER
- App Store/Play Store crash-free rate'i sıralama faktörü olarak kullanır
- Kötü review'lerin #1 nedeni crash ve yavaşlık
- Featured olma için %99+ crash-free rate beklenir
- Apple ve Google, crash rate yüksek uygulamaları arama sonuçlarında geri sıralara atar
Araçlar
Firebase Crashlytics (Google)
- Ücretsiz ve sınırsız
- Gerçek zamanlı crash raporları
- Stack trace + device bilgisi
- Breadcrumb (crash öncesi kullanıcı aksiyonları)
- iOS + Android + React Native desteği
- Firebase Analytics ile entegre
- Velocity alerts (ani crash artışında bildirim)
Sentry
- Crash + error + performance monitoring
- Ücretsiz tier mevcut (5K event/ay)
- Source map desteği (JS/TS - okunabilir stack trace)
- Release tracking ve regression tespiti
- Session replay (mobil için sınırlı)
- iOS, Android, React Native, Flutter desteği
- Issue grouping ve assignment
Bugsnag
- Stability score ile genel sağlık görünümü
- Error grouping (akıllı gruplama)
- Release health dashboard
- Feature flag entegrasyonu
Crash Raporu İçerir
- Stack trace: Hatanın tam kodu ve çağrı zinciri
- Device info: Model, OS version, memory, disk, battery
- Breadcrumbs: Crash öncesi kullanıcı aksiyonları (navigation, tap, API call)
- Custom keys: Geliştiricinin eklediği ekstra bilgi (user state, feature flag)
- User info: Kullanıcı ID (varsa, PII dikkat)
- App info: Versiyon, build number, binary architecture
Crash-Free Rate
Formül: Crash-free sessions / Toplam sessions x 100
| Rate | Durum | Aksiyon |
|---|---|---|
| %99.5+ | Mükemmel | Korumaya devam |
| %99.0-99.5 | İyi | İyileştirme fırsatı |
| %98.0-99.0 | Kabul edilebilir | Top crash'lere odaklan |
| < %98 | Sorunlu | Acil müdahale gerekli |
Crash Türleri
Native Crash
- Segmentation fault, null pointer dereference
- Memory corruption
- Stack overflow
- dSYM (iOS) / mapping file (Android) ile sembolizasyon gerekli
JavaScript Exception (React Native)
- Unhandled promise rejection
- TypeError, ReferenceError
- Source map ile okunabilir stack trace
- ErrorBoundary ile yakalanabilir (ama crash'i önlemez)
ANR (Application Not Responding) - Android
- Main thread 5+ saniye bloke
- Input event 10+ saniye yanıtsız
- Google Play Vitals'da ayrı metrik
- Background ANR: BroadcastReceiver timeout
OOM (Out of Memory)
- iOS'ta Jetsam tarafından öldürülme (crash raporu oluşmayabilir)
- Memory warning'leri handle et
- Büyük görsel/video'da dikkatli ol
Best Practices
Entegrasyon
- Uygulama ilk yüklendiğinde Crashlytics/Sentry initialize et
- Source map / dSYM yükle (okunabilir stack trace için)
- Breadcrumb ekle (önemli aksiyonlarda)
- Custom key'ler ekle (kullanıcı durumu, sayfa bilgisi)
- CI/CD'den otomatik dSYM/source map upload
İzleme
- Günlük crash raporu kontrol et
- Yeni release sonrası crash spike izle
- Top crash'leri önceliklendir (etkilenen kullanıcı sayısına göre)
- Regression alert'leri kur (Slack/Discord entegrasyonu)
Düzeltme
- Top 5 crash'i her sprint'te ele al
- Crash → fix → release → verify döngüsü
- Non-fatal error'ları da takip et (crash değildir ama sorun)
- Crash reproducing: Device info ve breadcrumb'larla senaryoyu yeniden oluştur
React Native İçin
- Crashlytics:
@react-native-firebase/crashlyticspaketi - Sentry:
@sentry/react-nativepaketi - JavaScript exception'ları ve native crash'ler ayrı raporlanır
- Source map yüklemeyi CI/CD pipeline'ına ekle
- Hermes engine kullanıyorsan Hermes source map gerekli
- ErrorBoundary ile graceful fallback UI göster
Crash reporting olmadan production'a çıkmak, gözleri kapalı araba sürmek gibidir. İlk günden entegre edin.