Zorunlu Uygulama Güncellemesi (Force Update) Nasıl Yapılır?

Bu mekanizma bir cezalandırma aracı değildir. Aksine, eski sürümün artık güvenli ya da çalışır olmadığı durumlarda kullanıcıyı korur. Örneğin ödeme altyapınızı değiştirdiyseniz eski sürüm yeni sunucuyla konuşamaz ve kullanıcı yarım kalan işlemlerle karşılaşır. Zorunlu uygulama güncellemesi bu kırılmayı kontrollü bir ekrana çevirir.

Talha Aslan ve ekibi olarak mobil projelerde bu konuyu ilk sürümden önce planlamayı öneriyoruz. Çünkü sürüm kontrolü uygulamanın içinde yoksa, sonradan eklemek için de bir güncelleme yayınlamanız gerekir. Bu rehberde şu soruları sırayla cevaplıyoruz:

• Zorlamak ne zaman gerçekten gerekir, ne zaman yumuşak bir hatırlatma yeterlidir?
• Android'de Google Play'in resmi uygulama içi güncelleme akışı nasıl çalışır?
• iOS tarafında hazır bir akış olmadığında nasıl bir yol izlersiniz?
• Kullanıcıyı kızdırmadan mesajı nasıl yazarsınız ve sonucu nasıl ölçersiniz?

Zorunlu uygulama güncellemesi ne zaman gerekir?

Zorlamak, son çare olmalıdır. Kullanıcının elinden uygulamayı birkaç dakikalığına almak, ancak eski sürümü açık bırakmanın daha büyük zarar doğuracağı durumlarda anlamlıdır. Saha tecrübemizde zorlamayı haklı çıkaran durumlar genellikle şu başlıklarda birleşir:

• Güvenlik açığı: Eski sürümde kullanıcı verisini riske atan bir hata varsa, o sürümün çalışmaya devam etmesi kabul edilemez.
• Geriye uyumsuz API değişikliği: Sunucu tarafında eski istek biçimini artık desteklemiyorsanız eski sürüm hata vermeye başlar.
• Ödeme ya da kimlik doğrulama değişikliği: Ödeme sağlayıcısı veya giriş yöntemi değiştiğinde eski akış yarım işlem üretir.
• Yasal ya da politika zorunluluğu: Mağaza politikası veya mevzuat yeni bir onay ekranı gerektiriyorsa eski sürüm bu şartı karşılamaz.
• Veri bozulması riski: Eski sürüm yeni veri yapısını yanlış yazıyorsa her kullanım sorunu büyütür.

Öte yandan yeni bir özellik, tasarım yenilemesi ya da küçük bir hata düzeltmesi zorlamayı haklı çıkarmaz. Bu durumlarda yumuşak bir hatırlatma yeterlidir. Kısacası soru şudur: kullanıcı eski sürümde kalırsa ona ya da size somut bir zarar doğar mı? Cevap hayırsa zorlamayın.

Yumuşak güncelleme ile zorunlu güncelleme arasındaki fark nedir?

Yumuşak güncelleme (soft update), kullanıcıya yeni sürümü önerir ama uygulamayı kullanmaya devam etmesine izin verir. Zorunlu güncelleme ise kullanıcı güncellemeden ana akışa geçmesine izin vermez. İkisi aynı sürüm kontrolü altyapısını kullanır; fark yalnızca kullanıcıya bırakılan seçimdedir. Aşağıdaki tablo farkı karar verirken bakacağınız eksenlerle özetliyor:

Sağlıklı bir yapı ikisini birlikte kullanır. Önce yumuşak hatırlatma ile kullanıcıların çoğunu yeni sürüme taşırsınız, ardından gerçekten gerekiyorsa kalan küçük grup için eşiği yükseltirsiniz.

Sunucu tarafı sürüm kontrolü nasıl çalışır?

