Çoğu iş uygulaması için React Native ya da Flutter ile iOS ve Android’i tek kod tabanından geliştirmek yeterlidir. Native geliştirme, yani iki platform için Swift ve Kotlin ile ayrı uygulama yazmak, platforma derinden bağlı özelliklerde ya da her platform için ayrı ekip kurabildiğiniz durumlarda öne çıkar. React Native ile Flutter arasındaki seçimi ise çoğunlukla ekibinizin bildiği dil ve web tarafıyla ne kadar kod paylaşmak istediğiniz belirler.
Üç yaklaşım nasıl çalışır?
React Native, uygulamayı JavaScript ya da TypeScript ile, React’in bileşen modeliyle yazmanızı sağlar. Çalışma anında her bileşen için iOS ve Android’in kendi görünümleri oluşturulur: bir <Text> iOS’ta UITextView, Android’de TextView olarak ekrana gelir (React Native). React Native ekibi yeni projelere Expo gibi bir çatıyla başlamayı öneriyor (reactnative.dev).
Flutter, Dart diliyle yazılır ve platformun arayüz bileşenlerini kullanmak yerine her kontrolün kendi uygulamasını çizer. Mobilde çizimi Impeller motoru yapar; yayın sürümü doğrudan makine koduna derlenir (Flutter mimarisi).
Native geliştirmede iOS uygulaması Swift ve SwiftUI ile, Android uygulaması Kotlin ve Jetpack Compose ile ayrı ayrı yazılır. Google, Compose’u Android’de native arayüz için önerilen modern araç olarak tanımlıyor.
| Konu | React Native | Flutter | Native |
|---|---|---|---|
| Dil | JavaScript / TypeScript | Dart | Swift (iOS), Kotlin (Android) |
| Arayüz | Platformun kendi bileşenleri | Flutter’ın kendi çizdiği bileşenler | Platformun kendi bileşenleri |
| Kod tabanı | Tek | Tek | Platform başına bir |
| Platform API’leri | Hazır kütüphane ya da native modül | Hazır paket ya da platform kanalı | Doğrudan |
| Web ile paylaşım | React bilgisi ve iş mantığı ortak | Flutter web mümkün, içerik siteleri için önerilmiyor | Yok |
Performans, arayüz ve platform API’leri
Performans ve arayüz
React Native’in dokümantasyonu, bileşenler platformun kendi görünümleriyle desteklendiği için uygulamaların diğer uygulamalar gibi göründüğünü ve çalıştığını belirtir. Flutter’da ise arayüz her platformda aynı çizilir; iOS görünümü için Cupertino, Android için Material bileşenleri hazır gelir (Flutter SSS). Bunun bir sonucu da şudur: Flutter kendi kontrollerini çizdiği için platformun kendi bileşenlerinde yaptığı görsel değişiklikler uygulamanıza kendiliğinden yansımaz.
Liste, form, harita ve ödeme ağırlıklı iş uygulamalarında üç yaklaşımla da akıcı bir deneyim kurulabilir. Bu tür uygulamalarda yavaşlığın nedeni çoğu zaman çerçeve değil; büyük görseller, gereksiz ağ istekleri ve gereksiz yeniden çizimlerdir. Yoğun animasyon, oyun benzeri grafik ya da kamera ve ses üzerinde gerçek zamanlı işlem gerekiyorsa seçimi küçük bir prototiple ölçerek yapmanızı öneririz.
Platform API’lerine erişim
Üç yaklaşım da telefonun bütün özelliklerine erişebilir; fark, bu erişimin kimin yazdığı kodla sağlandığıdır. React Native’de ihtiyacınız olan platform API’si React Native’de ya da hazır bir kütüphanede yoksa entegrasyonu bir Turbo Native Module olarak kendiniz yazarsınız. Flutter’da aynı iş platform kanalları ya da Pigeon paketiyle yapılır. İki durumda da platform tarafı Kotlin/Java ve Swift/Objective-C ile yazılır.
Bazı özellikler zaten native koda bağlıdır. Örneğin iOS’ta ana ekran widget’ları ve Live Activities, WidgetKit ile ve SwiftUI görünümleriyle hazırlanır (Apple); çapraz platform bir uygulamada bu parça yine Swift ile yazılır. Apple ve Google yeni özellikleri kendi SDK’ları üzerinden yayınlar; React Native ya da Flutter tarafında bunları kullanmak için bir kütüphanenin güncellenmesini bekler ya da modülü kendiniz yazarsınız.
Biz de genellikle iOS ve Android’i React Native ile tek kod tabanından geliştiriyor, hazır kütüphanenin yetmediği yerde platforma özel modüller ekliyoruz.
Ekip yetkinliği ve web ile kod paylaşımı
Teknoloji seçimi, aslında ekip seçimidir. React Native, React’in programlama modelini Android ve iOS’a taşır (reactnative.dev); React ve TypeScript bilen bir web ekibi aynı dil, aynı bileşen mantığı ve aynı paket yöneticisiyle çalışmaya devam eder. Flutter için Dart bilen ya da öğrenecek bir ekip gerekir; Flutter çatısının kendisi de Dart ile yazılmıştır (Flutter SSS). Native geliştirmede ise iki ayrı uzmanlık gerekir: iOS için Swift, Android için Kotlin. Google, yeni bir Android uygulamasına Kotlin ile başlamayı öneriyor ve Compose gibi yeni araçları Kotlin kullanıcılarını düşünerek tasarlıyor (Android Developers).
Web tarafında React ya da Next.js ile yazılmış bir yönetim paneliniz veya müşteri siteniz varsa, React Native ile şunları paylaşabilirsiniz: TypeScript tipleri, API istemcisi, doğrulama kuralları ve iş mantığı. Arayüz bileşenleri ise doğrudan paylaşılmaz, çünkü React Native HTML yerine View ve Text gibi kendi bileşenlerini kullanır. Bu bileşenleri web’de çalıştırmak için topluluk projesi React Native Web vardır; Expo da tek projeden Android, iOS ve web uygulaması çıkarmayı hedefler.
Flutter ile de web uygulaması yapılabilir; ancak Flutter’ın kendi dokümantasyonu, Flutter web’in uygulama odaklı deneyimlere (PWA, tek sayfa uygulamalar) uygun olduğunu, blog gibi metin ağırlıklı statik siteler için uygun olmadığını ve çıktısının arama motorlarının dizinleme ihtiyacıyla örtüşmediğini belirtir (Flutter web SSS). Arama motorunda görünmesi gereken sayfalarınız varsa bunları ayrı planlamanız gerekir.
Ekosistem, uygulama boyutu ve uzun vadeli bakım
Ekosistem. React Native, npm paketlerini ve topluluğun geliştirdiği native bileşenleri kullanır (React Native). Flutter paketleri pub.dev üzerinde yayınlanır. Native tarafta Apple’ın ve Google’ın kendi kütüphaneleri doğrudan kullanılır. Hangi yolu seçerseniz seçin, bir kütüphaneyi eklemeden önce son sürüm tarihine, açık hata kayıtlarına ve çerçevenin güncel sürümünü destekleyip desteklemediğine bakın; eklediğiniz her kütüphane ileride güncellemeniz gereken bir parçadır.
Uygulama boyutu. Flutter’ın dokümantasyonuna göre motor, uygulamaya sıkıştırılmış hâlde birkaç megabaytlık bir taban boyut ekler; boyutu asıl belirleyen görseller, fontlar ve üçüncü taraf paketlerdir (Flutter SSS). React Native varsayılan olarak Hermes motorunu kullanır; dokümantasyona göre birçok uygulamada JavaScriptCore’a kıyasla daha küçük uygulama boyutu sağlar (Hermes). Native uygulamada ayrıca bir çerçeve motoru taşınmaz. Gerçek indirme boyutunu ise geliştirme çıktısından değil, Play Console ve App Store Connect raporlarından ölçmek gerekir (Flutter).
Bakım ve işe alım. Mağaza gereksinimleri üç yaklaşımı da etkiler. Google Play’de 31 Ağustos 2026’dan itibaren yeni uygulamalar ve güncellemeler Android 16’yı (API düzeyi 36) hedeflemelidir; App Store’a 28 Nisan 2026’dan bu yana yüklenen uygulamalar Xcode 26 ve iOS 26 SDK’sı ile derlenmelidir. Çapraz platformda bu güncellemelere React Native ya da Flutter sürüm yükseltmesi ve kütüphanelerin uyumu eklenir; native tarafta ise aynı iş iki ayrı kod tabanında yapılır. İşe alımda da benzer bir tablo vardır: React Native için web’le ortak bir JavaScript/TypeScript yetkinliği, Flutter için Dart deneyimi, native için iki ayrı uzman profili ararsınız.
Hangisi ne zaman mantıklı?
React Native mantıklıdır, eğer:
- Ekibinizde React ve TypeScript bilgisi varsa ya da web tarafınız React veya Next.js ile yazılmışsa,
- Müşteri, işletme ve kurye gibi birden çok rolü olan; form, liste, harita ve ödeme ağırlıklı bir iş uygulaması yapıyorsanız,
- Arayüzün her platformda o platformun bileşenleriyle görünmesini istiyorsanız.
Flutter mantıklıdır, eğer:
- Her platformda aynı görünen, markaya özel ve animasyonu bol bir arayüz istiyorsanız,
- Ekibiniz Dart’a hâkimse ya da öğrenmeye hazırsa,
- Mobilin yanında masaüstü sürümleri de hedefliyorsanız; Flutter macOS, Windows ve Linux’u da destekler (Flutter SSS).
Native mantıklıdır, eğer:
- Uygulamanın değeri platforma derinden bağlıysa: widget’lar, saat uygulamaları, arka plan işlemleri, yoğun kamera ya da sensör kullanımı,
- Yalnızca tek bir platform hedefliyorsanız,
- iOS ve Android için ayrı ve kalıcı ekipler kurabiliyorsanız.
Sık sorulan sorular
Kotlin Multiplatform nerede duruyor?
Kotlin Multiplatform, JetBrains’in Android, iOS, masaüstü, web ve sunucu arasında kod paylaşmayı sağlayan açık kaynak teknolojisidir. Arayüzü SwiftUI ya da UIKit ile native yazabilir, Compose Multiplatform ile ortak yazabilir ya da ikisini karıştırabilirsiniz (Kotlin). Android ekibi güçlü olan ve iOS’ta native arayüzden vazgeçmek istemeyen ekipler için dördüncü bir seçenektir.
Mevcut native uygulamaya React Native ya da Flutter eklenebilir mi?
Evet. React Native, mevcut native uygulamalara tek bir ekran ya da akış eklemeyi destekler; Flutter da Add-to-App ile mevcut Android ve iOS uygulamalarına eklenebilir. Böylece uygulamayı baştan yazmak yerine yeni özellikleri yeni teknolojiyle geliştirerek kademeli geçiş yapabilirsiniz.
Teknolojiyi sonradan değiştirmek mümkün mü?
Mümkün, ancak arayüz katmanı büyük ölçüde yeniden yazılır. Arka uç, API ve veritabanı aynı kalabilir. Bu yüzden iş kurallarını mümkün olduğunca sunucuda tutmak, ileride yapılacak bir geçişi de kolaylaştırır.
Sonuç
React Native, Flutter ve native arasındaki seçimi çoğu zaman performanstan çok ekibinizin dili, web ile paylaşmak istediğiniz kod ve platforma ne kadar derin bağlanacağınız belirler. Biz genellikle React Native ile tek kod tabanından ilerliyor, gerektiğinde platforma özel modüller ekliyoruz. Projenizin bütçesini neyin belirlediğini mobil uygulama geliştirme maliyeti yazımızda anlattık. İsterseniz projenize uygun yaklaşıma birlikte bakalım: web ve mobil uygulama geliştirme sayfamızdan nasıl çalıştığımızı görebilirsiniz.
