Uygulama Çökme Oranı Kaç Olmalı? Crashlytics ve Google Play Eşikleri

Bir kullanıcı uygulamanızı açar, sepete ürün ekler ve ödeme ekranında uygulama kapanır. Bu kişi büyük olasılıkla bir daha denemez; üstelik mağazaya düşük puan bırakabilir. Bu yüzden çökmeyi yalnız teknik bir hata gibi değil, gelir ve itibar kaybı gibi düşünmenizi öneriyoruz.

Biz Talha Aslan ve ekibi olarak mobil projelerde yayın sonrası ilk haftaları en hassas dönem sayıyoruz. Bu rehberde Google Play eşiklerini, App Store tarafındaki yaklaşımı, Crashlytics ile takibi, hangi hatayı önce düzelteceğinizi ve yayın sonrası kontrol listesini adım adım anlatıyoruz.

Çökme, ANR ve donma arasındaki fark nedir?

Çökme (crash), uygulamanın beklenmeyen bir hata yüzünden aniden kapanmasıdır. Kullanıcı ekranda uygulamanın kaybolduğunu ve ana ekrana döndüğünü görür. Örneğin boş gelen bir veriyi işlemeye çalışan kod satırı, uygulamayı tamamen kapatabilir.

ANR ise "Application Not Responding" ifadesinin kısaltmasıdır ve Android'e özgü bir kavramdır. Android geliştirici belgelerine göre uygulamanın arayüz iş parçacığı çok uzun süre bloke kaldığında ANR hatası tetiklenir. Kullanıcı bu durumda uygulamanın donduğunu ve dokunuşlara yanıt vermediğini görür.

Donma (hang) ise daha genel bir ifadedir; iOS tarafında da arayüzün bir süre yanıt vermemesini anlatır. Ayrıca kullanıcı gözünden bakarsanız fark küçüktür, çünkü her üç durumda da işini bitiremez.

• Çökme: Uygulama kapanır, kullanıcı baştan başlamak zorunda kalır.
• ANR: Uygulama açık kalır ama donar; sistem kullanıcıya bekleme ya da kapatma seçeneği sunar.
• Ölümcül olmayan hata (non-fatal): Uygulama kapanmaz, ama bir işlem sessizce başarısız olur.

Mağaza değerlendirmesinde en çok ağırlık taşıyan iki metrik çökme ve ANR oranıdır. Ölümcül olmayan hatalar ise mağaza eşiklerine girmez; yine de kullanıcı deneyimini bozdukları için takip etmeniz gerekir.

Google Play uygulama çökme oranı eşiği kaç?

Google, Android geliştirici belgelerinde "kötü davranış eşikleri" adıyla iki ayrı sınır yayımlar: genel eşik ve cihaz başına eşik. Android Developers sitesindeki Android vitals sayfasına göre bu yazıyı hazırladığımız sırada geçerli değerler aşağıdaki gibidir. Ancak Google bu değerleri değiştirebilir; güncel değeri resmi sayfadan kontrol edin.

Genel eşik, tüm cihaz modellerindeki günlük aktif kullanıcılar içinde çökme yaşayanların payını ifade eder. Cihaz başına eşik ise tek bir telefon modelindeki kullanıcıları ayrı değerlendirir. Yani uygulamanız genelde sağlıklı görünse bile belirli bir modelde ciddi sorun yaşıyorsa o modelde eşiği aşabilir.

Akıllı saat uygulamaları için Google ayrı ve daha sıkı değerler yayımlar. Ayrıca tablodaki eşikler "kullanıcının algıladığı" çökmeler içindir; arka planda yaşanan ve kullanıcının fark etmediği çökmeler bu hesaba girmez.

Google Play eşiği aşan uygulamaya ne yapar?

Android vitals sayfasındaki ifadeye göre uygulamanız kötü davranış eşiğini aşarsa Play uygulamanın görünürlüğünü azaltabilir. Üstelik Play, mağaza girişinizde kullanıcılara bir uyarı da gösterebilir. Bu iki sonuç, aynı anda hem keşfedilmeyi hem de indirme kararını olumsuz etkiler.

