Kısa cevap: Teknoloji seçimi bir tercih değil, ihtiyacın sonucudur. Doğru soru "native mi hibrit mi" değil, "uygulama ne yapacak ve ekip bunu neyle sürdürebilir" sorusudur. Cihaz özelliklerine derin erişim gerekmiyorsa çapraz platform yaklaşımlar çoğu e-ticaret senaryosunu karşılar.
- Karar, uygulamanın çözeceği somut soruna bakılarak verilir.
- Toplam maliyet ilk sürüm değil, iki yıllık bakım üzerinden hesaplanır.
- Uygulama ve site birbirini beslemeli; ayrı iki ürün gibi yönetilmemelidir.
Mobil uygulama teknolojisi seçimi, çoğu zaman bir tercih olarak sunulur: “native mi, hibrit mi?” Oysa doğru soru teknoloji değil ihtiyaçtır. Uygulamanızın ne yapması gerektiği ve ekibinizin ne yapabileceği, cevabı büyük ölçüde belirler. Bu yazıda üç yaklaşımı ve karar kriterlerini karşılaştırıyoruz.
Üç yaklaşım
1. Native (Swift / Kotlin)
Her platform için ayrı, o platformun kendi diliyle geliştirilen uygulama. En yüksek performansı, en iyi platform entegrasyonunu ve en akıcı arayüz davranışını verir.
Karşılığında iki ayrı kod tabanı, iki ayrı uzmanlık ve iki katına yakın bakım maliyeti getirir. Yeni bir özellik iki kez yazılır.
2. Çapraz platform (React Native / Flutter)
Tek kod tabanından iki platforma çıktı alınır. Çoğu e-ticaret senaryosu için performansı yeterlidir ve geliştirme maliyetini belirgin biçimde düşürür.
Sınırları: platforma özgü yeni özelliklere erişim gecikebilir, karmaşık animasyon ve yoğun grafik gerektiren senaryolarda native’in gerisinde kalır, üçüncü taraf kütüphanelere bağımlılık artar.
3. Web tabanlı (PWA / WebView)
Mevcut web sitenizin uygulama gibi davranmasını sağlayan yaklaşım. En düşük maliyetlidir ve tek kod tabanı ile hem web hem mobil karşılanır.
Sınırları: cihaz özelliklerine erişim daha kısıtlıdır, uygulama mağazasındaki görünürlük avantajı sınırlıdır ve kullanıcı deneyimi native hissi vermez.
Karar için sorular
- Uygulama gerçekten gerekli mi? Mobil siteniz iyi çalışıyorsa ve tekrar satın alma oranınız düşükse, uygulama çözmediğiniz bir soruna verilen pahalı bir cevap olabilir.
- Hangi cihaz özelliklerine ihtiyacınız var? Kamera, konum, biyometrik doğrulama, arka plan çalışma — ihtiyaç arttıkça native’e yaklaşırsınız.
- Ekibiniz ne biliyor? Mevcut ekibin bildiği teknoloji, kâğıt üzerindeki en iyi teknolojiden çoğu zaman daha iyi sonuç verir.
- Bütçe ve zaman? Native, iki kat geliştirme ve iki kat bakım demektir.
- Ne kadar sık güncelleyeceksiniz? Sık güncellenen bir uygulamada tek kod tabanı büyük avantajdır.
E-ticaret için pratik cevap
E-ticaret uygulamaları çoğunlukla liste, detay, sepet ve ödeme ekranlarından oluşur. Bu tür arayüzler için çapraz platform yaklaşımı genelde yeterli performansı verir ve maliyeti belirgin biçimde düşürür.
Native’e yönelmenin makul olduğu durumlar: yoğun kamera kullanımı (sanal deneme gibi), karmaşık animasyon, çok yüksek performans gerektiren listeler ya da platforma özgü yeni özellikleri ilk gün kullanma ihtiyacı.
Web tabanlı yaklaşım ise başlangıç aşamasındaki mağazalar için mantıklıdır: uygulama fikrini düşük maliyetle test etmenizi sağlar.
Önce şunu sorun: uygulama ne çözecek?
Uygulama yatırımının en pahalı hatası, sebebi netleşmeden yapılmasıdır. “Rakiplerin var” bir gerekçe değildir.
Uygulamanın gerçek avantajı üç şeydir: bildirim izni, hızlı tekrar erişim ve kayıtlı ödeme bilgisiyle sürtünmesiz alışveriş. Üçü de tekrar eden müşteri için değerlidir. Müşterileriniz bir kez alıp gidiyorsa uygulama bu sorunu çözmez — çünkü uygulamayı da bir kez indirip silerler.
Bu yüzden karar, teknoloji karşılaştırmasından önce tekrar satın alma oranınıza bakılarak verilmelidir. Elde tutma tarafını sadakat programı yazısında ele aldık. Aynı konuyu kararı veriyle vermenin üç metriği yazısında açtık.
Uygulama ve site birbirini beslemeli
Uygulama kararı verildiğinde sık atlanan bir soru vardır: uygulama ile site aynı veriyi mi kullanacak? Cevap "evet" olmalıdır — ama pratikte çoğu proje iki ayrı dünya olarak kurulur ve sonuçları pahalıdır.
Ayrı kurulduğunda olanlar şunlardır: sepet cihazlar arasında taşınmaz, sipariş geçmişi eksik görünür, stok ve fiyat farklı zamanlarda güncellenir, kampanya bir tarafta görünüp diğerinde görünmez. Her biri müşteri için bir hata, sizin için bir destek talebidir.
Doğru kurgu, ikisinin de aynı arka uçtan beslenmesidir. Bu yaklaşım aynı zamanda geliştirme maliyetini düşürür: iş kuralları tek yerde yazılır, iki arayüz onu kullanır. Yeni bir kampanya kuralı eklendiğinde iki kez uygulanmaz.
Ne zaman uygulama yapmamalı?
Bu soruyu açıkça sormak, teknoloji karşılaştırmasından daha çok para kazandırır. Uygulama yatırımını ertelemenin makul olduğu durumlar:
- Tekrar satın alma oranı düşükse: uygulamanın bütün avantajları tekrar eden müşteriye yöneliktir.
- Mobil siteniz henüz iyi çalışmıyorsa: aynı deneyim sorunları uygulamaya da taşınır; önce siteyi düzeltmek daha ucuzdur.
- Katalog dar ve nadir güncelleniyorsa: kullanıcının uygulamayı düzenli açması için bir sebep oluşmaz.
- Bakım bütçesi yoksa: güncellenmeyen bir uygulama, puanı düşen ve markaya zarar veren bir varlığa dönüşür.
Bu dördünden biri geçerliyse, aynı bütçeyi mobil site hızına, ürün sayfası kalitesine ve elde tutma çalışmalarına ayırmak daha yüksek getiri sağlar. Mobil performansı Core Web Vitals yazısındaki ölçütlerle değerlendirebilirsiniz.
Toplam maliyeti hesaplayın
Uygulama maliyeti, ilk geliştirmeden ibaret değildir. Hesaba katılması gerekenler: mağaza yayın ücretleri, işletim sistemi güncellemelerine uyum, kütüphane güncellemeleri, hata düzeltmeleri, yeni özellikler, mağaza optimizasyonu ve bildirim altyapısı.
Pratik bir kural: yıllık bakım maliyeti, ilk geliştirme maliyetinin küçümsenmeyecek bir oranıdır. Bu kalemi bütçelemeden başlayan projeler, bir yıl sonra güncellenmeyen ve puanı düşen bir uygulamayla kalır.
Sıkça atlanan konular
- Mağaza onay süreçleri: güncellemeler incelemeden geçer; acil düzeltmeler anında yayınlanamaz.
- Eski sürüm desteği: kullanıcıların bir kısmı güncellemez; eski sürümü ne kadar destekleyeceğinizi baştan belirleyin.
- Analitik ve izin: uygulama içi takip de kişisel veri işlemedir; izin ve aydınlatma gerekir. Ayrıntısını KVKK uyumluluğu yazısında ele aldık.
- Ödeme entegrasyonu: mağaza kuralları, dijital ürün satışında farklı işler.
- Bildirim altyapısı: uygulamanın asıl değeri bildirimdir; kurgusunu push bildirimleri yazısında anlattık.
Karar verdikten sonra
Teknoloji seçimi, uygulamanın başarısını belirleyen faktörlerin içinde sanıldığından küçük bir yer tutar. Kullanıcıyı elde tutan şey, hangi dille yazıldığı değil şunlardır: açılış hızı, arama kalitesi, ürün sayfasının netliği, ödeme akışının kısalığı ve bildirimlerin isabeti.
Bu yüzden seçimi fazla uzatmayın. Ekibinizin bildiği ve ihtiyaçlarınızı karşılayan yaklaşımı seçip enerjiyi deneyime harcamak, doğru teknolojiyi aylarca tartışmaktan çok daha fazla kazandırır.
Sık sorulan sorular
E-ticaret uygulaması için hangisi daha uygun?
Tipik bir e-ticaret uygulaması — katalog, sepet, ödeme, bildirim — cihazın özel donanımına derin erişim gerektirmez; bu yüzden çapraz platform yaklaşımlar tek kod tabanıyla iki platformu karşılayarak maliyeti belirgin biçimde düşürür. Native tercih, ağır grafik veya donanım erişimi gerektiren senaryolarda anlam kazanır.
Hibrit uygulama yavaş mı olur?
Modern çapraz platform çatıları, tipik e-ticaret akışlarında kullanıcının fark edeceği bir yavaşlık üretmez. Performans sorunları genellikle teknoloji seçiminden değil, ağır görsellerden ve gereksiz ağ isteklerinden doğar — bunlar native uygulamada da aynı sonucu verir.
Ne zaman uygulama yapmamalıyım?
Tekrar satın alma oranınız düşükse, aktif müşteri sayınız azsa ya da mobil siteniz henüz iyi çalışmıyorsa. Uygulama, çalışmayan bir mobil deneyimi düzeltmez; onun daha pahalı bir kopyasını üretir. Önce mobil siteyi düzeltin, sonra kararı yeniden verin.
Özet
Native en iyi performansı, çapraz platform en iyi maliyet dengesini, web tabanlı en düşük giriş bariyerini sunar. E-ticaret senaryolarının çoğunda çapraz platform yeterlidir. Ama teknoloji kararından önce şunu sorun: uygulama hangi sorunu çözecek? Tekrar satın alma oranınız düşükse uygulama bu sorunu çözmez. Toplam maliyeti ilk geliştirmeyle değil yıllık bakımla birlikte hesaplayın.
