Yükseltmeden önce çalışan başlangıç sürümünü kaydediyoruz
Mevcut React Native uygulamasının iOS ve Android build durumu ilk değerlendirme girdisidir. Uygulama bugün nerede çalışıyor, hangi ortamda hata veriyor ve son yayınlanan sürüm hangisi soruları yanıtlanır. Çalışan başlangıç yoksa önce bunun kurulması gerekebilir. Böylece eski bir hatayla yükseltmenin oluşturduğu yeni sorunu birbirine karıştırmayız.
Kaynak kod, paket kilit dosyası, native proje ayarları ve build süreci incelenir. Geliştirme makinesinde çalışan uygulamanın otomatik build'de de aynı biçimde kurulabildiği varsayılmaz. Kritik kullanıcı akışları ve mevcut bilinen sorunlar kaydedilir. Bu başlangıç listesi teslimde karşılaştırma sağlar. Projeye erişmeden, yalnızca mevcut sürüm numarasına bakarak kesin süre veya sabit geçiş maliyeti söylemek sağlıklı değildir.
Hedef sürümü paket uyumu ve ürün ihtiyacı belirler
Expo kullanılan bir projede SDK ve bağlantılı paketlerin uyumu birlikte değerlendirilir. Resmi yükseltme rehberleri ve hedef sürüm notları kontrol edilir. Birden fazla sürüm geride kalan projede artımlı geçiş, kırılmanın hangi aşamada oluştuğunu anlamayı kolaylaştırabilir. Bare React Native yapısında da JavaScript paketleriyle native proje farkları birlikte incelenir.
Her bağımlılık aynı hızda güncellenmez. Bakımı bırakılmış bir paket için güncelleme, alternatif veya sınırlı özel düzeltme seçenekleri karşılaştırılır. Yeni mimari ve özel native kodun gereksinimleri projenin durumuna göre ele alınır; isimleri pazarlama vaadine dönüştürülmez. Hedef kararında istediğiniz özellik, build koşulları ve bakım yükü görünür tutulur. En yeni etiketin her ürün için tek doğru hedef olduğu varsayılmaz.
Uyum envanteri
React Native, React, Expo varsa SDK ve önemli üçüncü taraf paketler kaydedilir. Güncellenebilen ve engel oluşturan bağımlılıklar ayrılır.
Native farklar
iOS/Android yapılandırmaları ve özel modüller incelenir. Üretici proje farkları mevcut özelleştirmeyi silmeden değerlendirilir.
Karar listesi
Paket değiştirme, geçici düzeltme veya kapsam dışı bırakma kararı gerekçesiyle yazılır. Yeni ürün özelliği geçiş işiyle karıştırılmaz.
OKUMADAN SONRAKİ ADIMA
Mevcut sürüm ve build durumundan başlayalım
React Native/Expo sürümünüzü, paket dosyanızı ve öncelikli sorunu paylaşın. Uyum envanteri ile geçişin ilk aşamasını belirleyelim.
Native proje değişikliklerini kopyala-yapıştırla geçmiyoruz
Mobil uygulama geliştirme sırasında eklenmiş kamera, bildirim, ödeme veya oturum modülleri sürüm geçişinde özel dikkat isteyebilir. Upgrade Helper gibi araçlar dosya farklarını göstermeye yardımcı olur; mevcut projeye özgü kararların yerini almaz. Bir ayarın neden değiştiği ve eski özelleştirmenin hâlâ gerekli olup olmadığı kontrol edilir.
Geçiş ayrı geliştirme kolunda ve gözden geçirilebilir değişikliklerle yürütülür. Paket güncellemeleri, native yapı düzenlemeleri ve ürün davranışı düzeltmeleri mümkün olduğunca anlaşılır parçalara ayrılır. Yalnızca hatayı bastırmak için bir kontrol kaldırılmaz. Sürüm notları ve gerekli düzeltmeler kayıt altına alınır. İki platformdan biri derleniyor diye diğerinin de hazır olduğu kabul edilmez; bağımsız build sonuçları alınır.
Kritik akış ve performans karşılaştırmasıyla kabul
React Native performans kontrolü sürüm geçişinin yararlı bir parçasıdır; yükseltmenin otomatik hız artışı getireceği söylenmez. Oturum açma, ödeme, bildirimden yönlendirme veya cihaz özelliği gibi ürünün önemli akışları seçilir. Kabul listesinde yalnızca ekran açılması değil, işlemin doğru tamamlanması bulunur.
Temsil edici cihaz ve işletim sistemi koşullarında yayın adayı test edilir. Oturum, yerelde saklanan bilgi ve eski uygulamadan güncelleme davranışı kontrol edilir. Yeni kurulumla mevcut kullanıcı güncellemesi farklı deneyimlerdir. Performans karşılaştırmasında aynı veri ve akış kullanılır. Değişen sonuç ile bilinen eski hata ayrılır; açık kalan madde ve ürün üzerindeki etkisi teslim incelemesinde görünür olur.
Karşılaştırma akışını seç
İşletme açısından kritik işlemler ve başlangıç davranışı kaydedilir. Test verisi ve hedef cihazlar belirlenir.
İki platformda doğrula
Release adayı iOS ve Android üzerinde denenir. API, yerel veri, izin ve native bağlantı sonuçları ayrı kaydedilir.
Açık maddeleri karara bağla
Bloklayan hata, sonraki bakım işi ve kabul edilen sınır ayrılır. Yayın kararını verecek sorumlu kişiye anlaşılır sonuç sunulur.
Build ve mağaza yayınını geçiş planına dahil edin
CI/CD ve yayın süreci yeni sürümün tekrar üretilebilir biçimde derlenmesini destekler. Signing, ortam bilgileri ve test dağıtımının erişimleri değerlendirilir. Mağazaya gönderilecek paketle geliştiricinin test ettiği paket arasındaki fark görünür tutulur. Mağaza incelemesi ve hesap yetkileri dış bağımlılıklar olarak takvimde belirtilir.
Kontrollü dağıtım, izlenecek hata sinyalleri ve olası müdahale adımları kararlaştırılır. Kullanıcıların tamamı hemen güncellemeyebilir; backend'in eski ve yeni istemciyle davranışı incelenir. Önceki mağaza sürümüne dönüş her zaman bir düğmeye basmak kadar basit değildir. Bu nedenle düzeltme sürümü, dağıtımı durdurma ve veri uyumluluğu ayrı konuşulur. Yeni build üretmekle bütün kullanıcıların sorunsuz güncellendiğini doğrulamak farklı işlerdir.
Tek seferlik yükseltmeden düzenli bakım planına
Mobil uygulama bakım ve destek planı güncelleme borcunun tekrar büyümemesini sağlayan çalışma düzenini tanımlar. Sürüm takibi, bağımlılık incelemesi ve planlı test sıklığı ürünün büyüklüğüne göre belirlenir. Acil build sorunu ile ürün geliştirme talebi aynı öncelik kuyruğuna atılmaz.
Maliyeti sürüm mesafesi, bağımlılık sayısı, native özelleştirme, mevcut testler ve yayın koşulları etkiler. Teslimde değişiklik özeti, çalışan build bilgisi, test sonuçları ve devam eden sorumluluklar bulunur. İlk görüşmeye mevcut sürümü, paket dosyanızı ve son build hatasını getirin. Erişimler kontrollü düzenlendikten sonra teknik inceleme ile gerçekçi hedef ve ilk aşamayı belirleyebiliriz.
KARAR VERMEDEN ÖNCE
Sık sorulan sorular
Sadece React Native sürüm numarasını değiştirmek yeterli mi?
Çoğu projede ilişkili paketler ve native proje dosyaları da incelenir. Derleme başarılı olsa bile kritik kullanıcı işlemleri doğrulanmalıdır. Gerekli değişiklikler mevcut proje ve hedef sürüm farkına göre belirlenir.
Expo projesi de yükseltilebilir mi?
Evet, kapsam değerlendirilebilir. Expo SDK, React Native ve bağlı paketlerin uyumu birlikte kontrol edilir. Resmi sürüm notları ve projenin native üretim yöntemi dikkate alınarak geçiş aşamaları tanımlanır.
Yükseltme uygulamayı kesin hızlandırır mı?
Hayır. Performans sonucu ürün kodu, paketler, cihazlar ve veri akışına bağlıdır. Gerekiyorsa başlangıç ve yeni sürüm aynı akışta ölçülür; performans düzeltmeleri ayrı kapsam olabilir.
Özel native modüller korunabilir mi?
İşlev ve uyumluluk incelemesinden sonra karar verilir. Modülün güncellenmesi, alternatif kullanılması veya özel geliştirme gerekebilir. Mevcut özelleştirme görülmeden aynı biçimde çalışacağı garantisi verilmez.
Mağaza onayı garanti mi?
Hayır. Uygulama mağazası inceleme kararları ilgili platforma aittir. Build hazırlığı, test dağıtımı ve gönderim kapsamlandırılabilir; hesap yetkileri, politika gereksinimleri ve inceleme süreci ayrıca değerlendirilir.
Çalışma sırasında özellik eklenebilir mi?
Eklenebilir, ancak yükseltme kabulüyle yeni özellik geliştirme ayrı iş listelerinde tanımlanmalıdır. Böylece bir sorun çıktığında kaynağı daha kolay anlaşılır ve ilk geçişin teslim sınırı açık kalır.
KAPSAMI BİRLİKTE BELİRLEYELİM
Mevcut sürüm ve build durumundan başlayalım
React Native/Expo sürümünüzü, paket dosyanızı ve öncelikli sorunu paylaşın. Uyum envanteri ile geçişin ilk aşamasını belirleyelim.
Sürüm geçişini değerlendirin