Yayından Sonra Mobil Uygulama: Bakım, Sürüm ve İzleme

Bir mobil uygulama yayına girdiği gün tamamlanmış olmaz; işletim sistemi güncellemelerine, mağaza kurallarına ve kullanıcı davranışına göre düzenli bakım, planlı sürümler ve sürekli izleme ister. Bu işlerin ihmal edildiği uygulamalar birkaç ay içinde yavaşlar, beklenmedik yerlerde çöker ve sonunda mağazalara güncelleme bile gönderemez hâle gelir.

Mobil uygulama geliştirme projelerimizde yayından sonraki dönemi en baştan planın bir parçası olarak kurguluyoruz.

Yayından sonra bir mobil uygulamayı neler etkiler?

Uygulamanızın koduna siz dokunmasanız da üzerinde çalıştığı zemin sürekli değişir. Bakım ihtiyacını doğuran başlıca etkenler şunlardır:

• İşletim sistemi sürümleri: Apple ve Google her yıl iOS ve Android'in yeni bir ana sürümünü yayımlar. Yeni sürümler izin modelini, arka planda çalışma kurallarını ve ekran davranışlarını değiştirebilir; eski API'ler kullanımdan kaldırılabilir.
• SDK ve bağımlılıklar: React Native, Firebase, ödeme, harita ve analitik kütüphaneleri düzenli olarak güncellenir. Güvenlik yamaları çoğu zaman yalnızca yeni sürümlerle gelir.
• Sunucu ve entegrasyonlar: Uygulamanın konuştuğu API, ödeme altyapısı ya da üçüncü taraf servisler değiştiğinde uygulama tarafında da uyarlama gerekir.
• Sertifikalar ve hesaplar: Dağıtım sertifikalarının ve profillerin süresi dolar. Apple Developer Program üyeliği her yıl yenilenmelidir; üyelik sona ererse uygulamanız App Store'dan kalkar.

Yeni iOS ve Android sürümlerini daha beta aşamasındayken uygulamanızla test edin; sorunları kullanıcılarınızdan önce görmüş olursunuz.

Mağaza kuralları değiştiğinde ne yapmanız gerekir?

App Store ve Google Play kurallarını düzenli olarak günceller ve bu değişiklikleri çoğu zaman bir son tarihle birlikte duyurur. O tarihe hazır olmayan bir uygulama güncelleme gönderemeyebilir ya da yeni kullanıcılara görünmez hâle gelebilir.

• Hedef API seviyesi: Google Play, yeni uygulamaların ve güncellemelerin güncel bir Android API seviyesini hedeflemesini şart koşar ve bu eşiği her yıl yükseltir. Eşiğin gerisinde kalan uygulamalar, yeni Android sürümlerini kullanan yeni kullanıcılara gösterilmez.
• Asgari Xcode ve SDK sürümü: Apple, belirli bir tarihten sonra gönderilen derlemelerin güncel Xcode ve SDK ile hazırlanmasını ister.
• Gizlilik beyanları: App Store'daki gizlilik bilgileri ve Google Play'deki Veri güvenliği formu, uygulamanın topladığı veriyle birebir örtüşmelidir. Yeni bir analitik ya da reklam SDK'sı eklediğinizde bu beyanları da güncelleyin.
• Hesap silme: Kullanıcının hesap oluşturabildiği uygulamalarda hesabı uygulama içinden silme imkânını her iki mağaza da şart koşar.

Play Console ve App Store Connect'ten gelen politika e-postalarını tek bir kişinin sorumluluğuna verin ve her uyarıyı son tarihiyle birlikte bakım planına ekleyin. İlk gönderim için App Store ve Google Play'de yayın süreci yazımıza göz atabilirsiniz.

Çökmeler ve performans nasıl izlenir?

Kullanıcılar bir çökmeyi genellikle size bildirmez; uygulamayı kapatır, bazen de siler. Bu yüzden izleme, şikâyete değil ölçüme dayanmalıdır.

Temel araçlar şunlardır: uygulamaya eklenen Firebase Crashlytics ya da Sentry gibi bir çökme raporlama aracı, Google Play Console'daki Android vitals ve Xcode Organizer. Takip etmeniz gereken ölçütler:

• Çökmesiz kullanıcı oranı: Belirli bir dönemde hiç çökme yaşamayan kullanıcıların payı; en temel sağlık göstergesidir.
• ANR oranı: ANR (Application Not Responding), Android'de uygulamanın uzun süre donup kalmasıdır. Kullanıcı bunu çökme gibi yaşar.
• Açılış süresi: Uygulamanın soğuk açılışta ilk ekranı ne kadar sürede gösterdiği.
• Takılan kareler: Kaydırma ve geçişlerde akıcılığı bozan yavaş ya da donmuş kareler.
• Ağ hataları ve API süreleri: Sorun çoğu zaman uygulamada değil, sunucuda ya da bağlantıdadır.

Her sürümde sembol dosyalarını (iOS'ta dSYM, Android'de R8 eşleme dosyası) izleme aracına yükleyin; aksi hâlde yığın izleri (stack trace) anlamsız bellek adreslerinden ibaret kalır. Google Play, aşırı çökme ve ANR oranlarını mağazadaki görünürlükte de dikkate alır. Bu yüzden eşik değerler için otomatik uyarı kurun ve her yeni sürümden sonra panoları yakından izleyin.

Yeni sürümler nasıl güvenle yayına alınır?

Web'de hatalı bir sürümü dakikalar içinde geri alabilirsiniz. Mobilde ise yayımlanan sürüm kullanıcıların cihazına iner; geri almak yerine düzeltilmiş yeni bir sürüm göndermeniz gerekir. Bu fark daha temkinli bir süreç ister:

1. Düzenli bir ritim belirleyin. Belirli aralıklarla çıkan küçük sürümler, aylarca biriken büyük sürümlerden daha az risk taşır.
2. Önce içeride test edin. iOS'ta TestFlight, Android'de Play Console'un dahili test kanalıyla her derlemeyi önce ekibinize ve seçili kullanıcılara dağıtın.
3. Aşamalı yayın kullanın. Google Play'de sürümü kullanıcıların küçük bir yüzdesine açıp sorun yoksa kademeli olarak artırabilir, gerekirse dağıtımı durdurabilirsiniz. App Store'daki aşamalı yayın (phased release) da otomatik güncellemeleri yedi güne yayar ve gerektiğinde duraklatılabilir.
4. Özellik bayrakları kurun. Uzaktan yapılandırma (remote config) ile sorunlu bir özelliği yeni sürüm göndermeden ve mağaza incelemesini beklemeden kapatabilirsiniz.
5. Sunucuyu geriye uyumlu tutun. Kullanıcıların bir kısmı aylarca eski sürümde kalır; API'de yapılan hiçbir değişiklik hâlâ kullanımda olan bir sürümü bozmamalıdır.

Derleme, test ve mağazaya gönderme adımlarını otomatikleştirmek bu süreci hem hızlandırır hem de elle yapılan hataları azaltır. Yaklaşımımızı Dramsız DevOps yazımızda anlattık.

Zorunlu güncelleme ne zaman gerekir?

Zorunlu güncelleme, eski bir sürümü kullanan kişinin uygulamayı güncellemeden devam edememesidir. Güçlü bir araçtır; bu yüzden şu gibi durumlara saklayın:

• Eski sürümde kullanıcı verisini riske atan bir güvenlik açığı varsa.
• Sunucu tarafındaki zorunlu bir değişiklik eski sürümlerle çalışamıyorsa.
• Yasal ya da sözleşmesel bir gereklilik eski davranışın sürmesine izin vermiyorsa.

Mekanizmayı ilk sürümden kurun; sonradan eklenen bir kontrol, zaten dağıtılmış eski sürümlere ulaşmaz. Yaygın yöntem, uygulamanın açılışta sunucudan desteklenen en düşük sürüm bilgisini okuması ve buna göre ya kapatılabilir bir öneri ya da engelleyici bir güncelleme ekranı göstermesidir. Android'de Google Play'in uygulama içi güncelleme (In-App Updates) arayüzü bu akışı destekler; iOS'ta kullanıcı App Store sayfasına yönlendirilir. Engelleyici ekranı nadiren kullanın, mesajı sade tutun ve bu ekranın diğer servisler çalışmasa bile açıldığından emin olun.

Anlık bildirimler kullanıcıyı yormadan nasıl yönetilir?

Anlık bildirim (push notification), uygulama açık değilken kullanıcıya ulaşan kısa mesajdır. Doğru kullanıldığında en değerli kanalınızdır; kötü kullanıldığında bildirim izninin kapatılmasına, hatta uygulamanın silinmesine yol açar. Bildirim hijyeni için şu kurallar işe yarar:

• İzni bağlamında isteyin: iOS'ta ve Android 13 ile sonrasında bildirim göndermek için kullanıcı izni gerekir. İzni ilk açılışta değil, kullanıcının faydasını göreceği anda isteyin.
• Türleri ayırın: İşlem bildirimlerini (ödeme, randevu, durum değişikliği) pazarlama mesajlarından ayırın. Android'deki bildirim kanalları, kullanıcının yalnızca istemediği türü kapatmasını sağlar.
• Sıklığı sınırlayın: Kişi başına bir üst sınır ve sessiz saatler belirleyin.
• Doğru ekrana götürün: Her bildirim, derin bağlantı (deep link) ile ilgili ekranı açmalıdır.
• Cihaz kimliklerini temizleyin: Geçersiz bildirim token'larını düzenli olarak silin; ölü kayıtlara gönderim yapmak hem kaynak israfıdır hem de ölçümleri bozar.

Kemerköy Sitesi için geliştirdiğimiz React Native sakin uygulamasında bildirimler Firebase üzerinden şablonlu, çevirili ve daireye özel gönderiliyor.

Analitik ve kullanıcı desteği bakımın neresinde durur?

İzleme uygulamanın ne kadar sağlıklı olduğunu, analitik ise nasıl kullanıldığını gösterir. İyi bir kurgu her olayı değil, cevaplamak istediğiniz soruları ölçer: Kullanıcılar kayıt akışının hangi adımında vazgeçiyor, hangi özellik hiç kullanılmıyor, ilk haftadan sonra kaç kişi geri dönüyor?

• Olay planını her sürümle birlikte belgeleyin; adı değişen bir olay geçmiş raporları bozar.
• KVKK kapsamındaki aydınlatma ve gerektiğinde açık rıza süreçlerini analitik kurulumuyla birlikte tasarlayın. iOS'ta kullanıcıyı başka şirketlerin uygulamaları arasında takip etmek için App Tracking Transparency izni gerekir.
• Uygulama içi geri bildirim formu sürüm numarasını, cihaz modelini ve işletim sistemi sürümünü otomatik eklesin; destek ekibi sorunu ilk mesajdan yeniden üretebilsin.
• Mağaza yorumlarını düzenli okuyun ve yanıtlayın; tekrarlayan şikâyetleri iş listesine taşıyın.

Destek, izleme ve analitikten gelen bulgular tek bir iş listesinde birleştiğinde bir sonraki sürümün önceliği kendiliğinden netleşir.

Bir mobil uygulama yayına girdiği gün bitmez; o gün kullanıcılarıyla birlikte yaşamaya başlar.

Sık sorulan sorular

Mobil uygulama ne sıklıkla güncellenmelidir?

Herkes için geçerli tek bir sıklık yoktur. Düzenli aralıklarla küçük sürümler çıkarmak, acil düzeltmeleri bu ritmin dışında yayımlamak ve uygulamayı her yeni iOS ve Android ana sürümüne karşı test etmek sağlıklı bir başlangıçtır.

Uygulamayı hiç güncellemezsek ne olur?

Uygulama bir süre çalışmaya devam eder, ancak yeni işletim sistemlerinde hatalar artar, bağımlılıklardaki güvenlik açıkları kapanmaz ve mağaza şartları karşılanamaz. Sonunda yeni kullanıcılara görünmeyen, hatta mağazadan kaldırılan bir uygulamayla karşılaşabilirsiniz.

Bakım için ayrı bir ekip kurmak gerekir mi?

Her zaman gerekmez. Gereken şey net bir sorumlu, kurulu bir izleme düzeni ve tekrarlanabilir bir sürüm sürecidir. Bu işi kendi ekibiniz de, uygulamayı geliştiren iş ortağınız da üstlenebilir; yeter ki kimin neyi ne zaman yapacağı yazılı olsun.

Çökme raporlama araçları kişisel veri toplar mı?

Bu araçlar cihaz, işletim sistemi ve hata bilgisi toplar; yapılandırmaya göre kullanıcı kimliği de ekleyebilir. Kayıtlara kişisel veri yazmayın ve toplanan veriyi mağaza gizlilik beyanlarında ve KVKK aydınlatma metninde doğru anlatın.

Nereden başlamalı?

Yayında bir uygulamanız varsa kısa bir sağlık kontrolüyle başlayın: Hedef API seviyesi ve SDK sürümleri güncel mi, Play Console ya da App Store Connect'te bekleyen bir politika uyarısı var mı, çökme panosunu düzenli izleyen biri var mı, zorunlu güncelleme mekanizması kurulu mu? Bu dört sorunun cevabı, bakım planınızın ilk sayfasını oluşturur.

Uygulamanızın bakımını ve sürüm sürecini birlikte planlamak isterseniz bizimle iletişime geçin.