Sunucu tarafı sürüm kontrolü, hangi sürümlerin kabul edildiği bilgisinin uygulamanın içine gömülmeden uzaktan yönetilmesidir. Uygulama açılışta küçük bir yapılandırma okur, kendi sürüm numarasını bu değerlerle karşılaştırır ve sonuca göre hiçbir şey göstermez, hatırlatma gösterir ya da güncelleme ekranını açar.

Bu yapılandırmayı kendi API'nizden ya da bir uzaktan yapılandırma servisinden okuyabilirsiniz. Örneğin Firebase Remote Config belgeleri, kullanım örnekleri arasında en düşük uygulama sürümünü zorunlu kılmayı açıkça sayar ve değerleri uygulama sürümüne göre koşullandırmaya izin verir. API kavramına yeniyseniz API nedir rehberimiz temeli anlatıyor.

Tipik bir yapılandırma üç değer içerir:

1. En düşük desteklenen sürüm: Bunun altındaki sürümler zorunlu güncelleme ekranını görür.
2. Önerilen sürüm: Bunun altındaki sürümler yumuşak hatırlatma görür.
3. Mesaj ve bağlantı: Ekranda çıkacak metin ve mağaza adresi, dile ve platforma göre ayrı durur.

Böylece yeni bir uygulama sürümü yayınlamadan, yalnızca yapılandırmayı değiştirerek eşiği yükseltebilir ya da hatalı bir kararı geri alabilirsiniz.

Minimum sürümü ve önerilen sürümü nasıl belirlersiniz?

Eşiği belirlerken tahmine değil, veriye bakmalısınız. İlk olarak analitik aracınızda aktif kullanıcıların sürümlere göre dağılımını çıkarın. Ardından her eski sürümün hangi sunucu uç noktalarını kullandığını ve hangilerinin yakında kapanacağını listeleyin. Eşik, kapanacak uç noktaya bağımlı olan en yeni sürümün bir üstü olur.

Önerilen sürüm ise genellikle mağazadaki güncel sürümdür. Ancak yeni sürümü yayınladığınız gün herkese hatırlatma göstermek iyi bir fikir değildir. Mağazalar yeni sürümü kademeli dağıtabilir; dolayısıyla bazı kullanıcılar mağazaya gittiğinde güncellemeyi henüz göremeyebilir. Bu yüzden hatırlatmayı yayından birkaç gün sonra açmak daha sağlıklıdır.

Sürüm numarasını karşılaştırırken de dikkatli olun. "1.10.0" ile "1.9.0" metin olarak karşılaştırılırsa yanlış sonuç verir. Bu nedenle sürümü parçalara ayırıp sayı olarak karşılaştırın ya da Android'deki sürüm kodu gibi tek bir artan tamsayı kullanın. iOS'ta ise derleme numarasını ayrı takip edin. Kısacası karşılaştırma mantığını tek bir yerde yazın ve test edin, çünkü bu satırdaki tek bir hata tüm kullanıcıları kilitleyebilir.

Android'de Google Play uygulama içi güncellemeler nasıl çalışır?

Google Play, Android tarafında bu iş için resmi bir özellik sunar: uygulama içi güncellemeler (in-app updates). Android geliştirici belgelerine göre bu özellik, Google Play Core kitaplıklarının bir parçasıdır ve arka plan güncellemelerini açmamış aktif kullanıcılara güncellemeyi uygulamanın içinden hatırlatır.

Belge iki akış tanımlar. Esnek (flexible) akışta güncelleme arka planda iner ve kullanıcı bu sırada uygulamayı kullanmaya devam eder. Anında (immediate) akışta ise tam ekran bir arayüz açılır; kullanıcı güncellemeyi kabul ettiğinde kurulumu ve uygulamanın yeniden başlatılmasını Google Play üstlenir. Belge, anında akışı uygulamanın temel işlevi için kritik olan güncellemelere uygun görür.

Bazı sınırları baştan bilmeniz gerekir:

• Belge, özelliğin belirli bir minimum Android sürümünden itibaren desteklendiğini belirtir; güncel değeri resmi sayfadan kontrol edin.
• Özellik Android telefonları, tabletleri ve ChromeOS cihazları kapsar.
• APK genişletme dosyaları (.obb) kullanan uygulamalarla uyumlu değildir.
• Test belgesine göre güncelleme yalnızca uygulamaya Google Play üzerinden sahip olan hesaplarda görünür.

Bu son madde önemlidir. Uygulamayı başka bir kaynaktan yüklemiş kişiler bu akışı görmez; dolayısıyla sunucu tarafı kontrolü her durumda yedek olarak tutmanız gerekir.

Esnek ve anında akışı hangi durumda seçmelisiniz?

Seçimi güncellemenin aciliyetine göre yapmalısınız; ama bunu tek bir kurala bağlamak yerine iki sinyali birlikte okumak daha iyi sonuç verir. Android belgesi, uygulamanın güncellemenin uygun olup olmadığını ve hangi türün izinli olduğunu sorgulayabildiğini anlatır. Sonuca göre esnek ya da anında akışı başlatırsınız.

Esnek akışta dikkat etmeniz gereken nokta şudur: güncelleme indikten sonra Google Play uygulamayı kendiliğinden yeniden başlatmaz. Uygulama indirme durumunu dinler, iş bitince kullanıcıya "yeniden başlat" seçeneği sunar ve kurulumu tamamlatır. Belge ayrıca uygulama her ön plana geldiğinde inmiş ama kurulmamış bir güncelleme olup olmadığını kontrol etmenizi önerir; aksi halde indirilen veri cihazda yer kaplamaya devam eder.

Anında akışta ise kullanıcı güncelleme sırasında uygulamayı kapatabilir. Belgeye göre güncelleme arka planda sürer ve uygulama yeniden açıldığında yarım kalan akışı devam ettirmeniz gerekir. Kullanıcı güncellemeyi reddederse belge, kullanıcının devam etmesine izin verip daha sonra yeniden sormayı önerir. Uygulama güncelleme olmadan çalışamıyorsa, önce durumu anlatan bilgilendirici bir mesaj göstermeniz gerekir. Yani anında akış bile, sunucu tarafındaki kesin kilidin yerini tek başına tutmaz.

Güncelleme önceliğini ve bekleme gününü nasıl kullanırsınız?

Google Play iki yardımcı sinyal sunar: güncelleme önceliği ve güncellemenin ne kadar süredir beklediği. Kotlin ve Java uygulama belgesine göre öncelik, sıfır ile beş arasında bir tamsayıdır; sıfır varsayılan, beş en yüksek önceliktir. Önceliği Play Console arayüzünden değil, Google Play Developer API ile yeni bir sürümü yayına alırken belirlersiniz. Belge, bu değerin sonradan değiştirilemeyeceğini de not eder.

İkinci sinyal, güncellemenin mağazada yayına çıktığı günden bu yana kaç gün geçtiğidir. Uygulama bu sayıyı okuyarak kademeli bir strateji kurabilir. Örnek senaryo:

1. Öncelik düşükse ve güncelleme birkaç gündür bekliyorsa esnek akışı başlatın.
2. Öncelik düşük ama güncelleme uzun süredir bekliyorsa hatırlatma sıklığını artırın.
3. Öncelik yüksekse anında akışı başlatın.
4. Sunucu yapılandırması en düşük sürümün altında olduğunu söylüyorsa, Play akışı ne derse desin kilit ekranını gösterin.

Burada gün sayıları sizin kararınızdır; belge yalnız yöntemi gösterir. Ayrıca öncelik, kurulu sürüm ile en güncel sürüm arasındaki tüm sürümlerin değerlerini hesaba katar. Bu nedenle bir güvenlik düzeltmesine yüksek öncelik verdiyseniz, sonraki sıradan sürümler bu önceliği silmez.

iOS'ta zorunlu uygulama güncellemesi nasıl yapılır?

