Mobil Uygulama Sürüm Güncellemeleri Nasıl Yönetilir?

Mobil Uygulama Sürüm Güncellemeleri Nasıl Yönetilir? sorusunun yanıtı; hata payını sıfıra indiren otomasyon mekanizmalarının kurulması, titizlikle yürütülen test prosedürleri ve platform kurallarına tavizsiz uyum gösterilmesidir. Şirket yöneticileri ve teknik karar vericiler için kritik öneme sahip bu süreç, sadece yeni özelliklerin yayına alınmasını değil, aynı zamanda kullanıcı sadakatini korumayı ve uygulama performansını optimize etmeyi de kapsar. Bu teknik rehber, yazılım ekiplerinin entegrasyon süreçlerinden App Store ve Google Play Console yayın politikalarına kadar tüm aşamaları yapılandırılmış bir metodolojiyle ele alarak riskleri nasıl yöneteceğinizi ve sürüm kalitesini nasıl artıracağınızı açıklamaktadır.

Uygulama Sürüm Yönetiminde Kurumsal Standartlar

Kurumsal bir yazılım ekosisteminde sürüm yönetimi, sistem mimarisinin istikrarını ve kullanıcı deneyiminin kesintisizliğini koruyan en temel disiplindir. Mobil uygulamalar, doğası gereği istemci tarafında (client-side) çalışan ve güncellemelerin doğrudan son kullanıcının cihazına indirilmesini gerektiren yapılardır. Bu durum, web uygulamalarındaki anlık dağıtım (instant deployment) kolaylığının aksine, her güncellemenin teknik ve operasyonel riskler barındırmasına neden olur. Başarılı bir sürüm yönetimi, geriye dönük uyumluluğu (backward compatibility) güvence altına alırken, veri tabanı şemalarındaki değişiklikleri ve dış API entegrasyonlarını senkronize bir şekilde koordine etmeyi zorunlu kılar.

Yazılım projelerinde standartlaşmayı sağlamanın yolu, sürüm numaralarının rastgele seçilmesini önleyerek her değişikliğin teknik niteliğini yansıtan bir terminoloji kullanmaktır. Kurumsal ölçekteki projelerde bu standardizasyon, ekipler arası iletişimi kolaylaştırır, bağımlı kütüphanelerin (dependency) yönetimini optimize eder ve sistem mimarlarının altyapı kararlarını daha sağlıklı almasına olanak tanır. Özellikle çoklu platformlarda (iOS ve Android) eş zamanlı yürütülen projelerde, tutarlı bir sürüm şeması benimsemek operasyonel karmaşayı engeller.

Semantik Sürümleme (SemVer) Nedir ve Nasıl Uygulanır? | Major, Minor ve Patch Sürüm Farkları

Semantik Sürümleme ya da yaygın bilinen adıyla Semantic Versioning (SemVer), yazılım sürümlerinin anlamlı ve öngörülebilir bir düzende numaralandırılması için kullanılan evrensel bir protokoldür. Bu protokol çerçevesinde her sürüm numarası, aralarına nokta konularak ayrılmış üç temel bileşenden oluşur: MAJOR.MINOR.PATCH (Örneğin: 2.4.1). Her bir bileşenin artırılma kuralları, yapılan değişikliğin kod tabanındaki ve kullanıcı tarafındaki yapısal etkisine göre kesin kurallarla belirlenmiştir.

+-----------------------------------------------------------+
|                      SEMANTIK SÜRÜMLEME                   |
|                            2.4.1                          |
+---------------------+---------------------+---------------+
|        MAJOR        |        MINOR        |     PATCH     |
|         (2)         |         (4)         |      (1)      |
+---------------------+---------------------+---------------+
|  Geriye Dönük       |  Yeni Geriye Dönük  | Geriye Dönük  |
|  Uyumsuz Değişiklik |  Uyumlu Özellikler  | Uyumlu Hata   |
|  (Breaking Change)  |  (New Features)     | Düzeltmeleri  |
+---------------------+---------------------+---------------+

