Sıfırdan Çalışan Uygulamaya Geçen Süre ve Ekip Beceri Uyumu
Expo'da başlangıç npx create-expo-app komutuyla saniyeler içinde çalışan bir uygulama verir; Node.js LTS dışında bir kurulum gerekmez, telefonda Expo Go ile anında test edebilirsin. Flutter'da resmi patika önce Flutter SDK kurulumunu, ardından platform toolchain'lerini (Xcode + CocoaPods, Android Studio + Gradle) kurmayı gerektirir — "sıfırdan çalışan uygulamaya" giden yol yapısal olarak daha uzun bir ilk adım içerir. Bu farkın nicel, resmi bir ölçümü yok; ikisi de "birkaç dakika" diyebileceğin işler ama Expo'nun path'i daha az bağımlılık ister.
Ekip beceri uyumu tarafında fark daha net: Expo React/TypeScript üzerine kurulu, bu yüzden bir web ekibinin JS/React bilgisi doğrudan taşınır. Flutter, Dart'ı öğrenmeni ister — sözdizimi C-ailesine yakın olsa da, widget-tree modeli ve state yönetim paternleri (Provider, Riverpod, BLoC) yeni bir öğrenme eğrisi getirir. Ekibinde zaten React bilgisi varsa Expo ile üretkenliğe geçiş süresi kısalır; sıfırdan bir mobile ekip kuruyorsan bu fark önemini kaybeder çünkü her iki dilde de öğrenme süreci gerekir.
UI Katmanı Sahipliği: Ayrılan Paketler vs Hiç Olmayan Kütüphane
Burada 12 Ağustos 2026 en büyük kırılma noktası. Flutter 3.47'ye kadar Material ve Cupertino widget'ları yalnız SDK'nın çekirdeğinde gelirdi; artık material_ui ve cupertino_ui adıyla pub.dev'de 1.0'a ulaşmış bağımsız paketler olarak da alınabiliyor. Dikkat et: bu sürümde geçiş opt-in — çekirdek SDK bu kütüphaneleri hâlâ içeriyor. Amaç, kütüphanelerin SDK'nın üç aylık döngüsünden bağımsız, haftalık planlanan kendi kadansında yayın yapabilmesi. Pratik sonucu şu: SDK-içi eski sürümler Kasım 2026 stable'ında deprecate edilecek, yani her Flutter projesi bir noktada dart fix --apply --code=migrate_design_widgets ile bu geçişi yapmak zorunda kalacak.
Expo/React Native tarafında bu tartışma hiç var olmadı çünkü resmi bir dahili tasarım kütüphanesi asla sunulmadı. Ekip, Material Design'a benzer bileşenler için React Native Paper gibi üçüncü taraf kütüphaneler seçer ya da kendi tasarım sistemini kurar. Tutarlı, platformdan bağımsız pixel-perfect görünüm istiyorsan Flutter'ın widget seti (yeni paket hâliyle de) daha az karar yükü getiriyor; native platform hissini birebir istiyorsan Expo/RN tarafında bu işi üçüncü taraf kütüphanelerle sen kurarsın.
Yönetilen Servis Kapsamı: EAS'ın 6 Ürünü vs Kendin Kur
Bu, iki tarafı en çok ayıran eksen. Expo'nun EAS'ı altı ayrı ürün sunuyor: Build (native derleme), Submit (mağaza gönderimi), Workflows (CI/CD otomasyonu), Update (OTA), Hosting ve 20 Ağustos 2026'da GA'ya geçen Observe (başlangıç/performans izleme). Hepsi tek hesap, tek fiyatlandırma, tek dashboard altında. Free plan ayda 15 Android + 15 iOS build ve 1.000 MAU'ya kadar OTA update içeriyor — küçük bir proje için sıfır ek maliyetle başlanabiliyor; aşımda Starter ($19/ay + kredi) veya Production ($199/ay) katmanına geçmek gerekiyor.
Flutter tarafında bu kapsam tek bir resmi ürüne değil, senin seçtiğin araçlara dayanır: CI/CD için Codemagic, GitHub Actions veya kendi pipeline'ın; crash/performans izleme için Firebase Crashlytics veya Sentry; dağıtım için Fastlane gibi araçları sen entegre edersin. Maliyeti iki yönlü: framework'ün kendisi ücretsiz, ama bu araçları seçmek, entegre etmek ve bakmak ekibin işi. Küçük bir ekipte Expo'nun "hepsi dahil" modeli DevOps yükünü belirgin azaltır; özel gereksinimleri olan kurumsal bir ekipte Flutter'ın "kendi araçlarını seç" esnekliği kısıtlama değil, tercihtir.
OTA Güncelleme Desteği: Resmi Ürün vs Ürün Yokluğu
EAS Update, Expo'nun en somut farklılaştırıcılarından biri: JS ve varlık (asset) düzeyindeki değişiklikleri mağaza incelemesi beklemeden kullanıcıya ulaştırabiliyorsun. Bunun sınırı da net — hem Apple'ın App Store Review Guideline 3.3.1'i hem Google Play politikası, OTA ile yalnız yorumlanan kod/varlık güncellemesine izin veriyor; native kod değişikliği veya uygulamanın temel amacını değiştirecek özellikler bu yolla gönderilemez. Yani EAS Update bir "her şeyi atlat" mekanizması değil, kritik JS-bug fix'leri için bir güvenlik supabı.
Flutter'da bu kapsamda resmi, dokümante edilmiş bir OTA/code-push ürünü yok — release build'ler AOT (ahead-of-time) derlenmiş native ikili olduğu için JS tarzı bir "runtime güncelleme" mimarisi framework'ün doğasında bulunmuyor. Pratik sonuç şu: Flutter'da küçük bir bug-fix bile yeni bir build + mağaza incelemesi döngüsü gerektiriyor. Sık, küçük düzeltmeler göndermesi gereken bir ürün ekibiysen bu, Expo lehine somut bir operasyonel fark.
Paket Ekosistemi Büyüklüğü ve Bakım Durumu
GitHub yıldızı kaba ama karşılaştırılabilir bir sinyal: flutter/flutter 178.800 yıldızla expo/expo'nun 52.063 yıldızının önünde (2026-09-06, GitHub API canlı veri). Ama bu rakam tek başına ekosistem büyüklüğünü tam yansıtmıyor — Expo, React Native'in devasa npm ekosisteminin üzerine kurulu; yani Expo projesi aslında hem Expo SDK paketlerine hem de milyonlarca npm paketine erişebiliyor. Flutter'ın pub.dev'i daha genç ama Google'ın doğrudan katkısıyla daha merkezi kalite kontrolüne sahip; flutter/packages altındaki resmi paketler (ör. go_router) ile topluluk favorileri (provider, riverpod) düzenli güncelleniyor.
Bakım açısından her iki ekosistemde de "terk edilmiş paket" riski var — bu, framework'e özgü değil, açık kaynak ekosisteminin genel bir gerçeği. Flutter'ın avantajı, material_ui/cupertino_ui örneğinde görüldüğü gibi Google'ın çekirdek widget'ları resmi olarak sürdürmesi; Expo'nun avantajı, expo-router/expo-updates/expo-camera gibi ilk-taraf modüllerin EAS ile aynı şirket tarafından, aynı release ritmiyle bakılması. İkisi de "resmi modüller güvenilir, üçüncü taraf modülde bakım durumunu kontrol et" kuralına tabi.
Web/Masaüstü Hedefleme ve Toplam Sahip Olma Maliyeti
Flutter resmi olarak dört hedef ailesini destekliyor: mobile, web, masaüstü (Windows/macOS/Linux) ve embedded; dokümantasyonda her platform için ayrı destek matrisi var. Expo'nun resmi kapsamı Android/iOS/web ile sınırlı; masaüstü ilk-taraf hedef listesinde yok, bunun için React Native ekosisteminde ayrı projeler (ör. React Native Windows/macOS) gerekiyor ve bunlar Expo'nun yönetilen akışının parçası değil. Masaüstünü de gerçekten ilk sınıf hedeflemek istiyorsan bu, Flutter lehine net bir fark.
Toplam sahip olma maliyeti (TCO) tarafında iki farklı maliyet kalemi var. Expo'da maliyet EAS abonelik kademelerinde somutlaşıyor: Free → Starter ($19/ay + kredi) → Production ($199/ay) — büyüdükçe fatura büyüyor ama karşılığında CI/CD, OTA ve izleme dahil geliyor. Flutter'da framework ücretsiz ve resmi bir fiyat sayfası yok, ama maliyet yok olmuyor — CI/CD (Codemagic ya da kendi runner'ların), crash/performans izleme (Firebase/Sentry) ve dağıtım (Fastlane) için ayrı araç seçip entegre etmen, bu araçların faturasını ve bakım yükünü üstlenmen gerekiyor. Kısacası: Expo'da TCO tek faturada görünür, Flutter'da TCO dağınık ama framework'ün kendisi bedava.