Flutter Uygulamasını Play Store ve App Store'a Yayınlama: Adım Adım Rehber

applicationId (Android) ve Bundle ID (iOS), uygulamanızın mağazalardaki kalıcı kimliğidir; ilk yüklemeden sonra hiçbiri değiştirilemez. Yayına başlamadan önce ikisini de kesinleştirin — değiştirmek isterseniz sıfırdan yeni bir liste açmanız, yani mevcut yorum ve kurulum sayısını kaybetmeniz gerekir.

Flutter'da sürüm numarası pubspec.yaml içindeki version: x.y.z+N alanında tutulur; x.y.z kullanıcıya görünen sürüm, N ise build numarasıdır ve aynı anda hem Android versionCode hem iOS build number'a karşılık gelir. Her yeni mağaza yüklemesinde N'yi artırmadan gönderim reddedilir.

İkon gereksinimleri iki mağazada farklıdır: Play, 512x512 piksel ve alfa kanallı (şeffaf) bir yüksek çözünürlüklü ikon ister; App Store ise 1024x1024 piksel, alfa kanalı OLMAYAN bir PNG bekler. flutter_launcher_icons paketiyle tek bir kaynak görselden ikisini de tek komutla üretebilirsiniz.

flutter build appbundle --release komutu build/app/outputs/bundle/release/app-release.aab konumunda mağazaya hazır paketi üretir. Play Store artık yeni yüklemeler için yalnızca .aab formatını kabul eder; ayrı bir .apk üretmenize gerek yoktur.

13 Kasım 2023'ten sonra açılan kişisel (bireysel) Play Console hesapları, production erişiminden önce en az 12 aktif test kullanıcısıyla kesintisiz 14 günlük bir kapalı test tamamlamak zorundadır. Bu şart kurumsal hesaplara ve daha önce açılmış kişisel hesaplara uygulanmaz; başvurudan önce Play Console'daki güncel şartı kontrol edin çünkü kural zaman zaman değişiyor.

Bir uygulamanın Play Console'a yüklenen İLK .aab dosyası her zaman elle yüklenir, otomatik/CLI gönderim kullanılamaz; sonraki sürümlerde CLI veya kendi entegrasyonunuzu kullanabilirsiniz. Production'a çıkarken tüm kullanıcılara birden değil, aşamalı yayınla (ör. %5-%20'den başlayıp Android vitals'ı izleyerek kademeli artırma) başlamanız riski azaltır.

flutter build ipa --release komutu build/ios/ipa/ altında yayına hazır bir .ipa dosyası üretir. Bu build'i arşivlemek ve App Store Connect'e göndermek için bir Mac (fiziksel veya bulut) gereklidir; Xcode Windows veya Linux'ta çalışmaz. Mac'iniz yoksa Codemagic, GitHub Actions macOS runner'ları veya MacStadium gibi bulut CI hizmetlerini kullanabilirsiniz.

Üretilen .ipa'yı Xcode Organizer'ın (Window > Organizer > Archives > Distribute App) akışıyla ya da bağımsız Transporter uygulamasıyla App Store Connect'e yükleyebilirsiniz; ikisi de aynı sonucu verir. Sürüm (version, kullanıcıya görünür) ve build numarası (her yüklemede benzersiz ve artan olmalı, aynı sürüm içinde tekrar kullanılamaz) ayrı iki alandır.

TestFlight iki test katmanı sunar: İç test (App Store Connect ekibinizdeki en fazla 100 kişiye yönelik) Apple incelemesi GEREKTİRMEZ ve build işlendikten hemen sonra kullanılabilir. Dış test ise e-posta veya genel bağlantıyla katılan (grup başına 10.000'e kadar) test kullanıcılarına yöneliktir; bir uygulamaya eklenen İLK build Apple'ın "beta review" incelemesinden geçmek zorundadır (genellikle bir gün içinde sonuçlanır), sonraki build'ler ise tam incelemeden muaf olabilir.

Play tarafında karakter sınırları katıdır: uygulama adı en fazla 30, kısa açıklama en fazla 80, uzun açıklama en fazla 4000 karakter. App Store Connect'te uygulama adı tüm mağazada tekil olmalı ve ayrıca altyazı (subtitle) ile anahtar kelime alanı doldurulur. Ekran görüntüsü boyutları (Play'de telefon için 1080x1920, App Store'da 6.9 inç iPhone sınıfı için tam piksel eşleşmesi) her iki mağazada farklı kurallara tabidir.

İki mağaza da veri toplama davranışınızı beyan etmenizi ister: Play'de Veri Güvenliği (Data safety) formu, App Store'da App Privacy ("besin değeri" olarak da anılır) etiketleri. Reklam SDK'sı, analitik veya çökme raporlama kullanıyorsanız bunu her ikisinde de doğru işaretlemeniz gerekir; her iki panel de gerçekten erişilebilir, güncel bir gizlilik politikası URL'si olmadan yayına izin vermez.

Her iki panel ayrıca bir destek/iletişim alanı ister: Play'de hesap düzeyinde bir destek e-postası ve isteğe bağlı bir web sitesi alanı, App Store Connect'te ise zorunlu bir Support URL ve isteğe bağlı bir Marketing URL. Bu alanlar için web siteniz yoksa pratik çözümleri ayrı bir yazıda ele alıyoruz.

Apple tarafında en sık görülen red nedenleri: Kural 2.1(a) (çökme, boş ekran, çalışmayan bağlantı, beyan edilmemiş eksik özellik veya giriş gerektiren bir özellik için İnceleme Notları'na çalışan bir demo hesap bırakılmaması), Kural 5.1.1 (izin açıklama metinlerinin boş/anlamsız olması) ve Kural 4.3 (küçük değişikliklerle tekrar gönderilen şablon uygulamalar). Göndermeden önce temiz bir cihazda uçtan uca test etmek bu üçünün çoğunu önler.

Play tarafında en sık sorun, Veri Güvenliği formunun gerçek SDK davranışıyla uyuşmaması ya da gizlilik politikası URL'sinin boş/erişilemez olmasıdır; ikisi de reddedilme ya da sonradan askıya alınma riski taşır. AdMob kullanıp app-ads.txt doğrulaması yapmamak doğrudan red getirmez ama reklam gösteriminin kısıtlanmasına ve gelir kaybına yol açabilir.

Expo (EAS) kullanan projelerde akış büyük ölçüde otomatikleşir: npx eas-cli build --platform all --profile production komutu her iki mağaza için de build'i bulutta üretir, npx eas-cli submit ise (Play'deki ilk yükleme istisnası dışında) gönderimi otomatikleştirir. Sürüm numaraları Flutter'daki tek pubspec.yaml alanı yerine app.json içinde expo.version, expo.ios.buildNumber ve expo.android.versionCode olarak üç ayrı alanda tutulur ve elle senkron kalmalıdır.