PromptWake
← Blog
·14 min

Platformlar Arası Mobil Geliştirme: Stratejinizi Seçmek

React Native, Flutter, Kotlin Multiplatform ve native geliştirmenin kapsamlı bir karşılaştırması — mobil stratejilerini seçen ekipler için pratik tavsiyeler.

Her mobil ekibi bir yol ayrımına gelir. iOS ve Android'de kullanıcılarınız, sınırlı bir mühendislik bütçeniz ve mevcut hızınızın ötesinde özellikler çıkarma baskınız vardır. Artık soru, platformlar arası geliştirmeyi düşünüp düşünmemek değil — hangi yaklaşımın sizin özel kısıtlamalarınıza uyduğudur. 2026'da ortam her zamankinden daha olgun ve dört baskın strateji dikkatinizi çekmek için yarışıyor: React Native, Flutter, Kotlin Multiplatform ve native SDK'lar. Her biri son birkaç yılda önemli ölçüde evrildi ve aralarındaki farklar daraldı.

Bu rehber, bu yaklaşımları önem taşıyan her boyutta karşılaştırıyor: geliştirici deneyimi, performans, UI doğruluğu, durum yönetimi, test, dağıtım ve uzun vadeli sürdürülebilirlik. Tek bir kazanan ilan etmez, çünkü böyle bir kazanan yoktur. Doğru seçim, ekibinizin mevcut becerilerine, ürününüzün gereksinimlerine ve platforma özgü geçici çözümlere olan toleransınıza bağlıdır. Bu rehberin yapacağı şey, bu kararı vermek için size yapılandırılmış bir çerçeve sunmaktır.

2026'de platformlar arası ortam

Platformlar arası geliştirme, PhoneGap ve Cordova'nın ilk günlerinden bu yana çarpıcı bir şekilde olgunlaştı. Mevcut nesil framework'ler, on yıl önce imkansız görünecek kod paylaşım oranlarıyla native kalitesinde deneyimler sunuyor. React Native mimari rönesansını yaşadı, Flutter mobilin ötesinde masaüstü ve web'e genişledi ve Kotlin Multiplatform, native UI'dan ödün vermeden paylaşılan mantık isteyen ekipler için pragmatik seçenek olarak ortaya çıktı.

Pazar da netleşti. Framework değişikliği — seçtiğiniz teknolojinin iki yıl içinde terk edileceği korkusu — 2022'de olduğundan daha az endişe verici. Meta, React Native'e yoğun yatırım yapmaya devam ediyor, Google Flutter geliştirmeyi yavaşlatma belirtisi göstermiyor ve JetBrains, güçlü endüstriyel benimsemeyle Kotlin Multiplatform'u istikrara kavuşturdu. Her platformun risk profili iyi anlaşılmış durumda ve bu istikrar, uzun vadeli taahhütte bulunmayı kolaylaştırıyor.

Değişmeyen şey ise temel gerilim: paylaşılan kod geliştirme maliyetini düşürür ancak sızıntı yapabilen soyutlama katmanları getirir — özellikle derin platform entegrasyonu gerektiğinde. 2026'daki kazanan strateji, platformu tamamen gizleyen bir framework bulmak değil; platform sınırını öngörülebilir ve geçmeniz gerektiğinde ergonomik hale getiren birini seçmektir.

React Native

Mimari ve yeni mimari

React Native, herhangi bir platformlar arası framework'ün en önemli mimari dönüşümünü geçirdi. Yeni Mimari — Fabric (yeni render sistemi) ve TurboModules'den (yeni native modül sistemi) oluşan — artık React Native 0.76 ve sonrasında varsayılandır. Bu, artımsal bir iyileştirme değil. Başlangıcından bu yana React Native'in darboğazı olan bridge'in baştan aşağı yeniden yazılmasıdır.

Eski bridge asenkrondü ve her şeyi JSON üzerinden serileştiriyordu. JavaScript ve native kod arasındaki her etkileşim bir serileştirme sınırını geçiyordu ve bu da her jest, animasyon ve API çağrısına gecikme ekliyordu. Fabric bunu, JavaScript Interface (JSI) adı verilen yeni bir iş parçacığında çalışan senkron bir arayüzle değiştiriyor ve JavaScript'in native nesnelere referans tutmasına ve onları doğrudan çağırmasına olanak tanıyor. Sonuç, daha hızlı başlatma süreleri, daha düşük bellek kullanımı ve çoğu kullanım durumunda native kodla rekabet eden animasyon performansıdır.

TurboModules, native modülleri tembelce yükler, böylece uygulamanız yalnızca gerçekten kullandığı modüller için başlatma maliyetini öder. Eski bridge altında, her native modül gerekip gerekmediğine bakılmaksızın başlangıçta yükleniyordu — bu, birçok bağımlılığı olan uygulamalar için önemli bir cezaydı. Yeni mimari ayrıca, daha önce garip geçici çözümler gerektiren dosya G/Ç ve veritabanı erişimi gibi senkron native API'lerle birlikte çalışabilirliği de sağlar.

Expo ve geliştirici deneyimi