MAJOR (Ana Sürüm): Uygulamanın API katmanında geriye dönük uyumluluğu bozan, köklü yapısal değişiklikler yapıldığında artırılır. Örneğin, veri tabanı şemasının tamamen değiştirilmesi, uygulamanın mimari altyapısının native'den cross-platform yapıya taşınması veya mevcut kullanıcı verilerinin eski sürümlerle artık işlenemeyecek düzeyde farklılaşması durumunda MAJOR sürüm artırılır. Bu güncelleme yapıldığında, alt bileşenler olan MINOR ve PATCH değerleri sıfırlanır (Örn: @@CODE0@@ -> @@CODE1@@).

MINOR (Yan Sürüm): Uygulamaya geriye dönük uyumlu yeni işlevlerin, özelliklerin veya ekranların eklendiği durumlarda artırılır. Kullanıcılar eski sürümü kullanmaya devam edebilir ve sistem servisleri bu durumdan zarar görmez. Yeni bir ödeme yöntemi entegrasyonu, profil sayfasına eklenen yeni bir sekme veya performans iyileştirmeleri içeren yeni modüller MINOR güncelleme kapsamında değerlendirilir. Bu durumda PATCH sıfırlanır (Örn: @@CODE0@@ -> @@CODE1@@).

PATCH (Yama Sürümü): Sadece geriye dönük uyumlu hata düzeltmeleri (bug fixes) ve kritik güvenlik yamaları için kullanılır. Uygulamaya yeni bir fonksiyonel özellik kazandırılmaz; mevcut özelliklerin hatalı çalışan kısımları optimize edilir. Bellek sızıntılarının giderilmesi, görsel kaymaların düzeltilmesi veya güvenlik açıklarının kapatılması PATCH sürümü ile dağıtılır (Örn: @@CODE0@@ -> @@CODE1@@). Semantik sürümleme kurallarına sadık kalmak, sürüm güncellemeleri yönetilirken bağımlılık krizlerini ve beklenmedik çökmeleri önlemenin en etkili yoludur.

Teknik Hazırlık ve Kalite Güvence (QA) Süreçleri

Mobil uygulamaların donanım ve işletim sistemi çeşitliliği, web tabanlı sistemlere kıyasla çok daha geniş bir test matrisi gerektirir. Kalite Güvence (QA) süreçleri, kod tabanındaki değişikliklerin kullanıcı cihazlarında kararlı çalışmasını sağlamak için yapılandırılır. Dağıtım öncesinde yapılacak testler, potansiyel uygulama çökmesi (crash rate) oranlarını asgari düzeye indirmek için zorunludur. Kalite güvence ekipleri, uygulamanın yalnızca yeni eklenen özelliklerini değil, mevcut tüm kritik iş akışlarını da içeren uçtan uca senaryoları doğrulamakla yükümlüdür.

Teknik hazırlık aşaması; kod imzalama (code signing) sertifikalarının güncelliğinin kontrol edilmesini, API uç noktalarının doğrulanmasını ve hedef cihaz profillerine göre test ortamlarının hazırlanmasını kapsar. Android cihazlardaki ekran boyutu ve yonga seti varyasyonları ile iOS cihazlardaki kapalı ekosistem kısıtlamaları, her iki platform için de özelleştirilmiş test stratejileri geliştirmeyi gerektirir. Bu süreçte hem simülatör/emülatörlerden hem de gerçek fiziksel cihazlardan yararlanmak operasyonel başarıyı doğrudan etkiler.

Regresyon ve Kullanıcı Kabul Testleri (UAT) | TestFlight ve Google Play Console İç Test Kanallarının Kullanımı