iOS'ta Google Play'deki gibi uygulama içinden güncellemeyi indirip kuran hazır bir akış bulunmaz. Bu yüzden iOS'ta zorunlu uygulama güncellemesi, sunucu tarafı sürüm kontrolü ile App Store bağlantısının birleşimidir. Uygulama sürümünü kontrol eder, gerekiyorsa bir ekran gösterir ve kullanıcıyı App Store'daki ürün sayfasına gönderir; kurulumu App Store yapar.

Apple Destek sayfasına göre App Store'dan indirilen uygulamalar varsayılan olarak otomatik güncellenir, ancak kullanıcı bu ayarı kapatabilir ya da güncellemeleri elle yapabilir. Dolayısıyla kullanıcılarınızın çoğu yeni sürüme kendiliğinden geçse de, otomatik güncellemeyi kapatmış ya da uzun süredir uygulamayı açmamış bir grup her zaman eski sürümde kalır.

Bazı ekipler mağazadaki güncel sürümü Apple'ın arama ve sorgu hizmetinden okur. Bu yöntem çalışabilir; ancak Apple bu hizmet için bir istek sınırı belirtir ve mağazadaki sürüm, kademeli yayın sırasında herkese aynı anda ulaşmayabilir. Bu nedenle karar mantığını kendi yapılandırmanıza bağlamak daha güvenlidir. Mağaza sorgusunu yalnızca yardımcı bir bilgi olarak kullanın.

iOS ve Android'i tek kod tabanında geliştiriyorsanız sürüm kontrolünü ortak katmana yazmak mantıklıdır. Bu yaklaşımın genel çerçevesini React Native rehberimizde anlattık.

App Store kuralları zorunlu güncelleme hakkında ne diyor?

App Store İnceleme Yönergeleri güncellemeye zorlamayı açıkça yasaklayan bir madde içermez. Ancak bu işi yaparken dikkat etmeniz gereken birkaç madde vardır ve bunları bilmek, inceleme sürecinde sürpriz yaşamanızı önler.

• Kendi kendine yeterlilik: Yönergelere göre uygulama, özellikleri ya da işlevi ekleyen veya değiştiren kodu indirip çalıştıramaz. Yani "güncellemeyi uygulamanın içinden indirip kurma" yolu iOS'ta size açık değildir; güncelleme App Store üzerinden gelir.
• Yenilikler metni: Yönergeler, yeni özelliklerin ve ürün değişikliklerinin "Yenilikler" metninde açıkça anlatılmasını ister. Basit hata düzeltmeleri ve güvenlik güncellemeleri genel bir açıklamayla geçebilir.
• Mağaza eylemine zorlama: Yönergeler, uygulamaya erişim karşılığında puan vermeye, yorum yazmaya ya da başka uygulama indirmeye zorlamayı yasaklar. Güncelleme ekranınızı bir puanlama isteğiyle birleştirmeyin.
• Güncel kalma: Yönergeler, işlevini yitiren ya da bozuk deneyim sunan uygulamaların mağazadan kaldırılabileceğini belirtir.

Mağaza reddi ve kaldırma süreçlerinde ayrıntıya ihtiyacınız varsa App Store 4.3 spam reddi yazımıza ve Android tarafı için Google Play politika ihlali itiraz rehberimize göz atabilirsiniz.

Kullanıcıyı kızdırmadan güncelleme mesajını nasıl yazarsınız?

Güncelleme ekranındaki metin, kullanıcının o anki niyetini kesen bir engeldir. Bu yüzden kısa, nedenini söyleyen ve tek bir eyleme yönlendiren bir metin yazmalısınız. Kullanıcı neden beklediğini anlarsa sabırla güncellemeyi yükler; anlamazsa uygulamayı siler ya da düşük puan verir.

İyi bir mesaj şu öğeleri içerir:

• Somut neden: "Ödeme ekranını daha güvenli hale getirdik" gibi, kullanıcıya dokunan bir açıklama.
• Tahmini zahmet: İndirmenin kısa süreceğini ve verilerin korunacağını belirtmek.
• Tek bir buton: "Şimdi güncelle" gibi net bir eylem; zorunlu ekranda kafa karıştıran ikinci seçenek olmamalı.
• Saygılı ton: Suçlayıcı ya da teknik dil yerine sade ve teşekkür eden bir ifade.

