Native mi, Cross-Platform mu? Mobil Uygulama İçin Doğru Teknoloji Seçimi

Mobil uygulama için doğru teknoloji en popüler olan değil; uygulamanızın ihtiyaç duyduğu performans ve cihaz özellikleri, bütçeniz, pazara çıkış süreniz ve uygulamanın yıllarca kim tarafından, nasıl bakımının yapılacağı birlikte düşünülerek seçilen teknolojidir.

Bir mobil uygulama projesinin ilk büyük kararı, uygulamanın nasıl geliştirileceğidir: Her platform için ayrı native uygulama mı, tek kod tabanıyla iki platformu birden hedefleyen cross-platform bir çözüm mü, yoksa tarayıcıda çalışan ama uygulama gibi davranan bir PWA mı? Bu karar bütçeyi, takvimi ve uygulamanın gelecekteki esnekliğini doğrudan etkiler. Bu yazıda üç yaklaşımı ve seçim yaparken bakmanız gereken ölçütleri ele alıyoruz.

Üç temel yaklaşım

  • Native geliştirme: iOS için Swift ve SwiftUI, Android için Kotlin ve Jetpack Compose ile her platforma ayrı uygulama yazılır. Platformun tüm olanaklarına doğrudan erişilir.
  • Cross-platform geliştirme: Flutter ya da React Native gibi çatılarla tek bir kod tabanından iOS ve Android uygulamaları üretilir. Kotlin Multiplatform ise iş mantığını paylaşıp arayüzü native bırakmaya imkân veren ara bir yoldur.
  • PWA (Progressive Web App): Web teknolojileriyle geliştirilir, tarayıcıda çalışır, ana ekrana eklenebilir ve belirli ölçüde çevrim dışı çalışabilir. Mağaza süreci gerektirmez.

Native ne zaman doğru tercihtir?

Native geliştirme, uygulamanın cihazla yoğun etkileşim kurduğu ve platform deneyiminin kusursuz olması gerektiği durumlarda öne çıkar:

  • Kamera, Bluetooth, sensörler, arka planda konum takibi ya da artırılmış gerçeklik gibi donanım özelliklerinin yoğun kullanıldığı uygulamalar.
  • Yüksek performanslı grafik ya da gerçek zamanlı ses ve görüntü işleme gerektiren senaryolar.
  • Widget'lar, saat uygulamaları ve sistem entegrasyonları gibi platforma özgü özelliklerin ürünün merkezinde olduğu durumlar.
  • Platformların yeni özelliklerini yayınlandıkları gün desteklemenin rekabet avantajı sağladığı ürünler.

Bedeli, iki ayrı kod tabanı ve genellikle iki ayrı uzmanlık demektir. Her özellik iki kez geliştirilir, iki kez test edilir ve iki platform arasında davranış farkı oluşmaması için ek özen gerekir.

Cross-platform ne zaman avantaj sağlar?

İş uygulamalarının, e-ticaret ve rezervasyon uygulamalarının, içerik ve topluluk uygulamalarının büyük bölümü için cross-platform çatılar bugün olgun ve güvenilir bir seçenektir. Avantajları şunlardır:

  • Tek kod tabanı: Özellikler bir kez geliştirilir, iki platform aynı anda güncellenir.
  • Daha hızlı pazara çıkış: Özellikle ilk sürümde takvim ve bütçe belirgin biçimde kısalır.
  • Tutarlı deneyim: Marka tasarımı her iki platformda da aynı şekilde uygulanır.
  • Native'e açılan kapı: Gerektiğinde belirli bir özellik için native modül yazılarak çatının sınırları aşılabilir.

Dikkat edilmesi gereken nokta, kullanılan çatının ve eklentilerin uzun vadeli bakımıdır. Bir eklentinin geliştirilmesi durduğunda ya da bir işletim sistemi güncellemesiyle uyumsuz hâle geldiğinde, ekibin bu açığı kapatabilecek native bilgiye de sahip olması gerekir.

PWA hangi durumlarda yeterlidir?