Bir mobil uygulamanın yeni sürümü mağazaya gönderilmeden önce iki ana test aşamasından geçmesi kritik bir gereksinimdir: Regresyon testi (regression testing) ve Kullanıcı Kabul Testi (UAT). Regresyon testleri, sisteme eklenen yeni bir kod parçasının veya düzeltilen bir hatanın, uygulamanın halihazırda sorunsuz çalışan diğer bölgelerinde beklenmeyen bir bozulmaya yol açıp açmadığını tespit etmek amacıyla gerçekleştirilir. Bu testler, hem otomatik test araçları (Appium, Espresso, XCUITest) hem de manuel senaryolar yardımıyla yürütülür. Kullanıcı Kabul Testi (UAT) ise uygulamanın iş mantığına ve tasarlanan kullanıcı niyetine uygunluğunu, doğrudan ürün sahipleri (product owners) ve paydaşlar gözünden doğrulamak için yapılan son aşama onay sürecidir.

Test süreçlerinin verimli yönetilebilmesi için platformların sunduğu dağıtım araçlarından en üst düzeyde faydalanılmalıdır. iOS ekosisteminde Apple tarafından sunulan TestFlight, dağıtım öncesi testlerin merkezinde yer alır. TestFlight üzerinde "Internal Testing" (İç Test) kanalı oluşturularak yazılım ekibindeki ve kurum içindeki 100'e yakın kullanıcıya, herhangi bir Apple inceleme süreci (app review process) olmaksızın anında yeni derlemeler ulaştırılabilir. Harici testler (External Testing) için ise 10.000'e kadar kullanıcıya erişim sağlanabilir ancak bu aşamada derleme, Apple'ın otomatik ve yarı-manuel beta incelemesinden geçmek zorundadır.

+-------------------------------------------------------------------------+
|                    MOBİL TEST KANALLARI HİYERARŞİSİ                      |
+-------------------------------------------------------------------------+
| iOS (TestFlight)                                                        |
|   |-- İç Test (Internal): 100 Kullanıcı, İncelemesiz, Anında Dağıtım    |
|   |-- Dış Test (External): 10.000 Kullanıcı, Beta İnceleme Süreci Gerekli  |
+-------------------------------------------------------------------------+
| Android (Google Play Console)                                           |
|   |-- Dahili Test (Internal): 100 Kullanıcı, İncelemesiz, Hızlı Erişim   |
|   |-- Kapalı Test (Closed): Belirli Listeler/Ülkeler, İnceleme Süreci Var   |
|   |-- Açık Test (Open): Mağazada Görünür Beta, Genel Katılım                |
+-------------------------------------------------------------------------+

Google Play Console tarafında ise süreç daha esnek ancak benzer hiyerarşik kanallarla yapılandırılmıştır. "Dahili Test" (Internal Testing) kanalı, 100 test kullanıcısına kadar hızlı ve incelemesiz sürüm dağıtımı yapılmasına imkan tanır. Daha geniş gruplar için "Kapalı beta" (Closed Testing) kanalları oluşturulabilir; burada belirli e-posta listeleri üzerinden veya bölgesel hedeflemelerle testler yönetilir. "Açık beta" (Open Testing) seçeneğinde ise dileyen her Google Play kullanıcısı, mağaza sayfasındaki beta katılım butonunu kullanarak teste dahil olabilir. Google'ın yeni kişisel geliştirici hesapları için getirdiği, uygulamayı açık mağazada yayınlamadan önce en az 20 aktif test kullanıcısıyla 14 gün boyunca kapalı testte tutma kuralı, kalite güvence süreçlerinin planlanmasında zaman çizelgelerine mutlaka dahil edilmelidir.

CI/CD Otomasyonu ile Hata Riskinin Minimizasyonu