Etki eşiğin türüne göre değişir. Google'ın çökme sayfasına göre genel eşiği aşan uygulama büyük olasılıkla tüm cihazlarda daha az keşfedilir. Cihaz başına eşiği aşan uygulama ise o cihazlarda daha az keşfedilir ve mağaza girişinde uyarı görünebilir.

• Değerlendirme süresi: Play, kaliteyi değerlendirmek için son 28 günün verisini kullanır ve göstergeleri her gün bu 28 günlük ortalamayla kontrol eder.
• Yeni ortaya çıkan sorunlar: Android vitals, cihazları 7 günden uzun süredir etkileyen çökme ve ANR sorunlarını işaretler ve düzeltmeniz için 21 gün tanır.
• İyileşme: Ortalama düzeldiğinde Android vitals uyarıları kalkar; sistem iyileşmeyi fark ederse mağaza uyarısı daha hızlı da kalkabilir.

Buradan çıkan sonuç şudur: düzeltmeyi yayınladığınız gün sonuç almazsınız. Dolayısıyla 28 günlük pencere boyunca yeni sürümün payı arttıkça ortalama da düzelir. Bu nedenle sorunu erken yakalamak, sonradan düzeltmekten çok daha ucuzdur.

App Store çökmeleri nasıl değerlendiriyor?

Apple, Google Play gibi kamuya açık bir yüzde eşiği yayımlamaz. Bunun yerine çökmeyi inceleme aşamasında ele alır. App Store İnceleme Yönergeleri içindeki 2.1 maddesi, uygulamayı göndermeden önce cihaz üzerinde hata ve kararlılık testi yapmanızı ister. Aynı madde, çöken ya da bariz teknik sorun gösteren paketleri reddedeceklerini açıkça yazar.

Yani iOS tarafında risk daha çok yayın öncesindedir. İnceleme ekibi uygulamanızı açtığında giriş ekranında çökme yaşarsa sürüm reddedilir; bu da yayın takviminizi günlerce kaydırabilir. Red nedenlerinin genel listesini uygulamanız neden reddedildi yazımızda topladık.

Yönergelerin tasarım bölümü ayrıca çalışmayı bırakan ya da kötüleşmiş deneyim sunan uygulamaların her an kaldırılabileceğini belirtir. Dolayısıyla yayın sonrasında da çökme takibi iOS için isteğe bağlı bir iş sayılmaz.

Apple tarafında çökme verisini Xcode içindeki Organizer penceresinden izlersiniz. Apple'ın çökme raporları belgesine göre bu ekran, tanılama verisi paylaşmayı kabul eden kullanıcıların raporlarını gösterir. TestFlight test kullanıcıları ise cihaz ayarından bağımsız olarak çökme raporlarını sizinle paylaşır.

Kullanıcının algıladığı çökme oranı nasıl hesaplanıyor?

Google'ın çökme sayfası, kullanıcının algıladığı çökme oranını şöyle tanımlar: günlük aktif kullanıcılarınızdan, uygulamayı aktif kullanırken en az bir çökme yaşayanların yüzdesi. Uygulama bir ekran gösteriyorsa ya da ön planda bir hizmet çalıştırıyorsa aktif kullanımda sayılır.

Burada "günlük aktif kullanıcı" tanımı önemlidir. Bir kişi aynı gün iki cihazda uygulamanızı açarsa her cihaz ayrı kullanıcı sayılır. Buna karşılık aynı cihazı birden çok kişi kullanırsa o cihaz tek aktif kullanıcıdır.

Ayrıca Android vitals oranı oturum başına değil, günlük aktif kullanıcı başına hesaplar. Google'ın verdiği örnek açıklayıcıdır: bir kullanıcı gün içinde üç oturum açar ve birinde çökme yaşarsa Android vitals bunu yüzde 100 gösterir, oturum bazlı bir araç ise yüzde 33 gösterebilir.