Expo, duvarlarla çevrili bir bahçeden React Native projesine başlamanın önerilen yoluna dönüştü. expo-dev-client yaklaşımı, çoğu geliştirme için Expo'nun yönetilen iş akışını kullanmanıza olanak tanırken, özel native modüller için gerektiğinde çıplak iş akışına geçme yeteneğini korur. Expo Application Services (EAS), geleneksel olarak React Native dağıtımıyla ilişkili DevOps sorunlarının çoğunu ortadan kaldıran bulut tabanlı derlemeler, gönderimler ve güncellemeler sağlar.

Geliştirici deneyimine değer veren ekipler için Expo'nun araçlarının önemi abartılamaz. Sıcak yeniden yükleme platformlar arasında güvenilir şekilde çalışır. Derleme hattı kod imzalama, provizyon profilleri ve app store meta verilerini halleder. Expo Updates aracılığıyla kablosuz güncellemeler, JavaScript paketlerini app store incelemesinden geçmeden göndermenizi sağlar — tek başına bu yetenek birçok ekip için denklemi değiştirir.

Expo, React Native geliştirici deneyimi için framework'ün kendisindeki herhangi bir değişiklikten daha fazlasını yaptı. Bir projeye başlamak ile mağazaya yayınlamak arasındaki mesafe haftalardan saatlere indi.

Pratik bir React Native bileşeni

import { View, Text, FlatList, Pressable, StyleSheet } from "react-native";
import { useCallback, useMemo } from "react";
import Animated, { FadeInUp } from "react-native-reanimated";

interface Product {
  id: string;
  name: string;
  price: number;
  inStock: boolean;
}

interface ProductListProps {
  products: Product[];
  onProductPress: (id: string) => void;
}

function ProductCard({ product, onPress }: {
  product: Product;
  onPress: (id: string) => void;
}) {
  return (
    <Animated.View entering={FadeInUp.duration(300)}>
      <Pressable
        style={styles.card}
        onPress={() => onPress(product.id)}
      >
        <Text style={styles.name}>{product.name}</Text>
        <Text style={styles.price}>
          ${product.price.toFixed(2)}
        </Text>
        {!product.inStock && (
          <Text style={styles.outOfStock}>Out of stock</Text>
        )}
      </Pressable>
    </Animated.View>
  );
}

export function ProductList({ products, onProductPress }: ProductListProps) {
  const renderItem = useCallback(
    ({ item }: { item: Product }) => (
      <ProductCard product={item} onPress={onProductPress} />
    ),
    [onProductPress]
  );

  return (
    <FlatList
      data={products}
      renderItem={renderItem}
      keyExtractor={(item) => item.id}
      contentContainerStyle={styles.container}
    />
  );
}

const styles = StyleSheet.create({
  container: { paddingHorizontal: 16, paddingVertical: 8 },
  card: {
    backgroundColor: "#fff",
    borderRadius: 12,
    padding: 16,
    marginBottom: 8,
    shadowColor: "#000",
    shadowOffset: { width: 0, height: 2 },
    shadowOpacity: 0.1,
    shadowRadius: 8,
    elevation: 3,
  },
  name: { fontSize: 16, fontWeight: "600" },
  price: { fontSize: 14, color: "#666", marginTop: 4 },
  outOfStock: { fontSize: 12, color: "#e53e3e", marginTop: 4 },
});

Bu bileşen, React Native'in güçlü yönlerini gösterir: tanıdık bir React API'si, Pressable ve FlatList gibi platformdan soyutlanmış ilkeller ve yüksek performanslı animasyonlar için reanimated kütüphanesine erişim. Aynı kod, çoğu durumda aynı davranışla her iki platformda da çalışır.

Flutter

Dart, widget'lar ve render motoru

Flutter, React Native'den temelde farklı bir yaklaşım benimser. Native UI bileşenlerine köprü kurmak yerine, Flutter kendi render motorunu — Skia (ve şimdi iOS'ta Impeller) — gönderir ve her pikseli kendisi boyar. Bu, Flutter'ın platformun UI araç takımına hiç bağımlı olmadığı anlamına gelir. Bir Flutter düğmesi, bir UIButton veya Android Button değildir. Flutter'ın motoru tarafından çizilen piksellerdir ve bu da framework'e render hattı üzerinde tam kontrol sağlar.

Bunun pratik sonucu öngörülebilirliktir. Flutter widget'ları, aynı widget'lar oldukları için iOS ve Android'de aynı şekilde davranır. Platform farklılaşması, bir metin girişinin bir platformda doğru görünüp diğerinde bozuk göründüğü uç durumlar yoktur. Bu tutarlılık, platform kurallarından çok marka ifadesine öncelik veren ekipler için Flutter'ın en önemli özelliğidir.

Bunun karşılığında, Flutter uygulamaları her platformda biraz yabancı hissedebilir. iOS'taki bir Flutter uygulaması, kutudan çıktığı gibi UIKit'in native kaydırma fiziğini, gezinme geçişlerini veya metin seçme davranışlarını kullanmaz. Google, iOS tasarım dilini taklit eden Cupertino widget'ları gibi platform uyarlama kütüphanelerine yatırım yapmıştır, ancak bunlar gerçek şeyin yaklaşımlarıdır. Platform kurallarına derinden alışmış kullanıcılar farkı fark edebilir.

