Native mi Cross-Platform mu? Kararı Belirleyen 6 Soru
Bu, mobil projelerde maliyeti en çok değiştiren tek karardır. Native seçmek pratikte iki ayrı uygulama yazmak, cross-platform seçmek ise tek kod tabanından iki mağazaya çıkmak demektir. Fark neredeyse iki katı emek; bu yüzden karar duyguyla değil, altı somut soruyla verilmeli.
Kısa cevap
Uygulamaların büyük çoğunluğu için doğru cevap cross-platformdur: tek kod tabanı, iki mağaza, yaklaşık yarı maliyet ve tek bakım hattı. Native, üç durumda gerçekten gereklidir — donanım destekli güvenlik (anahtar deposu, biyometri, şifreli yerel depolama) merkezdeyse, işletim sisteminin derin ve yeni API’lerini kullanmanız gerekiyorsa, veya uygulama sürekli arka planda çalışan bir sistem davranışını değiştiriyorsa. Bunların dışında native tercih etmek, aynı işlevi ikinci kez ödemek anlamına gelir.
Bu soruyu soranlar: Mobil uygulama yaptıracak işletmeler ve teknik yaklaşıma karar veren proje sahipleri
Karşılaştırılan Taraflar
Bu kümeye yalnızca her iki tarafını da gerçekten sahaya çıkardığımız karşılaştırmaları koyuyoruz. Aşağıda hangi seçeneği hangi işimizde kullandığımız yazılı.
Native (Kotlin / Swift)
Her platform için kendi diliyle ayrı ayrı yazılan uygulama; sisteme en yakın erişim.
Şifre Yöneticisi (Kotlin, Android Keystore ve şifreli yerel depolama), Sessiz Uyku (Kotlin, sistem sessiz modu davranışı)
Cross-platform (Flutter / React Native)
Tek kod tabanından iOS ve Android’e birden çıkan uygulama.
Ev Hizmet (Flutter, iki mağazada yayında), Canlı Altın (Flutter, iki mağazada yayında), Dini Bilgi Yarışması (Flutter)
Kriter Kriter Karşılaştırma
| Kriter | Native (Kotlin / Swift) | Cross-platform (Flutter / React Native) |
|---|---|---|
| Geliştirme maliyeti | Yüksek. Aynı özellik iki kez, iki ayrı dilde yazılır. | Belirgin şekilde düşük. Tek kod tabanı, iki çıktı. |
| Bakım ve güncelleme | İki ayrı hat. Bir hata iki yerde düzeltilir, iki ayrı sürüm çıkılır. | Tek hat. Düzeltme bir kez yapılır, iki mağazaya birlikte gider. |
| Donanım destekli güvenlik | En güçlü. Anahtar deposu, biyometri ve şifreli depolama API’lerine doğrudan erişim. | Yapılabilir ama arada köprü katmanı var; kritik güvenlik senaryolarında bu katman risk ekler. |
| Yeni işletim sistemi özelliklerine erişim | Anında. Apple veya Google bir özellik duyurduğu gün kullanılabilir. | Gecikmeli. Çerçevenin veya paketin desteklemesi beklenir. |
| Arka plan ve sistem davranışı | Güçlü. Sistem seviyesinde davranış değiştirmek native ile mümkün. | Sınırlı. Uzun süreli arka plan işleri platform kısıtlarına daha çok takılır. |
| Görünüm tutarlılığı | Her platform kendi tasarım diline uyar; iki ayrı tasarım eforu gerekir. | Tek tasarım iki platformda çalışır; Flutter tarafında birebir aynı görünür. |
| Yayın hızı | Daha yavaş. İki uygulama ayrı ayrı hazırlanır ve incelemeye girer. | Daha hızlı. Tek geliştirme, iki mağazaya paralel başvuru. |
| Ekip ihtiyacı | İdealde iki uzmanlık: Android tarafı ve iOS tarafı. | Tek uzmanlık yeterli; nadir donanım ihtiyacında native destek alınır. |
Tablo mobilde yana kaydırılabilir. Değişken rakamlar (komisyon oranı, paket ücreti, sürüm numarası) bilerek yazılmadı — bunlar zamanla değişir, güncel değeri sağlayıcıdan doğrulayın.
Soru 1: Uygulamanın merkezinde güvenlik var mı?
Şifre yöneticisi, kimlik doğrulama uygulaması, dijital cüzdan ya da hassas belge saklayan bir uygulama yazıyorsanız native ciddi bir avantaj sunar. Şifre Yöneticisi uygulamamızı Kotlin ile native yazmamızın sebebi buydu: Android’in donanım destekli anahtar deposunu ve biyometrik doğrulama API’sini doğrudan kullanmak istedik. Cross-platform katmanı arada olduğunda bu bütünleşme hem karmaşıklaşıyor hem de güvenlik açısından denetlenmesi zor bir yüzey ekliyor. Uygulamanız kullanıcı adı-parola ile giriş yapılan sıradan bir iş uygulamasıysa bu kaygı sizin için geçerli değildir.
Soru 2: Sistemin kendi davranışını değiştiriyor musunuz?
Sessiz Uyku uygulamasını native yazmamızın sebebi güvenlik değil, sistem davranışıydı: uygulama, seçilen kişilerden gelen aramaların sessiz moddayken bile çalmasını sağlıyor. Bu, telefonun rahatsız etmeyin davranışına müdahale eden bir işlevdir ve platformun izin modeline sıkı sıkıya bağlıdır. Bu tür uygulamalarda cross-platform paketleri ya eksik kalır ya da işletim sistemi güncellemesinden sonra bozulur. Ölçüt basit: uygulamanız telefonun bir sistem davranışını değiştiriyorsa native düşünün; sadece veri gösterip veri topluyorsa gerek yok.
Soru 3: Bütçeniz iki uygulamayı kaldırıyor mu?
Native seçmek pratikte iki ayrı uygulama yazmaktır ve bu, geliştirme maliyetini yaklaşık iki katına çıkarır. Ama asıl maliyet burada bitmez: her yeni özellik iki kez yazılır, her hata iki yerde düzeltilir, her işletim sistemi güncellemesi iki tarafta test edilir. Yani native kararı tek seferlik bir harcama değil, kalıcı bir işletme gideridir. Bütçeniz sınırlıysa ve uygulamanız güvenlik ya da sistem davranışı merkezli değilse, native seçmek parayı yanlış yere koymaktır — o para ürünün kendisine, pazarlamaya veya ikinci faz özelliklere gitmelidir.
Soru 4: Hangi platformla başlıyorsunuz?
Türkiye’de kullanıcı tabanı ağırlıklı olarak Android’dir; bu yüzden bazı ekipler "önce Android native yapalım, iOS sonra" diyor. Bu kısa vadede ucuz görünen ama pahalıya patlayan bir karardır: ikinci platform geldiğinde sıfırdan başlarsınız ve iki kod tabanı arasında özellik farkı oluşur. Cross-platform ile başlamak, ikinci platformu neredeyse ek maliyetsiz açmanızı sağlar. Ev Hizmet uygulamasında müşteri kitlesi ağırlıklı Android olmasına rağmen tek kod tabanından iki mağazaya birden çıktık; işletme sahiplerinin ve yöneticilerin iPhone kullanma ihtimali de hesaba katılmalıydı.
Soru 5: Karma çözüm mümkün mü?
Evet ve çoğu proje aslında burada duruyor. Uygulamanın tamamı cross-platform yazılır, yalnızca ihtiyaç duyulan tek bir yerde native kod parçası eklenir. Örneğin genel akış Flutter ile, kritik bir donanım entegrasyonu Kotlin ile yazılabilir ve ikisi birbirine bağlanır. Bu yaklaşım her iki dünyanın avantajını verir ama bir maliyeti vardır: o native parçayı bakacak birinin olması gerekir. Karma çözümü, gerçekten gerekli olduğu kadar küçük tutmak gerekir; native parça büyüdükçe cross-platformun bütün avantajı erir.
Soru 6: Uygulamayı beş yıl sonra kim bakacak?
Bu soruyu her teknoloji kararında soruyoruz çünkü mobil uygulamalar teslim edildiği gün bitmez. Mağazalar her yıl hedef sürüm zorunluluğu getirir ve güncellenmeyen uygulama bir gün yayından düşer. Native seçtiyseniz iki ayrı uzmanlık alanında insan bulmanız gerekir; cross-platform seçtiyseniz tek uzmanlık yeterlidir. Küçük ve orta ölçekli işletmeler için bu, native aleyhine en güçlü argümandır. Büyük bir teknoloji ekibi olan şirketlerde ise denklem değişir; onlar iki ayrı ekibi zaten taşıyabiliyordur.
Hangisini Seçmelisiniz?
Native (Kotlin / Swift) seçin, eğer:
- Uygulamanın merkezinde donanım destekli güvenlik var (anahtar deposu, biyometri, şifreli kasa)
- Telefonun bir sistem davranışını değiştiriyorsunuz
- İşletim sisteminin yeni duyurulan API’lerini gecikmeden kullanmanız gerekiyor
- Uzun süreli arka plan işlemi uygulamanın çekirdek işlevi
- Bütçeniz ve ekibiniz iki ayrı kod tabanını uzun vadede taşıyabiliyor
Cross-platform (Flutter / React Native) seçin, eğer:
- Uygulama veri gösteriyor, form dolduruyor, bildirim ve ödeme akışı içeriyor
- İki mağazaya birlikte çıkmak istiyorsunuz
- Tek bakım hattı ve tek ekip ile ilerlemek istiyorsunuz
- Bütçeyi ürünün kendisine ve pazarlamaya ayırmak istiyorsunuz
- Ürünün ilk sürümünü hızlı yayına almak önceliğiniz
Bizim Deneyimimiz
Native tarafında iki uygulamamız Play Store’da: Şifre Yöneticisi (Kotlin; Android Keystore, biyometrik doğrulama ve şifreli yerel depolama ile tamamen çevrimdışı çalışıyor) ve Sessiz Uyku (Kotlin; seçilen kişilerin aramalarının sessiz modda da çalmasını sağlıyor). İkisini de native yazmamızın sebebi aynıydı: birinde donanım destekli güvenlik, diğerinde sistem davranışına müdahale. Cross-platform tarafında ise Ev Hizmet ve Canlı Altın uygulamaları Flutter ile tek kod tabanından hem App Store hem Google Play’de yayında. Ev Hizmet iki taraflı bir pazaryeri ve tek kod tabanında rol bazlı iki kabuk olarak çalışıyor — cross-platformun mimari esnekliğe engel olmadığının somut örneği.
Sıkça Sorulan Sorular
Native uygulama gerçekten daha hızlı çalışır mı?
Uygulamamı önce Android yapıp iOS’u sonra eklesek olmaz mı?
Cross-platform uygulamalar mağaza tarafında dezavantajlı mı?
Güvenlik kritikse cross-platform hiç kullanılamaz mı?
Hangi seçenek daha hızlı yayına çıkar?
Karar Verdiyseniz
Bu karşılaştırmanın karşılık geldiği çözüm sayfaları — sistemin hangi modüllerden oluştuğunu ve sürecin nasıl işlediğini orada bulacaksınız.
Konuyla İlgili Yazılar
Flutter mı Kotlin mı? Android Uygulamanız İçin Doğru Seçim
Yeni bir Android uygulama projesinde Flutter ve Kotlin arasında karar verirken hangi soruları sormalısınız? Geliştirme süresi, performans, ekip uyumu ve uzun vadeli bakım maliyetleri.
Mobil Uygulama Maliyetleri 2026: Fiyatı Belirleyen 7 Faktör
Mobil uygulama fiyatları neden bu kadar farklı? Ekran sayısından entegrasyonlara, mağaza ücretlerinden bakım maliyetine — bütçenizi doğru planlamanız için dürüst bir rehber.
Diğer Karşılaştırmalar
Flutter mı React Native mi? İkisini de Yayınlamış Bir Ekipten
Flutter / React Native
Önce Web Sitesi mi, Mobil Uygulama mı?
Web sitesi / mobil uygulama
Sanal POS Karşılaştırması: İyzico, PayTR ve Stripe
Sanal POS: İyzico / PayTR / Stripe
Supabase mi Firebase mi? Uygulama Altyapısı Karşılaştırması
Supabase / Firebase
Hâlâ emin değil misiniz?
Durumunuzu anlatın, hangisinin size uyduğunu söyleyelim. Cevap "ikisi de değil" ya da "bu iş için bize ihtiyacınız yok" olursa onu da söylüyoruz.
WhatsApp'tan Sorun