Yayınlanacak derlemeyi tekrar üretilebilir kılın
React Native geliştirme tesliminde kontrol edilecek dosyanın kaynağını kaydedin: commit, bağımlılık kilidi, React Native sürümü, native araç zinciri ve derleme numarası. Bir geliştiricinin yerel klasöründen çıkan ama kaynağı bilinmeyen paket yayın için güvenilir referans değildir. Temiz ortamdan aynı tarifle derleme alınabildiğini doğrulayın; imzalama anahtarını kontrol raporuna kopyalamayın.
Android ve iOS ayrı çıktı ve imzalama süreçlerine sahiptir. React Native’in resmî iOS yayın belgesi yayın yapılandırmasını ve mağaza gönderimini anlatır. Projedeki gerçek sürüm ve araçlara uygun adımları kullanın. Debug sürümünde geçen testleri release paketinde tekrarlayın. Eksik kaynak dosyası, yanlış uygulama kimliği veya derleme numarası uyuşmazlığı için sorumlu atayın; kanıtta paket kimliği ve sonucu gösterin.
Ortamları ve mağaza hesap erişimini ayırın
Yayın süreci kurulurken test ve üretim API adresleri, bildirim anahtarları ve uygulama kimliklerini açık eşleyin. Paket test sunucusuna bağlanırken mağaza metninde canlı hizmet vaat etmemelidir. Cihazdaki önceki sürüm veya önbellek yanlış ortamı gizleyebilir; temiz kurulum ve mevcut sürümden güncelleme senaryolarını ayrı çalıştırın. Hassas servis anahtarları uygulama içine gömülmemelidir.
Hesap sahibini, mağaza gönderimi yapabilen rolü ve faturalama ya da sözleşme kabulü gereken kişiyi belirleyin. Paylaşılan kişisel hesap yerine uygun yetkileri kullanın. Yetkisiz ekip üyesinden mağaza koşullarını kabul etmesini beklemeyin. Sertifika, provisioning ve hesap erişimi hazır değilse teknik test bitti diye mağaza gönderimini tamamlandı işaretlemeyin. Her ortamın kanıtını gerçek değerleri ifşa etmeden; alan adı sınıfı, rol ve kontrol tarihiyle kaydedin.
| Kontrol | Kanıt | Tekrar koşulu |
|---|---|---|
| Yayın paketi | Commit, paket kimliği, derleme numarası | Yeni derleme üretildiğinde |
| Üretim hedefi | Release paketinin ağ hedefi | Ortam değişkeni değiştiğinde |
| Hesap erişimi | Yetkili rolün doğrulanması | Ekip veya sertifika değiştiğinde |
OKUMADAN SONRAKİ ADIMA
Mağaza yayın hazırlığını değerlendirelim
Mevcut sürümü, hedef mağazaları ve açık test bulgularını paylaşın.
Oturum ve API hatalarını gerçek görevlerle sınayın
API kabulü uygulamanın başarılı yanıtı göstermesinden fazlasını kapsar. Giriş, çıkış, süresi dolan oturum, yanlış parola ve yetkisiz kayıt erişimi için beklenen davranışı yazın. Kullanıcı uygulamayı arka plana alıp geri döndüğünde eski ekranın yanlış hesap verisini göstermediğini kontrol edin. Token yenileme hatası sessizce sonsuz yükleme ekranına dönüşmemelidir.
Zayıf ağ, bağlantı kesilmesi, sunucu hatası ve zaman aşımını kontrollü test ortamında deneyin. Kayıt oluşturan eylemi yeniden denemek iki kayıt oluşturabilir; kullanıcıya ne olduğunu açıklayan durum ve yeniden deneme kararı gerekir. Loglara parola veya kişisel veri eklemeyin. Her bulguda ekran yolu, sürüm, ağ koşulu ve beklenen sonuç bulunmalı. API ya da oturum davranışı değiştiğinde yalnızca açılış ekranını değil aynı hata senaryosunu yeniden sınayın.
İzinleri ve mağaza beyanlarını gerçek veri akışıyla eşleştirin
Mobil uygulama kapsamındaki kamera, konum, mikrofon ve bildirim izinlerini kullanım anına göre inceleyin. Kullanıcı izni reddettiğinde uygulamanın hangi görevi sürdürebildiği açık olmalıdır. Kullanılmayan bir izin yalnızca ileride gerekebilir diye paket içinde bırakılmaz. Üçüncü taraf SDKlerin topladığı veriler de envantere girer; “biz toplamıyoruz” ifadesi bütün uygulama için yeterli değildir.
Google Play’in Kullanıcı Verileri politikası veri işleme açıklamalarını ve SDK sorumluluğunu ele alır. Apple, hesap oluşturmayı destekleyen uygulamalarda uygulama içinden silme başlatma imkânını ister. Uygulamanın koşullarına uygun güncel kuralları inceleyin. Mağaza gizlilik beyanı, politika bağlantısı ve gerçek ağ davranışı tutarlı olmalıdır. Silme, oturumu kapatma veya hesabı geçici dondurma ile karıştırılmaz; kapsamı ürün sahibi doğrular.
İzin reddi
Özelliğin neden kullanılamadığı açıklanır ve mümkünse alternatif görev sunulur. Testte ilk reddetme ile ayarlardan sonradan kaldırma ayrı gözlenir.
SDK incelemesi
Veri türü, gönderim amacı, hedef servis ve açıklama sahibi kaydedilir. SDK sürümü değişirse mağaza beyanının aynı kaldığı varsayılmaz.
Gerçek cihaz testini ve mağaza metnini aynı sürüme bağlayın
Mobil performans incelemesinde açılış, liste kaydırma, klavye ve görsel yükleme gibi gerçek görevleri sınayın. Simülatör sonuçlarına ek olarak desteklenen eski ve yeni cihazlarda release paketini deneyin. Android geri tuşu, iOS güvenli alanları, küçük ekran, büyük yazı ve cihaz izinleri platforma göre farklılaşabilir. Cihaz matrisinde test edilmemiş kombinasyonları açık bırakın.
Ekran görüntüleri ve açıklamalar gönderilen sürümün yapabildiği işleri göstermelidir. Henüz yayınlanmayan özelliği mevcutmuş gibi sunmayın. Destek ve gizlilik bağlantılarını mağaza dışından açıp erişilebilirliğini doğrulayın. İnceleme için gerekiyorsa yetkili ekip özel deneme hesabını uygun mağaza alanında hazırlar; bu hesap bilgisi genel rapora yazılmaz. Çökme takibinin release sürümüyle ilişkilendiğini ve olay kayıtlarının gereksiz kişisel veri taşımadığını kontrol edin.
Sürüm toparlanmasını mağaza gerçeklerine göre planlayın
Yayın ve izleme planı mağazaya gönderimle bitmez. İnceleme durumu, dağıtılan sürüm, hata sinyalleri ve destek talepleri için sahip belirleyin. Eski sunucu davranışını kullanan cihazlar yaşamaya devam edebilir; API değişikliği tek anda bütün kullanıcılara ulaşmış yeni sürüm varmış gibi yapılamaz. Kritik işlevler için istemci ve sunucu uyumluluk aralığını yazın.
Mağaza uygulamasını geri alma, web dosyasını önceki sürüme çevirmek kadar anlık olmayabilir. Toparlanma planına yeni düzeltme paketi, dağıtımı durdurma seçenekleri ve gerektiğinde sunucu tarafında güvenli özellik kapatma kararını koyun. Veri değişikliklerinin geri alınabilirliğini ayrıca değerlendirin. Yayın sonrası kontrolün tarihini, sahibini ve durdurma ölçütünü belirleyin. Bu hazırlık mağaza onayını veya hatasız çalışma süresini garanti etmez; kanıtlanmış sonuç ve bekleyen iş ayrımını sağlar.
Kontrol listesini al ve kapsamını değerlendir
E-posta ve telefon bu taleple ilgili iletişim içindir. Bülten aboneliği oluşturmaz.
KARAR VERMEDEN ÖNCE
Sık sorulan sorular
Debug paketindeki testler yeterli mi?
Hayır. Release yapılandırması farklı servis hedefleri, optimizasyonlar ve imzalama kullanabilir. Mağazaya gönderilen artefaktı gerçek cihazda sınayın. Yeni paket üretilirse önceki paketin test sonucu kendiliğinden yeni sürüme aktarılmaz.
Her cihazı test etmek mümkün değilse ne yapılır?
Desteklenen işletim sistemleri, cihaz sınıfları ve kritik özelliklere göre temsilî matris hazırlayın. Gerçek cihaz sonuçları ile simülatör sonuçlarını ayırın. Test edilmeyen koşulları teslim notunda belirtin; bütün cihazlarda kusursuzluk iddiası kullanmayın.
Hesap silme sadece çıkış yapmak mıdır?
Hayır. Çıkış yapmak oturumu bitirir; hesap ve ilişkili veri konusunda ayrı işlem gerekir. Apple ve Google’ın güncel koşullarını gerçek hesap oluşturma akışınıza göre değerlendirin. Saklanması gereken veriler varsa gerekçe ve açıklama ürün sahibince incelenir.
Mağaza gönderimi kim tarafından yapılır?
Yetkili hesap rolü olan kişi yapar; hesap sahibi gerekli sözleşme ve organizasyon kararlarını tamamlar. Geliştirme ekibi teknik paketi hazırlayabilir. Paylaşılan kişisel giriş bilgilerini kullanmak yerine görev ve erişimi baştan tanımlayın.
Yeni sürüm sorun çıkarırsa hemen eski sürüme dönebilir miyiz?
Bütün kullanıcılarda anlık geri dönüş varsaymayın. Mağaza dağıtım seçenekleri, inceleme ve cihazdaki sürümler etkilidir. Önceden düzeltme paketi, dağıtımı durdurma ve sunucu uyumluluğu planlayın; veri değişikliklerini ayrı geri dönüş kararıyla değerlendirin.
KAPSAMI BİRLİKTE BELİRLEYELİM
Mağaza yayın hazırlığını değerlendirelim
Mevcut sürümü, hedef mağazaları ve açık test bulgularını paylaşın.
Yayın kapsamını görüş