Flutter'ın arkasındaki dil olan Dart, evrilmeye devam ediyor. Null güvenliği, bir dizi çalışma zamanı çökmesini ortadan kaldırdı. Dart 3'te tanıtılan pattern matching ve record'lar, dili modern TypeScript ve Kotlin ile rekabet edebilir hale getiriyor. JavaScript veya Java'dan gelen geliştiriciler için öğrenme eğrisi sığdır, ancak widget-ağacı kompozisyon stili, JSX şablonlarına alışkın geliştiriciler için uyum gerektirir.

Bir Flutter widget örneği

import 'package:flutter/material.dart';

class Product {
  final String id;
  final String name;
  final double price;
  final bool inStock;

  const Product({
    required this.id,
    required this.name,
    required this.price,
    required this.inStock,
  });
}

class ProductCard extends StatelessWidget {
  final Product product;
  final VoidCallback onTap;

  const ProductCard({
    super.key,
    required this.product,
    required this.onTap,
  });

  @override
  Widget build(BuildContext context) {
    return Card(
      margin: const EdgeInsets.symmetric(horizontal: 16, vertical: 4),
      child: InkWell(
        onTap: onTap,
        child: Padding(
          padding: const EdgeInsets.all(16),
          child: Column(
            crossAxisAlignment: CrossAxisAlignment.start,
            children: [
              Text(
                product.name,
                style: const TextStyle(
                  fontSize: 16,
                  fontWeight: FontWeight.w600,
                ),
              ),
              const SizedBox(height: 4),
              Text(
                '\$${product.price.toStringAsFixed(2)}',
                style: const TextStyle(
                  fontSize: 14,
                  color: Colors.grey,
                ),
              ),
              if (!product.inStock)
                const Text(
                  'Out of stock',
                  style: TextStyle(
                    fontSize: 12,
                    color: Colors.red,
                  ),
                ),
            ],
          ),
        ),
      ),
    );
  }
}

class ProductList extends StatelessWidget {
  final List<Product> products;
  final void Function(String id) onProductTap;

  const ProductList({
    super.key,
    required this.products,
    required this.onProductTap,
  });

  @override
  Widget build(BuildContext context) {
    return ListView.builder(
      itemCount: products.length,
      itemBuilder: (context, index) {
        final product = products[index];
        return ProductCard(
          product: product,
          onTap: () => onProductTap(product.id),
        );
      },
    );
  }
}

Flutter'ın widget kompozisyonu, React Native'e kıyasla açık ve ayrıntılıdır, ancak widget ağacı üzerinde size tam kontrol verir. Her görsel öğe bir widget'tır — padding, margin, hizalama, hatta jest yönetimi. CSS veya JSX yoktur; her şey Dart kodudur. Bu yaklaşım, birçok web tabanlı framework'ü rahatsız eden düzen dosyaları ile mantık dosyaları arasındaki bağlam değiştirmeyi ortadan kaldırır.

Impeller ve render performansı

Impeller, Flutter'ın yeni render çalışma zamanı, iOS'ta Flutter hakkında en sık yapılan şikayeti ele alır: animasyonların ilk karesindeki takılma. Skia'nın shader derleme gecikmesi, ilk renderlarda görünür takılmalara neden oluyordu. Impeller, shader'ları derleme zamanında önceden derleyerek bu takılmayı tamamen ortadan kaldırır. Flutter'ın 120 fps kaydırma ve özel animasyondaki mevcut güçlü yönleriyle birleştiğinde, render hikayesi artık tüm platformlarda etkileyicidir.

Kotlin Multiplatform

Paylaşılan mantık, native UI

Kotlin Multiplatform (KMP), React Native veya Flutter'dan farklı bir felsefi pozisyon alır. Birleşik bir UI framework'ü sağlamak yerine, KMP yalnızca iş mantığını — ağ iletişimi, veri modelleri, doğrulama, depository ve durum yönetimi — paylaşmaya odaklanırken UI katmanını tamamen native bırakır. Paylaşılan kodunuzu Kotlin'de yazar, Kotlin/Native aracılığıyla platforma özgü ikili dosyalara derler ve iOS'ta Swift'ten, Android'de ise Kotlin/JVM'den çağırırsınız.

Bu yaklaşım, platforma özgü UI hakkında güçlü fikirleri olan ancak iş mantığının tekrarlanmasını ortadan kaldırmak isteyen ekiplerde yankı bulur. Karmaşık veri modelleri, sofistike ağ iletişim mantığı veya paylaşılan doğrulama kuralları olan bir uygulama oluşturuyorsanız, KMP bu kodu bir kez yazmanıza ve her iki platform kod tabanından kullanmanıza olanak tanır. UI kodu, özdeş SwiftUI veya Jetpack Compose olarak kalır; bu, iOS uygulamanızın bir iOS uygulaması gibi, Android uygulamanızın da bir Android uygulaması gibi hissettirmesi anlamına gelir.