Örnek hesap: Bir günde 20.000 cihazda aktif kullanılan bir uygulama düşünün. Bunlardan 160 cihazda kullanıcı en az bir çökme yaşadıysa o günün oranı 160 / 20.000 = %0,8 olur. Bu değer genel eşiğin altındadır. Ancak bu çökmelerin 120'si toplam 1.000 aktif kullanıcısı olan tek bir telefon modelinde yaşandıysa o modeldeki oran %12 olur ve uygulamanız cihaz başına eşiği aşar.

Bu örnek, yalnız genel ortalamaya bakmanın neden yetmediğini gösterir. Bu yüzden Play Console'daki cihaz kırılımını her hafta açmanızı öneriyoruz.

Crashlytics nedir ve ne işe yarar?

Firebase Crashlytics, Google'ın Firebase platformundaki gerçek zamanlı çökme raporlama aracıdır. Firebase belgelerine göre iOS, Android, Android NDK, Flutter ve Unity projelerini destekler. Uygulamanız çöktüğünde yığın izini (stack trace, hatanın oluştuğu kod satırlarının listesi) ve cihaz bilgisini sunucuya gönderir.

Crashlytics'in en büyük katkısı gruplamadır. Aynı hatadan doğan binlerce çökmeyi tek bir "sorun" (issue) altında toplar; yığın izi çerçevelerine, hata mesajlarına ve hata kodlarına bakar. Böylece binlerce satır yerine birkaç düzine sorunla uğraşırsınız.

• Gerçek zamanlı uyarılar: Yeni, geri dönen ve büyüyen sorunlar için bildirim alırsınız.
• Varyantlar: Aynı sorun içinde farklı kök nedenleri ayırt etmenizi sağlar.
• Ölümcül olmayan hatalar: Uygulamayı kapatmayan ama işlemi bozan hataları da kaydedebilirsiniz.
• Özel anahtarlar ve loglar: Çökmeden önce uygulamanın hangi durumda olduğunu raporlara eklersiniz.

Android vitals ile Crashlytics birbirinin rakibi değildir. Android vitals mağazanın sizi nasıl gördüğünü söyler; Crashlytics ise hatayı bulup düzeltmeniz için ayrıntı verir. Üstelik Crashlytics iOS tarafında da aynı paneli sunduğu için iki platformu tek yerden izlersiniz.

Crashlytics kurulumu için hangi adımlar gerekiyor?

Kurulumun teknik ayrıntısı kullandığınız teknolojiye göre değişir; yerel Android, iOS, Flutter ya da React Native projelerinde adımlar farklılaşır. Yine de genel akış her projede benzerdir:

1. Firebase konsolunda proje oluşturun ve Android ile iOS uygulamalarınızı bu projeye kaydedin.
2. Platformun yapılandırma dosyasını projeye ekleyin ve Crashlytics paketini bağımlılıklara dahil edin.
3. Derleme sırasında sembol dosyalarının (Android'de eşleme dosyası, iOS'ta dSYM) otomatik yüklenmesini ayarlayın.
4. Test sürümünde bilinçli bir test çökmesi tetikleyin ve raporun panele düştüğünü doğrulayın.
5. Gizlilik metninizi ve veri toplama tercihlerinizi güncelleyin; gerekiyorsa kullanıcı onayına bağlı raporlamayı açın.
6. Uyarıları ekibinizin gerçekten baktığı bir kanala yönlendirin.

Dördüncü adımı atlamayın. Pek çok ekip kurulumu bitti sanar, ama sembol dosyaları eksik olduğu için ilk gerçek çökmede okunamayan bir yığın iziyle karşılaşır. Ayrıca yayın öncesi testin genel çerçevesi için yayın öncesi test süreci rehberimize bakabilirsiniz; mantık mobil için de geçerlidir.

Crash-free users ve crash-free sessions ne anlatır?

Crashlytics panelinde iki temel oran görürsünüz. Firebase'in çökmesiz metrikler sayfasına göre çökmesiz kullanıcı oranı, seçilen dönemde uygulamayı kullanan ama çökme yaşamayan kullanıcıların yüzdesidir. Çökmesiz oturum oranı ise çökmeyle bitmeyen oturumların yüzdesidir.

