Mobil Uygulama

Mobil uygulamanın ekran tarafı işin en öngörülebilir kısmıdır. Asıl zor olan kısım dağıtımdır: yayınladığınız sürüm kullanıcının telefonuna iner ve orada aylarca kalır, web'de on dakikada geri aldığınız hatalı bir sürümü mobilde aynı hızda geri alamazsınız. Araya bir de mağaza incelemesi girer ve güncellemeyi herkes aynı anda kurmaz. Bu yüzden en pahalı karar hangi ekranın nasıl görüneceği değil, altı ay sonra sahada kaç farklı sürümün çalışıyor olacağı ve sunucunun hepsine nasıl cevap vereceğidir. Detartech'te mobil işi bu soruyla başlatıyoruz.

Mobil uygulamada asıl zorluk

Mobil yayın, web yayınından farklı olarak binlerce bağımsız cihaza yapılan bir dağıtımdır ve her cihaz güncellemeyi kendi bildiği zaman alır; araya kontrol edemediğiniz iki eşik girer: mağaza incelemesi ve kullanıcının güncelleme davranışı. İndirilmiş bir sürüm geri çağrılamaz; geri alma diye bir şey yok, yalnızca yeni bir sürüm yayınlamak var ve o da yeniden incelemeye bağlı. Bundan üç sonuç çıkıyor: sunucu, artık değiştiremeyeceğiniz eski istemcilerle uyumlu kalmak zorunda kalıyor; uygulama, kullanıcıya "bu sürüm artık desteklenmiyor" diyebilecek bir mekanizmaya sahip olması gerekiyor; ve sahadaki hatalar uzaktan görülebilir olmalı, çünkü kullanıcı size hata bildirmez, doğrudan uygulamayı siler. Üçü de ilk sürümde kurulmazsa, sonradan çok daha pahalıya kurulur.

Bir mobil uygulamada verilen kararlar

Aşağıdaki altı başlık bir mobil uygulama projesindeki kalıcı kararların tamamını kapsıyor. İlk ikisi teknoloji ve sözleşme, sonraki ikisi cihazın kendi kısıtları, son ikisi dağıtım tarafı.

Çapraz platform ile native arasındaki karar

Flutter ve React Native tek kod tabanından iOS ve Android çıkarır; Swift ve Kotlin her platformu ayrı yazar. Kararı üç ölçüt belirliyor: uygulamanın cihaz yeteneklerine ne kadar dokunduğu (kamera, Bluetooth, arka plan konumu), arayüzün ne kadar platforma özgü his gerektirdiği ve devirden sonra bakımı kimin yapacağı. Tek ekip beslemek çoğu iş uygulamasında belirleyici oluyor. Welldone bu tarafın örneği: saha uygulaması Flutter, yönetim paneli React, servisler .NET ile yazıldı. Sahadaki ihtiyaç QR kod okutup ürün bazlı paketleme yapmak ve sipariş durumunu anlık görmekti, platforma özgü bir etkileşim değil. Çapraz platform seçmek native koda hiç dokunulmayacağı anlamına da gelmez. İzinler, bildirim kaydı ve arka plan davranışı iki platformda ayrı ele alınır.

Backend sözleşmesi ve sürüm uyumu

Mobil uygulamanın API'si bir sözleşmedir ve karşı tarafında güncelleyemeyeceğiniz bir istemci durur. Web'de arayüzle sunucuyu aynı anda yayınlarsınız, mobilde yayınlayamazsınız. Kural şu: alan silinmez, alan adı değiştirilmez, zorunlu yeni alan eklenmez. Değişiklik gerekiyorsa yeni alan eklenir ve eski alan bir süre daha doldurulmaya devam eder; hangi sürüme kadar doldurulacağı yazılı olur. Sunucu ayrıca desteklediği asgari uygulama sürümünü söyleyebilmelidir, çünkü destek penceresini kapatma kararı istemcide değil sunucuda verilir. Togodo ve Welldone projelerinin ikisinde de mobil tarafın karşısında .NET servisleri duruyor. Sorun sözleşme değil de yükse, yani eş zamanlı kullanıcı sayısı ve sorgu maliyetiyse, iş mobil tarafından çıkar ve Backend Ölçekleme tarafına geçer.

Çevrimdışı çalışma ve senkronizasyon

Çevrimdışı çalışma sonradan eklenen bir özellik değil, veri modelini baştan değiştiren bir karardır. Kapsam yazılırken üç soru cevaplanır: hangi ekranlar bağlantı olmadan açılacak, bağlantı yokken yapılan bir kayıt kuyruğa mı alınacak yoksa engellenecek mi, aynı kaydı iki cihaz farklı zamanlarda değiştirdiğinde hangisi kazanacak. Üçüncü sorunun cevabı yazılı değilse veri sessizce bozulur ve bunu aylar sonra fark edersiniz. Çevrimdışı desteklemek uygulamanın içine küçük bir yerel veritabanı ve bir senkronizasyon katmanı koymak demektir; gerçek bir maliyet kalemi. Depo, bodrum ve araç içi gibi bağlantının güvenilir olmadığı yerlerde bu kalemi atlamak, uygulamanın sahada kullanılmamasıyla sonuçlanır. Ofis içindeki bir uygulamada ise gereksiz karmaşıklık olabilir; karar ihtiyaca göre verilir.