Mobil uygulama geliştirme süreçlerinde manuel olarak derleme (build) almak, kod imzalama işlemlerini yerel bilgisayarlarda gerçekleştirmek ve dosyaları mağaza panellerine elle yüklemek, insan hatasına en açık operasyonel adımlardır. Geliştiricinin yerel ortamındaki konfigürasyon farklılıkları, yanlış API uç noktası (endpoint) kullanımı veya hatalı imzalama sertifikaları (provisioning profiles / keystore) nedeniyle yayına hatalı sürümler çıkması riski her zaman mevcuttur. Bu riskleri sıfıra indirmek ve sürüm döngülerini hızlandırmak amacıyla CI/CD (Continuous Integration / Continuous Deployment) süreçlerinin kurulması kurumsal bir standarttır.

Sürekli Entegrasyon (CI) ve Sürekli Dağıtım (CD) süreçleri, kod deposuna (repository) gönderilen her değişikliğin otomatik olarak derlenmesini, test edilmesini ve mağaza dağıtım kanallarına aktarılmasını sağlar. Bu otomasyon mimarisi, sürüm kalitesini standartlaştırırken geliştiricilerin operasyonel iş yükünü hafifletir. Böylece, teknik karar vericiler ve iş sahipleri için zaman ve maliyet tasarrufu sağlayan, insan bağımsız çalışan bir dağıtım mekanizması oluşturulur.

Derleme (Build) Süreçlerinin Otomatize Edilmesi | Otomatik Mağaza Dağıtım Ardışık Düzenleri (Pipelines)

Mobil platformlarda CI/CD pipeline süreçlerini tasarlarken kullanılan en popüler araçlar arasında Fastlane, Bitrise, GitHub Actions, GitLab CI ve Jenkins yer alır. Özellikle Fastlane, mobil uygulamalara özel geliştirilmiş açık kaynaklı bir otomasyon aracı olarak sektör standardı haline gelmiştir. Fastlane, kod imzalama sertifikalarını yönetmeyi (Fastlane Match), mağaza ekran görüntülerini otomatik almayı (Screengrab/Deliver) ve derlenen paketleri (IPA/AAB) doğrudan App Store Connect ile Google Play Console API'leri üzerinden mağazalara göndermeyi sağlar.

[ Kod Deposu (Git Push) ]
          │
          ▼
[ CI/CD Pipeline Tetikleyici (GitHub Actions / Bitrise) ]
          │
          ├─► Statik Kod Analizi (SonarQube)
          ├─► Unit / UI Testlerinin Koşulması
          ▼
[ Kod İmzalama Aşaması (Fastlane Match / Android Keystore Decrypt) ]
          │
          ▼
[ Derleme Üretimi (.ipa / .aab) ]
          │
          ▼
[ Otomatik Mağaza Dağıtımı (TestFlight / Google Play Beta) ]

Otomatik mağaza dağıtım ardışık düzenleri (pipelines) kurulurken, sürüm güvenliğini sağlamak için kod imzalama aşaması kritik bir eşiktir. iOS uygulamalarında Xcode imzalama sertifikalarının ve provizyon dosyalarının tüm ekip arasında senkronize edilmesi için Fastlane Match yaklaşımı tercih edilir. Bu yaklaşım, sertifikaları şifreli bir özel Git deposunda tutarak bulut tabanlı CI/CD runner'larının (örneğin GitHub Actions macOS sunucularının) derleme esnasında bu sertifikaları güvenle çekip imzalama yapmasına olanak tanır. Android tarafında ise Gradle derleme betikleri içerisine gömülen Keystore dosyaları ve şifreleri, CI/CD sistemlerinin güvenli değişkenler (Secrets/Environment Variables) bölümünde saklanarak dinamik olarak çözülür.

Derleme sürecinin otomasyonu, kodun ana dala (main branch) birleştirilmesiyle (merge) başlar. Pipeline tetiklendiğinde ilk olarak statik kod analizi (linter) ve birim testler (unit tests) çalıştırılır. Testlerden başarıyla geçen kod tabanı, hedeflenen ortama göre (Staging, Pre-prod, Production) yapılandırma dosyalarını (Environment/Config files) otomatik olarak değiştirir. Ardından sırasıyla iOS için @@CODE0@@, Android için @@CODE1@@ (Android App Bundle) dosyaları oluşturulur. Elde edilen bu çıktılar, insan müdahalesine gerek kalmaksızın doğrudan Apple ve Google sunucularına API anahtarları aracılığıyla iletilir ve ilgili test kanallarında (TestFlight / Internal Testing) dağıtıma hazır hale getirilir.