Örnek metin: "Uygulamamızı güvenliğiniz için güncelledik. Devam etmek için yeni sürümü yüklemeniz gerekiyor. Güncelleme birkaç dakika sürer, kayıtlı bilgileriniz korunur." Yumuşak hatırlatmada ise "Yeni sürüm hazır: sepet ekranı artık daha hızlı açılıyor. Şimdi güncelleyebilir ya da daha sonra hatırlatmamızı seçebilirsiniz." gibi bir ifade yeterlidir.

Ayrıca ekranın görsel düzeni de mesaj kadar önemlidir. Arayüz ilkeleri için kullanıcı odaklı arayüz tasarımı yazımız iyi bir başlangıç noktasıdır.

Zorunlu güncelleme ekranında hangi öğeler olmalı?

Kilit ekranı kullanıcıyı uygulamanın dışına göndermeden önce son temas noktasıdır. Dolayısıyla bu ekranı yalnızca bir uyarı kutusu olarak değil, küçük bir ürün parçası olarak tasarlamalısınız. Ekipçe kullandığımız asgari liste şöyledir:

1. Uygulamanın logosu ve tanıdık renkleri; kullanıcı ekranın sahte olmadığını hemen anlamalı.
2. Kısa başlık ve iki üç cümlelik açıklama.
3. Mağazaya giden tek ve büyük bir buton.
4. Destek kanalına giden küçük bir bağlantı; güncelleyemeyen kişi yardım isteyebilmeli.
5. Uygulamanın kurulu sürüm numarası; destek ekibi sorunu hızlı tanır.
6. Geri tuşu ve kaydırma hareketiyle kapanmayan bir yapı; ancak uygulamayı kapatmak her zaman mümkün olmalı.

Öte yandan bu ekranda reklam, kampanya ya da puanlama isteği göstermeyin. Kullanıcı zaten bir engelle karşılaşmış durumdadır; ek bir istek, güveni zedeler. Ayrıca ekran metnini uygulamanın desteklediği tüm dillerde hazırlayın, çünkü İngilizce kalmış bir kilit ekranı, Türkçe kullanan biri için ciddi bir kafa karışıklığı yaratır.

Zorunlu uygulama güncellemesini adım adım nasıl kurarsınız?

Mekanizmayı sıfırdan kurarken sırayı doğru tutmak, sonradan düzeltme yükünü azaltır. Aşağıdaki adımlar hem Android hem iOS için geçerli bir iskelet sunar:

1. Sürüm kontrolünü ilk sürüme ekleyin: Mekanizma uygulamada yoksa onu getirmek için bile bir güncelleme gerekir.
2. Uzaktan yapılandırmayı tanımlayın: En düşük sürüm, önerilen sürüm, mesajlar ve mağaza bağlantıları için platform ve dil bazlı alanlar açın.
3. Karşılaştırma mantığını yazın: Sürümleri sayı olarak karşılaştırın ve sınır durumlarını birim testleriyle doğrulayın.
4. Android'de Play akışını bağlayın: Esnek akış için indirme durumunu dinleyin, anında akış için yarım kalan güncellemeyi yeniden başlatın.
5. iOS'ta ekranı ve App Store bağlantısını hazırlayın: Kullanıcıyı doğrudan uygulamanın ürün sayfasına gönderin.
6. Varsayılan değerleri güvenli seçin: Yapılandırma okunamazsa uygulama kilitlenmemeli.
7. Olay kaydı ekleyin: Ekranın gösterilmesini, butona dokunulmasını ve sonraki açılıştaki sürümü ölçün.
8. Kademeli açın: Eşiği önce küçük bir kitleye uygulayın, sonra genişletin.

