Native Uygulamadan React Native / Expo'ya Geçiş: Kapsamlı Migration Rehberi

Native Uygulamadan React Native'e Geçiş İçin Neden Doğru Zaman?

Native uygulamadan React Native'e geçiş, 2026'da artık bir risk değil olgunlaşmış bir mühendislik kararı. React Native 0.76 ile New Architecture yeni projelerde varsayılan hale geldi; eski (legacy) mimari önce donduruldu, ardından güncel sürümlerde tamamen kaldırıldı. Bugün yeni bir React Native projesi köprüsüz (bridgeless) çalışıyor, Expo SDK 57 güncel React Native sürümünü kutudan çıktığı gibi destekliyor. Yani eski dönemin en büyük eleştirisi olan "köprü performansı" tartışması fiilen kapandı.

Ayrı Swift/Kotlin ekipleriyle iki kod tabanı taşıyan şirketler için bu tablo somut bir soruyu gündeme getiriyor: iOS ve Android'i tek kod tabanında birleştirmenin maliyeti, iki ayrı uygulamayı yaşatmanın maliyetinden artık daha mı düşük? Bu rehberde karar çerçevesini, iki ana geçiş stratejisini, aşamalı planı, tipik tuzakları ve gerçekçi süre-maliyet beklentilerini bulacaksınız. Türkçede bu derinlikte bir migration rehberi bulmak zor; o boşluğu kapatmak için yazdık.

Geçişten Önce: Mevcut Uygulamanızın Röntgenini Çekin

Strateji seçmeden önce bir haftalık bir keşif çalışması, aylarca sürecek yanlış bir yatırımı önler. Şu dört alanı puanlayın:

• Kod tabanı sağlığı: Mimarî katmanlar ayrık mı, yoksa iş mantığı görünüm katmanına mı gömülü? İyi yapılandırılmış bir uygulama kademeli geçişe uygundur; teknik borcu ağır bir uygulama için sıfırdan yazım daha ekonomik olabilir.
• Bağımlılık envanteri: Kullandığınız her native SDK'yı listeleyin ve React Native karşılığını reactnative.directory üzerinden kontrol edin. Karşılığı olmayan her SDK, kendi köprüleyeceğiniz bir modül demektir — çabanın en az bilinen kalemi budur.
• Ekip profili: Ekipte React/TypeScript deneyimi var mı? Native geliştiricileriniz süreçte kalacak mı? Brownfield yaklaşımının en büyük avantajı, native ekiplerin çalışma şeklini değiştirmeden React Native'i kademeli sokabilmesidir.
• Ürün yol haritası: Önümüzdeki 6 ayda büyük özellik teslimatı varsa tam yeniden yazım ürün akışını keser; kademeli geçiş teslimatla paralel ilerleyebilir.

İki Ana Strateji: Full Rewrite mi, Brownfield mi?

Sektörde geçiş projeleri iki ana kalıpta ilerliyor:

Kriter	Full Rewrite (Greenfield)	Brownfield / Kademeli Geçiş
Yaklaşım	Uygulama Expo/React Native ile sıfırdan yazılır, hazır olunca eskisinin yerini alır	React Native, mevcut native uygulamanın içine ekran ekran entegre edilir
Başlangıç maliyeti	Yüksek — ilk sürüm çıkana dek çift bakım	Düşük — ilk ekran haftalar içinde üretimde olabilir
Risk profili	Büyük patlama: tüm risk tek geçiş anında toplanır	Dağıtılmış: her ekran ayrı ayrı doğrulanır, geri dönüş kolaydır
Ürün teslimatına etkisi	Yol haritasını duraklatabilir	Teslimatla paralel ilerler
Ne zaman mantıklı?	Kod tabanı miadını doldurmuşsa, uygulama küçük/orta ölçekliyse	Uygulama büyük ve yaşıyorsa, kesintisiz teslimat şartsa
Sonuç	Tek, temiz kod tabanı	Geçiş süresince karma kod tabanı; hedef yine tek kod tabanı

Karar Ağacı

1. Uygulamanız küçük veya orta ölçekli mi (≈30 ekran altı) ve teknik borcu ağır mı? → Full rewrite. Eski mimariyi taşımanın maliyeti, sıfırdan yazmaktan yüksek olur.
2. Uygulamanız büyük, aktif geliştirilen ve gelir üreten bir ürün mü? → Brownfield. Riski ekran ekran dağıtın.
3. Native ekibiniz devam edecek ama React Native denemek mi istiyorsunuz? → Brownfield pilotu: tek bir düşük riskli ekranla başlayın (ayarlar, yardım, kampanya sayfası gibi).
4. Uygulama fikri kanıtlanmış ama kod tabanı bakımsız ve ekip dağılmış mı? → Full rewrite; mevcut uygulamayı davranış spesifikasyonu olarak kullanın.