App Store ve Google Play Politikalarına Tam Uyum

Mobil uygulama sahipleri için en büyük operasyonel risklerden biri, aylarca süren geliştirme faaliyetlerinin ardından hazırlanan güncellemenin mağaza inceleme süreçlerinde takılması veya tamamen reddedilmesidir (rejection). Apple App Store ve Google Play, kendi ekosistemlerinin güvenliğini, kullanıcı gizliliğini ve kalitesini korumak amacıyla son derece katı kurallar uygular. Bu kurallar statik olmayıp, yasal mevzuatlar (GDPR, KVKK, CCPA), siber güvenlik tehditleri ve kullanıcı eğilimlerine göre sürekli güncellenmektedir. Bu nedenle teknik karar vericilerin, her sürüm öncesinde güncel politikaları yakından takip etmesi gerekmektedir.

Platformların uyguladığı politikalar, uygulamanın teknik mimarisinden pazarlama materyallerine kadar geniş bir yelpazeyi kapsar. Özellikle veri gizliliği beyanları, kullanıcı izleme izinleri (App Tracking Transparency - ATT), çocuklara yönelik içerik kuralları (COPPA) ve üçüncü taraf kütüphanelerin lisans uyumlulukları en sık denetlenen alanlardır. Bu standartlara uyum sağlamak, sadece yasal cezaları önlemekle kalmaz, aynı zamanda uygulamanın mağazalardaki görünürlüğünü ve ASO (App Store Optimization) performansını da doğrudan destekler.

Uygulama İnceleme Süreçlerinde Dikkat Edilmesi Gereken Kritik İhlaller | Sürüm Notlarının (Release Notes) Şeffaf ve Kurumsal Şekilde Hazırlanması

Uygulamanın inceleme sürecinde (App review process) en sık karşılaşılan ret nedenleri ve politika ihlali (policy violation) durumları analiz edildiğinde, belirli teknik ve operasyonel hatalar öne çıkmaktadır. Apple'ın "App Store Review Guidelines" kılavuzunun 2.1 Performance maddesi uyarınca, uygulamanın açılışta çökmesi, eksik işlevler barındırması veya test aşamasında bırakılmış "placeholder" içeriklere sahip olması doğrudan ret sebebidir. Ayrıca her iki platform da, kullanıcı girişi gerektiren uygulamalarda, inceleme ekibinin (reviewers) sistemi tam olarak test edebilmesi için geçerli ve aktif bir test hesabı girilmesini zorunlu kılar. Bu bilgilerin eksik veya hatalı olması, inceleme sürecinin günlerce aksamasına yol açar.

Veri gizliliği ve güvenlik ihlalleri, son dönemde en ağır yaptırımlarla karşılaşılan alanlardır. Apple'ın yürürlüğe koyduğu "Privacy Manifests" (Gizlilik Manifestoları) gereklilikleri doğrultusunda, uygulamanın ve kullanılan tüm üçüncü parti SDK'ların hangi kullanıcı verilerini topladığı, hangi amaçlarla işlediği ve bu verilerin takibinin yapılıp yapılmadığı beyan edilmelidir. Google Play tarafında ise benzer şekilde "Data Safety" (Veri Güvenliği) beyanının güncel tutulması zorunludur. Özellikle kullanıcıların hesaplarını uygulama içerisinden kolayca silebilmesini sağlayan "Hesap Silme" (Account Deletion) özelliğinin bulunmaması, her iki platformda da kritik bir ihlal olarak kabul edilir ve sürüm güncellemesinin engellenmesiyle sonuçlanır.

