Bölüm 11 — Konu 53: Store Yayınlama Süreci (İmzalama, Listing, Versiyonlama)

Bölüm 9 Konu 44'te build sistemlerinin mekaniğini (.apk/.aab/.ipa, imzalama temelleri) öğrenmiştik. Bu ders, o mekaniği gerçek bir yayınlama sürecine bağlıyor — Play Store'a ve App Store'a bir uygulamayı nasıl koyduğunu, adım adım.

#Play Store — Google Play Console

#1. Geliştirici Hesabı ve İlk Kurulum

Play Console'a erişim, bir kerelik $25 ücretle satın alınan bir geliştirici hesabı gerektirir (Bölüm 9 Konu 44'teki karşılaştırma tablosunu hatırla). Hesap oluşturduktan sonra, her uygulama için yeni bir "uygulama oluştur" girişi açılır — burada applicationId'nin (Konu 44) Play Console'daki karşılığı kaydedilir.

#2. İmzalama — Play App Signing

flutter build appbundle --release

Konu 44'te kendi keystore'unu (.jks) oluşturmayı öğrenmiştik. Google, artık "Play App Signing" adında bir sistemi zorunlu kılıyor: sen .aab dosyanı kendi keystore'unla imzalayıp yüklüyorsun, ama Google, kullanıcıya giden nihai APK'yı kendi sunucularında, kendi anahtarıyla yeniden imzalıyor. Bu, Konu 44'te bahsettiğimiz "keystore'unu kaybedersen güncelleyemezsin" riskini büyük ölçüde azaltır — keystore'unu kaybetsen bile, Google'ın kendi güvenlik sürecinden geçerek kimlik doğrulama yaparak yeni bir anahtar talep edebilirsin.

#3. Test Aşamaları (Release Tracks)

İç Test (Internal Testing)  →  en hızlı, sadece belirlediğin kişiler (dakikalar içinde yayınlanır)
Kapalı Test (Closed Testing) →  daha geniş bir grup (örn. 100-1000 kişi)
Açık Test (Open Testing)     →  Play Store'da HERKESİN katılabileceği bir beta
Üretim (Production)          →  gerçek, herkese açık yayın

Neden bu aşamalar var? Bölüm 10 Konu 45-46'da testler ve CI ile kod hatalarını yakalamayı öğrenmiştik — ama gerçek kullanıcı davranışı (farklı cihazlar, farklı ağ koşulları, beklenmedik kullanım şekilleri), otomatik testlerin hiçbir zaman tam olarak yakalayamayacağı bir şeydir. Bu aşamalı sistem, hataları giderek büyüyen bir gruba göstererek, üretime çıkmadan önce yakalama şansı veriyor.

#4. Store Listing (Mağaza Sayfası)

Uygulamanın Play Store'daki görünen yüzü:

• Başlık ve kısa açıklama — arama sonuçlarında görünen kısım.
• Tam açıklama — özellikler, kullanım senaryoları.
• Ekran görüntüleri — farklı cihaz boyutları için ayrı ayrı yüklenmesi gerekir (telefon, tablet).
• Gizlilik politikası URL'si — zorunludur, özellikle Bölüm 9'da öğrendiğimiz izinleri (kamera, konum) kullanan uygulamalar için Google titizlikle kontrol eder.
• İçerik derecelendirmesi (content rating) — bir anket doldurarak (şiddet, kullanıcı içeriği gibi sorular) otomatik belirlenir.

Pratik uyarı: Gizlilik politikası ve izin kullanım açıklamaları (Bölüm 9 Konu 41'de iOS için gördüğümüz UsageDescription metinlerine benzer bir mantık, Android tarafında da Play Console'un "Data Safety" formunda karşına çıkar), Google'ın inceleme sürecinde en sık reddetme sebeplerinden biridir — özellikle konum/kamera gibi hassas izinler kullanıyorsan, neden kullandığını açıkça beyan etmen gerekir.

#5. Staged Rollout — Kademeli Yayın

%5 kullanıcıya yayınla → sorun yok → %20'ye çıkar → ... → %100

Üretime çıkarken bile, doğrudan %100 yerine, Play Console kademeli yayın (staged rollout) sunar — yeni sürümü önce kullanıcıların küçük bir yüzdesine gösterir. Eğer çökme oranı (crash rate) artarsa, yayını durdurabilir ve sorunu düzeltip tekrar deneyebilirsin — bu, Bölüm 10 Konu 48'de öğrendiğimiz DevTools/profiling disiplinin, üretim ortamında devam eden hali gibi düşünebilirsin (artık senin cihazın değil, gerçek kullanıcıların verisiyle).

#App Store — Apple App Store Connect

#1. Apple Developer Hesabı

Konu 44'te bahsettiğimiz gibi, yıllık ~$99 ücretli bir Apple Developer hesabı gerekir. Play Store'dan farklı olarak, hesap bireysel ya da kurumsal olabilir — kurumsal hesap, bir DUNS numarası (şirket kimlik numarası) gerektirir.

#2. TestFlight — Apple'ın Test Sistemi

flutter build ipa --release

TestFlight, Play Console'un iç/kapalı/açık test aşamalarının Apple karşılığıdır — ama tek bir araçta birleşmiştir. Dahili test (kendi takımın, 100 kişiye kadar, App Review gerektirmez) ve harici test (dışarıdaki kullanıcılar, App Review'dan geçmesi gerekir, 10.000 kişiye kadar) olmak üzere iki modu var.

#3. App Review — Apple'ın İnceleme Süreci

