Mobil uygulama geliştirme: native mi, cross-platform mu?

Mobil uygulamayı iki yoldan yazabilirsiniz. Native geliştirmede her platform için ayrı bir uygulama yazılır. Cross-platform geliştirmede tek bir kod tabanından hem iOS hem Android uygulaması üretilir. Çoğu iş uygulamasında cross-platform, ilk sürüme daha hızlı ulaşmanın yoludur. Uygulamanız derin cihaz özelliklerine ya da ağır grafiğe dayanıyorsa native daha doğru olabilir. Aşağıda iki yaklaşımın artılarını ve eksilerini anlatıyoruz.

Native ve cross-platform ne anlama geliyor?

Native geliştirme, her platform için o platformun kendi araçlarıyla ayrı bir uygulama yazmak demektir. iOS tarafında genellikle Swift ile SwiftUI ya da UIKit kullanılır. Android tarafında Kotlin ile Jetpack Compose ya da klasik görünüm sistemi tercih edilir. Her uygulama işletim sisteminin çerçevelerine doğrudan bağlanır, bu yüzden yeni bir cihaz özelliği platforma eklendiği gün kullanılabilir.

Cross-platform geliştirmede ise tek bir kod tabanı hem iOS hem Android uygulaması üretir. Bu alanda iki yaygın seçenek var: JavaScript ya da TypeScript ile React kullanan React Native ve Dart dilini kullanan Flutter. İkisi de gerçek, mağazadan yüklenebilir uygulamalar üretir. Farkları arayüzü çizme biçimlerinde ortaya çıkar. React Native bileşenlerini platformun kendi görünüm öğelerine eşler. Flutter ise arayüzü kendi render motoruyla çizer, bu da iki platformda aynı görünümü sağlar.

“Native” kelimesi bazen gevşek kullanılır. Bir ajansla konuşurken arayüzün hangi kısmının gerçek native bileşen, hangisinin özel çizim ya da web görünümü olduğunu sorun. Bu cevap, tek başına “native” etiketinden daha fazla şey anlatır.

Hangisi nerede daha iyi?

Aşağıdaki tablo, seçimi çoğunlukla belirleyen beş faktöre göre iki yaklaşımı karşılaştırıyor. Bunlar genel eğilimlerdir, garanti değildir. İyi kurulmuş bir cross-platform uygulama çoğu iş ekranı için yeterince hızlıdır. Dikkatsiz planlanmış bir native proje ise yine de gecikebilir.

Faktör	Native (Swift, Kotlin)	Cross-platform (React Native, Flutter)
Performans	Ağır grafik, animasyon ve gerçek zamanlı işlemler için en fazla alan	Çoğu iş uygulaması için yeterli; ağır özel çizimde dikkatli çalışma gerekir
Cihaz API erişimi	Doğrudan erişim, çoğu zaman yeni özelliğin çıktığı gün	Bakımı yapılan eklentilerle sağlanır; yeni ya da alışılmadık API’ler native kod gerektirebilir
Ekip büyüklüğü	Ayrı iOS ve Android uzmanlığı, çoğu zaman iki geliştirici ya da iki ekip	Tek ekip iki platformu kapsar; uç durumlar için native uzman eklenir
İlk sürüme süre	Daha uzun, çünkü iki kod tabanı yazılır, test edilir ve incelenir	Her iki mağazaya çıkacak ilk sürüm için genellikle daha kısa
Uzun vadeli bakım	İki kod tabanını güncellemek, test etmek ve güvende tutmak	Tek ortak kod tabanı; çatı ve eklentilerde düzenli yükseltme

Ekipler bakım maliyetini en çok küçümser. Her işletim sistemi sürümü izinleri, arka plan davranışını ya da arayüz yönergelerini değiştirebilir. Native projede iki projeyi birden güncellersiniz. Cross-platform projede ayrıca çatı sürümünü yükseltirsiniz. Büyük bir yükseltme derleme araçlarına, eklentilere ve ortak koda aynı anda dokunabilir. İki yaklaşımda da güncellemeler için sürekli bir bütçe gerekir. Bakımı yapılmayan uygulamanın maliyeti, zamanla çökmeler ve reddedilen mağaza güncellemeleri olarak geri döner.

Native geliştirme ne zaman kazanır?

Uygulamanın değeri, cross-platform katmanın zayıf ya da geç desteklediği bir şeye dayanıyorsa native kazanır. Tipik durumlar şunlardır:

Video düzenleme, kamera işleme hattı ya da ses işleme gibi ağır medya işleri. Bu işlerde uygulama cihazın grafik donanımına ve kodeklerine yakın çalışır.

ARKit (iOS) ya da ARCore (Android) üzerine kurulu artırılmış gerçeklik uygulamaları. Kamera, sensörler ve çizim döngüsü sıkı biçimde birlikte çalışmalıdır.

Ana uygulama cross-platform olsa bile ana ekran widget’ları, iOS’taki Canlı Etkinlikler, saat uygulamaları ve klavye ya da paylaşım uzantıları. Bunların her biri platforma özgü proje hedefleri ve API’ler kullanır, bu yüzden native yazılır.

Arka plan işleme kuralları, sistem düzeyinde erişilebilirlik servisleri ya da alışılmadık Bluetooth profilleri gibi derin işletim sistemi özellikleri.

Yalnızca tek bir platform önemliyse de native mantıklı olabilir. Örneğin bir ülkedeki satış ekibi için tasarlanmış, yalnızca iPhone’da kullanılacak bir araç Android sürümüne ihtiyaç duymayabilir. Bu durumda iki platform tartışması da ortadan kalkar.

React Native mi, Flutter mı?

Çoğu iş uygulaması cross-platform grubuna girer. Randevu uygulamaları, sipariş takibi, saha servis kontrol listeleri, müşteri portalları, üyelik uygulamaları ve şirket içi araçlar çoğunlukla liste, form, harita, bildirim ve ödeme gösterir. İki çatı da bu işleri iyi karşılar ve tek bir ekip iki platformu aynı iş listesinden yayınlayabilir.

İki çatı arasındaki seçim çoğunlukla ekibe bağlıdır. React Native, web için zaten TypeScript ve React yazan ekiplere uygundur. Mantığı ya da tipleri web uygulamasıyla paylaşmak isteyen ekipler için de iyi bir seçimdir. Flutter ise tek bir render motoru ve iki platformda birebir aynı ekranlar isteyen ekipler için, ya da JavaScript geçmişi olmadan başlayan ekipler için daha uygundur. İkisi de olgun ve resmi dokümantasyonları aktif. Eski karşılaştırmalar güncelliğini yitirmiş olabilir. React Native 0.76 duyurusuna göre 0.76 sürümünden itibaren New Architecture projelerde varsayılan olarak açık geliyor. Flutter tarafında native API’lere erişim platform kanalları üzerinden yapılır. Ajansa hangi çatı sürümünü kullandıklarını ve native modüllerini nasıl yönettiklerini sorun, çünkü bu, size ait olacak platform kodunun miktarını belirler.

iOS uygulama geliştirme: Swift mi React Native mi?

Swift, iOS için native dildir. Uygulama yalnızca iOS’a gerekiyorsa en doğrudan yol Swift’tir ve Apple’ın çerçeveleri üzerinde en fazla kontrolü verir. Hem iOS hem Android önemliyse ve ekip tek bir kod tabanı istiyorsa React Native devreye girer. Asıl soru, ikinci bir native kod tabanının ürününüz için maliyetine değip değmeyeceğidir.

Maliyet ve süreyi ne belirler?

Fiyat kapsama bağlıdır, bu yüzden tek bir rakam verilemez. Tahmini en çok değiştiren faktörler şunlardır:

Ekran sayısı ve her ekranın karmaşıklığı. Liste, form ve profil sayfası basittir. Sürükle bırak ile çalışan özel bir düzenleyici ya da çevrimdışı senkronizasyon ekranı basit değildir.

Arka uç. Giriş, kullanıcı verileri, yönetim paneli ve API’ler çoğu zaman en büyük belirsizliktir. Belgelenmiş mevcut bir API’ye bağlanan uygulama, sıfırdan arka uç gerektiren uygulamadan daha hızlı çıkar.

Ödeme sağlayıcıları, CRM, takvim, harita, SMS servisleri ya da ERP entegrasyonları. Her birinin kendi test ortamı, dokümantasyonu ve hata durumları vardır, ve her biri gerçek cihazlarda test edilmelidir.

Tasarımın hazır olma durumu. Bitmiş tasarımlar yapımı kısaltır. Yapım sırasında tasarımı değiştirmek, gecikmenin en sık nedenlerinden biridir.

Cihaz özellikleri ve çevrimdışı kullanım. Arka plan görevleri, kamera erişimi ve çevrimdışı veri, her işletim sistemi sürümünde ek test işi çıkarır.

Mağaza incelemesi. Apple ve Google her gönderimi inceler ve ilk gönderimde düzeltme istemek sık görülür. Projede en az bir inceleme turu için zaman ayırın.

