Mobil Uygulama Güncelleme Nasıl Yayınlanır? (2026)

Mobil uygulama güncellemesi, yeni sürümün derleme numarası artırılıp mağazaya yüklenmesi, incelemeden geçmesi ve kullanıcılara kademeli olarak açılmasıyla yayınlanır. İlk yayından farkı şudur: artık sahada gerçek kullanıcılar var ve hatalı bir sürüm herkese birden ulaşırsa geri almak mümkün değildir — mağazalar bir önceki sürüme dönüş düğmesi sunmaz, yalnızca dağıtımı durdurmanıza ve düzeltilmiş yeni bir sürüm göndermenize izin verir. Bu yüzden güncelleme sürecinin özü hız değil, kontrollü açılımdır.

Bu yazı uygulamanın ilk kez mağazaya çıkışını değil, yayındaki uygulamaya yeni sürüm çıkarmayı anlatıyor. İlk yükleme adımları için Play Store’a uygulama yükleme, iki mağazanın genel akışı için App Store ve Google Play yayınlama süreci yazılarına bakabilirsiniz.

Mobil uygulama güncelleme öncesi: sürüm numarası

Her iki mağazada da uygulamanın iki ayrı numarası vardır ve karıştırılması en sık yükleme hatasıdır. Kullanıcının gördüğü sürüm adı (Android’de versionName, iOS’ta CFBundleShortVersionString) “2.4.0” gibi bir etikettir. Mağazanın baktığı ise derleme numarasıdır (Android’de versionCode, iOS’ta CFBundleVersion): her yüklemede bir öncekinden büyük olmak zorundadır. Aynı derleme numarasıyla ikinci kez yükleme yapılamaz; reddedilen ya da test kanalında kalan bir derleme de o numarayı tüketir.

• Sürüm adı anlamsal sürümleme (semver) ile verilir: hata düzeltmesi 2.4.1, yeni özellik 2.5.0, geriye uyumsuz değişiklik 3.0.0.
• Derleme numarası elle değil, CI hattında otomatik artırılır; iki geliştiricinin aynı numarayla derleme alması böylece önlenir.
• Android ve iOS sürüm adlarını aynı tutun. Destek ekibi “hangi sürümdesiniz” diye sorduğunda iki platform için ayrı tablo tutmak zorunda kalmaz.
• Sürüm notunu (What’s new / Yenilikler) mağazaya her güncellemede yazın; boş not, kullanıcıya güncellemenin neden gerektiğini anlatmaz.

Google Play’de güncelleme: test kanalı ve kademeli dağıtım

Play Console’da yeni sürüm doğrudan üretim kanalına gitmek zorunda değildir. Doğru akış, derlemeyi önce dahili test kanalına yükleyip ekibe dağıtmak, sorun yoksa aynı derlemeyi üretime yükseltmektir — yeniden derleme yapılmaz, test edilen dosya yayına çıkar. Üretime alırken kademeli dağıtım (staged rollout) yüzdesi seçilir: sürüm önce kullanıcıların küçük bir kısmına açılır, çökme ve ANR oranları Android vitals ekranında izlenir, sonra yüzde adım adım artırılır.

Kademeli dağıtımın asıl değeri durdurma düğmesidir. Yüzde 5’te çökme oranı yükselirse dağıtım durdurulur; sürümü almamış yüzde 95 etkilenmez. Sürümü zaten almış kullanıcılar için tek çare, derleme numarası daha yüksek bir düzeltme sürümüdür. İnceleme süresi güncellemelerde genellikle ilk yayından kısadır ama garanti değildir; acil düzeltmeyi incelemeye bağlı bir takvime yazmayın.

App Store’da güncelleme: aşamalı yayın

App Store Connect’te karşılığı aşamalı yayındır (phased release). Otomatik güncellemesi açık kullanıcılara sürüm yedi gün boyunca artan oranlarda dağıtılır ve istenirse duraklatılır. İki farkı bilmek gerekir: aşamalı yayın yalnızca otomatik güncellemeyi etkiler — mağazaya girip elle güncelleyen herkes yeni sürümü ilk günden alabilir; ve Apple’da da geri dönüş yoktur, hatalı sürüm yerine yeni bir derleme incelemeye gönderilir. Kritik hata durumunda hızlandırılmış inceleme talebi açılabilir, ancak bu bir hak değil, Apple’ın takdirindedir.

İncelemeden dönen güncellemelerin çoğu ilk yayındaki sebeplerle döner: eksik test hesabı, izin açıklaması ile gerçek kullanım arasında fark, gizlilik beyanının güncellenmemesi. Yeni bir özellik yeni bir veri topluyorsa mağazadaki gizlilik ve veri güvenliği beyanları da aynı güncellemede değişmelidir. Ret sebeplerinin tam listesi için uygulama neden reddedilir yazısına bakın.

Mağazalarda geri alma yoktur, yalnızca durdurma ve ileri düzeltme vardır. Bu yüzden her güncelleme küçük bir yüzdeyle açılır ve bir sonraki adım ancak çökme oranı izlendikten sonra atılır.

Zorunlu güncelleme: eski sürümü sunucudan kapatmak