Bildirim ve arka plan işleri

Push bildirimi uygulamanın bir özelliği değil, bir zincirdir: sizin sunucunuz, Apple ve Google'ın bildirim servisleri, cihaz ve son sözü söyleyen işletim sistemi. Zincirin her halkasında bildirim düşebilir: kullanıcı izni reddedebilir, sistem pil tasarrufu için teslimi geciktirebilir, cihaz kapalı olabilir. Bu yüzden bildirime bağlı hiçbir iş akışı tek kanala bırakılmaz; bildirimi kaçıran kullanıcı aynı bilgiyi uygulamayı açtığında görebilmelidir. Arka plan işleri de sınırlı: işletim sistemi uygulamanızı istediği zaman uyandırır, siz istediğiniz zaman değil. Düzenli aralıklarla çalışacağı varsayılan bir arka plan görevi test cihazında çalışır, sahada çalışmaz. Togodo bu tarafın örneği: sosyal etkinlik uygulamasına gerçek zamanlı mesajlaşma ve push bildirimleri geliştirildi.

Mağaza yayın süreci ve red sebepleri

App Store ve Google Play iki ayrı süreçtir; kuralları, inceleme biçimleri ve süreleri farklıdır. Yayın takvimi yazılırken inceleme süresi ayrı bir kalem olarak durur, çünkü o süre sizin kontrolünüzde değil ve ilk gönderim genelde en yavaş olanı. Reddin yaygın sebepleri baştan elenebilir: eksik veya gerçekle uyuşmayan gizlilik beyanı, hesap silme yolunun bulunmaması, incelemeciye çalışan bir test hesabı verilmemesi, gerekçesiz zorunlu giriş, açıklama metni olmadan istenen izinler ve eksik mağaza görselleri. Her biri sonradan düzeltildiğinde takvimi bir inceleme turu geciktirir; gönderim öncesi kontrol listesinde dururlar. Mağaza listelemesi de teslim paketinin parçası: başlık, açıklama, anahtar kelimeler, görseller. Otomatik derleme hattı döngüyü kısaltır; Welldone projesinde CI/CD otomasyonu Jenkins ile kuruldu, ayrıntısı DevOps ve CI/CD tarafına düşer.

Zorunlu güncelleme ve geri alınamazlık

Asgari desteklenen sürüm mekanizması ilk sürümde kurulur, sonradan değil. Çalışma biçimi basit: uygulama açılışta sunucuya kendi sürümünü söyler, sunucu desteklenip desteklenmediğini döner, desteklenmiyorsa kullanıcı mağazaya yönlendiren engelleyici bir ekran görür. Mekanizma yoksa eski sürümü emekliye ayırmanın yolu da yok; elinizde yalnızca beklemek kalır. Kurulduğunda ölçülü kullanılır, çünkü zorunlu güncelleme kullanıcıyı uygulamanın ortasında durdurur; güvenlik açığı, veri bozan bir hata veya sürdürülemeyen bir sözleşme değişikliği için saklanır. Kademeli dağıtım da emniyet valfidir: sürümü kullanıcıların bir bölümüne açıp çökme oranını izler, kötü giderse dağıtımı durdurursunuz. Durdurmak yalnızca henüz kurmamış olanları korur. Bu yüzden çökme ve hata raporlaması ilk sürümle açılır; sahadaki bir sorunu mağaza yorumlarından öğrenmek en geç öğrenme biçimidir.

Eski sürümler neden sorun olur

Yayınlanmış her sürüm sahada yaşamaya devam eder. Otomatik güncellemeyi kapatmış cihazlar, güncelleme almayan eski işletim sistemleri ve uygulamayı ayda bir açan kullanıcılar yüzünden sahada tek bir sürüm değil bir sürüm kuyruğu bulunur. Günlük maliyeti şu: sunucudaki her değişiklik yalnızca en yeni sürüme göre değil, desteklenen en eski sürüme göre de kontrol edilmek zorunda. Asıl pahalı hata sınıfı çökme değil, çünkü çökme görünür. Pahalı olan, eski bir istemcinin eksik veya eski biçimde veri yazması; bu sessiz gerçekleşir ve veritabanına yerleşir. Desteklenen sürüm penceresi bu yüzden baştan yazılı bir politika olur: hangi işletim sistemi sürümleri destekleniyor, hangi uygulama sürümünün altında ne davranış gösteriliyor. Bir de çoğu ekibin atladığı test var: yeni sunucu sürümü, bir önceki yayınlanmış uygulama sürümü hâlâ kuruluyken denenir.

Yayın sonrası bakımın kapsamı