Bunun karşılığında, KMP Kotlin, Swift ve Android geliştirmede yeterlilik gerektirir — React Native veya Flutter'ın talep ettiğinden daha geniş bir beceri seti. Paylaşılan kod, Android topluluğu dışında JavaScript veya Dart kadar yaygın olarak bilinmeyen Kotlin'dir. KMP'yi benimseyen ekiplerin tipik olarak çapraz eğitime yatırım yapması veya birden çok ekosistemde rahat olan geliştiricileri işe alması gerekir.

Entegrasyon desenleri

  • Ktor istemcisi ile paylaşılan ağ katmanı — API sözleşmelerini bir kez tanımla, her iki platformdan kullan
  • Paylaşılan veri modelleri ve doğrulama mantığı — platforma özgü uygulamalar arasındaki kaymayı ortadan kaldırır
  • expect/actual bildirimleri ile platforma özgü depolama uygulamalarına sahip depository deseni
  • Platform tarafından gözlemlenebilir durum akışlarına sahip paylaşılan ViewModel veya use-case katmanı
  • Paylaşılan analitik, günlük kaydı ve hata raporlama altyapısı

expect/actual mekanizması, platform farklılaşmasını yönetmek için KMP'nin birincil aracıdır. Ortak kodda beklenen bir API bildirir ve her platform için gerçek uygulamalar sağlarsınız. Bu, React Native'in native modül bridge'inden daha temizdir çünkü arayüz derleme zamanında kontrol edilir — beklenen bir işlev bir platformda uygulanmazsa, kodunuz derlenmez.

Compose Multiplatform

JetBrains ayrıca Jetpack Compose'u iOS ve masaüstüne genişleten Compose Multiplatform'a yatırım yapıyor. Bu, Flutter'a daha doğrudan bir rakiptir ve Compose'un bildirimsel render modeli aracılığıyla UI kodunu platformlar arasında paylaşır. 2026 itibarıyla, iOS için Compose Multiplatform kararlıdır ancak widget kütüphanesi derinliği ve üçüncü taraf ekosistemi açısından Flutter'dan daha az olgundur. Halihazırda Kotlin ekosistemine yatırım yapmış ekipler için izlenmeye değerdir, ancak henüz daha yerleşik platformlar arası UI framework'leriyle eşit seviyede değildir.

Performans karşılaştırması ve kıyaslamalar

Performans, platformlar arası framework'lerin en çok ilerleme kaydettiği — ve pazarlama iddialarının gerçeklikten en kopuk olduğu — alandır. Her framework, native kodu geride bıraktığı bir demo gösterebilir. Asıl soru, karmaşık gezinme, arka plan iş parçacıkları ve cihaz parçalanması olan gerçek bir uygulamada ne olduğudur.

  • Flutter, kendi kendine yeten motoru sayesinde ham render iş hacminde liderdir. Impeller, orta seviye cihazlarda bile tutarlı 120 fps sağlar. Bedeli daha büyük bir uygulama ikili dosyasıdır — tipik olarak native eşdeğerinden 15-30 MB daha fazla.
  • Fabric ile React Native, arayı önemli ölçüde kapatır. JSI, bridge darboğazını ortadan kaldırır ve yeni mimari, kullanım durumlarının %95'inde native kaydırma ve animasyon performansına ulaşır. Kalan %5 — karmaşık jest etkileşimleri, ağır liste geri dönüşümü — hala native müdahale gerektirebilir.
  • Kotlin Multiplatform'un render ek yükü sıfırdır çünkü UI nativedir. Performans tamamen platform UI kodunuz tarafından belirlenir. Paylaşılan mantık katmanı, çoğu işlem için ihmal edilebilir olan birlikte çalışabilirlik sınırının ötesinde hiçbir çalışma zamanı maliyeti eklemez.
  • Native geliştirme, tavanı temsil etmeye devam eder. Uygulamanız mobil donanımın yapabileceklerinin sınırlarını zorluyorsa — gerçek zamanlı video işleme, AR, yüksek frekanslı sensör verileri — native kod, mantığınızla donanım arasına bir soyutlama katmanı eklemeyen tek seçenek olmaya devam eder.

Pratik çıkarım, tüketici ve kurumsal uygulamaların büyük çoğunluğu için herhangi bir modern platformlar arası framework'ün performansının yeterince iyi olduğudur. Çoğu mobil uygulamadaki darboğazlar ağ gecikmesi, verimsiz veri çekme ve kötü durum yönetimidir — render framework'ü değil. Bu daha büyük endişeleri göz ardı ederken render performansı için erken optimize etmek yaygın bir anti-desendir.

Ekiplerin, uygulamalarının gerçek darboğazı ana iş parçacığında çalışan tek bir SQL sorgusuyken, bir platformlar arası framework için render performansını optimize etmek üzere aylar harcadığını görüyoruz. Mimarınızı bir kıyaslamaya yatırmadan önce gerçek uygulamanızı profillemelisiniz.

Native modüller ve platforma özgü kod