Bu adımların her biri küçük bir iş gibi durur. Ancak birlikte doğru çalışmadıklarında sonuç, binlerce kullanıcının aynı anda kilitlenmesi olabilir. Uygulamanızı biz geliştirip mağazaya biz çıkarıyorsak bu iskeleti ilk sürümden itibaren kuruyoruz; kapsam ve süre için mobil uygulama geliştirme hizmetimiz üzerinden teklif alabilirsiniz.

Hangi hatalar kullanıcıları yanlışlıkla kilitler?

Zorunlu güncellemenin en büyük riski, güncellenmesi mümkün olmayan kullanıcıları da kilitlemesidir. Sahada en sık gördüğümüz hatalar şunlardır:

• Mağazada henüz olmayan sürümü şart koşmak: Eşiği, sürüm incelemeden geçmeden ya da kademeli yayın tamamlanmadan yükseltmek.
• Eski işletim sistemini unutmak: Yeni sürüm daha yüksek bir minimum işletim sistemi istiyorsa, eski cihazdaki kullanıcı güncellemeyi hiç göremez ve kalıcı olarak kilitlenir.
• Metin karşılaştırması: Sürümleri metin olarak karşılaştırıp yanlış sonuç almak.
• Yanlış mağaza bağlantısı: Butonun genel mağaza ana sayfasına ya da başka bir ülke mağazasına gitmesi.
• Güvensiz varsayılan: Yapılandırma okunamadığında uygulamanın "güncelleme gerekli" sonucuna varması.

İkinci madde özellikle önemlidir. Yeni sürümünüz eski bir işletim sistemi sürümünü bırakıyorsa, o cihazlar için ayrı bir karar vermeniz gerekir. Bu kullanıcılara kilit yerine "bu cihazda yeni özellikler gelmeyecek" bilgisini vermek çoğu durumda daha adil bir yoldur. Elbette güvenlik nedeniyle eski sürümü kapatmak zorundaysanız bunu açıkça anlatın ve alternatif bir kanal, örneğin web sürümü önerin.

Ayrıca mağaza tarafındaki teknik şartlar da sürüm planınızı etkiler. Örneğin Google Play, uygulamaların belirli bir hedef API seviyesini karşılamasını ister; bu şartın sürüm takviminize etkisini Google Play hedef API seviyesi şartı yazımızda anlattık.

Çevrimdışı ve zayıf bağlantıda ne olmalı?

Sürüm kontrolü bir ağ isteğine dayanır; bu yüzden ağ yoksa ne olacağını önceden kararlaştırmalısınız. Varsayılan davranış "kilitlememek" olmalıdır. Kullanıcı metroda ya da zayıf bağlantılı bir yerde uygulamayı açtığında, sunucuya ulaşamadığı için kilit ekranı görmesi kabul edilemez.

Pratik bir yöntem, son başarılı yapılandırmayı cihazda saklamaktır. Uygulama açılışta bu kayıtlı değeri kullanır ve arka planda yenisini çekmeye çalışır. Böylece açılış gecikmez ve bağlantı yokken bile son bilinen eşik geçerli olur. Üstelik yapılandırma isteğine kısa bir zaman aşımı koyarsanız, yavaş ağda açılış ekranı uzun süre takılı kalmaz.

Bir de şu durumu düşünün: kullanıcı güncelleme ekranını gördü, mağazaya gitti ama indirme yarıda kaldı. Bu kullanıcı uygulamayı tekrar açtığında aynı ekranı görecektir; dolayısıyla ekranda "indirme sürüyorsa mağazadan durumu kontrol edin" gibi kısa bir yönlendirme bulunmalıdır. Android'de anında akışın yarıda kesilmesi durumunda ise belgede anlatıldığı gibi akışı yeniden başlatmanız yeterlidir.

API sürümleme zorunlu güncelleme ihtiyacını nasıl azaltır?

Zorunlu güncellemelerin büyük kısmı, sunucu tarafında eski istemciyi düşünmeden yapılan değişikliklerden doğar. Bu nedenle en iyi zorunlu güncelleme, hiç ihtiyaç duymadığınız güncellemedir. API sürümleme, sunucunun bir süre boyunca hem eski hem yeni istemciye hizmet vermesini sağlar.

