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

Native uygulama, her platformun kendi diliyle ve araçlarıyla yazılan uygulamadır: iOS için Swift (arayüzde genellikle SwiftUI), Android için Kotlin (arayüzde Jetpack Compose). Platformun tüm yeteneklerine ilk günden erişir, performans ve sistem entegrasyonunda tavanı en yüksek seçenektir. Karşılığında iki ayrı kod tabanı, çoğu zaman da iki ayrı uzmanlık gerekir.

Cross-platform (çapraz platform) uygulama, tek bir kod tabanından hem iOS hem Android uygulaması üretir. Bugün kurumsal projelerde en yaygın iki seçenek React Native (JavaScript/TypeScript) ve Flutter (Dart) çerçeveleridir. Her ikisi de mağazalarda gerçek uygulama olarak yayınlanır; kamera, konum, bildirim gibi cihaz özelliklerine eklentiler veya yerel modüllerle erişir. Kotlin Multiplatform ise iş mantığını paylaşıp arayüzü platforma bırakmak isteyen ekipler için giderek olgunlaşan üçüncü bir yoldur.

PWA (Progressive Web App), tarayıcıda çalışan ama ana ekrana eklenebilen, çevrimdışı önbellek ve bildirim gibi yeteneklere sahip web uygulamasıdır. Mağaza onayı gerekmez, güncelleme anında yayılır. Ancak iOS'ta web bildirimi yalnız ana ekrana eklenmiş uygulamalarda çalışır; arka plan işlemleri, Bluetooth gibi donanım erişimleri ve mağazada görünürlük konusunda sınırları vardır. "PWA nedir" sorusunun kısa cevabı: uygulama gibi davranan, iyi yapılmış bir web sitesidir.

Hangi yolun doğru olduğu; hedef kitlenin cihaz dağılımına, uygulamanın ne kadar cihaz yeteneği kullandığına ve ekibinizin uzun vadede neyi sürdürebileceğine bağlıdır. Aşağıdaki tablo dört yaklaşımı aynı ölçütlerle yan yana koyar.

İki çerçeve de olgun, büyük topluluklara sahip ve üretimde yaygın kullanılıyor; aralarındaki fark "iyi-kötü" değil, mimari tercihtir. React Native, arayüzü platformun kendi bileşenlerine eşler. Yeni mimarisi (Fabric ve TurboModules) varsayılan hâle geldiğinden JavaScript ile yerel katman arasındaki iletişim eskisine göre çok daha doğrudan ve hızlıdır. Expo gibi araçlar derleme, güncelleme ve yayın süreçlerini kolaylaştırır.

Flutter ise ekranı kendi render motoruyla (Impeller) piksel piksel çizer. Bu sayede iOS ve Android'de birebir aynı görünen, yoğun animasyonlu ve markaya özel arayüzler kurmak kolaylaşır. Dart dili öğrenmesi kolay bir dildir ama web ekibinizde büyük olasılıkla hazır bulunmaz.

Pratik kural şöyle özetlenebilir: web tarafında React/TypeScript kullanıyorsanız, uygulama çoğunlukla form, liste, akış ve entegrasyondan oluşuyorsa React Native öne çıkar. Tasarım platformdan bağımsız, marka kimliği güçlü ve animasyon yoğunsa Flutter avantajlıdır. Uygulamanın kalbi AR, ileri kamera işleme, düşük gecikmeli ses/görüntü veya derin sistem entegrasyonuysa native yazmak en az sürprizli yoldur. Kararsız kaldığınızda bu seçimi mobil yazılım geliştirme ekibimizle kısa bir teknik ön görüşmede birlikte netleştirebilirsiniz.

Aşağıdaki kartlardan uygulamanızda olmasını istediğiniz özellikleri seçin, hedef platformu ve tasarım seviyesini belirleyin. Planlayıcı; karmaşıklık puanını, örnek bir efor aralığını, ilk sürüm (MVP) ile sonraki sürüm ayrımını ve size uygun teknoloji yaklaşımını gerekçesiyle gösterir. Seçtiğiniz özellikler telefon maketinde ekran olarak belirir.

