React Native ile iOS ve Android uygulama geliştirme

React Native mi, native mi? Kararı neye göre veriyoruz?

Mobil projelerimizin büyük kısmı Expo ve React Native ile yazılıyor; FitZen, GlowTira, PeakUp, HuntLine IQ, RichlyMe, Muslim Mubarak, in5min ve Karaman Mobile bunlardan bazıları. Yalnız iOS’a çıkan iki ürünümüz ise SwiftUI ile yazıldı: PersonaDreams (145 Swift dosyası) ve AppsPaper. Kararı ekran sayısına göre değil; iki platformun ne kadar akışı paylaştığına, cihaz entegrasyonunun derinliğine ve bakım ihtiyacına göre veriyoruz.

React Native seçmek native koddan vazgeçmek anlamına gelmiyor. Platforma özgü parçayı küçük bir native modülle ekliyoruz:

• Muslim Mubarak’ta modules/widget-bridge namaz verisini paylaşılan depolamaya yazıyor; targets/widget altındaki beş SwiftUI widget’ı bu veriyi okuyor.
• in5min’de Live Activities ve ana ekran widget’ı native modül olarak eklendi; aynı Expo kod tabanı iPhone, Mac ve Vision Pro’ya çıkıyor.
• Amenza’da ana ekran widget’ı uygulamanın verisini native bir köprü üzerinden okuyor.

Ürünün asıl değeri platforma özel bir etkileşimdeyse bunu keşif aşamasında açıkça konuşuyor ve native seçeneği de masaya koyuyoruz.

Expo ve EAS ile derleme ve mağazaya gönderim nasıl yürüyor?

HuntLine IQ’nun iOS ve Android uygulamaları tek bir Expo SDK 57 kod tabanından EAS ile TestFlight’a ve Play’e gönderildi. Push bildirimleri Expo Push Service üzerinden gidiyor ve uygulamada Firebase SDK’sı yok; FCM anahtarını EAS’e yalnız kimlik bilgisi taşıyan bir Firebase projesi sağlıyor.

Karaman Mobile’da müşteri mağaza derlemelerini kendi Expo ve Firebase hesaplarından alacaktı. Bu yüzden kaynak kodda hiçbir sır tutulmadı: Karaman API’sine giden çağrılar karaman-proxy üzerinden geçiyor ve üretim profili sahte veriyle derlemeyi reddediyor.

En öğretici hata FitZen’in Android 2.0.2 sürümünde çıktı. Yerel EAS derlemesi eas.json içindeki $DEGISKEN yer tutucularını çözmeden pakete koydu; RevenueCat, Firebase ve Google girişi anahtarları pakete yer tutucu metin olarak girdi. Çözüm, app.config.js içinde $ ile başlayan değerleri boş saymak ve istemci anahtarları için varsayılan tanımlamak oldu. FitZen’in yayın kontrol listesindeki şu madde oradan geliyor: ortam değişkenlerinin gerçekten çözüldüğünü, yerel ve bulut derlemede paketin içinden doğrulayın. Anahtarların yalnız .env içinde değil EAS ortamında da tanımlı olması ayrı bir madde.

Abonelikleri RevenueCat ile nasıl kuruyoruz?

FitZen’de altı mağaza ürünü iki mağazada birebir aynı kimlikle açıldı ve üç abonelik RevenueCat’te tek bir "premium" yetkisine bağlandı. RevenueCat tek doğruluk kaynağı; Firebase yalnız bir ayna tutuyor ve bu aynayı istemci değil sunucu yazıyor:

• imzalı webhook, olay kimliğini belge kimliği yaparak çift sayımı engelliyor;
• giriş ve uygulama açılışında çağrılan bir callable, RevenueCat REST API’sine abonenin gerçek durumunu soruyor;
• her gece 03:15’te çalışan bir görev süresi dolanları kapatıyor.

Firestore kuralları 18 yetki alanına istemci yazımını reddediyor. Denetimler iki ders bıraktı: iade ayrı bir olay tipiyle gelmiyor, CANCELLATION içindeki cancel_reason ile tanınıyor; bitiş tarihi taşımayan tek seferlik paket hiçbir zaman süresiz premium sayılmamalı.

Aynı kalıp başka projelerde de var. RichlyMe’de üyelik yalnız Apple uygulama içi satın alımıyla satılıyor ve RevenueCat ile yönetiliyor; GlowTira ve HuntLine IQ RevenueCat webhook’u kullanıyor. Araç ürüne göre değişebiliyor: Parent Daily’de abonelik Adapty ile çalışıyor.

Backend olarak Supabase mi, Firebase mi?