+-------------------------------------------------------------------------------+
|                      MAĞAZA İNCELEME ENGELLEYİCİLERİ                          |
+-------------------------------------------------------------------------------+
| 1. Eksik Test Hesabı: İnceleme ekibine çalışır durumda test hesabı sunulmaması.|
| 2. Hesap Silme Eksikliği: Kullanıcıya profilini silme imkanı tanınmaması.      |
| 3. Gizlilik Beyanı Hatası: Toplanan verilerin manifestolarda belirtilmemesi.  |
| 4. Placeholder İçerikler: 'Lorem Ipsum' tarzı taslak görsellerin kalması.     |
+-------------------------------------------------------------------------------+

Sürüm yönetiminin kurumsal itibar boyutunu temsil eden en önemli unsurlardan biri de sürüm notları (release notes) içeriğidir. Birçok geliştirici ekip tarafından kolaycılığa kaçılarak hazırlanan "Hata düzeltmeleri ve performans iyileştirmeleri yapıldı" şeklindeki jenerik ifadeler, kurumsal standartlarla bağdaşmamaktadır. Sürüm notları hem son kullanıcıya değer katacak hem de platformların şeffaflık ilkelerine uyacak şekilde tasarlanmalıdır. Yeni eklenen özellikler net ve anlaşılır bir dille listelenmeli, varsa düzeltilen kritik hatalar kullanıcının anlayabileceği bir dille aktarılmalıdır. Şeffaf ve profesyonel sürüm notları, kullanıcı güvenini tesis etmede ve uygulamanın yaşayan, dinamik bir ürün olduğunu hissettirmede doğrudan rol oynar.

Güvenli Dağıtım Modelleri ve Stratejileri

Hazırlanan bir mobil uygulama güncellemesinin aynı anda tüm aktif kullanıcı tabanına sunulması, öngörülemeyen teknik felaketlere zemin hazırlayabilir. Lab ortamlarında veya kapalı test gruplarında tespit edilemeyen bazı donanımsal uyumsuzluklar, bellek sızıntıları veya API yük dengesizlikleri, milyonlarca kullanıcıya ulaşıldığında yıkıcı sonuçlar doğurabilir. Bu durum, markanın prestijine zarar verirken mağaza puanlarının (ratings) hızla düşmesine neden olur. Dolayısıyla, kurumsal sürüm yönetiminde risklerin kademeli olarak dağıtılmasını sağlayan kontrollü canlıya çıkış modelleri benimsenmelidir.

Güvenli dağıtım modelleri, yazılım ekiplerinin canlı ortamdaki kullanıcı davranışlarını ve teknik metrikleri gerçek zamanlı izlemesine olanak tanır. Olası bir hata durumunda tüm kullanıcıların etkilenmesi engellenir ve kriz henüz büyümeden müdahale etme şansı elde edilir. Bu stratejiler, dağıtım sürecini bir gecede tamamlanan riskli bir operasyon olmaktan çıkarıp, günlere yayılan kontrollü ve ölçülebilir bir sürece dönüştürür.

Aşamalı Dağıtım (Phased Rollout) ile Risk Kontrolü | Zorunlu Güncelleme (Force Update) Mantığı ve Doğru Kullanımı

Aşamalı dağıtım (Phased rollout veya Staged rollout), yeni bir uygulama sürümünün kullanıcıların yalnızca belirli bir yüzdesine kademeli olarak açılması yöntemidir. Bu strateji sayesinde, uygulamanın yeni sürümünde kritik bir hata olması durumunda sadece küçük bir kullanıcı grubu bu hatadan etkilenir. Google Play Console, geliştiricilere tamamen esnek bir staged rollout yapısı sunar; güncelleme oranı isteğe göre %1, %5, %20, %50 ve %100 gibi değerlerle manuel olarak artırılabilir veya süreç herhangi bir aşamada tamamen duraklatılabilir.