Efor aralığı yol göstericidir: tek bir ekibin tipik projelerdeki ortalamasından türetilmiş örnek bir hesaptır, teklif değildir. Gerçek süre; iş kurallarının derinliğine, mevcut backend'in durumuna, içerik ve onay süreçlerine göre değişir. Sonucunuzu projenize özel bir değerlendirmeye çevirmek için mobil uygulama teklif formunu kullanabilirsiniz.

iOS ve Android uygulama geliştirme süreci, iyi yönetildiğinde öngörülebilir bir döngüdür. Aşağıdaki altı aşama, orta ölçekli bir iş uygulamasının tipik akışıdır. Bir aşamaya tıklayarak o adımda neler üretildiğini ve nelere dikkat edilmesi gerektiğini görün. Süreler yalnızca örnektir.

Mobil uygulama maliyeti sorusuna tek bir rakamla cevap vermek mümkün değildir; çünkü fiyatı belirleyen şey ekip saatidir ve ekip saatini kapsamın derinliği belirler. İki uygulama da "sipariş alma" ekranına sahip olabilir; birinde sipariş yalnızca e-postayla bildirilir, diğerinde stok kontrolü, bayi fiyat listesi ve ERP'ye fatura aktarımı yapılır. Ekranlar benzer görünür, iş yükü kat kat farklıdır.

Bu nedenle güvenilir bir teklif, özellik listesinden önce iş kurallarını sorar. Aşağıdaki görsel, efor üzerinde etkisi yüksek olan faktörleri örnek ağırlıklarla gösterir. Ağırlıklar her projede değişir; amaç hangi soruların fiyatı en çok etkilediğini görmenizi sağlamaktır.

• Özellik derinliği ve iş kurallarıEtki: YüksekÖdeme, çevrimdışı senkron, mesajlaşma ve rol/yetki yapıları eforun en büyük kısmını oluşturur.
• EntegrasyonlarEtki: YüksekERP, CRM, ödeme kuruluşu, kargo veya kimlik doğrulama servisleri; dokümantasyon kalitesi ve test ortamı süreyi doğrudan etkiler.
• Backend ve yönetim paneliEtki: YüksekHazır bir API var mı, sıfırdan mı yazılacak? Panel yalnızca içerik mi yönetecek, yoksa operasyon mu?
• Platform hedefiEtki: OrtaTek kod tabanıyla iki platform ekonomiktir; iki ayrı native uygulama ise geliştirme ve test eforunu belirgin artırır.
• Tasarım seviyesiEtki: OrtaSistem bileşenleriyle sade arayüz ile markaya özel animasyonlu arayüz arasında tasarım ve geliştirme süresi farklıdır.
• Güvenlik ve uyumlulukEtki: OrtaKVKK, kişisel veri saklama, sağlık/finans gibi hassas alanlar ek denetim, loglama ve test gerektirir.
• Yayın sonrası bakımEtki: SürekliOS güncellemeleri, kütüphane yükseltmeleri, izleme ve küçük geliştirmeler için yıllık bir bütçe öngörülmelidir.

Teklif karşılaştırırken yalnızca toplam tutara değil; neyin kapsama dahil olduğuna (backend, panel, mağaza yayını, test cihazları, garanti süresi, bakım) bakın. Kapsamı eşitlenmemiş iki teklifi karşılaştırmak yanıltıcıdır. Bu konuda yazılım firması seçerken dikkat edilmesi gerekenler rehberimizdeki teklif şeffaflığı kriterine göz atabilirsiniz.

Kullanıcı hesabı olan, veri paylaşan veya içerik güncellenen hemen her mobil uygulamanın bir sunucu tarafına ihtiyacı vardır. Uygulama cihazdaki arayüzdür; kullanıcı verisi, iş kuralları, yetkilendirme ve diğer sistemlerle konuşma işi backend ile API (uygulamanın sunucuyla konuştuğu arayüz) üzerinden yürür. Kritik kurallar asla yalnız uygulamanın içinde tutulmamalıdır; çünkü mobil uygulamanın kodu kullanıcının cihazındadır ve incelenebilir.