İkisiyle de yayında ürünümüz var; seçim verinin şekline ve yetki kuralının nerede durması gerektiğine bağlı.

Firebase tarafında FitZen, Wardrova, Muslim Mubarak, in5min, Garaj ve Düzce Biz var. Garaj’da 1v1 bilgi yarışmasının her maç kararı Cloud Functions’ta veriliyor; istemci yalnız çağırıyor ve maç belgesini dinliyor. GPS ile ölçülen performans testi ise güvenlik kuralı gereği yalnız kullanıcının kendi belgesine yazabiliyor.

Supabase tarafında ilişkisel veri ve satır düzeyinde yetki öne çıkıyor:

• RichlyMe: 49 migration, 17 Edge Function, 38 SQL test dosyasında 401 test.
• GlowTira: 29 Edge Function; hız sınırları abonelik seviyesine göre bir Postgres RPC’sinde atomik tutuluyor ve hiçbir sağlayıcı anahtarı pakete girmiyor.
• PeakUp: 15 Edge Function, 36 veritabanı ve RLS testi.
• Karaman Mobile: teslimat bölgeleri PostGIS poligonu olarak sunucuda doğrulanıyor.

Mevcut backend’i yeniden kurmadan bağlandığımız projeler de var. Karaman.com’un hesaplarını bir köprü Edge Function’ı Supabase profiline eşliyor; HuntLine IQ’nun mobil uygulaması web platformuyla aynı Supabase projesini kullanıyor.

Web ürünüyle aynı kuralları paylaşan bir mobil uygulama nasıl kuruluyor?

Mobil uygulama çoğu zaman tek başına değil, bir web paneli ya da web ürünüyle birlikte yaşıyor. Bu durumda en pahalı hata, iki tarafın aynı kuralı farklı uygulaması.

HuntLine IQ’da müşterinin web uygulaması hazırdı ve iOS ile Android uygulamalarının Tennessee fuar takvimine yetişmesi için üç hafta vardı. Kapsam cümlesi netti: web ile birebir aynı davranış ve sözleşmede tanımlanan iki native özellik. Tipli API katmanı, sabitler, tarih biçimlendirme ve EXIF’i koruyan fotoğraf hazırlığı web deposundan taşındı. TanStack Query anahtarları web önbelleğiyle aynı, tasarım değişkenleri web CSS’inden donduruldu ve NativeWind’e aktarıldı. Sunucuya yalnız iki şey eklendi: push token kaydı ve RevenueCat webhook’u.

PeakUp’ta üye, antrenör ve stüdyo sahibi aynı Expo uygulamasında; sahip için ayrıca Next.js 16 ile bir panel var. Ortak @peakup/shared paketi zod şemalarını ve KDV, devamsızlık, paket düşümü kurallarını taşıyor; aynı kurallar veritabanında CHECK kısıtlarıyla da uygulanıyor. Düzce Biz’de de Expo uygulaması, Next.js 16 panelleri ve paylaşılan tipler tek bir monorepo içinde duruyor.

Mağaza yayınında ve App Review’da neler önemli?

FitZen’de App Review riskini koddan çok ödeme ekranının sunumunda bulduk. 91 numaralı derleme (1.2.3) için yaptığımız denetim iki engel çıkardı: ödeme ekranı uygunluk kontrolü yapmadan "3 gün ücretsiz" gösteriyordu, fiyatlar ve üstü çizili indirimler mağaza vitrinine göre değil arayüz diline göre koda gömülüydü. Yeni usePaywall kancasında fiyat ve deneme bilgisi doğrudan RevenueCat offering’inden geliyor; uygunluk bilinmiyorsa deneme vaat edilmiyor. İnceleyici ödeme duvarını geçebilsin diye inceleme notu ve premium bir demo hesap hazırlanıyor.

Yayından önce bir kalite kapısı koşuyor. PeakUp’ta veritabanı ve RLS testleri, sözleşme kontrolleri ve birim testleri tek bir pnpm dogrula komutunda toplanıyor; yeşil değilse hiçbir şey yayına çıkmıyor. Uygulama, mevcut mağaza kaydına 2.0.0 güncellemesi olarak iOS ve Android’de yayınlandı.

App Store ve Google Play geliştirici hesapları müşterinin adına açılıyor. Karaman Mobile bunun tipik örneği: müşteri derlemeyi kendi Expo hesabından alıyor; uygulama kaynak kod, kurulum talimatı ve sunucu yayın notlarıyla Eylül 2026’da teslim edildi.

Sık sorulan sorular

İLGİLİ STÜDYO NOTLARI