Firebase bu iki oranı ortalama olarak değil, dönem boyunca toplam olarak hesaplar. Bu nedenle farklı uzunluktaki dönemleri karşılaştırmamanızı belirtir; uzun dönemler genelde daha düşük değer verir. Örneğin 7 günlük değeri 30 günlük değerle kıyaslarsanız yanlış sonuca varabilirsiniz.

İki metrik daha dikkat ister. Birincisi, bu oranlar yalnız ölümcül hatalardan hesaplanır; paneli ölümcül olmayan hatalara ya da ANR'lere süzerseniz grafik boş kalır. İkincisi, kullanıcı onayına bağlı raporlamayı açarsanız veri yalnız onay veren kullanıcılardan gelir ve tablo genel kitleyi tam yansıtmayabilir.

Peki uygulama çökme oranı ile çökmesiz kullanıcı oranı aynı şey mi? Tam olarak değil. Android vitals günlük aktif kullanıcı ve aktif kullanım tanımıyla ölçer; Crashlytics ise kendi oturum ve kullanıcı tanımını kullanır. Bu yüzden iki paneldeki sayıların birebir tutmaması normaldir.

Android vitals, Crashlytics ve Xcode Organizer arasında ne fark var?

Üç araç farklı soruları yanıtlar. Hangisinin neye yaradığını bilmek, ekip içindeki "hangi sayıya bakıyoruz" tartışmasını bitirir. Aşağıdaki tablo, resmi belgelerdeki tanımlara dayanan bir özet karşılaştırmadır:

Pratikte üçünü birlikte kullanmanızı öneriyoruz. Android vitals sizi mağaza riskine karşı uyarır, Crashlytics hatanın nedenini gösterir, Organizer ise iOS tarafında Apple'ın kendi verisini sunar.

Hangi çökmeyi önce düzeltmelisiniz?

Her çökmeyi aynı anda düzeltemezsiniz; bu nedenle önceliklendirme şarttır. Google'ın Android vitals önerisi nettir: en çok kullanıcıyı etkileyen çökme ve ANR'leri önce düzeltin. Belirli cihazlarda kaliteyi artırmak için o cihazlardaki en büyük grupları ele alın. Her iki sorun da varsa önce genel olarak en büyük kümelere odaklanın.

Biz bu öneriye iş etkisini de ekliyoruz. Aynı sayıda kullanıcıyı etkileyen iki hatadan ödeme ekranındaki, ayarlar ekranındakinden her zaman önce gelir.

1. Etkilenen kullanıcı sayısı: Toplam çökme sayısına değil, kaç farklı kullanıcının etkilendiğine bakın.
2. Eşiğe yakınlık: Bir telefon modelinde cihaz başına eşiğe yaklaşan sorun, mağaza görünürlüğünü tehdit eder.
3. İş akışı kritikliği: Giriş, kayıt, sepet ve ödeme adımlarındaki çökmeleri öne alın.
4. Yeni mi, geri mi döndü: Son sürümle ortaya çıkan sorun genellikle son değişiklikle ilgilidir; bu yüzden genellikle hızlı çözersiniz.
5. Büyüme hızı: Sayısı her gün artan bir sorun, sabit duran büyük bir sorundan daha acil olabilir.

Bu sıralamayı her sürüm sonrası tekrar yapın. Böylece ekip sesi en yüksek çıkan hataya değil, gerçekten en çok zarar verene zaman ayırır.

Okunamayan yığın izi nasıl okunur hale gelir?

Derleme araçları yayın sürümlerinde kodu genellikle küçültür ve karıştırır. Android'de bu işlem sınıf ve metot adlarını kısa harflere çevirir; iOS'ta ise çökme raporu bellek adresleri içerir. Sonuç olarak, eşleme bilgisi olmadan yığın izi "a.b.c" gibi anlamsız satırlardan oluşur.

Çözüm, her derlemenin sembol dosyasını saklamak ve ilgili araca yüklemektir. Android tarafında eşleme dosyasını hem Play Console'a hem Crashlytics'e verirsiniz. iOS tarafında ise dSYM dosyası adresleri fonksiyon adlarına ve satır numaralarına çevirir.