Yayından sonraki işler: işletim sistemi güncellemeleri, mağaza sayfası değişiklikleri, çökme takibi ve yeni cihaz desteği.

App Store ve Google Play incelemesinde neye bakılır?

Apple’ın App Store İnceleme Yönergeleri, bir uygulamanın yalnızca web sitesini paketlemiş olmaması, web sitesinden öteye geçen özellikler, içerik ve arayüz sunması gerektiğini belirtir. 4.2 numaralı madde, ince uygulamalara en çok yöneltilen itirazdır. Uygulamanız büyük ölçüde bir web sitesini çerçeve içinde göstermekten ibaretse, native özellikleri, çevrimdışı davranışı ya da hesaba bağlı değeri inşa başlamadan planlayın, reddedilmeden sonra değil.

Aynı yönergeler dijital özelliklerin ve içeriklerin uygulama içi satın alma ile satılmasını ister. Abonelikler, premium içerik ya da tam sürüm açma bu kapsamdadır. Uygulama dışında tüketilen fiziksel mal ve hizmetler için başka ödeme yöntemleri kullanılabilir. Yani bir iş uygulamasında abonelik planlıyorsanız, ödeme mimarisini baştan buna göre kurmanız gerekir. Uygulamanın dışında tüketilen fiziksel bir mal ya da hizmet satıyorsanız, örneğin bir otel rezervasyonu ya da kargo ücreti için iyzico gibi bir Türk ödeme sağlayıcısı kullanabilirsiniz. Dijital bir özelliği bu yolla satmak ise Apple ve Google kurallarına aykırıdır.

Google Play’in kendi takvimi var. Google’ın hedef API seviyesi gereksinimlerine göre yeni uygulamaların ve güncellemelerin, 31 Ağustos 2026 itibarıyla gönderilebilmesi için Android 16 (API seviyesi 36) ve üzerini hedeflemesi gerekir. Bu seviye her yıl yükseldiği için çatı ve derleme araçlarınızın da buna ayak uydurması gerekir. İki mağaza da bir gizlilik politikası ve uygulamanın topladığı verilerin açık bir dökümünü ister. Bunları projenin son haftasına bırakmayın.

Türkiye’den geliştirici hesabı açarken dikkat edilecek bir nokta daha var. Apple Developer Program ve Google Play Console kaydında bireysel mi yoksa şirket adına mı kayıt yapacağınızı, hangi kimlik ve vergi bilgilerinin istendiğini kayıt sırasında kontrol edin. Bu tercih vergi durumunuza göre değişir, bu yüzden muhasebecinizle birlikte karar verin. KVKK kapsamında uygulamanın hangi kişisel verileri topladığını ve bunları neden topladığını da baştan yazılı hale getirmek, hem mağaza beyanı hem de hukuki uyum için işinize yarar.

Bir ajansla görüşmeden önce neler hazırlanmalı?

Bir ajans, görüşmeye net girdilerle başlandığında çok daha hızlı tahmin yapabilir. Şu noktaları hazırlayın:

Uygulamanın çözdüğü sorunu ve hizmet verdiği kullanıcıyı iki ya da üç cümlede yazın.

Kayıt olma, randevu alma, ödeme ve sipariş takibi gibi temel akışları, kabaca ekran listesiyle birlikte çıkarın.

Uygulamanın bağlanması gereken sistemleri listeleyin. Elinizde API dokümantasyonu ya da erişim bilgisi varsa bunları da ekleyin.

Şimdi ve ileride ihtiyaç duyacağınız platformları ve kullanıcılarınızın bulunduğu ülkeleri belirtin.

Kamera, konum, push bildirimi, Bluetooth ya da çevrimdışı mod gibi kullanmayı beklediğiniz cihaz özelliklerini not edin.

Yayından sonra uygulamanın kimin tarafından yönetileceğini ve güncellemeler için bütçe ayırıp ayırmadığınızı belirtin.

Mevcut tasarımlarınız, marka kılavuzunuz ya da tıklanabilir bir prototipiniz varsa ekleyin.

Bu bilgilerle bir ajans, uygulamanız için native, React Native ya da Flutter seçeneğinin uyup uymadığını ve nedenini açıklayabilir. Mobil uygulama geliştirme hizmetimiz hakkında daha fazla bilgi alabilirsiniz. Bir uygulama fikrini konuşmaya hazır olduğunuzda, yukarıdaki listeyle birlikte iletişim sayfamızdan bize ulaşın.