Mobil Uygulama Geliştirme

Native mi, çapraz platform mu?

Bu, projenin ilk teknik kararıdır ve maliyetin büyük kısmını belirler. Üç seçenek var:

• Native geliştirme: iOS için Swift, Android için Kotlin ile iki ayrı uygulama yazılır. Performans ve platform özelliklerine erişim en üst düzeydedir, ama aynı işi iki kez yaparsınız. Yoğun grafik işleyen, ileri düzey kamera veya arka plan işlemleri kullanan uygulamalarda doğru tercihtir.
• Çapraz platform (React Native, Flutter): Tek kod tabanından iki platform derlenir. Arayüz gerçek yerel bileşenlerle çizildiği için kullanıcı farkı hissetmez. İş uygulamaları, sipariş, rezervasyon, üyelik ve içerik uygulamalarının büyük çoğunluğu için en verimli seçenektir.
• Aşamalı web uygulaması: Mağaza yayını olmadan, tarayıcı üzerinden ana ekrana eklenebilen çözüm. Maliyeti en düşük olanıdır ancak anlık bildirim ve cihaz donanımı erişiminde platform kısıtları vardır.

Projelerin çoğunda çapraz platform öneriyoruz. Ancak ihtiyacınız gerçekten native gerektiriyorsa bunu baştan söylüyoruz; yanlış teknoloji seçimi, projenin ortasında fark edildiğinde en pahalı hatadır.

Mobil uygulama geliştirme süreci nasıl işliyor?

Süreç web projelerine benzer ama iki önemli farkı var: mağaza inceleme süreçleri ve cihaz çeşitliliği.

Önce ürün tanımı yapılıyor. Burada en kritik konu kapsamı daraltmak: ilk sürüm, kullanıcının uygulamayı indirmesine değecek tek işi çok iyi yapmalı. İkincil özellikler sonraki sürümlere bırakılıyor. Uygulamanın hiç indirilmemesinin en yaygın nedeni özellik eksikliği değil, ne işe yaradığının anlaşılmamasıdır.

Ardından arayüz tasarımı ve prototip geliyor. Mobil tasarımda dikkat ettiğimiz şeyler: tek elle kullanım için önemli eylemlerin ekranın alt bölgesine yerleştirilmesi, dokunma hedeflerinin yeterli boyutta olması, platform alışkanlıklarına saygı (iOS ve Android geri hareketi farklı çalışır), yükleme ve boş durum ekranlarının tasarlanması.

Geliştirme iki haftalık sprintlerle ilerliyor ve her sprint sonunda size dahili dağıtım üzerinden gerçek bir derleme gönderiliyor. Kendi telefonunuzda kullanmadan uygulama hakkında sağlıklı geri bildirim vermek mümkün değil.

Uygulama mağazalarda yayınlanma süreci nasıl?

İki mağazanın süreci farklı. Android tarafında yayın genellikle hızlıdır; ilk yayında birkaç gün süren bir inceleme olur, sonraki güncellemeler daha kısa sürede geçer. iOS tarafında inceleme daha sıkıdır ve ret alma ihtimali yüksektir. En sık karşılaşılan ret nedenleri şunlar:

• Uygulamanın yalnızca web sitesinin çerçeve içine alınmış hâli olması
• Hesap silme seçeneğinin uygulama içinde bulunmaması
• Dijital içerik satışında mağaza içi satın alma yerine harici ödeme kullanılması
• Gizlilik politikasının eksik olması ya da toplanan veri beyanının gerçekle uyuşmaması
• İnceleme ekibine test hesabı verilmemesi

Bu maddeleri geliştirme sırasında karşılıyoruz, böylece ret riski büyük ölçüde azalıyor. Ret gelirse yazışmayı biz yürütüyoruz. Mağaza hesapları geliştirici hesabı olarak sizin adınıza açılıyor; uygulamanın sahipliği hiçbir aşamada ajansta kalmıyor.

Sunucu tarafı da gerekli mi?

Uygulama kullanıcı hesabı tutuyor, veri kaydediyor veya içerik gösteriyorsa evet. Mobil uygulama genellikle buzdağının görünen kısmıdır; arkasında API, veritabanı ve yönetim paneli bulunur. Bu bileşenleri de biz geliştiriyoruz ve fiyatlandırırken ayrı kalem olarak gösteriyoruz, çünkü bazı projelerde müşterinin hâlihazırda çalışan bir sistemi oluyor.

Mevcut bir sisteme bağlanılacaksa önce o sistemin API kalitesini inceliyoruz. Yanıt süreleri, sayfalama desteği, hata mesajlarının anlaşılırlığı ve dokümantasyonun güncelliği, mobil tarafın ne kadar iş yapacağını doğrudan belirliyor. Zayıf bir API üzerine kurulan mobil uygulamada, eksik işleri kapatmak için araya bir ara katman yazmak gerekebiliyor; bunu keşif aşamasında tespit edip teklife yansıtıyoruz.