+---------------------------------------------------------------------------------+
|                   APPLE PHASED RELEASE 7 GÜNLÜK ZAMAN ÇİZELGESİ                 |
+---------------------------------------------------------------------------------+
| Gün 1: %1  | Gün 2: %2  | Gün 3: %5  | Gün 4: %10 | Gün 5: %20 | Gün 6: %50 | Gün 7: %100 |
+---------------------------------------------------------------------------------+
|    * Her an duraklatılabilir (Pause).                                           |
|    * Maksimum duraklatma süresi 30 gündür.                                      |
+---------------------------------------------------------------------------------+

App Store Connect tarafında ise "Phased Release for Automatic Updates" özelliği otomatik olarak 7 günlük standart bir takvim uygular. Bu sisteme göre otomatik güncellemeleri açık olan kullanıcıların; 1. gün %1'i, 2. gün %2'si, 3. gün %5'i, 4. gün %10'u, 5. gün %20'si, 6. gün %50'si ve 7. gün %100'ü güncellemeyi alır. Geliştiriciler bu 7 günlük süreçte, canlı izleme araçlarında bir anomali tespit ettiklerinde dağıtımı istedikleri an duraklatabilirler. Dağıtım duraklatıldığında, yeni sürümü indirmemiş olan kullanıcılara dağıtım durdurulur ve mevcut durum 30 güne kadar askıda tutulabilir. Hata giderildikten sonra yeni bir sürümle süreç sıfırdan başlatılır.

Bazı durumlarda ise uygulamanın eski sürümlerinin çalışmasını tamamen engellemek ve tüm kullanıcıları istisnasız yeni sürüme geçmeye zorlamak gerekir. Bu işleme zorunlu güncelleme (Force update) adı verilir. Zorunlu güncelleme mekanizması; arka uç (backend) API katmanında geriye dönük uyumluluğun tamamen kalktığı köklü değişikliklerde, çok kritik bir güvenlik açığı tespit edildiğinde veya yasal/finansal kuralların değiştiği durumlarda devreye sokulmalıdır.

Zorunlu güncelleme mimarisini kurarken, uygulamanın henüz ilk sürümlerinden itibaren bu mantığı destekleyecek şekilde tasarlanmış olması gerekir. Uygulama açılışında (splash screen) çalışan bir API servisi, uygulamanın mevcut sürüm numarası ile sunucudan dönen "asgari desteklenen sürüm" (minimum supported version) bilgisini karşılaştırır. Eğer mevcut sürüm bu değerin altındaysa, uygulamanın kullanımı engellenir ve ekranda kullanıcının kapatamayacağı, doğrudan App Store veya Google Play sayfasına yönlendiren bir uyarı penceresi (dialog) gösterilir. Bu mekanizma, kullanıcıyı kaybetmeyecek kadar şık, net ve açıklayıcı tasarlanmalı; gereksiz yere her küçük düzeltmede kullanılmamalıdır.

Canlı Ortam İzleme ve Kriz Yönetimi

Yeni bir uygulamanın mağaza onayından geçerek canlıya çıkması, sürüm yönetim sürecinin tamamlandığı anlamına gelmez. Gerçek kullanıcı dünyası; zayıf internet bağlantıları, yetersiz bellek miktarları, farklı arka plan kısıtlamaları ve öngörülemeyen kullanıcı davranışları ile doludur. Bir sürümün başarısı, laboratuvar ortamında değil, gerçek dünya koşullarında gösterdiği kararlılıkla ölçülür. Bu nedenle sürüm yönetimi stratejisinin en kritik bacaklarından biri, canlı izleme (telemetry) ve kriz yönetimi aşamasıdır.

Canlı ortamda meydana gelen hatalara ve performans düşüşlerine (performance degradation) anında müdahale edebilmek, kullanıcı kaybını önlemenin en etkili yoludur. Gelişmiş telemetri sistemleri, hata oluştuğu anda geliştirici ekibe detaylı hata günlükleri (stack traces) ve kullanıcı işlem adımlarını (breadcrumbs) göndererek sorunun kaynağının dakikalar içinde tespit edilmesini sağlar. Başarılı bir kriz yönetimi, önceden tanımlanmış eylem planları ve net görev dağılımları ile mümkündür.

