Mobil Uygulama: Native mi, Cross-Platform mu?

Native uygulama, iOS ve Android için ayrı ayrı, her platformun kendi diliyle geliştirilen uygulamadır. Buna karşılık cross-platform (çapraz platform) uygulama, tek bir kod tabanından iki platforma birden çıkar. Native vs cross platform sorusunun tek doğru cevabı yoktur: Çoğu iş uygulaması için cross-platform yeterli ve daha ekonomiktir; platformun en yeni özelliklerine derinden bağlı ya da çok yoğun grafik işleyen uygulamalarda native öne çıkabilir.

Native uygulama nedir?

Native (yerel) uygulama, her platformun üreticisinin önerdiği dil ve araçlarla yazılır. Örneğin Apple, SwiftUI'ı "Swift'in gücüyle tüm Apple platformlarında uygulama geliştirmek" için sunar. Google ise 2019'dan bu yana Android geliştirmeyi "Kotlin öncelikli" (Kotlin-first) olarak konumlandırır; modern arayüz aracı Jetpack Compose da Kotlin ile kullanılır.

Artıları:

• Platformun yeni özelliklerine ilk gün erişim,
• Platform davranışına en yakın kullanıcı deneyimi,
• Yoğun grafik, kamera, sensör ya da arka plan işlerinde en geniş kontrol.

Eksileri:

• İki ayrı kod tabanı, çoğu zaman iki ayrı uzmanlık,
• Her özelliğin iki kez geliştirilip test edilmesi,
• Daha yüksek geliştirme ve bakım maliyeti.

Cross-platform nedir?

Cross-platform yaklaşımda uygulamanın büyük kısmı bir kez yazılır ve hem iOS hem Android'de çalışır. Ancak platforma özgü küçük bölümler (ör. belirli bir donanım özelliği) gerektiğinde bunları native kodla eklersiniz.

Bugün bu alanda en yaygın iki araç Flutter ve React Native'dir. İkisi de açık kaynaklıdır ve büyük topluluklara sahiptir. Bununla birlikte aralarındaki asıl fark, arayüzü nasıl ekrana getirdikleridir.

Flutter

Google tarafından geliştirilen Flutter'da uygulamalar Dart diliyle yazılır. Flutter'ın resmî mimari belgesine göre Flutter, arayüzü işletim sisteminin bileşenlerine çevirmez; kendi bileşen setini taşır ve her pikseli kendi çizer. Mobilde bu iş için uygulamanın içinde gelen Impeller çizim motorunu kullanır. Ayrıca yayın sürümünde kod, doğrudan makine koduna derlenir.

Bu yaklaşımın sonucu: Uygulama iOS ve Android'de aynı görünür ve davranır; işletim sistemi kendi bileşenlerini değiştirse bile sizin arayüzünüz etkilenmez. Platformun yerel bir bileşenine (ör. harita) ihtiyaç olduğunda "platform view" ile yerleştirilir, cihaz özelliklerine ise "platform channel" ile erişilir.

React Native

Meta tarafından geliştirilen React Native'de uygulamalar JavaScript ya da TypeScript ile, web dünyasından tanıdık React yaklaşımıyla yazılır. React Native belgelerine göre çalışma anında her bileşenin karşılığı olan iOS ve Android görünümleri oluşturulur; yani ekrandaki buton ya da metin, platformun kendi bileşenidir. React Native 0.76 sürümüyle (Ekim 2024) "Yeni Mimari" (New Architecture) varsayılan hale geldi.

Bu yaklaşımın sonucu: Uygulama her platformda o platformun yerel bileşenleriyle görünür. Üstelik web tarafında React kullanan bir ekip için öğrenme eğrisi daha kısadır.

Karşılaştırma tablosu

Bu tablo yalnızca genel eğilimleri gösterir. İki cross-platform aracı arasında "hangisi daha hızlı" sorusunun tek cümlelik bir cevabı yoktur; performans, uygulamanın nasıl yazıldığına çok daha fazla bağlıdır.

Nasıl karar verirsiniz?

Şu soruları sırayla sorun:

1. Uygulama gerçekten mobil uygulama mı olmalı? Kullanıcılar onu ne sıklıkla, nerede kullanacak? Bazen iyi tasarlanmış, mobil uyumlu bir web uygulaması yeterlidir.
2. Hangi cihaz özelliklerine ihtiyacınız var? Kamera, konum, bildirim, Bluetooth, arka plan çalışması gibi. Bunların çoğu cross-platform araçlarda eklentilerle desteklenir; çok özel bir donanım ihtiyacı varsa native daha rahat olabilir.
3. Arayüz her platformda aynı mı görünmeli, yoksa platforma uymalı mı?
4. Uygulamayı uzun vadede kim geliştirecek? Kendi ekibiniz React biliyorsa React Native, ayrı iOS/Android uzmanlarınız varsa native, tek bir mobil ekiple iki platform hedefliyorsanız her iki cross-platform seçeneği de anlamlıdır.
5. Bütçe ve süre ne kadar? İki ayrı native uygulama, genellikle tek kod tabanlı bir uygulamadan daha fazla emek ister. Maliyeti belirleyen diğer etkenleri Özel Yazılım Maliyeti Neye Göre Belirlenir? yazımızda anlattık.