Örneğin sipariş uç noktasının cevap biçimini değiştirmeniz gerekiyorsa, eski biçimi hemen kapatmak yerine yeni biçimi ayrı bir sürüm olarak açarsınız. Yeni uygulama sürümü yeni uç noktayı kullanır, eski sürüm bir süre eskisini kullanmaya devam eder. Ardından eski sürümü kullanan kitle küçüldüğünde önce yumuşak hatırlatma, en sonda da zorunlu güncelleme devreye girer.

Bu yaklaşım şu faydaları sağlar:

• Kullanıcıyı aniden kilitlemek yerine geçişi haftalara yayarsınız.
• Yeni sürümde çıkan bir hatada eski sürüm çalışmaya devam eder.
• Kilit kararını teknik bir zorunluluktan çok bilinçli bir ürün kararına dönüştürürsünüz.

Kısacası zorunlu güncelleme bir güvenlik ağıdır; günlük sürüm yönetiminin yerine geçmemelidir.

Zorunlu güncellemeyi nasıl test edersiniz?

Test etmeden açılan bir kilit, gerçek kullanıcıların telefonunda keşfedilen bir hataya dönüşür. Bu yüzden mekanizmayı her iki platformda ayrı ayrı denemelisiniz.

Android tarafında resmi belgelerin bağlantı verdiği test rehberi, dahili uygulama paylaşımı (internal app sharing) yöntemini anlatır. Önce cihaza uygulamanın dahili paylaşım bağlantısıyla kurulmuş bir sürümünü yüklersiniz. Ardından daha yüksek sürüm koduna sahip yeni bir sürümü paylaşır, bağlantıya tıklar ama mağaza sayfasından kurmazsınız. Uygulamayı açtığınızda güncelleme akışı ekrana gelir. Test rehberi, güncelleme önceliği alanının dahili paylaşımda desteklenmediğini de not eder.

iOS tarafında ise test, büyük ölçüde sizin sürüm kontrolünüzü sınamaktan ibarettir. Yapılandırmadaki eşiği test ortamında yükseltir, ekranın göründüğünü, butonun doğru ürün sayfasına gittiğini ve ağ yokken kilit oluşmadığını doğrularsınız. Test senaryolarını otomatikleştirmek isterseniz test araçları karşılaştırmamız genel yaklaşımı özetliyor.

Son olarak her iki platformda yapılandırmanın okunamadığı, bozuk geldiği ve boş geldiği durumları da deneyin.

Güncellemenin etkisini hangi metriklerle ölçmelisiniz?

Bir güncelleme kampanyasının başarısı, kullanıcıların ne kadarının yeni sürüme geçtiğiyle ve bu sırada ne kadarını kaybettiğinizle ölçülür. Dolayısıyla tek bir sayıya değil, birbirini tamamlayan birkaç göstergeye bakmalısınız:

• Sürüm dağılımı: Aktif kullanıcıların hangi sürümlerde olduğu, gün gün.
• Ekran gösterimi ve dönüşüm: Güncelleme ekranını gören kişilerden kaçının butona dokunduğu ve kaçının sonraki açılışta yeni sürümde geldiği.
• Kayıp: Kilit ekranını görüp bir daha dönmeyen kullanıcı sayısı.
• Destek talepleri: "Güncelleyemiyorum" konulu talep artışı.
• Mağaza yorumları: Güncelleme zorlamasından şikâyet eden yorumlar.

Örnek hesap: Kilit ekranını 2.000 kişi gördü, 1.700'ü butona dokundu ve 1.600'ü bir hafta içinde yeni sürümle geri geldi. Bu durumda ekranın dönüşümü yüzde 80 olur ve 400 kişi ya güncelleyemedi ya da vazgeçti. Bu rakamlar yalnızca hesabın mantığını gösteren örnek değerlerdir; hedef ya da sektör ortalaması değildir. Kayıp yüksekse önce mesajı, sonra eski cihaz desteğini gözden geçirin.

