Native Uygulama Ne Demek, Cross-Platform'dan Nasıl Ayrılır?
Ayrım dilde değil, mekanizmada. Native uygulama platformun kendi diliyle ve kendi araçlarıyla çıkar; iOS'ta Swift, Android'de Kotlin iş görür. Cross-platform ise tek kaynaktan iki platforma çıkar. Ayrım dilde değil, ekranı kimin çizdiğinde ve donanıma kimin eriştiğindedir. Mekanizmayı anlayan ekip doğru yolu kolay seçer.
Adlar kafa karıştırır, mekanizma karıştırmaz. Yerli kod yolunda uygulamanız işletim sisteminin bileşenlerini doğrudan kullanır. Tek kod tabanı yolunda ise araya bir katman girer ve o katman iki tarafa tercüme eder.
Bu katmanın varlığı tek başına iyi ya da kötü değildir. Ne kazandırdığı ve ne geciktirdiği, ürünün cinsine göre değişir.
İki yol üç noktada ayrışır. Aşağıdaki sıra, bu yazının da omurgasını kurar.
- Ekranı kim çiziyor — platformun kendi öğesi mi, çatının fırçası mı.
- Donanıma kim erişiyor — doğrudan mı, ara katman üzerinden mi.
- Performans nerede ayrışıyor — günlük akışta mı, ağır grafikte mi.
Üçünü birlikte tarttığınızda karar kendini gösterir. Native uygulama tartışması, bu üç soruyu atlayıp marka adı yarıştırınca çıkmaza girer.
Aynı Uygulama İki Kez mi Yazılıyor?
Yerli kod yolunda evet, iki ayrı proje yürür. Ekran tasarımı ve sunucu tarafı ortaktır ama arayüz kodunu iki kez yazarsınız. Tek kod tabanında ortak işi bir kez yazarız; yalnız platforma özgü parçaları ayrı tutarız. Uygulama tarafında native kod yine de gerekebilir, ama kapsamı dardır.
Tek Kod Tabanı Ekranı Nasıl Çiziyor?
İki yaklaşım var. Kimi çatılar platformun kendi bileşenine köprü kurar, kimi de her pikseli kendi çizer. Köprü kuran yol yerli görünüm verir. Kendi çizen yol iki platformda birebir aynı sonucu üretir. Bu tercih, uygulamanın hangi cihazda tanıdık hissettireceğini doğrudan belirler. Native uygulama tarafında böyle bir tercih yoktur; bileşen zaten yerlidir.
Köprü kuran yaklaşımda düğmeye bastığınızda gerçek bir sistem düğmesi tepki verir. Kullanıcı cihazını tanıdık bulur, ama iki platform birbirinin aynı görünmez. Kendi çizen yaklaşımda ise arayüz öğeleri çatının kendi fırçasıyla çizilir; her yerde aynı görünür, hiçbir yerde tam yerli hissettirmez.
Marka deneyimi tek tip olsun istiyorsanız ikinci yol işinize gelir. Cihaz alışkanlığına yaslanmak istiyorsanız birincisi daha iyi oturur.
Bu tercihin bakım tarafında da bir bedeli var. Platform arayüzünü yenilediğinde köprü kuran çatı yeniliği kendiliğinden alır. Kendi çizen çatıda ise güncel görünümü siz kovalarsınız. Uygulamanın native bileşenlere ne kadar yaslandığı, bu kovalamacanın uzunluğunu belirler. Platform beklentileri belgelidir; Apple’ın arayüz kılavuzu ile Material Design farklı davranış tarif eder.
Kullanıcı Bu Farkı Görür mü?
Çoğu kullanıcı adını koyamaz ama farkı sezer. Kaydırma sönümlemesi, klavye davranışı ve geri hareketi cihazdan cihaza değişir. Bunlar küçük ayrıntılardır; üst üste bindiklerinde ürünü yabancı hissettirirler.
Donanıma Erişim Hangi Noktada Ayrışır?
Kamera, sensör ve arka plan konumu gibi yetenekler her iki yolda da çalışır. Fark hızda değil, yeni bir yetenek çıktığında ortaya çıkar. Platform yeni bir özellik duyurduğunda native uygulama onu ilk gün kullanır. Cross-platform tarafta ise köprünün güncellenmesini beklersiniz. Bekleme süresi genelde haftalarla ölçülür.
Yaygın yetenekler için hazır ara katmanlar mevcuttur ve iyi çalışır. Sorun, yaygın olmayanda çıkar: yeni bir sensör, yeni bir ödeme yöntemi, yeni bir güvenlik akışı. O noktada ya köprüyü siz yazarsınız ya da beklersiniz.
Ürününüz donanımın ucuna oturuyorsa bu bekleme kabul edilebilir olmayabilir. Donanım ihtiyaçlarını iOS ve Android tarafında ayrı ayrı ele alıyoruz.
Köprüyü Kendimiz Yazabilir miyiz?
Yazabilirsiniz ve bazen doğru olan budur. Ancak o köprü artık sizin bakım yükünüzdür. Tek kod tabanının sadeliği, kendi yazdığınız her köprüyle biraz daha azalır.
Performans Farkı Nerede Gerçekten Hissedilir?
Günlük listelerde ve formlarda fark görünmez. Ayrışma ağır grafik, sürekli animasyon ve yoğun veri işlemede başlar. Oyun, harita üstü canlı çizim ve video düzenleme bu gruba girer. Sıradan bir katalog ya da sipariş akışı için native uygulama şart değildir. Ölçüt hız değil, işin cinsidir.
Ürününüzü Hangi Soruyla Sınamalısınız?
Performans tartışması genelde soyut kalır, çünkü kimse hangi işten söz ettiğini söylemez. Ürününüzü şu soruyla sınayın: ekranda saniyede kaç kez yeni bir kare çizilmesi gerekiyor? Yanıt “nadiren” ise mimari seçimi performans üzerinden yapılamaz.
Uygulamanın açılış süresi ve kurulum boyutu da tabloya girer. İkisi de kullanıcı kaybının sessiz nedenleridir; bütçeye etkisini uygulama maliyeti yazısında ayrıca ele aldık.
“Kullanıcılar uygulamaların hızlı yüklenmesini ve yanıt vermesini bekler. Başlangıç süresi yavaş olan bir uygulama bu beklentiyi karşılamaz ve kullanıcıları hayal kırıklığına uğratabilir.”
— Android Developers, Uygulama başlatma süresi
Hangi Ürün Hangi Yolu Seçmeli?
Üç soru yeter. Ürün donanıma ne kadar yaklaşıyor, iki platform aynı anda mı gerekiyor, ekip hangi dile hâkim? Donanım derinse ve tek platform yeterse native uygulama kazanır. İki mağaza şartsa ve donanım sıradan kalıyorsa tek kod tabanı öne geçer. Karar ürünün cinsine bağlıdır, modaya değil.
Ekip yetkinliğini çoğu liste atlar, oysa en somut ölçüt odur. Elinizde deneyimli bir yerli kod ekibi varsa tek kod tabanına geçmek hız kazandırmaz. Tersi de doğrudur.
Kararı hangi soruların netleştirdiğini uygulama yaptırma soruları yazısında sıralamıştık. Seçim tek kod tabanından yana çıkarsa iki yaygın çatıyı React Native mi Flutter mı yazısında karşılaştırdık.
Sonradan Yol Değiştirmek Mümkün mü?
Mümkün ama ucuz değil. Arayüz kodunu baştan yazarsınız; sunucu tarafı ve tasarım kalır. Bu yüzden kararı erken vermek, geç vermekten belirgin biçimde ucuza gelir. Uygulamanın native parçalarını sonradan söküp takmak da aynı yükü doğurur.
Mimarinizi Birlikte Seçelim
Mimari kararı tek başına teknik bir tercih değildir. Ürününüzün donanım ihtiyacını, platform beklentisini ve ekibinizin yetkinliğini birlikte konuşuyoruz. Elinizde bir teknoloji adı değil, seçimin gerekçesi kalıyor. Native uygulama ile tek kod tabanı arasındaki fark o gerekçeyle anlam kazanır. Yanlış mimari, altı ay sonra kendini gösterir.
Görüşmede üç ölçütü tek tek işaretleriz: donanım derinliği, platform şartı ve ekip. Üçü aynı yönü gösteriyorsa karar nettir. Ayrışıyorlarsa hangisinin ağır bastığını birlikte tartarız. Tek kod tabanı yaklaşımını hizmet sayfasında ayrıca anlattık.
Kararın Gerekçesini Neden Yazmalı?
Kararı yazıya dökmek de işin parçası. Hangi ölçütün ağır bastığını bir cümleyle not edin. Altı ay sonra “neden native uygulama seçmiştik” sorusu geldiğinde yanıtı aramak zorunda kalmazsınız. Native uygulama ya da tek kod tabanı, gerekçesi yazılı olduğunda savunulabilir bir karardır.
Native ile tek kod tabanı: hangi ölçütte hangisi
Native uygulama; yeni platform özelliklerinde, ağır grafikte ve animasyonda öne geçer. Tek kod tabanı iki mağazaya tek kaynaktan çıkmayı ve tek dilli ekiple çalışmayı sağlar. Native tarafta arayüz platformun kendi öğesini kullanır. Tek kod tabanı köprü ya da kendi çizimiyle çalışır, yeni özellik için ara katman güncellemesi bekler.
| Ölçüt | Native uygulama | Tek kod tabanı |
|---|---|---|
| Arayüz bileşeni | Platformun kendi öğesi | Köprü ya da kendi çizimi |
| Yeni platform özelliği | İlk gün kullanılabilir | Ara katman güncellemesi beklenir |
| Ağır grafik ve animasyon | Avantajlı | Sınırda kalabilir |
| İki mağaza aynı anda | Ayrı iki proje yürür | Tek kaynak, ortak iş |
| Ekip gereksinimi | Swift ve Kotlin bilgisi | Tek dil yeterli |
Seçim Ne Zaman Kendiliğinden Netleşir?
Native uygulama ile tek kod tabanı arasındaki seçim bir üstünlük yarışı değil, mekanizma tercihidir. Donanım derinliği, platform şartı ve ekip yetkinliği aynı yönü gösteriyorsa karar zaten kendini söyler.