Uygulama Çökmelerini Yayından Önce Değil Sonra da İzlemek: Crash Reporting

Test cihazında sorunsuz çalışan bir uygulama, yayınlandıktan bir hafta sonra bambaşka bir cihaz-işletim sistemi kombinasyonunda çökebiliyor. Bunu test ekibi asla yakalayamaz çünkü piyasada yüzlerce farklı Android cihaz modeli ve onlarca işletim sistemi sürümü var. Crash reporting tam bu noktada devreye giriyor: kullanıcı çökmeyi yaşadığı anda, siz o hatayı fark etmeden önce raporu elinize geçiriyor.

Crashlytics nasıl çalışıyor

Firebase Crashlytics, uygulama çöktüğünde cihazdaki hata izini (stack trace), işletim sistemi sürümünü, cihaz modelini, çökme anındaki bellek durumunu ve hangi ekranda olunduğunu toplayıp bir sonraki uygulama açılışında sunucuya gönderiyor. Bu sayede geliştirici konsola bakıp "Samsung A serisi cihazlarda, Android 12'de, ödeme ekranında NullPointerException alınıyor" gibi net bir tablo görüyor. Manuel olarak bu bilgiyi kullanıcıdan toplamaya çalışmak — "ekran görüntüsü atar mısınız" demek — hem yavaş hem güvenilmez bir yöntem.

Her crash aynı öncelikte değil

Crashlytics panelinde onlarca farklı hata türü listelenebiliyor ve hepsine aynı anda müdahale etmek gerçekçi değil. Öncelik belirlerken iki eksene bakıyoruz: kaç kullanıcıyı etkiliyor ve uygulamanın hangi kritik akışında oluyor. Günde 5 kullanıcıyı etkileyen ama ayarlar ekranında oluşan bir hata ile günde 500 kullanıcıyı etkileyen ve ödeme ekranında oluşan bir hata aynı sıraya konulamaz. Crashlytics'in "etkilenen kullanıcı yüzdesi" ve "olay sayısı" metrikleri bu önceliklendirmeyi objektif hale getiriyor; sadece "en son gelen hatayı düzelt" mantığıyla ilerlemek genelde yanlış yerlere efor harcatıyor.

Yayın sonrası izleme bir seferlik iş değil

Yeni bir sürüm yayınlandıktan sonraki ilk 24-48 saat kritik. Bu dönemde crash-free kullanıcı oranı (uygulamayı hiç çökme yaşamadan kullanan kullanıcı yüzdesi) yakından takip edilmeli. Bu oran aniden düşerse, sorunun yeni sürümdeki bir değişiklikten kaynaklandığı hemen anlaşılır ve gerekirse hızlı bir hotfix ya da kademeli yayının durdurulması gündeme gelir. Bu disiplin olmadan yayınlanan her sürüm bir kumar haline geliyor. Android uygulama geliştirme projelerinde Play Console'daki "Android vitals" verisi de Crashlytics ile birlikte okunduğunda, hangi cihaz segmentinin sorun yaşadığı daha net görülüyor.

iOS tarafında ekstra bir katman: TestFlight

iOS uygulama geliştirme sürecinde App Store'a çıkmadan önce TestFlight üzerinden sınırlı bir kullanıcı grubuna dağıtım yapmak, crash'leri gerçek kullanıcıdan önce yakalamanın önemli bir adımı. Apple'ın kendi crash raporlama sistemi (Xcode Organizer) da simge tablosu (symbolication) doğru yüklendiğinde okunabilir hata izleri veriyor, ama Crashlytics'in çapraz platform tek panel görünümü genelde daha pratik.

Crash olmayan ama crash kadar önemli hatalar

Uygulama çökmeden de kullanıcı deneyimini bozan durumlar var: sonsuz yükleniyor ekranı, boş liste görünümü, tıklanan butonun tepki vermemesi. Crashlytics'te bunları "non-fatal error" olarak loglamak mümkün ve bu, gerçek çökme kadar değerli bir veri kaynağına dönüşüyor. Uygulamanın kararlılığını sadece çökme sayısıyla değil, bu tür sessiz hatalarla birlikte değerlendirmek, kullanıcı memnuniyetini daha gerçekçi ölçmeyi sağlıyor.

Crash Reporting Firebase Crashlytics Hata Takibi Kalite Kontrol Mobil Uygulama