Mağaza güncellemeyi kullanıcıya önerir ama dayatmaz; otomatik güncellemesi kapalı bir kullanıcı aylarca eski sürümde kalabilir. API’de geriye uyumsuz bir değişiklik yaptığınızda ya da eski sürümde bir güvenlik açığı kapattığınızda o kullanıcıyı yeni sürüme geçirmenin tek yolu, uygulamanın açılışta sunucudan minimum desteklenen sürümü okumasıdır. Bu mekanizma ilk sürümde kurulmazsa sonradan eklenemez: mekanizmayı içermeyen eski sürüm, kendisinin eski olduğunu hiçbir zaman öğrenmez.

type AppGate = { minVersion: string; storeUrl: string };

function isBelow(current: string, minimum: string): boolean {
  const a = current.split('.').map(Number);
  const b = minimum.split('.').map(Number);
  for (let i = 0; i < Math.max(a.length, b.length); i++) {
    const x = a[i] ?? 0;
    const y = b[i] ?? 0;
    if (x !== y) return x < y;
  }
  return false;
}

async function checkForcedUpdate(currentVersion: string) {
  try {
    const res = await fetch('https://api.ornek.com/app-gate');
    const gate: AppGate = await res.json();
    return isBelow(currentVersion, gate.minVersion)
      ? { blocked: true, storeUrl: gate.storeUrl }
      : { blocked: false };
  } catch {
    return { blocked: false };
  }
}

Örnekte iki karar bilinçlidir. Sürümler metin olarak değil sayı parçaları olarak karşılaştırılır; metin karşılaştırmasında “2.10.0”, “2.9.0”dan küçük çıkar. Sunucuya ulaşılamazsa uygulama açılır (fail-open): ağ hatası kullanıcıyı kilitlememelidir. Zorunlu güncellemeyi her sürümde kullanmayın; yalnızca eski sürümün gerçekten çalışamayacağı ya da güvensiz olduğu durumlar için saklayın, gerisinde kapatılabilir bir “yeni sürüm var” uyarısı yeterlidir. Güvenlik tarafındaki gerekçeyi mobil uygulama güvenliği yazısında anlattık.

OTA güncelleme: mağazayı atlamanın sınırları

React Native ve benzeri yapılarda JavaScript paketini mağazaya gitmeden kullanıcıya ulaştıran OTA (over-the-air) güncelleme servisleri vardır. Metin, stil ya da iş kuralı hatası gibi küçük düzeltmelerde dakikalar içinde etki eder. Sınırı nettir: yalnızca JavaScript ve görsel varlıklar değişebilir; yeni bir native kütüphane, yeni bir izin ya da SDK güncellemesi mutlaka mağaza sürümü ister. Mağaza kuralları da uygulamanın amacını ve inceleme sırasında beyan edilen davranışını OTA ile değiştirmeyi yasaklar. OTA, mağaza sürecinin yerine değil, onun arasındaki küçük düzeltmeler için kullanılır.

Güncellemeyi zorunlu kılan dış takvim

Uygulamanıza hiç yeni özellik eklemeseniz de güncelleme yapmak zorunda kalırsınız. Google Play her yıl güncel bir Android API seviyesini hedeflemeyi şart koşar; hedefi geride kalan uygulama yeni Android sürümlerindeki kullanıcılara görünmez hâle gelebilir ve güncelleme yüklenemez. Apple da yeni Xcode ve iOS SDK sürümüyle derleme şartını belirli aralıklarla yükseltir. Bunlara ödeme, harita ve bildirim SDK’larının eski sürüm desteğini kesmesi eklenir. Tarihler her yıl duyurulur; güncel şartı Play Console ve App Store Connect bildirimlerinden takip edin, yıllık planı bu takvime göre yapın. Bu zorunlu işin bütçedeki yeri için mobil uygulama bakım maliyeti yazısına bakabilirsiniz.

Yayın öncesi kontrol listesi

• Derleme numarası artırıldı, sürüm adı iki platformda aynı.
• Derleme dahili test kanalında / TestFlight’ta gerçek cihazlarda denendi; üretime aynı derleme yükseltiliyor.
• Eski sürümden yeni sürüme geçiş test edildi: yerel veri, oturum ve önbellek bozulmadan taşınıyor.
• Sunucu tarafı değişiklikleri eski sürümle de çalışıyor; geriye uyumsuzsa zorunlu güncelleme eşiği hazır.
• Gizlilik ve veri güvenliği beyanları yeni özelliklerle uyumlu.
• Kademeli dağıtım küçük bir yüzdeyle başlıyor; çökme raporlama açık ve izleyen kişi belli.
• Sürüm notu iki dilde yazıldı.

Bu adımların çoğu elle değil CI hattında yürütüldüğünde güvenilir hâle gelir: derleme numarası, imzalama ve test kanalına yükleme otomatikleşir, insan yalnızca yüzdeyi artırma kararını verir. Kurulumu CI/CD nedir yazısında adım adım anlattık.

Sonuç

Mobil uygulama güncelleme yayınlamak bir yükleme işlemi değil, kontrollü bir açılımdır: derleme numarası artırılır, test edilen derleme üretime yükseltilir, sürüm küçük bir yüzdeyle açılıp izlenir, eski sürümler gerektiğinde sunucudan kapatılır. Bu düzen ilk sürümde kurulursa her güncelleme sıradan bir iş olur. Yayındaki uygulamanızın güncelleme ve bakım sürecini birlikte planlamak isterseniz mobil uygulama geliştirme sayfamıza göz atın ya da teklif alın.