Her platformlar arası framework, soyutlamalarının sızdığı sınıra eninde sonunda gelir. Bir React Native uygulamasının yalnızca Swift kütüphanesi olan bir Bluetooth SDK ile entegre olması gerekir. Bir Flutter uygulamasının, uygulama içi satın almalar için Apple'ın StoreKit'ini kullanması gerekir. Bir KMP uygulamasının, iOS'ta bulunmayan bir Kotlin kütüphanesine erişmesi gerekir. Her framework'ün bu sınırı nasıl ele aldığı, platformunuzu seçerken en önemli faktörlerden biridir.

React Native native modülleri

React Native'in TurboModules sistemi, native kod yazmak için temiz bir arayüz sağlar. Swift veya Java'da bir protokol uygular, modül kaydına kaydeder ve JavaScript'ten çağırırsınız. Yeni mimari, bunu kod oluşturma yoluyla senkron ve tip güvenli hale getirir. react-native-bluetooth-scan ve react-native-video gibi kütüphaneler iyi bakılır ve çoğu yaygın native entegrasyon ihtiyacını karşılar.

Zorluk, bir native modül yazmanın platform SDK'sı hakkında bilgi gerektirmesidir, bu da ekipte iOS ve Android geliştiricilerine ihtiyacınız olduğu anlamına gelir. Birçok React Native ekibi, yine de native uzmanlığına ihtiyaç duyduklarını fark eder — ya modül yazma ya da platforma özgü sorunları hata ayıklama için. Yalnızca JavaScript'ten oluşan bir mobil geliştirme ekibi hayali, pratikte nadiren gerçekleşir.

Flutter platform kanalları

Flutter, native kodla iletişim kurmak için platform kanallarını kullanır. Mekanizma React Native'in bridge'ine benzer — mesajlar serileştirilir ve Dart ile platform arasında asenkron olarak gönderilir. Flutter'ın Pigeon paketi, paylaşılan bir arayüz tanımından tip güvenli platform kanal kodu oluşturarak standart kodu azaltır ve serileştirme hatalarını ortadan kaldırır.

Flutter'ın ekosistemi, pub.dev aracılığıyla çoğu yaygın native kullanım durumu için paketler içerir — kamera, konum, biyometri, ödemeler. Platform kanal API'si basit entegrasyonlar için anlaşılırdır, ancak karmaşık native etkileşimler (çift yönlü iletişim gerektiren özel bir harita görünümü gibi), native geliştirme ile elde ettiğiniz doğrudan erişime kıyasla hantal hale gelebilir.

KMP expect/actual

Kotlin Multiplatform'un platforma özgü koda yaklaşımı, üçü arasında en tip güvenli olanıdır. expect/actual mekanizması, her platformun gerekli uygulamayı sağlamasını derleme zamanında zorunlu kılar. Bu, bir React Native modülünün bir platformda eksik olduğunda meydana gelen çalışma zamanı çökmelerini ortadan kaldırır. Dezavantajı, derleme zamanı kontrolünün geliştirme sürtünmesini artırmasıdır — yeni bir platform yeteneği eklemek, kodunuz derlenmeden önce hem expect bildiriminde hem de tüm actual uygulamalarında güncelleme gerektirir.

UI tutarlılığı ve platform kuralları

Marka tutarlılığı ile platform kuralları arasındaki gerilim, mobil geliştirmedeki en eski tartışmalardan biridir. Platformlar arası framework'ler marka tutarlılığına yönelme eğilimindedir — uygulamanız iOS ve Android'de aynı görünür. Bu, görsel kimliğin kritik olduğu ürünler için değerlidir. Ancak, platform standart davranışlarını bekleyen kullanıcıları hayal kırıklığına uğratabilir.

  • iOS kullanıcıları geri kaydırma hareketleri, yaylı animasyonlar ve native metin seçme tutamaçları bekler. Flutter ve React Native bunları yaklaşık olarak yapabilir, ancak davranış platform uygulamasıyla hiçbir zaman piksel mükemmelliğinde olmaz.
  • Android kullanıcıları geri düğmesinin tutarlı çalışmasını, material ripple efektlerini ve paylaşım intent'lerini bekler. Platformlar arası framework'ler bunların çoğunu halleder ancak erişilebilirlik hizmetleri veya üçüncü taraf klavye entegrasyonları gibi uç durumlarda sıklıkla farklılıklar ortaya çıkar.
  • Gezinme desenleri önemli ölçüde farklılaşır. iOS, geri düğmeleri ve itme geçişleri olan gezinme çubukları kullanır. Android, donanım veya yazılım geri düğmesi kullanır ve giderek tahmine dayalı geri hareketlerine dayanır. Platformlar arası gezinme kütüphaneleri bu farklılıkları soyutlar, ancak soyutlama kusursuz değildir.
  • Erişilebilirlik, farkın en geniş olduğu alandır. Her platformlar arası framework erişilebilirlik desteğini iyileştirmiştir, ancak native ekran okuyucular, dinamik metin ve yardımcı teknolojiler her platformda farklı davranır. Platform kalitesinde erişilebilirlik elde etmek, framework seçiminizden bağımsız olarak platforma özgü çalışma gerektirir.