Bu, Play Store'a göre en büyük fark noktasıdır. Google Play, yeni bir sürümü genelde otomatik/hızlı bir incelemeden geçirirken, Apple'ın App Review'u insan gözden geçirmesi içerir ve genelde 1-3 gün sürer. Apple'ın App Store Review Guidelines'ı, uygulamanın:

• Çökmemesi gerektiğini (temel bir kalite barajı),
• Konu 41'deki izin açıklamalarının anlamlı ve doğru olması gerektiğini,
• Belirli kategorilerde (ödeme, kullanıcı içeriği, çocuklara yönelik uygulamalar) ek kurallara uyması gerektiğini belirtir.

Pratik tavsiye: İlk yayınlamadan önce App Review Guidelines'ı (Apple'ın resmi dokümantasyonu) en azından bir kez gözden geçirmek, reddedilme döngüsünü (düzelt → tekrar gönder → 1-3 gün bekle → tekrar reddedilme) önlemenin en etkili yoludur.

#4. Metadata ve Ekran Görüntüleri

Play Store'a çok benzer bir süreç: başlık, açıklama, anahtar kelimeler (App Store'a özgü, arama sıralamasını etkiler), ekran görüntüleri (her cihaz boyutu için ayrı ayrı, App Store bunları otomatik ölçeklemez).

#Versiyonlama — İki Katmanlı Sistem

# pubspec.yaml
version: 1.2.0+7

Bu tek satır, aslında iki farklı sayı sistemini birleştiriyor:

1.2.0 — semantic versioning (anlamsal sürümleme), Dart Bölüm 12'de paket ekosistemini işlerken kısaca değindiğimiz bir kavram: BÜYÜK.KÜÇÜK.YAMA (MAJOR.MINOR.PATCH). Büyük sürüm, geriye uyumsuz bir değişikliği; küçük sürüm, geriye uyumlu yeni özellikleri; yama, hata düzeltmelerini işaret eder. Kullanıcının Store'da gördüğü sürüm numarası budur (Konu 44'teki versionName).

+7 — bu, Konu 44'te öğrendiğimiz versionCode'un (Android) ve iOS'taki karşılığı CFBundleVersion'ın kaynağıdır — flutter build, bu sayıyı otomatik olarak ilgili platform dosyalarına yansıtır. Kritik kural: her yayında (hatta her Store'a yükleme denemesinde), bu sayı kesinlikle önceki yüklemeden büyük olmalıdır — Store'lar, aynı ya da daha küçük bir build numarasıyla yükleme reddeder.

Pratik akış:

1.0.0+1  → ilk yayın
1.0.1+2  → küçük bir hata düzeltmesi (yama)
1.1.0+3  → yeni bir özellik eklendi (küçük sürüm)
2.0.0+4  → büyük bir mimari değişiklik / geriye uyumsuz (büyük sürüm)

#Sürüm Notları (Release Notes) — Küçümsenmemesi Gereken Bir Detay

Her yayında, kullanıcıya "bu sürümde ne değişti" açıklaması yazman gerekir (Store'ların ikisinde de). Bu, sadece formalite değildir — kullanıcıların güncellemeye güvenmesini sağlayan, ve destek talebi sayısını azaltan bir iletişim aracıdır. İyi bir alışkanlık: her sürümde, kullanıcının fark edeceği değişiklikleri (yeni özellik, düzeltilen bir sorun), teknik jargon olmadan, 2-3 madde ile özetlemek.

#🎯 Bu Dersten Çıkarılması Gerekenler

• Play Store'da Play App Signing, kendi keystore'unu kaybetme riskini azaltır; iç/kapalı/açık test aşamaları, üretime çıkmadan önce kademeli geri bildirim toplamanı sağlar.
• Staged rollout, üretim yayınını bile kademeli yapar — çökme oranı artarsa yayın durdurulabilir.
• App Store'da TestFlight, test sürecini birleştirir; App Review, Play Store'a göre daha yavaş ve insan gözden geçirmeli bir süreçtir (1-3 gün).
• Gizlilik politikası ve izin açıklamaları, her iki mağazada da en sık reddetme sebeplerinden biridir.
• Versiyonlama iki katmanlıdır: semantic version (1.2.0, kullanıcıya görünen) ve build number (+7, her yüklemede kesinlikle artması gereken, Konu 44'teki versionCode/CFBundleVersion'ın kaynağı).

#📝 Ödevler

• [ ] (Eğer bir hesabın varsa) Play Console'da bir uygulama oluştur, iç test track'ine flutter build appbundle ile üretilmiş bir .aab yükle.
• [ ] Bir uygulamanın store listing metnini (başlık, kısa/uzun açıklama) yaz, en az 3 farklı boyutta ekran görüntüsü hazırla.
• [ ] pubspec.yaml'daki version: satırını değiştirerek, semantic version ve build number'ı birlikte artırdığında flutter build'in ürettiği dosyalardaki (Android versionCode, iOS CFBundleVersion) değişimi gözlemle.
• [ ] Apple'ın App Store Review Guidelines'ından, izinlerle (kamera, konum) ilgili bölümü oku, kendi projendeki izin açıklamalarının (Bölüm 9 Konu 41) bu kurallara uygun olup olmadığını değerlendir.
• [ ] Kendi cümlelerinle, "neden staged rollout'un, tüm kullanıcılara aynı anda yayın yapmaktan daha güvenli olduğunu" açıkla.

Sıradaki konu: Bölüm 11 — Konu 54: App Size, Obfuscation, Flavor Yönetimi (Bölüm 11'in Son Konusu)