Mobil Uygulamada Sürüm Yönetimi: Güncelleme Ritmi Nasıl Kurulur?

Mobil uygulamada sürüm yönetimi üç ayrı kararı aynı çatı altında toplar: bir değişikliğin hangi sürüm numarasıyla çıkacağı, kullanıcıya mağaza incelemesinden mi yoksa anlık bir kanaldan mı ulaşacağı ve yeni sürümün ne hızda tüm kullanıcı tabanına yayılacağı. Bu üç karar birlikte planlanmazsa ekip ya haftalarca mağaza inceleme kuyruğunda bekler ya da kritik bir hatayı doğrudan yüzde yüz kullanıcıya dağıtıp geri dönemez hale gelir. Bu yazıda sürüm numaralandırmasından zorunlu güncelleme mekanizmasına, kademeli yayınlamadan eski sürüm desteğinin ne zaman kesileceğine kadar sürüm yönetiminin pratik kurallarını sırayla anlatıyoruz.

Sürüm numarası ile derleme numarası aynı şey mi?

Hayır — ve bu karışıklık mağaza reddinin sık görülen nedenlerinden biri. Sürüm adı (version name), kullanıcının mağaza sayfasında gördüğü, nokta işaretiyle ayrılan üç haneli sayıdır (1.4.2 gibi) ve semantik sürümleme (semver) mantığını izler: ilk hane geriye dönük uyumsuz bir değişikliği, ikinci hane yeni ama uyumlu bir özelliği, üçüncü hane ise hata düzeltmesini gösterir. Derleme numarası (build number / versionCode) ise kullanıcının hiç görmediği, her mağaza gönderiminde artması zorunlu tam sayıdır. İki numarayı karıştırıp derleme numarasını sabit bırakmak, App Store Connect ve Google Play Console'un en sık verdiği "bu derleme zaten kullanıldı" reddinin sebebidir.

1. Kırıcı bir değişiklik varsa (major). Bir API uç noktası kaldırıldıysa veya veri modeli geriye dönük çalışmıyorsa, ilk haneyi artırın ve eski istemcilerin bu sürümle konuşamayacağını varsayın.
2. Yeni ama uyumlu bir özellik eklendiyse (minor). Mevcut kullanıcı akışı bozulmadan yeni bir ekran veya yetenek geldiyse ikinci hane artar.
3. Yalnızca hata düzeltmesi veya küçük iyileştirme varsa (patch). Üçüncü hane artar; bu genelde en sık görülen sürüm tipidir.
4. Derleme numarasını her gönderimde artırın — sürüm adı değişmese bile. Aynı sürüm adıyla ikinci bir düzeltme derlemesi göndermeniz gerektiğinde bu kural sizi kurtarır.

OTA güncelleme mi, mağaza güncellemesi mi?

Değişikliğin türü, hangi kanaldan dağıtılacağını belirler. Expo/EAS Update gibi bir OTA (over-the-air) güncelleme katmanı kullanılıyorsa, yalnızca JavaScript kodunu ve statik varlıkları (görsel, metin, stil) değiştiren bir düzeltme, mağaza incelemesi beklemeden dakikalar içinde kullanıcıya ulaşabilir. Ancak yerel (native) kod değişikliği — yeni bir izin, bir native kütüphane güncellemesi, kamera veya konum gibi donanım erişimi eklenmesi — bu kanaldan geçemez; bu tür değişiklikler her zaman tam mağaza inceleme sürecinden geçmek zorundadır. İki kanalı karıştırıp native bir değişikliği OTA ile göndermeye çalışmak mağazaların inceleme kurallarına aykırıdır ve hesabın askıya alınmasına kadar gidebilir.

Kademeli yayınlama nasıl kurulur?

Yeni bir sürümü ilk günden kullanıcıların tamamına açmak, küçük bir hatayı büyük bir krize çevirmenin en hızlı yoludur. Hem Google Play hem App Store, sürümü önce küçük bir kullanıcı yüzdesine gösterip sorun çıkmazsa kademeli olarak artırmayı destekler: Google Play'de staged rollout yüzdesi elle ayarlanır, App Store'da ise phased release yedi gün boyunca otomatik olarak yüzde 1'den yüzde 100'e çıkar. Mekanizmanın amacı basit: çökme oranı veya olumsuz değerlendirme küçük bir grupta görülürse, geri kalan kullanıcıya ulaşmadan yayını durdurabilirsiniz.

• İlk yüzde 5-10'da çökme oranını izleyin. Bu dilim, önceki sürüme göre anlamlı bir sapma varsa görmenizi sağlayacak kadar büyük, tüm kullanıcıyı riske atmayacak kadar küçüktür.
• Yükseltmeden önce en az 24 saat bekleyin. Bazı çökmeler yalnızca belirli cihaz/işletim sistemi kombinasyonlarında, kullanım biriktikçe ortaya çıkar.
• Yayını istediğiniz an durdurabileceğinizi unutmayın. Google Play'de staged rollout yüzdesini sıfıra çekmek yeni indirmeleri durdurur; App Store'da phased release duraklatılabilir.
• Kritik güvenlik yamalarında kademeyi atlayın. Aktif olarak istismar edilen bir güvenlik açığında, yavaş yayılan bir düzeltme riski uzatmaktan başka işe yaramaz.