Örnek senaryo: ödeme altyapısı değişen bir uygulamada ne yapmalısınız?

Bir randevu uygulamasının ödeme sağlayıcısını değiştirdiğini düşünelim. Eski sağlayıcı belirli bir tarihten sonra istek kabul etmeyecek. Eski sürümdeki kullanıcı ödeme adımına geldiğinde hata alacak ve randevusu yarım kalacak. Bu, zorunlu uygulama güncellemesini haklı çıkaran tipik bir örnek senaryodur.

Biz bu durumda süreci şöyle planlarız:

1. Yeni sağlayıcıyı kullanan sürümü yayınlar ve kademeli dağıtımın tamamlanmasını bekleriz.
2. Önerilen sürümü yükseltip yumuşak hatırlatmayı açarız; Android'de esnek akışı kullanırız.
3. Eski sağlayıcının kapanma tarihine yaklaşırken hatırlatmanın sıklığını artırırız.
4. Kapanmadan önce en düşük sürümü yükseltir, zorunlu ekranı açarız.
5. Kapanmanın ardından eski sürümden gelen ödeme isteklerine anlaşılır bir hata mesajı döndürürüz.

Böylece kullanıcıların çoğu kilit ekranını hiç görmeden yeni sürüme geçer. Kilit ekranını yalnızca uzun süredir uygulamayı açmayan küçük bir grup görür. Üstelik bu grup da ekranda nedeni ve tek bir eylemi görür; yarım kalmış bir ödeme hatasıyla karşılaşmaz.

Yayından önce hangi kontrol listesini kullanmalısınız?

Eşiği yükseltmeden önce aşağıdaki listeyi ekipçe tek tek işaretlemenizi öneriyoruz. Her madde, sahada karşılaştığımız bir kilitlenme hatasının karşılığıdır:

• Yeni sürüm her iki mağazada da yayında ve kademeli dağıtım tamamlandı.
• Yeni sürümün desteklediği en düşük işletim sistemi sürümünü kontrol ettiniz.
• Eşiğin altında kalan aktif kullanıcı sayısını biliyorsunuz.
• Mesaj metni tüm dillerde hazır ve nedeni açıkça söylüyor.
• Butonlar doğru ürün sayfasına gidiyor.
• Yapılandırma okunamazsa uygulama kilitlenmiyor.
• Destek ekibi olası soruları ve cevaplarını biliyor.
• Kararı geri almak için yapılandırmayı kimin, nasıl değiştireceği belli.
• Mağazadaki yenilikler metni değişikliği anlatıyor.

Bu liste kısa görünse de her maddesi bir kullanıcı grubunu korur. Özellikle geri alma maddesini atlamayın, çünkü yanlış bir eşik dakikalar içinde tüm kullanıcıları etkileyebilir.

Zorunlu uygulama güncellemesini sizin için nasıl kuruyoruz?

Talha Aslan ve ekibi olarak mobil uygulamalarda sürüm yönetimini, uygulamanın kendisi kadar önemli bir parça olarak ele alıyoruz. Yeni bir projede sürüm kontrolünü, uzaktan yapılandırmayı, Google Play uygulama içi güncelleme akışını ve iOS güncelleme ekranını ilk sürümden itibaren kuruyoruz. Mevcut bir uygulamada ise önce sürüm dağılımını ve sunucu bağımlılıklarını inceliyor, ardından kademeli bir geçiş planı hazırlıyoruz.

Uygulamanızı biz geliştirir, mağazaya biz çıkarırız; sonraki sürümlerde de geçişin kullanıcıyı kızdırmadan ilerlemesini takip ederiz. Kapsamı, platformları ve zaman planını konuşmak için mobil uygulama geliştirme sayfamızdan teklif isteyebilirsiniz. Bu arada ekibinize Android geliştirici alacaksanız Android Kotlin mülakat soruları yazımız da işinize yarayabilir.