Flutter ile geliştirilen uygulama, geliştirme ortaminda sorunsuz calissa bile store yayininda imzalama, izin aciklamalari, bundle kimligi ve inceleme politikalarina takilabilir. App store yayinlama süreci yalnizca "build al ve yükle" degildir; sürüm yönetimi, gizlilik beyani, crash raporlama ve kullanıcı geri bildirim dongusu ile birlikte dusunulmelidir. Bu makale Flutter odaklı teknik adimlari iOS ve Android icin ayri ayri ele alir.
Yayın oncesi hazirlik kontrol listesi
Store'a cikmadan once su maddeler gozden gecirilmelidir:
pubspec.yamlsürüm numarasi:version: 1.2.0+42formati- Üretim API endpoint'leri ve feature flag'ler
- Debug banner, log ve test hesaplarinin kaldirilmasi
- Gizlilik politikasi URL'si ve veri toplama aciklamalari
- Izin metinleri (kamera, konum, bildirim) platform dosyalarinda
- Obfuscation ve symbol dosyasi yedegi (crash cozumleme icin)
Sürüm kodu (+42) her store yuklemesinde artirilmalidir; ayni kodla tekrar yükleme reddedilir.
Android: imzalama ve App Bundle
Google Play artik çoğu yeni uygulama icin APK yerine Android App Bundle (AAB) ister. Flutter'da release build:
flutter build appbundle --release --obfuscate --split-debug-info=build/debug-info/Imzalama icin upload keystore oluşturulur ve android/key.properties ile build.gradle dosyasina baglanir. Keystore dosyasi ve sifreler repoya konmamali; CI secret manager uzerinden enjekte edilmelidir.
Play Console yapilandirmasi
Play Console'da uygulama olusturduktan sonra:
- Internal testing track ile ilk AAB yuklemesi
- Data safety formunu doldurma
- Content rating anketi
- Store listing: baslik, açıklama, ekran goruntuleri
- Production'a promote etme
Flutter uygulamalarinda target SDK surumu Google'in güncel gereksinimine uygun olmalidir; eski targetSdk degerleri incelemede red sebebi olabilir.
iOS: sertifika, profil ve Archive
iOS tarafinda Apple Developer hesabi, App ID, Distribution sertifikasi ve provisioning profile gerekir. Xcode'da Runner hedefinde bundle identifier, signing team ve release configuration ayarlanir. Flutter komutu:
flutter build ipa --release --obfuscate --split-debug-info=build/debug-info/Alternatif olarak flutter build ios --release sonrasi Xcode Organizer uzerinden Archive alinip App Store Connect'e yuklenebilir.
App Store Connect ve TestFlight
Ilk yuklemeden sonra build islenir; eksik export compliance veya encryption sorulari yanitlanmalidir. TestFlight ile internal ve external test kullanıcıları davet edilir. Flutter'da platform özel kod varsa (push, deep link, in-app purchase) test cihazlarinda ayri dogrulama yapin.
Metadata ve ASO temelleri
Store gorunurlugu icin baslik, alt baslik (iOS), kisa açıklama (Android) ve anahtar kelimeler stratejik secilmelidir. Ekran goruntuleri farklı cihaz boyutlari icin hazirlanmali; Flutter uygulamasinin Material ve Cupertino karisiminda tutarlı marka dili korunmali. Video preview opsiyoneldir ancak donusumde etkilidir.
Gizlilik ve uyumluluk
App Tracking Transparency (iOS), GDPR/KVKK metinleri ve üçüncü parti SDK veri paylasimi store incelemesinde sik incelenir. Firebase Analytics, Crashlytics, reklam SDK'lari gibi paketlerin topladigi veriler Data safety ve Privacy Nutrition Label formlarinda açıkça belirtilmelidir. Yanlış beyan uygulamanin kaldirilmasina yol acabilir.
CI/CD ile otomatik yayın
Codemagic, GitHub Actions, Bitrise gibi platformlarda Flutter pipeline tanimlanabilir. Tipik akis: test çalıştır, sürüm numarasini artir, imzali build uret, store API ile yükle. Fastlane supply ve deliver lane'leri Android ve iOS yuklemelerini otomatiklestirir.
# Ornek: surum kodunu CI'da artirma
flutter pub run build_runner build --delete-conflicting-outputs
flutter test
flutter build appbundle --releaseOtomasyonda imza materyallerinin güvenliği en kritik konudur. Keystore ve App Store Connect API key'leri yalnizca şifreli secret olarak tutulmalidir.
Obfuscation ve crash sembolizasyonu
--obfuscate release binary boyutunu ve tersine muhendisligi zorlastirir; ancak stack trace'ler anlamsizlasir. --split-debug-info ile uretilen sembol dosyalari Firebase Crashlytics veya Sentry'ye yuklenmelidir. Her store surumu icin eslesen symbol setini arsivlemek zorunludur.
Inceleme reddi ve sik nedenler
Flutter uygulamalarinda sik karsilasilan red nedenleri:
- Login olmadan calismayan demo hesap bilgisi sunmama
- WebView icindeki odeme akisi (IAP politikasi)
- Eksik izin aciklamasi (
Info.plistusage strings) - Crash veya bos ekran inceleme sirasinda
- Metadata ile gerçek uygulama davranisinin uyumsuzlugu
Inceleme notlarina test kullanıcısı, VPN gereksinimi ve özel yapılandırma adimlarini açıkça yazmak süreci hizlandirir.
Surumleme stratejisi
Semantic versioning kullanın: breaking değişiklik, yeni özellik, patch. Store'da staged rollout (Android) ve phased release (iOS) ile kademeli acilis riski azaltir. Hotfix gerektiginde branch'ten patch surumu cikarip yalnizca kritik duzeltmeyi tasiyin; feature flag ile yarim kalmis isleri kapali tutun.
Release sonrasi izleme
Yayinlandiktan sonra crash-free users, ANR orani, store yorumlari ve retention metrikleri izlenmelidir. Flutter tarafinda firebase_performance ile ilk acilis suresi, firebase_crashlytics ile hata trendi takip edilir. Kritik hata artisinda once rollback veya hızlı patch degerlendirilir.
Platform özel farklar
Ayni Flutter kodu olsa bile iOS ve Android store kurallari farklidir. Örneğin arka plan konum kullanımı Android'de foreground service bildirimi gerektirebilir; iOS'ta ise "Always" izni icin güçlü gerekce sarttir. Platform channel ile native SDK entegre edildiyse her iki tarafta da ilgili manifest ve plist guncellemeleri release checklist'ine eklenmelidir.
Deep linking ve universal links
Store'dan indirme sonrasi kullanıcıyı doğru ekrana tasimak icin deep link yapilandirmasi release oncesi test edilmelidir. Android App Links ve iOS Universal Links icin domain dogrulama dosyalari, intent filter ve associated domains ayarlari birlikte calismalidir. Flutter tarafinda go_router veya app_links paketi ile gelen URI'nin cold start ve warm start senaryolarinda parse edildigini otomatik testlerle dogrulayin.
In-app purchase ve abonelik
Dijital ürün satan uygulamalarda store politikasi platform odeme sistemini zorunlu kilar. in_app_purchase paketi ile receipt dogrulama, restore purchases ve fiyat yerellestirmesi release checklist'ine eklenmelidir. Sandbox test hesaplari ile abonelik yenileme ve iptal akislari TestFlight ve Play internal track uzerinde ayri ayri dogrulanir.
Localization ve bolgesel gereksinimler
Store listing birden fazla dilde hazirlanabilir; uygulama icindeki flutter_localizations ile tutarlı olmali. Bazi bolgelerde veri ikamet gereksinimi veya yas dogrulamasi ek metadata ister. Sürüm notlarinda kullanıcıya gorunen dilde anlamli değişiklik maddeleri yazmak, güncelleme kabul oranini artirir.
Özet
Flutter uygulamasini store'a tasimak; doğru imzali build, eksiksiz metadata, gizlilik formlari ve test edilmis release adayini bir araya getirmeyi gerektirir. Android'de AAB ve Play Console track'leri, iOS'ta Archive ve TestFlight süreci teknik omurgayi oluşturur. CI otomasyonu ve symbol yönetimi ile tekrarlanabilir, güvenli yayın dongusu kurulabilir.
Store ekran goruntulerini otomatik üretmek icin integration test ve screenshot callback kullanılabilir. Boylece her major surumde görsel set güncel kalir.
iOS'ta dSYM dosyalarini her Archive sonrasi yedekleyin; Crashlytics sembol yuklemesi olmadan stack trace cozulemez. Android tarafinda mapping.txt ayni rolu oynar.
Uygulama icerisinde acilacak web sayfalari ve deeplink scheme'leri store metadata ile uyumlu olmali. App Links ve Universal Links yapilandirmasi eksikse pazarlama kampanyasi kirilabilir.
Store incelemesine gondermeden once gerçek cihazda düşük depolama ve düşük ag senaryolarini test edin; incelemeci cihazlari her zaman optimal kosullarda olmayabilir.
Her release adayinda CHANGELOG ve known issues listesini ekip icinde paylasin; store sürüm notlari ile uyum saglanmali.
Play App Signing etkinse upload key kaybini onlemek icin Google'in yedekleme politikasini okuyun; iOS tarafinda Distribution sertifika suresi dolmadan once yenileme takvimi olusturun.