Uygulamanız ağırlıklı olarak içerik gösteriyor, form topluyor ya da basit işlemler yaptırıyorsa PWA hızlı ve ekonomik bir başlangıç olabilir. Tek bir web kod tabanıyla masaüstü ve mobil kullanıcılara ulaşırsınız; güncellemeler mağaza onayı beklemeden anında yayına çıkar. iOS, 16.4 sürümünden itibaren ana ekrana eklenmiş web uygulamalarında bildirim desteği sunsa da arka plan işlemleri, bazı donanım erişimleri ve mağazada görünürlük gibi konularda PWA'lar native uygulamaların gerisinde kalır. Kullanıcılarınızın uygulamayı mağazada araması bekleniyorsa bu fark önemlidir.

Teknoloji seçimi bir kerelik bir karar değil, uygulamanın yıllar sürecek bakım planının ilk maddesidir.

Karar verirken hangi ölçütlere bakılmalı?

  1. Cihaz özellikleri: Uygulama hangi donanım ve sistem özelliklerine ihtiyaç duyuyor, bunlar seçilen çatıda ne kadar iyi destekleniyor?
  2. Performans beklentisi: Uygulama ağırlıklı olarak liste, form ve içerikten mi oluşuyor, yoksa yoğun animasyon ve gerçek zamanlı işlem mi gerektiriyor?
  3. Bütçe ve takvim: İlk sürüm ne zaman yayında olmalı, iki ayrı ekip finanse edilebilir mi?
  4. Ekip ve bakım: Uygulamanın bakımını kim yapacak, bu ekip hangi teknolojilerde deneyimli?
  5. Web ile paylaşım: Aynı ürünün bir web sürümü de olacak mı, iş mantığı ve tasarım sistemi paylaşılabilir mi?
  6. Uzun vadeli yol haritası: Önümüzdeki iki yılda eklenmesi planlanan özellikler, seçilen teknolojinin sınırlarını zorlar mı?

Bu soruların cevabı netleşmeden teknoloji seçmek, sonradan pahalı bir yeniden yazıma yol açabilir. İlk sürümün kapsamını doğru belirlemek de en az teknoloji seçimi kadar önemlidir; bu konuyu MVP ile Başlamak yazımızda ayrıntılı olarak anlattık.

Görünmeyen yarı: Arka uç ve mimari

Kullanıcılar yalnızca ekranları görür, ama bir mobil uygulamanın kalitesini çoğu zaman arka uç belirler. Uygulamanın konuştuğu API iyi tasarlanmamışsa en iyi arayüz bile yavaş ve kırılgan hissettirir. Sağlıklı bir yapı için birkaç ilke öne çıkar: API'yi web ve mobilin ortak kullanabileceği biçimde tasarlamak, sürümlemek ve eski uygulama sürümlerini bir süre daha destekleyecek şekilde planlamak. Mobil cihazların bağlantısı her zaman güçlü olmadığı için zayıf ağ koşullarında anlamlı davranan, verileri önbelleğe alan ve gerektiğinde çevrim dışı çalışabilen bir kurgu da kullanıcı deneyimini doğrudan iyileştirir. Kimlik doğrulama, bildirim gönderimi ve dosya yükleme gibi ortak ihtiyaçların ilk günden doğru kurulması, sonraki her sürümün hızını belirler.

Gözden kaçan maliyetler

Mobil uygulama bütçesi yalnızca ekranların geliştirilmesinden oluşmaz. Projenin başında konuşulması gereken kalemler şunlardır:

  • Arka uç ve API: Uygulamanın konuştuğu sunucu tarafı, yönetim paneli ve entegrasyonlar.
  • Mağaza hesapları ve süreçleri: Apple Developer Program yıllık, Google Play ise tek seferlik ücretlidir; her sürüm bir inceleme sürecinden geçer.
  • Mağaza gereksinimleri: Gizlilik etiketleri, veri güvenliği formları ve hesap oluşturulabilen uygulamalarda uygulama içinden hesap silme imkânı gibi zorunluluklar.
  • Yıllık işletim sistemi güncellemeleri: Her yıl yayınlanan yeni iOS ve Android sürümlerine uyum çalışması.
  • İzleme altyapısı: Çökme raporlama, analitik ve anlık bildirim servisleri.
  • Destek ve bakım: Kullanıcı yorumlarına yanıt, hata düzeltmeleri ve güvenlik güncellemeleri.