• Sembol dosyasının yüklenmesini derleme hattına bağlayın; elle yüklemeye güvenmeyin.
• Her sürüm numarası için sembol dosyasını arşivleyin, çünkü eski bir sürümün çökmesi aylar sonra da gelebilir.
• Çapraz platform çatılarda (Flutter, React Native) yerel katmanın ve çatının kendi sembollerini ayrı ayrı kontrol edin.

Okunamayan yığın izi, ekibin saatlerini tahminle harcamasına yol açar. Dolayısıyla sembol yükleme adımını kurulum kontrol listesinin zorunlu maddesi yapın.

Özel anahtarlar, loglar ve kırıntı kayıtları neden önemli?

Yığın izi size hatanın nerede olduğunu söyler, ama nedenini her zaman söylemez. Firebase'in rapor özelleştirme belgesine göre Crashlytics'e özel anahtarlar (key-value), özel log mesajları ve kullanıcı tanımlayıcısı ekleyebilirsiniz. Ayrıca kırıntı kayıtları (breadcrumb) çökmeye giden kullanıcı etkileşimlerini gösterir.

Örneğin "seçili dil", "sepetteki ürün sayısı" ya da "aktif ödeme yöntemi" gibi anahtarlar, hatanın yalnız belirli koşulda çıktığını hemen fark ettirir. Böylece sorunu yeniden üretmek dakikalara iner.

Ancak burada gizlilik sınırına dikkat edin. Raporlara ad, telefon, e-posta ya da kart bilgisi gibi kişisel veri yazmayın. Kullanıcı tanımlayıcısı gerekiyorsa sizin sisteminizdeki anonim bir kimliği kullanın. Ayrıca veri toplama tercihlerini gizlilik metninizle ve mağaza gizlilik formlarıyla uyumlu tutun. Bu konu hukuki danışmanlık değildir; kişisel veri süreçlerinizi hukuk danışmanınızla birlikte değerlendirin.

Son olarak, sunucu tarafındaki hataları da hesaba katın. Uygulamanın çöktüğü pek çok durumda asıl neden beklenmeyen biçimde dönen bir sunucu yanıtıdır; bu bağlantının mantığını API nedir yazımızda anlattık.

En sık çökme nedenleri nelerdir?

Her projenin kendi hata profili olsa da bizim sahada en sık gördüğümüz başlıklar benzerdir. Aşağıdaki liste kesin bir istatistik değil, saha tecrübesine dayalı bir kontrol başlangıcıdır:

• Boş veya beklenmeyen veri: Sunucudan eksik alan gelir ve kod bunu hiç beklemediği için kapanır.
• Bellek baskısı: Büyük görselleri küçültmeden yüklemek, düşük bellekli cihazlarda uygulamayı sonlandırır.
• Yaşam döngüsü hataları: Kullanıcı ekranı kapattıktan sonra geç gelen bir yanıt, artık var olmayan ekranı güncellemeye çalışır.
• İzin ve sürüm farkları: Yeni bir işletim sistemi sürümünde değişen izin davranışı eski kodu bozar.
• Üçüncü taraf kütüphaneler: Güncellenmemiş bir SDK, yeni sistem sürümüyle uyumsuz kalır.
• Cihaz parçalanması: Belirli üreticinin yazılım katmanı, yalnız o modellerde çökmeye yol açar.

Son madde, cihaz başına eşiğin neden önemli olduğunu açıklar. Özellikle Android'de yüzlerce farklı model olduğu için test cihaz listenizi kullanıcılarınızın gerçek dağılımına göre seçin.

ANR oranını düşürmek için ne yapmalısınız?

Google'ın ANR sayfasına göre şu an kullanıcının algıladığı ANR olarak yalnız "Input dispatching timed out" türü sayılır. Yani uygulama kullanıcının dokunuşuna zamanında yanıt veremediğinde bu metrik artar. Bu tür ANR'ler her zaman kullanıcı uygulamayla etkileşimdeyken yaşanır ve en çok rahatsızlığı verir.

ANR'nin ortak noktası, ana iş parçacığının uzun süre meşgul kalmasıdır. Bu nedenle ilk bakacağınız yer, ekran çizimi dışındaki işlerin ana iş parçacığında yapılıp yapılmadığıdır.

