Mobil uygulama yaptırma rehberi: native mi, hibrit mi?

Önce: uygulamaya gerçekten ihtiyacınız var mı?

Her dijital ihtiyaç mobil uygulama gerektirmez. Kullanıcı sizi yılda birkaç kez ziyaret ediyorsa ya da yalnızca bilgi arıyorsa, hızlı ve mobil uyumlu bir web sitesi çoğu zaman daha doğru ve daha ekonomik bir yatırımdır.

Uygulamanın gerçekten fark yarattığı durumlar ise şunlardır:

• Kullanıcı ürünü sık kullanıyorsa (sipariş, randevu, takip, öğrenme)
• Anlık bildirimler işin merkezindeyse
• Kamera, konum, sağlık verisi veya çevrimdışı kullanım gibi cihaz özelliklerine ihtiyaç varsa
• Sadakat programı, üyelik veya abonelik gibi kullanıcıyla sürekli ilişki kuruluyorsa

Emin değilseniz, önce bir web uygulaması ile başlayıp talebi ölçmek ve ardından mobil uygulamaya geçmek de geçerli bir stratejidir.

Native, cross-platform ve hibrit: kısa tanımlar

Bu terimler sektörde farklı anlamlarda kullanılabildiği için önce neyi kastettiğimizi netleştirelim:

• Native: Her platform kendi resmî diliyle ve araçlarıyla geliştirilir. iOS'ta Swift ve SwiftUI, Android'de Kotlin ve Jetpack Compose. İki platform için iki ayrı kod tabanı vardır.
• Cross-platform: React Native veya Flutter gibi çatılarla tek bir kod tabanından iki platforma uygulama üretilir. Arayüz büyük ölçüde ortak kodla çizilir; gerektiğinde platforma özel kod eklenir.
• Hibrit (WebView tabanlı): Uygulama, aslında bir uygulama kabuğu içinde çalışan bir web sitesidir. En hızlı başlangıç yoludur ancak kullanıcı deneyimi ve cihaz özelliklerine erişim açısından en sınırlı seçenektir.

Günlük dilde "hibrit" kelimesi çoğu zaman cross-platform çözümler için de kullanılır. Bu yazının devamında ikisini birlikte "hibrit" başlığı altında değerlendiriyoruz, farklarını gerektiğinde ayrıca belirtiyoruz.

Artılar ve eksiler: dürüst bir karşılaştırma

Özetle: Hibrit yaklaşım, özellikle iki platformun aynı anda ve sınırlı bütçeyle çıkması gerektiğinde başlangıçta avantaj sağlayabilir. Native yaklaşım ise performans, platform hissi, cihaz özelliklerine erişim ve uzun ömür açısından daha güçlüdür.

Dromocob neden native geliştiriyor?

Geliştirdiğimiz uygulamaların çoğu kullanıcının her gün açtığı, bildirim, kamera, abonelik ve çevrimdışı kullanım gibi platform özelliklerine dayanan ürünler. Bu tür ürünlerde akıcılık ve platforma uyum, kullanıcı yorumlarına ve mağaza puanına doğrudan yansıyor. Native geliştirme bize üç somut avantaj sağlıyor:

• Apple ve Google'ın yeni özelliklerine ilk günden erişim: Widget, bildirim türleri, gizlilik gereklilikleri gibi değişikliklere bir ara katman beklemeden uyum sağlıyoruz.
• Daha az dış bağımlılık: Uygulamanın ömrü boyunca bir çatının veya eklentinin güncel kalmasına bağlı kalmıyoruz.
• Platforma özgü tasarım: iPhone kullanıcısına iOS'un, Android kullanıcısına Android'in alıştığı davranışları sunuyoruz.

App Store'da yayında olan Kalori Merkezi, The Jacks Coffee, Bizim 6'ncı Kuyumculuk ve Dromocob uygulamalarını uygulamalar sayfasında inceleyebilirsiniz.

Mobil uygulama maliyetini neler belirler?

Uygulama maliyetini ekran sayısından çok, ekranların arkasındaki iş mantığı belirler. Başlıca kalemler şunlardır:

• Platform sayısı: Yalnızca iOS mu, yalnızca Android mi, yoksa ikisi birden mi?
• Arka uç (backend): Kullanıcı hesapları, veri tabanı, dosya depolama ve bildirim altyapısı. Uygulamaların büyük çoğunluğu bir sunucu tarafına ihtiyaç duyar.
• Yönetim paneli: İçeriği, siparişleri veya kullanıcıları yöneteceğiniz web tabanlı panel.
• Kullanıcı rolleri: Müşteri, işletme, yönetici gibi farklı rollerin her biri ayrı ekran ve yetki demektir.
• Ödeme ve abonelik: Dijital içerik ve abonelik satışında mağazaların uygulama içi satın alma kuralları geçerlidir; fiziksel ürün ve hizmet satışında farklı ödeme altyapıları kullanılabilir. Bu ayrım hem tasarımı hem geliştirmeyi etkiler.
• Entegrasyonlar: Mevcut web siteniz, CRM, POS veya muhasebe sistemiyle veri alışverişi.
• Tasarım düzeyi: Sistem bileşenleriyle sade bir arayüz mü, yoksa markaya özel animasyonlu bir deneyim mi?