• AKimlik doğrulamaToken tabanlı oturum, yenileme, cihaz yönetimi, hesap silme.
• Bİş API'siSipariş, randevu, içerik gibi iş kuralları; sürümlenmiş uç noktalar.
• CBildirim servisiAPNs (Apple) ve FCM (Google) üzerinden hedefli gönderim.
• DDosya depolamaGörsel ve belgeler için güvenli, erişim kontrollü depolama.
• EEntegrasyon katmanıERP/CRM, ödeme ve kargo servisleriyle kuyruklu, tekrar denemeli aktarım.
• Fİzleme ve loglarHata takibi, performans ölçümü, güvenlik olay kayıtları.

İki temel yol vardır. Hazır backend servisleri (BaaS) kimlik doğrulama, veritabanı ve bildirim gibi yapı taşlarını hızla sunar; prototip ve basit uygulamalarda işi hızlandırır. Özel API ise ERP entegrasyonu, karmaşık yetki yapıları, veri yerleşimi ve uzun vadeli maliyet kontrolü gerektiğinde daha doğru tercihtir. Birçok projede ikisi birlikte kullanılır. İyi tasarlanmış bir API; sürümlenir, dokümante edilir ve web paneliyle mobil uygulamaya aynı kuralları uygular. Bu katmanı kurumsal API geliştirme çalışmalarımızda ayrıca ele alıyoruz.

Saha satış, servis veya bayi uygulamalarında backend'in en önemli görevi çoğu zaman ERP ile köprü kurmaktır: cari bakiye, stok, fiyat listesi ve sipariş aktarımı. Bu senaryonun ayrıntıları için Logo ERP entegrasyonu rehberimiz iyi bir başlangıçtır. Sunucu tarafının nerede ve nasıl barındırılacağı da baştan planlanmalıdır; ölçeklenebilir bir bulut sunucu altyapısı kampanya dönemlerindeki ani yükleri karşılamayı kolaylaştırır.

Uygulamayı yayınlamak için Apple Developer Program ve Google Play Console hesapları gerekir. Şirket adına yayın yapılacaksa hesapların şirket tüzel kişiliğiyle açılması önerilir; her iki platform da kurumsal hesaplarda D-U-N-S numarası gibi kuruluş doğrulaması ister. Hesapların şirketinizin kontrolünde olması, ileride ajans veya firma değiştirdiğinizde uygulamanızı taşıma derdi yaşamamanızı sağlar.

App Store incelemesi insan ve otomasyon kontrolünün birleşimidir; Apple, gönderimlerin büyük çoğunluğunun genellikle bir iki gün içinde değerlendirildiğini belirtir. Ret nedenlerinin başında çökmeler, eksik veya işlevsiz içerik, giriş gerektiren uygulamalarda test hesabı verilmemesi, gizlilik bilgilerinin uygulamanın davranışıyla uyuşmaması ve dijital içerik satışında uygulama içi satın alma kurallarına uyulmaması gelir. Hesap oluşturmaya izin veren uygulamalar, hesabın uygulama içinden silinmesine de olanak tanımalıdır.

Google Play tarafında inceleme süresi uygulamaya ve hesabın geçmişine göre değişir; yeni hesaplarda daha uzun sürebilir. Yeni açılan kişisel geliştirici hesaplarında, üretime çıkmadan önce belirli sayıda test kullanıcısıyla en az 14 gün süren kapalı test şartı bulunur. Ayrıca Google Play her yıl hedef API seviyesini yükseltir: 31 Ağustos 2026 itibarıyla yeni uygulamaların ve güncellemelerin Android 16'yı (API 36) hedeflemesi gerekir. Apple da App Store'a yüklenen sürümlerin güncel Xcode ve SDK ile derlenmesini belirli tarihlerden itibaren zorunlu kılar.