Mobil uygulamada bakım "hata düzeltme" demek değildir. Kimse koduna dokunmasa bile bir mobil uygulama zamanla çalışmaz hale gelir, çünkü altındaki zemin yılda birkaç kez değişir. Takvim belli kalemlerden oluşur: her yıl çıkan işletim sistemi ana sürümlerinin davranış değişiklikleri, mağazaların derleme hedefi ve gizlilik beyanı kuralları, süresi dolan imzalama sertifikaları ve sağlayıcı profilleri, üçüncü taraf kütüphanelerin güncellemeleri. Sertifika süresi dolduğunda uygulama çalışmaya devam eder ama yeni sürüm yayınlayamazsınız, yani hata düzeltme yeteneğinizi kaybedersiniz. Yanında sürekli izleme durur: çökme raporları, yanıt vermeyen ekran kayıtları ve mağaza yorumları. Mağaza yorumu pazarlama göstergesi değil, hata kaynağıdır. Yayındaki bir uygulamayı devralıp geliştirmek de bu işin normal parçası. Togodo'da mevcut uygulama işlevseldi ancak etkinlik yönetimi, mesajlaşma ve kullanıcı profili ekranlarında eksikler vardı; mevcut platforma yeni ekranlar tasarlandı, gerçek zamanlı mesajlaşma geliştirildi, SEO ve ASO (mağaza içi görünürlüğü artıran optimizasyon) çalışması yapıldı.

Doğru formatı nasıl seçiyoruz

Karar dört soruya bakılarak veriliyor. İş tarayıcıda karşılanabiliyorsa, yani ihtiyaç içerik göstermek, form doldurtmak veya rapor sunmaksa, mobil uyumlu bir web uygulaması daha hızlı yayına çıkıyor ve mağaza incelemesi beklemiyor. Talep henüz doğrulanmamışsa önce MVP Geliştirme tarafında doğrulanıyor, çünkü mağazada yer almak talebin kanıtı sayılmıyor. Kullanıcısı tanımlı bir iç kullanım aracıysa ve kamera, QR okuma, çevrimdışı çalışma ya da donanım erişimi gerekmiyorsa web paneli daha hızlı sonuç veriyor. Tek gerekçe bildirim göndermekse e-posta, SMS ve web bildirimi önce değerlendiriliyor, çünkü sürekli bakım gerektiren bir varlığı tek kanal için kurmak pahalı bir karar oluyor. Bu dört soru netleştikten sonra doğru format da netleşiyor.

Hesaplar, imzalama anahtarları ve devir

Mobil uygulamada sahiplik yalnızca kaynak kodu değil, hesaplar ve anahtarlardır. Mağaza hesapları sizin şirketiniz adına açılır: uygulamanın listelemesi, yorumları, puanları ve indirme geçmişi o hesaba bağlı ve hesabı taşımak ayrı bir iş. İmzalama anahtarları daha da kritik. Android tarafında uygulama imzalama anahtarı, iOS tarafında sertifikalar kaybedildiğinde aynı listelemeyi güncelleyemezsiniz; kullanıcıların yeni bir uygulama kurması gerekir, yani mevcut kullanıcı tabanınızı kaybedersiniz. Anahtarlar bu yüzden proje başında sizin kontrolünüzdeki bir yerde saklanır. Kaynak kod tüm geçmişiyle sizin deponuzda, sunucu ve veritabanı sizin adınıza açılmış hesaplarda durur. Devir belgesi de teslim paketinin parçası: uygulamanın yerelde nasıl derlendiği, mağazaya nasıl gönderildiği, hangi izinlerin neden istendiği ve asgari desteklenen sürüm politikası.

Yayındaki iki uygulama

Aşağıdaki iki iş yayında; ayrıntıları Başarı Hikayeleri bölümündeki kendi sayfalarında duruyor.

• Welldone: Endüstriyel çamaşırhane operasyonu için Flutter saha uygulaması, React yönetim paneli ve .NET servisleri. Sipariş, sevkiyat, raflama ve paketleme tek platformda toplandı; sahada QR kod okutarak ürün bazlı paketleme yapılıyor, sipariş durumu anlık güncelleniyor, ekip içi iletişim aynı platform üzerinden yürüyor. Altyapı .NET ve MySQL üzerinde kuruldu, CI/CD otomasyonu Jenkins ile sağlandı. Welldone Helper App Store ve Google Play üzerinden indirilebiliyor.
• Togodo: Yayında olan bir sosyal etkinlik uygulaması geliştirildi. Etkinlik listeleme, kullanıcı profilleri ve topluluk yönetimi için yeni ekranlar tasarlandı; kullanıcılar etkinlik oluşturabiliyor, katılabiliyor ve arkadaşlarını davet edebiliyor. Gerçek zamanlı mesajlaşma ve push bildirimleri geliştirildi, SEO ve ASO çalışması yapıldı, performans iyileştirmeleriyle yüksek trafik altındaki davranış düzeltildi. Mobil taraf Flutter, sunucu tarafı .NET.