Brownfield Geçiş: Adım Adım Plan

Kademeli geçişin bugünkü en olgun aracı, Expo config plugin desteğiyle gelen React Native Brownfield v3 yaklaşımı: React Native tarafı tek bir artefakta (iOS için XCFramework, Android için AAR) paketlenir ve native projeye sıradan bir kütüphane gibi eklenir. Native ekip build sürecini değiştirmez; React Native ekibi kendi tarafında Expo araçlarıyla çalışır.

1. Pilot ekran (2-4 hafta): Düşük riskli, ölçülebilir bir ekran seçin. Amaç teknik doğrulamadır: navigasyon köprüsü, tema/tasarım uyumu, çökme telemetrisi.
2. Köprü sözleşmeleri: Native ile React Native arasındaki veri alışverişini (oturum, kullanıcı, tema, deep link) tip güvenli tek bir sözleşme katmanında toplayın. Bu katmanı baştan düzgün kurmak, ileride yüzlerce ekranın temelini oluşturur.
3. Bileşen kütüphanesi: Tasarım sisteminizi React Native bileşenleri olarak yeniden üretin; her yeni ekran bu kütüphaneden beslensin.
4. Özellik dilimleri: Ekran ekran değil, uçtan uca özellik dilimleriyle ilerleyin (ör. tüm "profil" akışı). Yeni özellikleri artık yalnızca React Native tarafında geliştirin — geçiş kendi kendini finanse etmeye başlar.
5. Devir ve temizlik: Kritik akışlar (onboarding, ödeme, ana akış) en sona kalır. Son native ekran kapandığında brownfield kabuğunu söküp saf React Native/Expo yapısına dönün.

Sektör deneyimi, ilk ekranın bir ay içinde üretime çıkabildiğini gösteriyor; kademeli yayın ve hızlı geri alma pratiklerini progressive delivery rehberimizde ayrıntılı anlattık.

Full Rewrite Yol Haritası: Expo ile Sıfırdan

Tam yeniden yazımda 2026'nın standart tercihi Expo'dur: dosya tabanlı yönlendirme (Expo Router), bulutta build (EAS Build), mağaza gönderimi (EAS Submit) ve OTA güncellemeleri (EAS Update) tek zincirde birleşir. Yol haritası:

1. Mevcut uygulamanın ekran ve davranış envanterini çıkarın — eski uygulama, yazılı gereksinim dokümanınızdır.
2. Analitik verisiyle ekranları kullanım sıklığına göre sıralayın; ilk sürüme yalnızca çekirdek akışları alın (kullanılmayan ekranları taşımamak, yeniden yazımın gizli kâr kalemidir).
3. Expo projesini TypeScript, Expo Router ve tasarım sistemi temelleriyle kurun.
4. Native SDK bağımlılıklarını Expo modül ekosisteminden karşılayın; karşılığı olmayanlar için native modül yazın (aşağıdaki bölüme bakın).
5. Beta dağıtımını TestFlight ve Play Console test kanallarında yürütün, mağaza geçişini tek seferde değil kademeli rollout ile yapın.

Mağaza tarafındaki gereksinimler (privacy manifest, Data Safety, hesap silme) yeniden yazımda da sizi bekliyor; ayrıntılar App Store ve Google Play yayınlama rehberimizde.

Native Modül Köprüleme: Turbo Modules ve Expo Modules

Karşılığı olmayan native SDK'lar geçişin en teknik kısmıdır. New Architecture ile native modüller Turbo Modules üzerinden, eski köprünün serileştirme maliyeti olmadan, JSI ile doğrudan çağrılır; arayüzler codegen ile tip güvenli üretilir. Expo projelerinde ise Expo Modules API, Swift ve Kotlin ile modern, az tören gerektiren bir modül yazma katmanı sunar. Pratik kurallarımız:

• Önce topluluk paketini arayın; yoksa SDK'nın yalnızca kullandığınız yüzeyini saran ince bir modül yazın, tamamını sarmayın.
• Platform farklarını native tarafta değil, TypeScript sözleşmesinde tek tipte buluşturun.
• Her köprülenen modül için native tarafta birim test, JS tarafında sözleşme testi yazın.

New Architecture'ın çalışma modeli hakkında derinleşmek isterseniz Expo SDK sürüm rehberimize göz atabilirsiniz.

Tipik Tuzaklar ve Kaçınma Yolları