Gizlilik beyanları artık yayının ayrılmaz parçasıdır. App Store'da "App Privacy" bölümü (gizlilik etiketi) uygulamanın ve içindeki üçüncü taraf SDK'ların topladığı verileri kategorilere göre gösterir; kullanıcıyı başka şirketlerin uygulama ve sitelerinde izlemek için App Tracking Transparency izni gerekir; yaygın SDK'lar ve belirli sistem API'leri için gizlilik manifesti beklenir. Google Play'de "Data safety" (Veri güvenliği) formu benzer bilgileri ister ve hesap silme için uygulama dışından da erişilebilen bir bağlantı talep eder. Türkiye'de bunlara ek olarak KVKK kapsamındaki aydınlatma metni ve gerekiyorsa açık rıza akışı uygulamada yer almalıdır.

Mobil uygulama, yayınlandığı gün en güncel hâlindedir ve o günden itibaren eskimeye başlar. Apple her yıl haziran ayındaki geliştirici konferansında yeni iOS sürümünü tanıtır ve genellikle eylül ayında yayınlar. Android ana sürümleri de yıllık bir takvimle gelir; Google Play'in hedef API şartı ise her yıl ağustos sonunda güncellenir. Bu takvim, bakımın "sorun çıkarsa bakarız" değil, planlı bir iş olmasını gerektirir.

• OS uyumluluk testiBeta sürümlerde erken test, ekran ve izin davranışı değişiklikleri.
• Bağımlılık güncellemeleriÇerçeve, SDK ve kütüphane sürümlerinin düzenli yükseltilmesi.
• Güvenlik yamalarıBilinen açıkların kapatılması, anahtar ve sertifika yönetimi.
• İzleme ve iyileştirmeÇökme oranı, açılış süresi ve kullanıcı yorumlarına göre küçük sürümler.

Bakımın tipik kalemleri şunlardır: yeni işletim sistemi beta sürümlerinde uygulamanın test edilmesi, kullanılan çerçevenin (React Native, Flutter) ve kütüphanelerin güncellenmesi, güvenlik yamaları, sertifika ve anahtar yenilemeleri, çökme raporlarındaki hataların giderilmesi ve mağaza politika değişikliklerine uyum. Uzun süre güncellenmeyen uygulamalarda kütüphane yükseltmeleri birikir ve tek seferde yapılması gereken iş büyür.

Güvenlik de bakımın parçasıdır. Mobil uygulamalarda en sık karşılaşılan riskler; cihazda şifrelenmeden saklanan veriler, API tarafında eksik yetki kontrolleri ve uygulamanın içine gömülmüş anahtarlardır. Kritik veri işleyen uygulamalar için yayın öncesinde ve büyük sürümlerden sonra bağımsız bir güvenlik testi yaptırmak iyi bir pratiktir; sürecin nasıl işlediğini sızma testi rehberimizde anlattık.

Aşağıdaki hatalar çoğu zaman kötü niyetten değil, sürecin görünmeyen kısımlarının bilinmemesinden kaynaklanır. Her biri erken fark edildiğinde ucuz, geç fark edildiğinde pahalıdır.

1. 1Her şeyi ilk sürüme sığdırmakTüm fikirleri MVP'ye koymak yayını aylarca geciktirir. Değeri kanıtlayan çekirdek akışla çıkın, gerisini kullanıcı verisiyle önceliklendirin.
2. 2Backend'i sonradan düşünmek"Önce ekranlar olsun" yaklaşımı, API ve veri modeli netleşince tasarımın yeniden elden geçmesine yol açar.
3. 3Mağaza hesaplarını tedarikçiye bırakmakGeliştirici hesabı, sertifikalar ve imza anahtarları şirketinizde olmalı; aksi hâlde uygulamanızın sahibi siz değilsinizdir.
4. 4Gizlilik beyanlarını geçiştirmekKullanılan SDK'ların topladığı veriyi bilmeden doldurulan beyanlar hem ret hem de itibar riski doğurur.
5. 5Sadece yeni ve hızlı cihazda test etmekKullanıcılarınızın önemli kısmı daha eski cihaz ve zayıf bağlantıyla gelir; test matrisi buna göre kurulmalı.
6. 6Bakım bütçesi ayırmamakİşletim sistemi güncellemesiyle bozulan bir uygulama, kullanıcı yorumlarında hızla puan kaybeder.