• Ağ isteklerini ve dosya okuma yazmayı arka plan iş parçacıklarına taşıyın.
• Uygulama açılışında yaptığınız işleri azaltın; zorunlu olmayanları erteleyin.
• Büyük listeleri ve görselleri parça parça yükleyin.
• Kilit beklemesine yol açan paylaşılan kaynakları gözden geçirin.

Önbellekleme de ANR riskini azaltır, çünkü aynı veriyi her seferinde yeniden hesaplamazsınız. Kavramın sunucu tarafındaki karşılığını önbellekleme rehberimizde bulabilirsiniz.

Aşamalı yayın çökme riskini nasıl azaltır?

Aşamalı yayın, yeni sürümü önce kullanıcıların küçük bir kısmına açmanız demektir. Google Play'de bu yöntemin adı staged rollout, App Store Connect'te ise phased release olarak geçer. Böylece yeni sürümdeki bir çökme tüm kullanıcılarınıza değil, yalnız küçük bir gruba ulaşır.

Yöntemin değeri, karar noktası koymasındadır. Yeni sürüm küçük grupta çalışırken Crashlytics'te yeni sorunlara ve çökmesiz kullanıcı oranındaki değişime bakarsınız. Oran beklenenden kötüyse yayını durdurur, düzeltmeyi hazırlar ve sonra devam edersiniz.

Örnek senaryo: Bir e-ticaret uygulaması yeni ödeme ekranını aşamalı yayınla açar. İlk günde Crashlytics, belirli bir Android sürümünde ödeme ekranında yeni bir sorun gösterir. Ekip yayını durdurur, düzeltmeyi bir sonraki sürüme alır. Böylece sorun kullanıcıların büyük kısmına ulaşmadan kapanır ve 28 günlük ortalama ciddi etkilenmez.

Ayrıca yeni sürümü yayına almadan önce iç test kanallarını kullanın. Test otomasyonunun bu süreçteki yerini test otomasyon mühendisi yazımızda anlattık.

Çapraz platform uygulamalarda çökme takibi farklı mı?

Flutter ya da React Native ile yazılan uygulamalarda iki katman vardır: çatının kendi kodu ve altta çalışan yerel Android ile iOS katmanı. Bu nedenle bir çökme iki farklı yerden gelebilir. Crashlytics resmi olarak Flutter'ı destekler; yine de her katmandaki hata yakalama ayarını ayrı ayrı kontrol etmeniz gerekir.

Örneğin Dart ya da JavaScript katmanında yakalanmayan bir hata, uygulamayı kapatmadan boş bir ekran bırakabilir. Kullanıcı bunu çökme gibi yaşar, ama mağaza metrikleri bunu çökme olarak görmeyebilir. Dolayısıyla çatı katmanındaki hataları ölümcül olmayan hata olarak raporlamanızı öneriyoruz.

Ayrıca çatı sürümünü güncellerken yerel bağımlılıkların da değiştiğini unutmayın. Sürüm yükseltmesinden sonraki ilk yayını mutlaka aşamalı yayınla açın ve cihaz kırılımını yakından izleyin.

Yayın sonrası izleme kontrol listesi

Yeni sürüm mağazaya çıktıktan sonraki ilk günler, uygulama çökme oranı açısından en kritik dönemdir. Aşağıdaki listeyi her sürümde tekrar kullanabilirsiniz:

1. İlk saatler: Crashlytics'te yeni sürüme ait sorunları ve uyarıları kontrol edin.
2. Birinci gün: Çökmesiz kullanıcı oranını bir önceki sürümle aynı uzunlukta dönem üzerinden karşılaştırın.
3. İlk üç gün: Android vitals'ta cihaz kırılımına bakın; tek bir modelde yükselen oran var mı, inceleyin.
4. Yedinci gün: Ölümcül olmayan hataları ve ANR listesini gözden geçirin.
5. Her hafta: Mağaza yorumlarını okuyun; "kapanıyor", "donuyor" gibi şikâyetleri çökme listesiyle eşleştirin.
6. Ayda bir: Üçüncü taraf SDK sürümlerini ve hedef işletim sistemi değişikliklerini kontrol edin.
7. Her sürümde: Sembol dosyalarının yüklendiğini doğrulayın.