Zorunlu güncelleme ne zaman devreye girer?

Zorunlu güncelleme (force update), kullanıcının belirli bir sürümün altında uygulamayı kullanmaya devam edemediği bir mekanizmadır — açılışta bir uzak yapılandırma (remote config) değeri okunur, mevcut sürüm bu eşiğin altındaysa kullanıcı güncelleme ekranından geçemeden uygulamayı kapatmak zorunda kalır. Bu mekanizma nadiren ve gerekçeyle kullanılmalı; her küçük düzeltmede zorunlu güncelleme dayatmak kullanıcıyı yorar ve mağaza değerlendirmelerine olumsuz yansır.

• Geriye dönük uyumsuz bir API değişikliği yapıldığında. Eski istemci artık sunucuyla konuşamıyorsa, çalışmayan bir uygulama bırakmaktansa güncellemeye yönlendirmek daha az kötü seçenektir.
• Aktif olarak istismar edilen bir güvenlik açığı kapatıldığında. Düzeltmenin tüm kullanıcıya en hızlı biçimde ulaşması gerekir.
• Ödeme veya yasal uyumluluk gerektiren bir değişiklikte. Eski sürümde çalışmaya devam etmek yasal bir riske dönüşüyorsa, geçiş zorunlu kılınır.

Güncelleme ritmi nasıl belirlenir?

Ritim, mağaza inceleme sürtünmesiyle kullanıcı yorgunluğu arasında bir denge sorusudur. Haftalık bir mağaza güncellemesi sık gelir gibi görünse de asıl birikimi önler: on değişikliği tek bir sürüme sıkıştırıp hangi değişikliğin hangi soruna yol açtığını ayırt edemez hale gelmek, küçük ve sık düzeltmelerden daha risklidir. TestFlight ve Google Play'in test kanallarını kullanan ekipler için pratik ritim şöyle işler: her hafta bir aday derleme dahili ekibe, iki haftada bir dış test grubuna, ayda bir de üretime çıkar. OTA katmanı varsa JavaScript düzeltmeleri bu ritmin dışında, ihtiyaç anında anlık olarak gönderilebilir.

Eski sürümleri ne zaman desteklemeyi bırakmalı?

Yayınlanan her yeni sürüm, eskisini otomatik olarak ortadan kaldırmaz — kullanıcının bir kısmı güncellemeyi hiç yapmaz veya haftalarca erteler. Analitikte belirli bir eski sürümün kullanıcı payı düşük bir eşiğin (örneğin yüzde 2-3) altına indiğinde, o sürümü hedefleyen sunucu tarafı uyumluluk kodunu kaldırmak makul olur. Bu eşiğe ulaşmadan destek kesmek, hâlâ o sürümü kullanan kullanıcıyı aniden çalışmaz hale getirir; eşik geçildikten çok sonra bile destek tutmak ise sunucu tarafında sürekli büyüyen bir uyumluluk kod yükü biriktirir.

En iyi güncelleme, kullanıcının hiç fark etmediğidir — ne bir zorunlu ekranla karşılaşır ne de eski sürümde takılıp kalır.

Kritik hata çıkarsa geri dönüş planı nedir?

Mağazadan indirilmiş bir uygulamayı geri çağırmak mümkün değil; ama yayılmasını durdurmak ve düzeltmeyi hızlandırmak mümkün. Üç katman birlikte çalışır: kademeli yayının duraklatılması, sunucu tarafında bir uzaktan kapatma anahtarı (kill switch) ile sorunlu özelliğin devre dışı bırakılması ve OTA katmanı varsa önceki kararlı pakete anında dönülmesi. Bu üç mekanizma önceden kurulmamışsa, tek çare acil bir düzeltme derlemesi hazırlayıp mağaza incelemesine sokmak olur — bu da en iyi ihtimalle bir gün, kötü ihtimalle daha uzun sürer.

1. Her yeni özelliği bir uzaktan anahtarın arkasına koyun. Sorun çıktığında kod göndermeden, sunucudan bir bayrağı kapatarak özelliği devre dışı bırakabilirsiniz.
2. Önceki OTA paketini her zaman erişilebilir tutun. Yeni paket sorun çıkarırsa, bir önceki kararlı sürüme dönmek dakikalar sürmeli.
3. Kademeli yayın yüzdesini izleyen bir uyarı kurun. Çökme oranı eşiği aştığında ekip, mağaza paneline elle bakmadan haberdar olmalı.

Mobil uygulama geliştirme hizmetimizde sürüm yönetimi ve güncelleme ritmi, mağaza gönderimi ve yayın sonrası bakımın standart bir parçası olarak planlanır. Uygulamanızın güncelleme ritmini nasıl kuracağınızdan emin değilseniz, mevcut sürecinizi birlikte gözden geçirelim — kısa bir görüşme talep edin.