Mobil uygulamalar için sabit bir paket fiyatımız yok; kapsam netleştikten sonra yazılı teklif hazırlıyoruz. Arka uç ve yönetim paneli tarafı için fikir vermesi açısından, Dromocob paketlerinde Web Application paketi 65.000 TL + KDV seviyesinden başlıyor.

İlk sürümün kapsamını nasıl daraltırsınız?

Mobil uygulama bütçesini en çok etkileyen karar, ilk sürüme neyin gireceğidir. Her fikri ilk günden uygulamaya koymak hem takvimi uzatır hem de kullanıcıların gerçekte neyi kullandığını öğrenmeden yatırım yapmak anlamına gelir. İlk sürümü planlarken şu yöntem işe yarar:

1. Uygulamanın çözdüğü tek ana problemi bir cümleyle yazın.
2. Bu problemi çözmek için kullanıcının mutlaka yapması gereken adımları sıralayın; geri kalan her şeyi "sonraki sürüm" listesine alın.
3. Yönetim tarafında ilk aşamada elle yapılabilecek işleri (ör. bazı raporlar veya onaylar) otomatikleştirmeyi erteleyin.
4. Yayından sonra hangi verilere bakarak karar vereceğinizi belirleyin: kayıt oranı, tekrar kullanım, en çok kullanılan ekranlar gibi.

Bu yaklaşım bütçeyi korur ve ikinci sürümün gerçek kullanıcı davranışına göre şekillenmesini sağlar. Native geliştirmede bu, önce tek platformla başlayıp ikinci platformu kanıtlanmış bir kapsamla eklemeyi de mümkün kılar.

Geliştirme süreci adım adım

1. Keşif: Hedef kullanıcı, temel senaryolar ve ilk sürümde olması gereken özellikler belirlenir. Her şeyi ilk sürüme koymamak, en çok bütçe kazandıran karardır.
2. UX ve prototip: Kullanıcı akışları ve ekranlar tasarlanır, tıklanabilir prototip üzerinden onay alınır.
3. Geliştirme: Uygulama ve arka uç kısa döngülerle geliştirilir; düzenli aralıklarla çalışan sürümler paylaşılır.
4. Test: iOS'ta TestFlight, Android'de Google Play'in test kanalları üzerinden gerçek cihazlarda kapalı test yapılır.
5. Mağaza yayını: Mağaza görselleri, açıklamalar, gizlilik bilgileri hazırlanır ve inceleme sürecine gönderilir.
6. Yayın sonrası: Hata raporları ve kullanım verileri izlenir, ilk güncellemeler planlanır.

Süre kapsamla doğrudan ilişkilidir. Deneyimimizde basit uygulamalar 1–2 ay, kapsamlı projeler 2–4 ay içinde tamamlanıyor; kesin takvim kapsam netleştikten sonra yazılı olarak paylaşılır.

App Store ve Google Play yayınında dikkat edilecekler

Mağaza yayını, uygulamanın bitmesinden sonraki son adım gibi görünse de planlamaya baştan dahil edilmelidir:

• Geliştirici hesapları: Apple Developer Program yıllık ücretli üyelik, Google Play Console ise tek seferlik kayıt ücreti ister. Güncel ücretleri Apple ve Google'ın kendi sayfalarından kontrol edin.
• Hesap kimin adına? Uygulamanın şirketiniz adına, şirket hesabıyla yayınlanması önerilir. Apple'da kurumsal hesap için D-U-N-S numarası istenir; bu sürecin birkaç gün sürebileceğini hesaba katın.
• Gizlilik bilgileri: Her iki mağaza da uygulamanın hangi verileri topladığını beyan etmenizi ister. Hesap oluşturma sunan uygulamalarda, hesabın uygulama içinden silinebilmesi de beklenir.
• İnceleme süreci: Uygulamalar yayından önce incelenir; eksik bilgi veya kural ihlali durumunda geri dönebilir. Takvimde bunun için pay bırakın.
• Kapalı test şartları: Google Play'de yeni açılan bazı geliştirici hesapları için yayından önce kapalı test yapılması şartı bulunabiliyor.

Yayından sonra: bakım bir seçenek değil

Apple ve Google her yıl işletim sistemlerinin yeni sürümlerini yayınlar ve mağaza kurallarını günceller. Güncellenmeyen uygulamalar zamanla uyumsuzluk yaşayabilir veya mağaza gerekliliklerinin gerisinde kalabilir. Bu yüzden bütçe planlarken yalnızca ilk sürümü değil, yıllık bakım ve küçük iyileştirmeleri de hesaba katın.

Teklif almadan önce şunları hazırlamanız süreci hızlandırır: uygulamanın çözdüğü problem, hedef kullanıcı, ilk sürümde mutlaka olması gereken 5–10 özellik, benzer bulduğunuz uygulamalar ve hedef yayın tarihi.