Bu liste uzun görünse de alışkanlık haline geldiğinde haftada kısa bir kontrol toplantısına sığar. Önemli olan, sorumluluğun bir kişiye net biçimde verilmesidir.

Ek olarak her kontrolün sonucunu kısa bir notla kaydedin. Örneğin "sürüm 3.2, birinci gün, yeni sorun yok" gibi tek satırlık bir kayıt bile, aylar sonra bir gerilemenin ne zaman başladığını bulmanızı kolaylaştırır.

Çökme oranı mağaza yorumlarını ve kaldırma riskini nasıl etkiler?

Çöken bir uygulama genelde önce yorumlarda kendini belli eder. Kullanıcılar "açılmıyor" ya da "ödeme sırasında kapanıyor" diye yazar ve puan düşer. Düşük puan da mağazadaki dönüşüm oranını aşağı çeker; yani çökme dolaylı olarak indirme kaybına da yol açar.

Öte yandan çökme her zaman doğrudan kaldırma sebebi değildir. Google Play'de kaldırmalar çoğunlukla politika ihlalleriyle ilgilidir; bu sürecin nasıl işlediğini Google Play uygulama kaldırıldı yazımızda anlattık. Ancak Apple yönergeleri, çalışmayı bırakan uygulamaların mağazadan kaldırılabileceğini açıkça belirtir.

Kısacası çökme oranını yalnız teknik ekip metriği olarak görmeyin. Pazarlama ekibiniz reklam bütçesi harcarken uygulama çökerse, reklamdan gelen kullanıcı da ilk oturumda kaybolur.

Uygulama çökme oranı hedefi ne olmalı?

Bu sorunun herkese uyan tek bir cevabı yoktur. Mağazanın yayımladığı eşik bir alt sınırdır; hedef değil. Eşiğin hemen altında kalan bir uygulama, mağaza cezasından kaçar ama kullanıcılarının bir kısmını yine de her gün kaybeder.

Biz hedefi mutlak bir rakamla değil, eğilimle belirlemeyi öneriyoruz. Her sürümün çökmesiz kullanıcı oranı bir öncekinden kötü olmamalı; ayrıca hiçbir telefon modeli cihaz başına eşiğe yaklaşmamalı. Bu yaklaşım, sektör ortalaması gibi kaynağı belirsiz sayılara yaslanmaktan daha sağlıklıdır.

Kendi uygulamanız için bir başlangıç çizgisi çekin: son üç sürümün değerlerini kaydedin ve yeni sürümü bu çizgiyle karşılaştırın. Bu çizgiden belirgin sapma, yayını durdurmak için yeterli bir sinyaldir.

Uygulama çökme oranı sorununda ne zaman profesyonel destek almalısınız?

Ekibinizde mobil geliştirici yoksa, uygulamayı başka bir firma geliştirip teslim ettiyse ya da Android vitals uyarısı haftalardır kalkmıyorsa dışarıdan destek mantıklı hale gelir. Ayrıca sembol dosyaları kaybolmuş, kaynak koda erişim sınırlı ya da çapraz platform katmanı karmaşıksa teşhis uzar.

Biz mobil uygulama geliştirme hizmetimizde uygulamanızı geliştirir, mağazaya biz çıkarırız; Crashlytics kurulumunu, sembol yükleme hattını ve yayın sonrası izleme düzenini de işin parçası olarak kurarız. Mevcut bir uygulamanın kararlılık sorununu da aynı çerçevede ele alırız.

Mağaza reddi ya da kaldırma gibi farklı bir sorunla karşılaşıyorsanız Guideline 4.3 spam reddi yazımız da yol gösterebilir. Uygulamanızın kararlılığını ve yayın sürecini birlikte ele almak isterseniz mobil uygulama hizmet sayfamızdan teklif alabilirsiniz. Teklifte mevcut durumu, hedef platformları ve yayın takvimini netleştiririz.