API tasarımında mobil koşulları gözetiyoruz: yanıtlar küçük tutulur, listeler sayfalanır, görseller cihaz ekranına uygun boyutta sunulur, kimlik doğrulama jeton tabanlı olur ve yenileme jetonuyla oturum sürekliliği sağlanır. Zayıf bağlantıda yeniden deneme ve zaman aşımı davranışları uygulama tarafında açıkça tanımlanır.

Çevrimdışı çalışma mümkün mü?

Mümkün, ama maliyeti göz ardı edilmemeli. Saha ekipleri için sıkça istenen bu özellik, uygulamanın verinin bir kısmını cihazda tutmasını ve bağlantı geldiğinde eşitlemesini gerektirir. Buradaki asıl zorluk eşitleme değil, çakışma çözümüdür: aynı kaydı iki kullanıcı çevrimdışıyken değiştirdiyse hangisi geçerli olacak?

Bu soruya iş kuralı düzeyinde cevap verilmeden çevrimdışı çalışma yazılmaz. Genellikle üç strateji kullanıyoruz: son yazan kazanır, alan bazlı birleştirme, ya da çakışmayı kullanıcıya gösterip karar aldırma. Doğru strateji veri tipine göre değişir ve analiz aşamasında birlikte belirlenir.

Yayına aldıktan sonra ne yapmak gerekiyor?

Mobil uygulama, yayınlandıktan sonra bakımı web sitesinden daha zorunlu olan bir üründür. Nedeni şu: işletim sistemleri yılda en az bir büyük sürüm çıkarır, mağazalar hedef sürüm zorunlulukları getirir ve uyum sağlamayan uygulamalar bir süre sonra mağazadan kaldırılır. Bu yüzden yılda en az iki bakım sürümü planlamanızı öneriyoruz.

İlk sürümden itibaren çökme takibi ve kullanım analitiği kurulu geliyor. İzlediğimiz temel göstergeler: çökmesiz oturum oranı, ilk açılış süresi, kayıt tamamlama oranı, birinci ve yedinci gün geri dönüş oranı ve temel akışların tamamlanma oranı. Bu veriler bir sonraki sürümde neye öncelik verileceğini tahminle değil ölçümle belirliyor.

Fiyat ve süre neye bağlı?

Süreyi ve fiyatı belirleyen başlıklar: benzersiz ekran sayısı, kullanıcı rolü sayısı, sunucu tarafının sıfırdan mı yazılacağı yoksa mevcut sisteme mi bağlanılacağı, çevrimdışı çalışma ihtiyacı, ödeme alınıp alınmayacağı ve cihaz donanımı kullanımının derinliği.

Orta ölçekli bir uygulama için gerçekçi süre 3 ila 6 aydır. Bu sürenin bir kısmı mağaza yayın ve inceleme dönemine gider; takvimde bunun için iki hafta pay bırakıyoruz. Fiyata dahil olmayan kalemler: mağaza geliştirici hesabı yıllık ücretleri, bulut ve bildirim servisi kullanım bedelleri, pazarlama ve indirme kampanyaları ile ilk sürüm sonrası yeni modül geliştirmeleri.

Uygulama içinde ödeme almak nasıl kurgulanıyor?

Bu konu, mobil projelerde en çok yanlış planlanan başlıktır ve mağaza kurallarıyla doğrudan ilişkilidir. Temel ayrım şu: fiziksel ürün ve gerçek dünyada verilen hizmetler için normal ödeme altyapınızı kullanabilirsiniz. Buna karşılık dijital içerik, üyelik ve uygulama içi özellik satıyorsanız mağazanın kendi satın alma altyapısını kullanmanız beklenir ve buradan komisyon kesilir.

Bu ayrım iş modelinizi doğrudan etkilediği için projeye başlamadan netleştiriyoruz. Bir eğitim uygulamasında kurs satışı, bir yayın uygulamasında abonelik, bir araçta gelişmiş özellik kilidi mağaza kanalına girer. Yemek siparişi, randevu, bilet ve fiziksel ürün satışı ise kendi ödeme sağlayıcınızla yürütülür.

Abonelik kurgusu ayrı bir teknik iş yüküdür. Yapılması gerekenler: satın alma makbuzunun sunucu tarafında doğrulanması, aboneliğin yenilenme ve iptal durumlarının izlenmesi, deneme süresi ve yükseltme/düşürme senaryolarının yönetilmesi, iki platformda alınan aboneliklerin tek kullanıcı hesabında birleştirilmesi ve iade durumlarında erişimin kapatılması. Makbuz doğrulaması sunucuda yapılmadığında sahte satın alma ile ücretsiz erişim mümkün hâle gelir; bu yüzden doğrulamayı hiçbir zaman yalnızca cihaz tarafında bırakmıyoruz.

Ayrıca fiyatların mağaza fiyat kademelerine göre tanımlanması, kur değişimlerinde fiyat güncelleme politikası ve mevcut abonelerin fiyat artışından nasıl etkileneceği gibi ticari kararların baştan verilmesi gerekiyor. Bu kararlar teknik değil ama teknik yapıyı belirliyor; bu yüzden analiz toplantısında masaya koyuyoruz.