Crashlytics ve Performans İzleme Araçlarının Rolü | Sürüm Geri Alma (Rollback) ve Hotfix Uygulama Prosedürleri

Uygulamanın sağlık durumunu izlemek için Firebase Crashlytics, Sentry, Instabug ve New Relic gibi gelişmiş araçlar kullanılır. Özellikle Firebase Crashlytics, gerçek zamanlı çökme raporlaması sunarak uygulamanın "Crash-free Users" (Çökme Yaşamayan Kullanıcılar) oranını takip etmeyi sağlar. Kurumsal standartlarda bir uygulamanın çökme yaşamayan kullanıcı oranının %99.9'un üzerinde (SLA standardı) olması hedeflenir. Çökme raporlarının anlamlı olabilmesi için iOS tarafında dSYM dosyalarının, Android tarafında ise ProGuard veya R8 obfuscation mapping (kod karartma eşleme) dosyalarının CI/CD pipeline aracılığıyla otomatik olarak bu platformlara yüklenmesi gerekir. Aksi takdirde, hata günlükleri okunamaz ve anlamlandırılamaz ham bellek adreslerinden ibaret kalır.

Canlı Sürüm Yayında 
    │
    ▼
[ Telemetri İzleme (Crashlytics / Sentry) ]
    │
    ├─► Durum Stabil: Süreci tamamla.
    ▼
[ Hata Tespiti (Çökme Oranı > %0.1) ]
    │
    ├─► Dağıtımı Acil Durdur (Pause Rollout)
    ▼
[ Kriz Değerlendirmesi ]
    │
    ├─► Platform Desteği Varsa: Geriye Dön (Rollback)
    └─► Platform Desteği Yoksa: Acil Yama Çık (Hotfix Pipeline)

Canlıda büyük bir hata tespit edildiğinde atılacak ilk adım, krizin büyümesini önlemek için dağıtımın derhal durdurulmasıdır. Eğer aşamalı dağıtım (staged rollout) devredeyse, yeni sürümün dağıtımı hemen duraklatılarak etkilenen kullanıcı havuzu sınırlandırılır. Bu aşamada teknik karar vericilerin önünde iki senaryo bulunur: Sürüm geri alma (Rollback / Downgrade) veya acil yama (Hotfix) yayınlama.

Mobil platformların doğası gereği, yayınlanmış bir sürümü web sitelerinde olduğu gibi tek bir tuşla anında eski haline döndürmek teknik olarak mümkün değildir. Apple App Store, doğrudan bir önceki sürüme geri dönme (downgrade) mekanizmasını desteklemez. Google Play Console ise belirli koşullar altında (örneğin sürüm kodunu yapay olarak artırıp eski kararlı paketi tekrar yükleyerek) dolaylı yollarla geri almaya izin verir ancak bu işlem de mağaza onay sürecine tabidir. Bu teknik kısıtlar nedeniyle, mobil dünyada kriz yönetiminin temel çözümü hızlı bir Hotfix (Acil Yama) operasyonudur.

Hotfix süreci, sadece tespit edilen kritik hatayı çözmeye odaklanan, minimum kod değişikliği içeren özel bir pipeline dalı (hotfix branch) üzerinden yürütülür. Hazırlanan bu acil düzeltme paketi, tüm test süreçlerinden hızlandırılmış olarak geçirilerek mağazalara iletilir. Apple App Store tarafında, inceleme sürecini hızlandırmak için acil durumlarda kullanılabilecek "Expedited Review" (Hızlandırılmış İnceleme) talebinde bulunulabilir. Bu talep, haklı teknik gerekçeler sunulduğunda Apple tarafından genellikle birkaç saat içinde onaylanır ve acil yamanın kullanıcılara hızla ulaşması sağlanır.