• Bağımlılık denetimini atlamak: En pahalı sürprizler, geçiş ortasında karşılığı olmayan bir SDK keşfetmekten çıkar. Keşif haftasında envanteri eksiksiz çıkarın.
• Navigasyon köprüsünü hafife almak: Brownfield'da native stack ile React Native navigasyonunun geçişleri (geri tuşu davranışı, deep link, modal yığınları) en çok hata üreten sınırdır; pilot ekranda ilk doğrulanacak şey budur.
• Oturum ve durum paylaşımı: Auth token'ları, kullanıcı durumu ve özellik bayrakları iki dünya arasında tek kaynaktan okunmalı; iki ayrı oturum kopyası tutmak senkron hatalarına yol açar.
• Performansı ölçmeden taşımak: Geçişten önce native tarafta açılış süresi, ekran geçişi ve kare hızı için taban çizgisi alın; her dilimde aynı metrikleri karşılaştırın. "Yavaşladı" tartışması ancak veriyle kapanır.
• Eski mimari dokümanlarına güvenmek: İnternetteki rehberlerin önemli kısmı köprü dönemine ait. 2026'da legacy mimari kaldırıldı; okuduğunuz rehberin New Architecture sonrası yazıldığını doğrulayın.
• Geçişi "bitmeyen proje"ye çevirmek: Brownfield'da bitiş tarihi ve "son native ekran" hedefi tanımlanmazsa karma kod tabanı kalıcılaşır ve iki dünyanın bakım maliyetini birden ödersiniz.

Süre ve Maliyet: Gerçekçi Beklentiler

Ölçek ve stratejiye göre kaba aralıklar şöyle şekillenir:

• Brownfield pilotu: Tek ekran, üretimde — 1 ay mertebesi.
• Orta ölçekli tam geçiş (30-60 ekran): Kademeli planla 4-9 ay; tam yeniden yazımda çekirdek sürüm için 3-6 ay artı kademeli kapsam genişletme.
• Belirleyici maliyet kalemleri: Köprülenecek native SDK sayısı, tasarım sisteminin yeniden üretimi, test kapsamı ve çift bakım süresi. Ne kadar kodun yeniden kullanılabildiği toplam maliyeti belirler.

Geçişin getirisi tek seferlik değildir: tek kod tabanı, her özelliğin iki platformda aynı anda çıkması ve tek ekiple bakım demektir. Bütçe kalemlerinin tam dökümü için mobil uygulama geliştirme maliyeti 2026 rehberimizi inceleyebilirsiniz.

Sahadan: Kompanse'nin React Native / Expo Pratiği

Bu rehberdeki yaklaşım, üretimde çalışan ürünlerden geliyor. Kendi ürünümüz Sepetteyiz, React Native ve Expo ile geliştirildi ve hem App Store hem Google Play'de canlı; tek kod tabanından iki mağazaya çıkışın build zinciri, native modül ihtiyaçları ve mağaza uyumluluğu dahil tüm adımlarını kendi ürünümüzde işletiyoruz. Müşteri projelerinde de aynı prensibi uyguluyoruz: önce keşif ve bağımlılık envanteri, sonra ölçülebilir pilot, ardından dilim dilim geçiş.

Geçiş Kontrol Listesi

1. Ekran ve davranış envanteri çıkarıldı; analitikle kullanım sıklığı sıralandı.
2. Native SDK bağımlılıkları listelendi, React Native/Expo karşılıkları doğrulandı.
3. Strateji kararı (full rewrite / brownfield) karar ağacıyla verildi ve gerekçesi yazıldı.
4. Performans taban çizgisi (açılış, geçiş, kare hızı) native tarafta ölçüldü.
5. Pilot ekran seçildi; navigasyon, oturum ve tema köprüleri tasarlandı.
6. Köprülenecek modüller için Turbo Module / Expo Module planı yapıldı.
7. Test stratejisi kuruldu: birim + sözleşme + uçtan uca; kademeli rollout planı hazır.
8. Bitiş tanımı yazıldı: "son native ekran" hedefi ve brownfield kabuğunun söküm planı.
9. Mağaza uyumluluğu (privacy manifest, Data Safety, hesap silme) geçiş planına dahil edildi.

Sonuç: Geçiş Bir Sıçrama Değil, Yönetilen Bir Süreç

Native uygulamadan React Native ve Expo'ya geçiş, doğru keşif ve doğru strateji ile riski ekran ekran yönetilebilen bir mühendislik sürecidir. 2026'da araç zinciri — New Architecture, Turbo Modules, Expo'nun brownfield desteği — bu süreci hiç olmadığı kadar öngörülebilir kılıyor. Kritik olan, stratejiyi uygulamanızın gerçek durumuna göre seçmek ve bitiş çizgisini baştan tanımlamaktır.

Geçiş kararını değerlendiriyorsanız, iki mağazada canlı React Native ürünü işleten ekibimizle iletişime geçin — mobil uygulama geliştirme hizmetimiz keşif analizi, geçiş planı ve uygulamayı uçtan uca kapsar.