Mobil Uygulama Geliştirme: Native mi, Cross-Platform mu?

Mobil uygulama geliştirme kararı, çoğu şirkette teknik değil finansal bir kararla başlar: iki ayrı uygulama mı yazacağız, yoksa tek kod tabanıyla iki mağazaya mı çıkacağız? Doğru cevap uygulamanın ne yaptığına bağlıdır. Aşağıda bu kararı somut ölçütlere bağlıyor, ardından yayına kadar olan yolu adım adım özetliyoruz.

Üç yaklaşım, üç farklı maliyet eğrisi

Yerel (native) geliştirme

Android için Kotlin, iOS için Swift kullanılır. Platformun bütün yeteneklerine ilk gün erişirsiniz; işletim sistemi yeni bir özellik duyurduğunda beklemeden kullanabilirsiniz. Bedeli açıktır: iki ayrı kod tabanı, iki ayrı uzmanlık, iki kat bakım. Bir ekran değişikliği iki kez yapılır, iki kez test edilir.

Cross-platform (Flutter, React Native)

Tek kod tabanı iki mağazaya çıkar. Ekran ve iş mantığının yüzde 80-90’ı ortaktır; geri kalan kısım platforma özel köprülerle yazılır. İş uygulamaları, kurumsal paneller, sipariş ve saha takibi gibi form ve liste ağırlıklı uygulamalarda maliyeti yarıya yakın düşürür.

Web tabanlı (PWA) yaklaşım

Mevcut web uygulamanızı mobilde uygulama gibi çalıştırır. Kurulum gerektirmemesi ve anında güncellenmesi büyük avantajdır; buna karşılık bildirim ve arka plan yetenekleri platforma göre sınırlıdır. İç kullanım için yeterli, tüketiciye yönelik ürünlerde genelde yetersizdir.

Karar tablosu: hangi durumda hangisi?

• Kamera ile sürekli görüntü işleme, Bluetooth cihaz haberleşmesi, arka planda konum takibi: yerel geliştirme.
• Form, liste, rapor, onay akışı, bildirim: cross-platform fazlasıyla yeterlidir.
• İki-üç kişilik ekip, kısıtlı bütçe, hızlı teslim: cross-platform.
• Uygulama şirketin ana ürünüyse ve beş yıl yaşayacaksa: yerel geliştirme uzun vadede kontrol sağlar.
• Yalnızca kurum içi kullanım, mağaza gerekmiyor: PWA ciddi bir alternatiftir.

Mimari: mobil uygulama tek başına bir ürün değildir

Mobil projelerde en sık yapılan hata, sunucu tarafını sonraya bırakmaktır. Uygulama mağazadaki bir sürümdür ve kullanıcı güncellemeyi bir ay yapmayabilir. Bu yüzden API tasarımı baştan sürümlenmeli, kırıcı değişiklikler yeni uç noktalarla yapılmalıdır.

Sağlıklı bir mobil mimaride şunlar bulunur:

1. Kimlik doğrulama: Token tabanlı oturum, yenileme (refresh) akışı ve cihaz bazlı oturum kapatma imkânı.
2. Çevrimdışı dayanıklılık: Ağ koptuğunda kullanıcı verisi kaybolmamalı; yerel kuyruk ve yeniden gönderim mantığı olmalı.
3. Bildirim altyapısı: Cihaz jetonlarının saklandığı ayrı bir tablo ve gönderim kayıtları.
4. Hata izleme: Kullanıcı "çalışmıyor" dediğinde bakılacak bir yer olmalı; çökme raporları toplanmalıdır.
5. Zorunlu güncelleme kontrolü: Sunucu, desteklenen en düşük sürümü bildirebilmeli.

Performansı belirleyen üç şey

Kullanıcının "bu uygulama hızlı" demesi genelde şu üçüyle ilgilidir: ilk açılış süresi, liste kaydırmanın akıcılığı ve dokunma sonrası geri bildirimin gecikmesi. Üçü de teknoloji seçiminden çok uygulama biçimiyle ilgilidir.

• Açılışta gereksiz veri çekmeyin; önce iskeleti gösterip veriyi sonra doldurun.
• Uzun listelerde sayfalama veya sanal liste kullanın; 2.000 kaydı tek seferde belleğe almayın.
• Görselleri sunucu tarafında boyutlandırın. Telefonda 200 piksellik alana 3.000 piksellik görsel indirmek en yaygın israftır.
• Her dokunuşa 100 milisaniye içinde görsel geri bildirim verin; işlem uzun sürüyorsa yükleniyor durumu gösterin.

Test etmenin mobildeki zorluğu

Web’de tek bir tarayıcı sürümüyle çalışırsınız; mobilde ise farklı ekran boyutları, işletim sistemi sürümleri ve üretici katmanları devreye girer. Her cihazı test etmek imkânsız olduğu için hedefi daraltmak gerekir.

Pratik yaklaşım şudur: kullanıcı istatistiklerinize göre en çok kullanılan üç cihaz sınıfını belirleyin (küçük ekran, orta ekran, büyük ekran) ve testleri bunlar üzerinde yapın. Ek olarak şu üç senaryoyu mutlaka deneyin: ağ bağlantısı yokken uygulama açılışı, uygulama arka plandayken gelen bildirim ve düşük bellekte sistemin uygulamayı kapatıp geri açması. Bu üç durum, gerçek kullanıcı şikâyetlerinin büyük bölümünü oluşturur.

Yayın öncesi kontrol listesi

Mağaza reddi çoğu zaman teknik değil belge kaynaklıdır. Gönderimden önce şunları hazırlayın: gizlilik politikası bağlantısı, kullanılan her izin için gerekçe metni, hesap silme yolu (App Store bunu arıyor), test hesabı bilgileri, ekran görüntüleri ve açıklama metni. Apple’ın güncel gereksinimleri için App Store inceleme kılavuzu takip edilmelidir.

Sürüm sonrası: asıl iş burada başlar

Yayın sonrasında izlenmesi gereken üç sayı vardır: çökme oranı, ilk gün geri dönüş oranı ve en çok kullanılan üç ekran. Bu üçü, bir sonraki sürümde neyi düzelteceğinizi tahmine değil veriye dayandırır. Kullanıcı yorumlarına cevap vermek de puan ortalamasını gözle görülür biçimde yükseltir.

Sonuç

Native ve cross-platform tartışmasının doğru cevabı "duruma göre"dir ama bu belirsiz bir cevap değildir. Uygulamanız donanıma ne kadar yakınsa yerel geliştirmeye, ekran ve akış sayısı ne kadar fazlaysa ortak kod tabanına yaklaşın. Kararı verdikten sonra enerjinizi teknoloji tartışmasına değil, API tasarımına ve çevrimdışı davranışa harcayın; kullanıcının hissettiği kalite oradan çıkar.