Bir mobil uygulamanın çoğu zaman bir de arka yüzü (sunucu, veritabanı, API) olduğunu unutmayın. Üstelik bu kısım native ya da cross-platform seçiminden bağımsızdır. Ayrıntı için Frontend ve Backend Nedir? ve API Entegrasyonu Nedir? yazılarımıza bakabilirsiniz.

Mağaza süreçleri: Şubat 2026 itibarıyla bilmeniz gerekenler

Seçtiğiniz teknoloji ne olursa olsun, uygulamanız App Store ve Google Play'in kurallarına uymak zorundadır. Ancak bu kurallar sık güncellenir; aşağıdakiler Şubat 2026 itibarıyla geçerlidir.

Geliştirici hesapları

• Apple Developer Program üyeliği yıllık ücretlidir.
• Google Play geliştirici hesabı tek seferlik bir kayıt ücretiyle açılır. Ayrıca Google, kayıt sırasında kimlik doğrulaması ister.
• Hesapları işletmenizin adına açın. Aksi halde geliştiricinin kişisel hesabında yayımlanan uygulamalar, ileride devir sorunlarına yol açabilir. Bu konuyu Mevcut Yazılımınızı Devralmak yazımızda ele aldık.

Google Play'e özgü kurallar

• Yeni kişisel hesaplarda test zorunluluğu: 13 Kasım 2023'ten sonra açılan kişisel geliştirici hesapları, uygulamayı yayına almadan önce en az 12 test kullanıcısıyla, kesintisiz 14 gün kapalı test yapmak zorundadır.
• Hedef API seviyesi: 31 Ağustos 2025'ten itibaren yeni uygulamalar ve güncellemeler Android 15 (API seviyesi 35) ya da üstünü hedeflemelidir. Üstelik Google bu eşiği her yıl yükseltir.
• Veri güvenliği formu: Uygulamanın hangi veriyi topladığı Play Console'daki Data safety bölümünde beyan edilir.

App Store'a özgü kurallar

• SDK zorunluluğu: 24 Nisan 2025'ten itibaren App Store Connect'e yüklenen uygulamalar Xcode 16 ve iOS 18 SDK ya da üstüyle derlenmelidir. Apple da bu eşiği düzenli olarak yükseltir.
• Yaş derecelendirmesi: Apple, yeni yaş derecelendirme sorularının her uygulama için 31 Ocak 2026'ya kadar cevaplanmasını istedi; cevaplanmayan uygulamaların güncelleme gönderiminde kesinti yaşanabilir.
• İnceleme: Giriş gerektiren uygulamalarda inceleme ekibine çalışan bir demo hesap verilmeli ve arka yüz inceleme sırasında açık olmalıdır.

İki mağazada ortak kurallar

• Hesap silme: Uygulamada hesap oluşturulabiliyorsa, kullanıcıya uygulama içinden hesabını silme imkânı sunulmalıdır. Google Play ayrıca, uygulamayı yeniden yüklemeden silme talebi gönderilebilecek bir web bağlantısı ister.
• Gizlilik politikası: Hem mağaza kaydında hem uygulama içinde erişilebilir bir gizlilik politikası bağlantısı bulunmalıdır.
• Asgari işlev: Apple'ın yönergelerine göre uygulama, "paketlenmiş bir web sitesinin" ötesinde gerçek bir işlev sunmalıdır.

Bizim deneyimimiz

Mobil uygulama hizmetimizde Flutter ve React Native ile çalışıyoruz. Hangisini önerdiğimiz projeye göre değişiyor: ekibinizin bildiği teknoloji, arayüzün markaya özel mi yoksa platforma uygun mu olması gerektiği ve uygulamayı uzun vadede kimin geliştireceği belirleyici oluyor.

Öte yandan kendi ürünlerimiz AquaCRM (Laravel), Etiket İş Takip Asistanı (Next.js) ve Grafik Sanat (React), web teknolojileriyle geliştirildi. Projelerimizde "bu iş için gerçekten mağazada bir uygulama gerekiyor mu?" sorusunu teknoloji seçiminden önce soruyoruz.

Sık sorulan sorular

Sonuç

Native ve cross-platform arasındaki seçim, bir teknoloji tartışmasından çok bir iş kararıdır: ekip, bütçe, cihaz özellikleri ve uzun vadeli bakım. Flutter ve React Native, iş uygulamalarının çoğu için tek kod tabanıyla iki platforma çıkmanın olgun yollarıdır. Hangi yolu seçerseniz seçin, mağaza kurallarını takviminize baştan ekleyin. Mobil uygulama fikrinizi birlikte değerlendirmek isterseniz Mobil Uygulama Geliştirme sayfamıza göz atabilir ya da bizimle iletişime geçebilirsiniz.