Pragmatik yaklaşım, hangi platform kurallarının kullanıcılarınız için gerekli olduğuna ve hangilerinin marka tutarlılığı için feda edilebileceğine karar vermektir. Bir bankacılık uygulaması, standart metin girişleri ve klavye davranışlarına ihtiyaç duyar çünkü kullanıcılar bunların parola yöneticileri ve otomatik doldurma ile çalışmasını bekler. Bir medya tüketim uygulaması daha özel UI'ye izin verebilir çünkü kullanıcılar gezinme kurallarına değil, içeriğe odaklanmıştır.

Platformlar arası durum yönetimi

Durum yönetimi desenleri, platformlar arası framework'ler arasında önemli ölçüde farklılık gösterir. React Native, React'in ekosistemini devralır; bu, Redux Toolkit, Zustand, Jotai ve MobX gibi seçenekleriniz olduğu anlamına gelir. Her birinin kendi zihinsel modeli vardır ve bu parçalanma kafa karışıklığı kaynağı olabilir. Bununla birlikte, React topluluğu birkaç desen etrafında birleşmiştir — sunucu durumu için global depolar, UI durumu için hook'larla yerel durum ve yönlendirme için URL odaklı gezinme durumu.

Flutter'ın durum yönetimi ortamı daha parçalıdır. Framework, basit durumlar için setState sağlar, ancak gerçek uygulamalar daha yapılandırılmış bir şeye ihtiyaç duyar. Provider, Riverpod, BLoC ve GetX, hiçbiri Redux'un React dünyasında bir zamanlar sahip olduğu hakimiyete ulaşamadan zihin paylaşımı için rekabet eder. Riverpod, yeni projeler için topluluk favorisi olarak ortaya çıkmıştır — tip güvenlidir, test edilebilirdir ve widget ağacına bağlı değildir. Ancak parçalanma, Flutter projeleri arasında geçiş yapmanın genellikle yeni bir durum yönetimi paradigması öğrenmeyi gerektirdiği anlamına gelir.

Kotlin Multiplatform, durum yönetimini platforma devrederek bu soruyu yanıtlamaktan kaçınır. Paylaşılan Kotlin kodu, platform UI'sının gözlemlediği durum akışlarını açığa çıkarır. Android'de bu, Jetpack Compose'un durum modeliyle doğal olarak entegre olur. iOS'ta, SwiftUI gözlemleri veya Combine yayıncıları KMP akışlarına bağlanır. Paylaşılan kod, iş mantığını ve veri akışını halleder; platform, onu nasıl render edeceğine karar verir.

Framework'den bağımsız olarak, vereceğiniz en önemli durum yönetimi kararı sunucu durumunu nasıl ele alacağınızdır. Her mobil uygulama API'lerden veri çeker ve önbelleğe alma, yeniden çekme, iyimser güncellemeler ve çevrimdışı destek için seçtiğiniz desen, uygulamanızın kalitesi üzerinde hangi durum yönetimi kütüphanesini seçtiğinizden daha fazla etkiye sahip olacaktır. React Query (TanStack Query), SWR ve benzeri araçlar tüm framework'lerde mevcuttur ve elle yazılmış önbelleğe alma çözümlerine evrensel olarak tercih edilir.

Gezinme

Gezinme, mobil geliştirmedeki en platforma özgü konulardan biridir ve platformlar arası soyutlamaların başarısız olma olasılığının en yüksek olduğu yerdir. iOS ve Android'in temelde farklı gezinme metaforları vardır. iOS, itme/çekme geçişleri olan bir gezinme yığını kullanır. Android tarihsel olarak aktivite tabanlı bir sistem kullanmış ve Jetpack Navigation Compose ile tek aktiviteli bir mimariye doğru hareket etmiştir. Platformlar arası framework'ler bu farklılıkları uzlaştırmalıdır ve sonuçlar hiçbir zaman mükemmel değildir.

React Navigation, React Native için fiili standarttır. Platforma uyarlanabilir geçişlerle yığın, sekme, çekmece ve modal gezginleri destekler. Kütüphane önemli ölçüde olgunlaştı ve derin bağlantı, durum kalıcılığı ve ekran takibini güvenilir şekilde halleder. Ana eleştiri, önemli bir JavaScript paketi boyutu eklemesidir — kabaca 100 KB gzip'li — ve özel geçişlerin native kod gerektirmesidir.

GoRouter, Flutter'ın önerilen gezinme çözümüdür. Tip güvenli parametreler, derin bağlantı desteği ve kalıcı düzenler için shell rotaları ile bildirimsel yönlendirme sağlar. Flutter'ın gezinmesi, rezil bir şekilde kafa karıştırıcı olan Navigator 1.0 API'sinin yerini aldı ve GoRouter çarpıcı bir iyileştirmeyi temsil ediyor. Karmaşık geçiş animasyonları için React Navigation'dan daha az esnektir ancak standart kullanım durumları için daha öngörülebilirdir.

Platformlar arası uygulamalar için test stratejileri

