Bu Flutter yayın hazırlık kontrol listesini imzalama, build flavor’ları, çökme raporlama, izin metinleri ve mağaza varlıklarını hazırlamak için kullanın; böylece ilk gönderiminiz sakin ve eksiksiz olur.
“Yayın hazır” demek “uygulama telefonumda çalışıyor” demek değildir. Bu, üretim yapısı oluşturup temiz bir cihaza yükleyebildiğiniz ve mağazaya son dakika sürprizleri olmadan gönderebildiğiniz anlamına gelir.
İlk gönderimden hemen önce bozulan şeyler genellikle sıkıcı ama can sıkıcıdır: eksik imzalama anahtarları, kazara yüklenen debug yapı, yararlı kayıt olmayan çökme raporları, kuşkulu görünen izin istemleri veya uygulamayla uyuşmayan mağaza varlıkları (yanlış simgeler, eski ekran görüntüleri, eksik gizlilik metni).
İlk Flutter gönderimi için “yayın hazır” dört sonuca indirgenir:
Bu rehber ilk gönderim için gerekli temel konulara odaklanır: imzalama, flavor’lar, çökme raporlaması, izin metinleri ve zamanlaması, ve mağaza varlıkları. Tam bir QA planı, performans denetimi veya hukuki inceleme değildir.
En az birkaç odaklanmış oturumu planlayın. Tek geliştirici bu işleri genellikle 1–2 günde halledebilir. Ekipte, net sahipler atayın (imzalama/derlemeler, çökme raporlaması, mağaza listelemesi ve metin) ki hiçbir şey son saate kalmasın.
Çoğu “son dakika” yayın problemi, erken aşamada vermediğiniz kararların sonucudur. Birkaç temel noktayı şimdi kilitleyin, gerisi daha basit olur.
Önce kimlikten başlayın: kullanıcıların göreceği tam uygulama adı ve mağazaların kullandığı iç kimlikler (Android’de package name, iOS’ta bundle identifier). Bunları sonradan değiştirmek güncelleştirmeleri, derin bağlantıları ve analitik geçmişini bozabilir. Ayrıca sürümleme stratejinizi de kararlaştırın ki her yapının net bir numarası olsun ve neyin yayında olduğunu tahmin etmek zorunda kalmayın.
Sonra platform sınırlarını belirleyin: ilk günde Android, iOS veya her ikisi mi olacak, ve destekleyeceğiniz minimum işletim sistemi sürümleri hangileri. Minimum sürümü sonradan yükseltmek tasarım değişiklikleri gerektirebilir veya desteklediğinizi düşündüğünüz cihazları dışlayabilir.
Bu kararları ekibinizin ulaşabileceği bir yerde yazılı tutun:
Son olarak, mağaza hesaplarınızın var olduğunu ve yayımlama yapabildiğinizi doğrulayın. Hesap onayı beklemek, eksik vergi formları veya yükleme izni olmayan bir hesap lansmanı durdurur. Bir araçla (ör. Koder.ai) uygulamayı üretiyor olsanız da, elle kodluyor olsanız da bu kararlar geçerlidir.
Uygulama imzalama, bir güncellemenin gerçekten sizden geldiğinin kanıtıdır. İmzalama yanlış yapılandırılmışsa mağaza yüzeyi reddedebilir veya gelecekte güncellemeleri gönderemeyebilirsiniz.
Android’de imzalama genellikle bir keystore dosyasında saklanan upload anahtarı (ve parolalar) anlamına gelir. iOS’ta ise Apple Developer hesabına bağlı sertifikalar ve provisioning profilleri vardır. Koder.ai ile derleyip kaynak dışa aktarsanız bile, ilk gönderimden önce mağaza hesaplarının ve imzalama varlıklarının sahipliği net olmalıdır.
Her platform için bir kayıt-sistemi sahibi seçin; ideal olan şirket hesabıdır, kişisel değil. Erişim kuralları belirleyin ki tek bir dizüstü bilgisayara veya tek bir kişiye bağlı kalmayın.
Kısa bir kayıt tutun ve şu sorulara cevap verin:
Kaybolan bir Android anahtarı aynı paket adına gelecekteki güncellemeleri engelleyebilir. Şifrelenmiş bir yedek ayrı bir yerde tutun ve geri yüklemeyi test edin. iOS’ta erişimi kaybetmek genellikle hesap kurtarma zorluğuna dönüşür; bu yüzden birden fazla güvenilir admin tutun ve kim olduklarını belgeleyin.
İmzalamayı temiz bir makinada doğrulayın (yeni checkout, yeni CI runner veya bir ekip arkadaşının dizüstü bilgisayarı). Eğer sadece tek bir bilgisayarda çalışıyorsa, hazır sayılmaz.
Flavor’lar, “telefonumda çalışıyor” durumunun “test sunucusunu gönderdik”e dönüşmesini engeller. Basitçe söylemek gerekirse, bir flavor aynı konfigürasyonu farklı ayarlarla isimlendirmenizi sağlar, böylece her yayın öncesi dosyaları elle değiştirmezsiniz.
Çoğu ekip iki flavor ile başlamalı: dev (test için) ve prod (göndereceğiniz yapı). Ekip “staging” diyorsa o kelimeyi kullanın. Karışık isimler yanlış yapının paylaşılmasına veya yüklenmesine yol açar.
Flavor’lar arasında neyin farklı olduğunu kilitleyin. En yaygın farklar uygulama kimliği (ad ve bundle ID), simgeler, API endpoint’leri, özellik bayrakları, analytics/çökme ayarları ve loglama seviyesidir.
Gizli değerleri repoya koymayın: environment dosyaları, CI secret’ları veya build-zamanı değişkenleri kullanın ki anahtarlar commitle sonradan karışmasın.
Tamam dediğinizde, kullanmayı planladığınız her flavor’ı, dahil üretim release yapısını da inşa edin. Eksik konfigürasyonlar burada görünür, yayın gününde değil.
Temiz bir yapı gönderip gerçek dünya sorunlarını kaçırabilirsiniz: tuhaf cihazlar, zayıf ağlar ve kenar durum akışları. Çökme raporlaması bu sürprizleri düzeltilebilir bir listeye çevirir.
Bir çökme raporlama aracı seçin ve bunu erken bağlayın. Marka/tedarikçi daha az önemlidir; önemli olan her sürümden yararlı raporlar gelmesidir.
“Tekrar edilemiyor” durumların çoğu eksik sembollerden gelir. Yayın adımı olarak şunları yüklemeyi zorunlu hale getirin:
Eğer bu manuelse, yoğun bir haftada atlanacaktır.
İlk günde ihtiyacınız olan bilgileri belirleyin: uygulama versiyonu/build, cihaz modeli, OS sürümü, locale ve son ekran veya eylem. Hesaplarınız varsa, stabil anonim kullanıcı ID’si ve “oturum açık/kapalı” bayrağı ekleyin. Kişisel verilerden kaçının.
Ayrıca fatal olmayan hataları da yakalayın. Flutter’da birçok sorun aplikasyonu çökertmeyen istisnalar şeklinde görünür (parse hataları, zaman aşımı, beklenmeyen null’lar). Bunları kısa bir mesaj ve birkaç anahtar-değer alanıyla non-fatal olay olarak gönderin.
Bunu yayından önce test edin: bir staging yapı oluşturun, gizli bir menü veya jestle kasıtlı çökme tetikleyin ve doğru versiyon ve bağlamla okunabilir bir yığın izinin geldiğini doğrulayın.
İzinler, ilk açılışta güveni kaybetmenin hızlı bir yoludur. Yayından önce uygulamanızın isteyebileceği her izni, bu iznin hangi özellik için gerektiğini ve kullanıcının ne kazanacağını listeleyin. Bir cümleyle açıklayamıyorsanız, muhtemelen istememelisiniz.
Metni sade ve spesifik tutun. “Fotoğraflarınıza erişmemiz gerekiyor” yerine “Makbuz eklemek için fotoğraflara izin verin” daha güçlüdür. “Depolama” gibi teknik kelimelerden kaçının ya da o an ne anlama geldiğini açıklayın.
Sadece kullanıcı ilgili eylemi tetiklediğinde sorun. Uygulama açılışında Fotoğraflar izni istemeyin. Kullanıcı “Fotoğraf ekle”ye dokunduktan sonra kısa bir ön-izin ekranı gösterin ve ardından sistem iznini isteyin.
Kullanıcı hayır derse, uygulama yine de kullanılabilir olmalı. Çekirdeği önceden planlayın: özelliği görünür tutun, neyin kısıtlandığını açıklayın, mümkünse alternatif sunun ve kullanıcı çalışmasını kaybetmesin. “Bir daha sorma” seçeneği seçildiyse, Ayarlar’a nasıl gidileceğini yönlendirici şekilde gösterin ama rahatsız etmeyin.
Platforma özgü metinleri iki kez kontrol edin. iOS Info.plist’te kullanım açıklamaları gereklidir. Android manifest girişleri doğru olmalı ve bazen kısa bir uygulama içi açıklama gerekir. Eksik veya belirsiz metin inceleme gecikmelerine veya kullanıcı kaybına neden olabilir.
Bu, gerçek bir release yapıda ortaya çıkan sorunları yakalamaya yönelik hafif bir geçiştir. Bir saatin altında çalıştırabileceğiniz şekilde tutun.
Geliştirici araçları olmasa bile herkesin izleyebileceği basit bir betik yazın. Kural: kullanıcıların yaptığı işleri test edin, geliştiricilerin inceleyebileceklerini değil.
En az bir küçük telefon ve bir daha büyük cihazda (mümkünse bir daha eski OS sürümünde) çalıştırın:
Çalıştırmadan sonra uygulamayı zorla kapatıp yeniden başlatın; uygulama temiz başlamalı ve sıcak duruma bağımlı olmamalı.
Bir şey başarısız olursa, tam ekranı, son eylemi ve yalnızca bir cihaz boyutunda olup olmadığını not edin. Bu genellikle hızlı bir düzeltme için yeterlidir.
Birçok lansman stresi koddan değil mağaza sayfalarından gelir. Listelemeyi yayın işinin bir parçası gibi ele alın; böylece son dakika tasarım talepleri, eksik gizlilik cevapları ve ekran görüntüsü karmaşası yaşamazsınız.
Neredeyse kesinlikle ihtiyacınız olacakları toplayın: uygulama ikonu, ekran görüntüleri, kısa bir alt başlık, uzun açıklama ve platforma özel gereken grafikler. Tanıtım videosu opsiyoneldir ve ancak güncel tutabiliyorsanız değerlidir.
Ekran görüntüleri için cihaz boyutlarını erken seçin ve ona bağlı kalın. Tutarlı bir sıra kullanın (onboarding, ana ekran, ana özellik, ayarlar, yükseltme) ki güncellemeler telaş olmasın.
Açıklamayı insan dilinde yazın: uygulamanın ne yaptığını bir cümlede açıklayın, ardından birkaç kısa fayda satırı ve varsa abonelikler veya hesap gereksinimleri hakkında net bir not. Söyleyemeyeceğiniz şeyleri vaat etmeyin.
Gizlilik ve veri kullanım cevaplarını da şimdi toplayın. Takip, toplanan veri türleri ve izinler hakkında sorulacaktır. Uygulama konum, kişiler veya fotoğraflar istiyorsa nedenini basitçe açıklayın.
Varlıkları düzenli tutarsanız, güncellemeler rutin olur. Basit bir yapı yeterlidir (ikon, cihaz türüne göre ekran görüntüleri, metin, gizlilik notları ve sürüm notları).
Kuru çalışma, mağaza gönderim akışını yayınlayacakmış gibi baştan sona geçmektir ama Publish tuşuna basmadan durmaktır. Tahminleri gerçek cevaplara çevirir.
Göndermeye hazır olacağınız bir yapıyı seçin (gerçekten yayımlamayabilirsiniz). Yapıyı yükleyin, formları doldurun ve her şeyi taslak olarak kaydedin. Eksik bilgileri zaman varken bulmak istersiniz.
Doğrulayın:
İlk sürüm kötü olursa ne yapacağınızı planlayın. Geri alma (önceki imzalı artefaktı saklama), sıcak düzeltme gönderme ve dağıtımı durdurma tetikleyicilerini belirleyin (çökme artışı, oturum açma hataları).
Ayrıca ilk 48 saatte erken geribildirim toplama yöntemini belirleyin. Küçük bir grup kanalı, gerçekten izlediğiniz bir destek gelen kutusu ve uygulama içi “Geribildirim Gönder” seçeneği bariz sorunları yıldızlı olumsuz değerlendirmelere dönüşmeden yakalayabilir.
Çoğu gecikme, test ettiğiniz yapının gönderdiğiniz yapıyla aynı olmamasından kaynaklanır. Bir debug veya profile yapısı mükemmel görünebilir, sonra release yapı gerçek cihazda küçültme, farklı konfigürasyon değerleri veya eksik runtime izinleri yüzünden başarısız olabilir.
Başka bir zaman kaybı, geliştirme ve üretim ayarlarını karıştırmaktır: staging API URL’sini, yanlış analytics anahtarını veya test ödeme ayarlarını göndermek. Üretimi ayrı bir ortam gibi ele alın ve tam olarak yükleyeceğiniz artefakt üzerinde doğrulayın.
Bu tuzaklar ekipleri tekrar tekrar yoruyor:
Cuma uploadunu hayal edin: bir inceleyici uygulamayı açar, erişim isteyen bir özelliğe dokunur ve metin belirsizdir. Metni düzeltirsiniz ama imzalama anahtarı çevrimdışı olan bir çalışma arkadaşınızın makinesindedir. İşte iki önlenebilir gün kaybı.
Bunu ilk mağaza yapısını kesmeden önceki gün kullanın. Kısa tutuldu; eğer herhangi bir madde “belki” ise, mağaza formlarına zaman harcamadan önce düzeltin.
Eğer Koder.ai gibi kaynağı dışa aktarabilen bir platformla inşa ediyorsanız, bir kontrol daha ekleyin: dışa aktarılan proje, yükleyeceğinizle aynı imzalı release yapıyı üretiyor mu doğrulayın.
Üç kişilik küçük bir ekip ilk Flutter uygulamalarını mağazalara sokuyor: bir geliştirici, bir tasarımcı ve yarı zamanlı bir PM. İlk gönderimi bir prova gibi ele alırlar.
Pazartesi geliştirici release yapıyı üretir ve imzalama anahtarının silinmek üzere olan bir dizüstü bilgisayarda olduğunu fark eder. Aynı gün bunu düzeltirler: anahtarı paylaşılan, erişim kontrollü bir vault’a taşırlar, sahipliği belgeleyip CI makinesinin imzalayabildiğini doğrularlar.
Salı PM tüm izin istemlerini yüksek sesle okur. Bir tanesi öne çıkar: fotoğraf izni “gerekli” diyor ama uygulama sadece isteğe bağlı profil fotoğrafları için kullanıyor. Metni yeniden yazarlar ve isteği kullanıcı “Fotoğraf ekle”ye dokunduğunda gösterirler.
Perşembe final ekran görüntüleri ve production yapıyla tam bir dry-run yaparlar. Mağaza açıklaması ile uygulama içi abonelik etiketleri arasında bir uyumsuzluk tespit edilir. Dry-run olduğu için bunu düzeltir ve yayın gününden önce yeniden gönderirler.
Ertesi sefer için basit bir zaman çizelgesi tutarlar:
İlk yayın size “hazır” olmanın ne demek olduğunu öğretir. Öğrendiklerinizi taze iken kayıt altına alın.
Net sahipler atayın. Küçük bir ekipte bile “herkes” genellikle “hiç kimse” demektir ve kritik görevler atlabilir:
Yaptıklarınızı tekrarlanabilir bir kontrol listesine ve sürüm notu şablonuna dönüştürün: çalıştırdığınız komutlar, aldığınız onaylar ve yüklediğiniz dosyalar. Hangi flavor’ın production olduğu ve hangi izin metninin inceleme sorunu yarattığı gibi tuzakları da ekleyin.
Yayın sonrası bir hafta içinde 20 dakikalık bir değerlendirme planlayın. Odak nokta düzeltmeler olsun, suçlama değil:
Koder.ai ile inşa ediyorsanız, Planning Mode yayın görevlerini tek yerde takip etmenize ve snapshots ile son dakika değişikliklerinden önce bilinen iyi bir duruma dönmenize yardımcı olabilir.
Release-ready, üretime yönelik imzalanmış bir release yapısını oluşturup temiz bir cihaza yükleyebildiğiniz ve son dakika düzeltmeleri olmadan mağazaya gönderebileceğiniz anlamına gelir.
Pratik bir temel şu öğeleri içerir:
Bir release build oluşturun ve uygulamayı daha önce hiç yüklenmemiş bir cihaza kurun.
Kontrol edin:
Sadece debug/profile test ettiyseniz, gönderdiğiniz şeyi gerçekten test etmiş sayılmayın.
İmzalama varlıklarını üretim kimlik bilgileri gibi yönetin:
Anahtar sadece bir dizüstü bilgisayarda varsa, güncellemeleri kaybetmeye bir kazayla yaklaşıyorsunuz demektir.
İmzalama Apple Developer hesabına bağlı olmalı ve yönetici erişimi net olmalıdır.
Erken yapmanız gerekenler:
İki flavor ile başlayın: dev ve prod.
Tipik farklar:
Amaç, yayın öncesi dosya düzenlemeleri yapmak zorunda kalmamaktır.
Gizli konfigürasyonları repoya koymaktan kaçının; bunun yerine secrets injection kullanın.
İyi uygulamalar:
Bu, staging endpoint’lerinin veya test ödeme ayarlarının kazara yayınlanmasını önler.
Tek bir çökme raporlama aracı seçin ve bunu erken entegre edin.
Minimum yapı:
Bunu staging/release yapıda zorunlu bir çökme tetikleyip raporun kullanılabilir olduğundan emin olarak test edin.
İzni sadece kullanıcı ilgili eylemi tetiklediğinde isteyin.
İyi bir model:
Belirsiz istemler ve erken izin istekleri güven kaybına ve inceleme gecikmelerine yol açar.
Herkesin takip edebileceği hızlı bir “release build smoke test” çalıştırın:
Not alın: son eylem, ekran, cihaz modeli ve yeniden üretilebilirlik bilgisi işinizi hızlandırır.
Mağaza gönderimini taslak olarak doldurup kaydedin (yayınlamadan önce dry-run).
Hazır olduğundan emin olun:
Ayrıca yayın öncesi geri alma/sıcak düzeltme planınızı belirleyin.