Uygulama canlıya alındıktan sonra hangi hizmetlerin hangi sürelerle verileceğini önceden yazılı hâle getirmek, bakım döneminde sürprizleri önler. Bunun nasıl yapılacağını SLA Nedir? yazımızda anlattık.

Yayın ve sonrası

İlk sürümü doğrudan tüm kullanıcılara açmak yerine TestFlight ve Google Play'in kapalı test kanallarıyla küçük bir grupta denemek, büyük sorunları erkenden yakalar. Yayından sonra kademeli dağıtım (staged rollout) ile yeni sürümler önce kullanıcıların küçük bir bölümüne açılabilir. Eski sürümü kullananları güncellemeye yönlendiren bir zorunlu güncelleme mekanizması da ilk sürümden itibaren uygulamada bulunmalıdır; aksi hâlde kritik bir değişiklikte eski sürümler sorun yaratmaya devam eder.

Canlıdaki başarıyı ölçmek için çökmesiz oturum oranı, uygulama açılış süresi, mağaza puanları ve kullanıcıyı elde tutma oranı gibi metrikler düzenli olarak takip edilmelidir. Mağaza sayfası da ürünün bir parçasıdır: Ekran görüntüleri, açıklama metni ve anahtar kelimeler (ASO), uygulamanın bulunmasını ve indirilmesini doğrudan etkiler.

Sık sorulan sorular

Cross-platform uygulamalar yavaş mı olur?

Bugünün olgun çatılarıyla geliştirilen uygulamalar, iş uygulamalarının büyük bölümünde kullanıcının fark edemeyeceği kadar akıcı çalışır. Performans farkı daha çok yoğun grafik ve donanım kullanan senaryolarda belirgin hâle gelir.

Önce tek platformla başlamak mantıklı mı?

Hedef kitleniz ağırlıklı olarak tek bir platformu kullanıyorsa evet. Ancak Türkiye'de Android'in pazar payının yüksek olduğunu, belirli kitlelerde ise iOS'un baskın olabildiğini unutmayın; kararı kendi kullanıcı verinize göre verin.

Mevcut web sitemizi uygulamaya dönüştürebilir miyiz?

Siteyi bir uygulama kabuğu içinde göstermek teknik olarak mümkündür, ancak mağazalar bu tür uygulamaları sınırlı değer sunduğu gerekçesiyle reddedebilir. Daha sağlıklı yol, web ve mobilin aynı API'yi ve tasarım sistemini paylaştığı bir mimaridir.

Mağaza onayı ne kadar sürer?

İnceleme süreleri değişkendir. Çoğu güncelleme bir iki gün içinde onaylanır, ancak ilk yayında ya da hassas izinler isteyen uygulamalarda süre uzayabilir ve ek açıklama istenebilir. Bu nedenle yayın planında incelemeye mutlaka pay bırakılmalıdır.

Nereden başlamalı?

Uygulamanın ilk sürümünde mutlaka bulunması gereken özellikleri listeleyin, her birinin gerektirdiği cihaz yeteneklerini işaretleyin ve kullanıcılarınızın platformlara göre dağılımına bakın. Bu üç bilgi, hangi yaklaşımın sizin için doğru olduğunu büyük ölçüde ortaya koyar. Mobil ve web'i birlikte düşünen bir yazılım geliştirme yaklaşımı, uzun vadede hem maliyeti hem bakım yükünü azaltır.

Mobil uygulamanız için doğru teknolojiyi birlikte seçmek isterseniz Geleceğe dokunun.

← Tüm yazılar

WhatsApp'tan Yazın