Platformlar arası bir uygulamayı test etmek, saf native geliştirmenin getirmediği bir karmaşıklık getirir. Paylaşılan kodu, platform entegrasyon katmanını ve platforma özgü UI'yı test etmeniz gerekir — ve bu katmanlar arasındaki sınırlar, hataların saklandığı yerlerdir.

Paylaşılan iş mantığı için birim testi, framework'ten bağımsız olarak anlaşılırdır. React Native Jest kullanır, Flutter flutter_test kullanır ve KMP kotlin.test kullanır. Anahtar, kodunuzu iş mantığının framework ve platform bağımlılıklarından izole edileceği şekilde yapılandırmaktır. Bağımlılık enjeksiyonu, test edilebilirlik için isteğe bağlı değildir — mantığınızı dakikalar yerine milisaniyeler içinde test etmek arasındaki farktır.

UI testi, platformlar arası framework'lerin ayrıştığı yerdir. React Native, bileşen testleri için React Native Testing Library'ye ve uçtan uca testler için Detox'a sahiptir. Flutter, gerçek cihazlarda ve simülatörlerde çalışan ve widget testleriyle aynı API'yi paylaşan integration_test'e sahiptir. KMP, UI testini platforma bırakır — iOS'ta XCUITest ve Android'de Espresso ile test edersiniz. Flutter'ın birleşik test hikayesi, aynı test kodunun her iki platformda da çalışması nedeniyle tartışmasız en güçlü olanıdır.

Anlık görüntü (snapshot) testi, platformlar arası uygulamalar için özellikle değerlidir. Tek bir API çağrısı, her iki platformda da aynı veri modelini üretmeli ve anlık görüntü testleri, veri şeklinin farklılaştığı gerilemeleri yakalar. react-native-screenshots ve Flutter'ın altın dosya testi gibi araçlar, UI bileşenlerinin platformlar arasında doğru şekilde render edildiğini görsel olarak doğrulamanıza olanak tanır; bu, özellikle platform teması farklılıkları beklenmeyen düzen değişikliklerine neden olduğunda önemlidir.

App store dağıtımı ve CI/CD

Platformlar arası bir uygulamayı mağazaya çıkarmak, native geliştirmeyle aynı adımların tümünü içerir — kod imzalama, provizyon profilleri, app store meta verileri, inceleme — artı paylaşılan bir kod tabanından iki platform için derleme yapmanın ek karmaşıklığı. Araçlar önemli ölçüde iyileşti, ancak henüz kesintisiz değil.

Expo Application Services, React Native için en cilalı CI/CD deneyimini sağlar. EAS Build, tek bir yapılandırma dosyasından hem iOS hem de Android derlemelerini halleder. EAS Submit, her iki platform için mağaza yüklemelerini yönetir. EAS Update, kablosuz güncellemeleri halleder. Halihazırda Expo kullanan ekipler için dağıtım hattı etkili bir şekilde çözülmüş bir sorundur — git push'tan mağaza gönderimine Xcode veya Android Studio'ya dokunmadan gidebilirsiniz.

Flutter'ın derleme araçları framework'ün içine yerleşiktir. flutter build komutu platforma özgü paketler oluşturur ve Codemagic, Flutter için özel olarak optimize edilmiş bir CI/CD hizmeti sağlar. Fastlane entegrasyonu her iki platform için de iyi çalışır. Flutter dağıtımındaki ana zorluk, ikili dosya boyutudur — Flutter motoru, her platform ikili dosyasına yaklaşık 15-25 MB ekler; bu, uygulama boyutu sınırlarının katı olduğu veya kullanıcıların sınırlı depolama alanına sahip olduğu pazarlar için bir endişe kaynağı olabilir.

KMP'nin CI/CD'si, iki platforma özgü derleme hattı içerdiğinden en karmaşık olanıdır. Paylaşılan kod, iOS ve Android projeleri tarafından tüketilen bir native kütüphaneye derlenir. Bu, CI hattınızın önce KMP paylaşılan modülünü, ardından iOS uygulamasını ve Android uygulamasını ayrı ayrı derlemesi gerektiği anlamına gelir. Gradle, Android tarafını iyi halleder, ancak iOS entegrasyonu Xcode derleme adımlarının çalıştırılmasını gerektirir; bu da tipik olarak macOS tabanlı CI çalıştırıcıları anlamına gelir.

Native'i ne zaman seçmeli

Platformlar arası framework'ler, yalnızca native geliştirmenin çoğu uygulama için artık varsayılan seçenek olmadığı noktaya kadar iyileşti. Ancak native geliştirmenin daha iyi bir seçenek olarak kaldığı açık durumlar vardır. Bir framework'e bağlanmadan önce bu durumları tanımak, önemli ölçüde yeniden çalışmayı önler.

  • Uygulamanız platformun kendisidir — bir kamera uygulaması, video düzenleyici veya oyun oluşturuyorsanız, platformlar arası framework'lerin soyutlama katmanları, temel değer teklifinizi doğrudan etkileyen gecikme ve karmaşıklık ekler.
  • Derin platform entegrasyonuna ihtiyacınız var — ARKit, CoreML, HealthKit veya diğer platforma özgü API'leri yoğun olarak kullanan uygulamalar, kod paylaşımıyla kazandıklarından daha fazla zamanı native modül yazarak harcar.
  • Ekibiniz zaten platform native'si — deneyimli iOS ve Android geliştiricileriniz varsa ve Swift ile Kotlin'de üretkenlerse, platformlar arası framework'ler net faydalar olmadan eğitim maliyetleri ve soyutlama ek yükü ekler.
  • Performans farklılaştırıcınızdır — uygulamanız sensör verilerini yüksek frekansta işliyor, karmaşık 3D sahneler render ediyor veya 200 milisaniyenin altında başlaması gerekiyorsa, native kod bu gereksinimleri karşılamak için en doğrudan yolu sağlar.
  • Platform kalitesinde erişilebilirliğe ihtiyacınız var — platformlar arası erişilebilirlik iyileşti, ancak native ekran okuyucular, dinamik metin ve yardımcı teknoloji desteği her platformun native SDK'sında daha tutarlıdır.

Karar kalıcı değildir. Birçok başarılı uygulama, platformlar arası bir framework ile başlamış ve kullanıcı tabanı büyüdükçe ve gereksinimleri daha platforma özgü hale geldikçe native'e geçmiştir. Bunun tersi de yaygındır — pazarı doğrulamak için Flutter veya React Native ile prototip yapan, ardından üretim sürümü için native'e yatırım yapan uygulamalar. Anahtar, seçiminizin ömür boyu bir taahhüt olmadığını anlamaktır.

Size en hızlı şekilde yayınlama imkanı veren framework ile başlayın, ardından veri size söylediğinde önemli olan kısımları native kodda yeniden yazın. Mükemmel mimari, üzerinde yineleme yapmayı göze alabileceğiniz mimaridir.

Ekibiniz için doğru seçimi yapmak

Tüm teknik boyutları inceledikten sonra, kararınızdaki en önemli faktör ekibinizdir. Ekibinizin üretken olduğu bir framework, ekibinizin zorlandığı teknik olarak üstün bir framework'ten daha iyi performans gösterecektir. Bu, bildiklerinizle kalmanız için bir argüman değil — öğrenme eğrisi ve üretim hızına ulaşmanın ne kadar sürdüğü konusunda dürüst olmanız için bir argümandır.

Ekibiniz öncelikle React deneyimi olan web geliştiricilerinden oluşuyorsa, React Native doğal seçimdir. Zihinsel model neredeyse doğrudan aktarılır ve bir web uygulamasından mobil uygulamaya geçiş yolu iyi belgelenmiştir. Ekibiniz aylar yerine haftalar içinde üretken olacaktır. Risk, mobil geliştirmeyi farklı bir render hedefi olan web geliştirme olarak ele almaları, bellek baskısı, pil kullanımı ve jest yönetimi gibi platforma özgü endişeleri kaçırmalarıdır.

Ekibiniz sıfırdan başlıyorsa veya tasarım odaklı bir geçmişe sahipse, Flutter en cilalı geliştirici deneyimini sunar. Dart öğrenmesi kolaydır, Flutter'ın araçları mükemmeldir ve framework'ün yerleşik tasarım sistemi, ekiplerin platform uzmanlığı olmadan güzel, tutarlı UI'lar yayınlamasına olanak tanır. Risk, Flutter'ın ekosisteminin React Native'inkinden daha küçük olması ve niş gereksinimler için paket bulmanın daha zor olabilmesidir.

Ekibiniz güçlü Android ve iOS uzmanlığına sahipse ve platform UI'sından ödün vermeden iş mantığını paylaşmak istiyorsa, Kotlin Multiplatform stratejik seçimdir. Paylaşılan kod katmanı, her iki platforma da yabancı bir UI paradigması dayatmadan tekrarı ortadan kaldırır. Risk, iki yerine üç alanda (Kotlin, Swift ve Android) uzmanlığa ihtiyacınız olmasıdır.

Seçiminiz ne olursa olsun, altyapınıza erken yatırım yapın. Platformlar arası geliştirme, iyi CI/CD, otomatik test ve tekrarlanabilir derlemelerin önemini artırır. Tek bir kod değişikliği iki platformu aynı anda bozabilir ve her iki platform için manuel test hızla bir darboğaz haline gelir. Platformlar arası geliştirmede başarılı olan ekipler, derleme hatlarını ve test süitlerini sonradan akla gelen şeyler olarak değil, birinci sınıf endişeler olarak ele alan ekiplerdir.

2026'daki platformlar arası ortam, her zamankinden daha affedicidir. Büyük framework'ler istikrarlı, iyi belgelenmiş ve ölçekte kanıtlanmıştır. Aralarındaki farklar daraldı ve kalan boşluklar iyi anlaşılmıştır. Göreviniz, nesnel olarak en iyi framework'ü bulmak değildir — böyle bir framework yoktur. Göreviniz, ekibiniz, ürününüz ve kullanıcılarınız için en iyi uyumu bulmaktır. Gerisi uygulamadır.