Mobil uygulama geliştirme: iOS, Android ve çapraz platform

Mobil uygulama geliştirme, bir iş fikrini iPhone ve Android'de çalışan, mağaza incelemesinden geçen ve yayından sonra güvenle güncellenebilen bir uygulamaya dönüştürme işidir. Uygulamayı yerel (Swift, Kotlin) ya da React Native veya Flutter ile tek kod tabanından yazıyoruz; seçim projeye göre yapılır. Mağaza yayını, abonelik ile reklam entegrasyonu ve kişisel veriyi en aza indiren mimari de işin başında tasarlanır.

Güncellendi:

Kısaca

  • Platform kararını ekran sayısı değil; cihaz özellikleri, bakımı yapacak ekip ve bütçe belirler. İş uygulamalarının çoğunda React Native veya Flutter iki platformu tek kod tabanıyla karşılar.
  • Mağaza kuralları takvime baştan girer: 13 Kasım 2023'ten sonra açılmış kişisel Google Play hesaplarında yayından önce 12 test kullanıcısıyla 14 günlük kapalı test şartı var; hesap açtıran uygulamalar iki mağazada da hesap silme sunmak zorunda.
  • Kendi uygulamamız UDF Mobil (md9) için reklam, abonelik, Face ID kilidi ve cihaz üzerinde OCR'ı biz kurduk; bu sayfadaki pratik notların çoğu oradan geliyor.
  • Kaynak kod, imzalama bilgileri ve mağaza hesapları sizin adınıza olur.
Bu sayfada
  1. Yerel mi, React Native mi, Flutter mı?
  2. iOS ve Android'de ayrıca nelere dikkat edilir?
  3. App Store ve Google Play yayın süreci nasıl işler?
  4. Reklam ve abonelik entegrasyonunda UDF Mobil'den öğrendiklerimiz
  5. Gizlilik ve KVKK'ya uygun mobil mimari nasıl kurulur?
  6. Teslimde neler size geçer?

Mobil projeler genellikle bir fikirle, hazır bir tasarımla ya da mobile taşınmak istenen çalışan bir web sistemiyle başlar. Üçünde de ilk iş, uygulamanın hangi cihaz özelliklerine ihtiyaç duyduğunu, hangi veriyi toplayacağını ve bakımını kimin yapacağını yazıya dökmektir. Kapsam net değilse önce proje danışmanlığı ve teknik şartname aşamasını öneririz; teslimdeki anlaşmazlıklar çoğu zaman bu belgenin eksikliğinden çıkar.

Yerel mi, React Native mi, Flutter mı?

Aynı ekranları iki platformda gösteren bir iş uygulamasında çapraz platform çoğu zaman yeterlidir; yoğun kamera, ses ya da artırılmış gerçeklik işi veya saat, widget gibi platform uzantıları varsa yerel geliştirme öne çıkar.

Yerel (Swift / Kotlin)React NativeFlutter
Kod tabanıHer platform için ayrıTek (TypeScript); gerektiğinde yerel modülTek (Dart); gerektiğinde platform kanalı
ArayüzPlatformun kendi bileşenleriPlatformun yerel bileşenleri, JavaScript tarafından yönetilirKendi çizim motoruyla çizilir; iki platformda birebir aynı görünebilir
Güçlü olduğu yerYoğun kamera, ses ve AR işleri; platform uzantıları; işletim sisteminin en yeni özellikleriForm, liste ve belge ağırlıklı iş uygulamaları; web tarafında React bilen ekiplerÖzel tasarımlı, animasyon ağırlıklı arayüzler
Dikkat edilecekİki kod tabanı, iki kat bakımYerel kütüphanelerin sürüm uyumu; ana sürüm yükseltmeleri emek isterDart bilen ekip; platformun görsel alışkanlıklarına uyum için ek iş

Kendi uygulamamız UDF Mobil (md9) React Native ile yazıldı; şu an yalnızca iPhone sürümü var. Çapraz platform her şeyi tek kodla çözmüyor: hazır paketlerin derleme yapılandırmamızla uyuşmadığı ya da hiç bulunmadığı yerlerde (izleme izni istemi, mağaza değerlendirme istemi, PDF şifrelemenin ihtiyaç duyduğu güvenli rastgele sayı üretimi) küçük Objective-C modülleri yazdık. React Native 0.76'da varsayılan olan yeni mimariyle Firebase kütüphanesinin son ana sürümü derlenmediği için bir önceki ana sürümde sabitledik. Cihazda metin tanıma (OCR) için seçtiğimiz kütüphane de en düşük iOS sürümünü 15.5'e çekti; böyle bir bağımlılık kimin uygulamayı hiç kuramayacağını belirler. Bu kararları gerekçesiyle teslim belgesine yazarız.

iOS ve Android'de ayrıca nelere dikkat edilir?

Eylül 2026 itibarıyla öne çıkan kurallar:

iOS

  • 28 Nisan 2026'dan beri App Store Connect'e yüklenen uygulamaların Xcode 26 ve iOS 26 SDK'sı ile derlenmesi gerekiyor.
  • Uygulamanın ve içindeki üçüncü taraf SDK'ların kullandığı belirli sistem API'leri için gizlilik bildirimi dosyasında (privacy manifest) onaylı gerekçe bulunmalı; Apple bunu 1 Mayıs 2024'ten beri arıyor.
  • Kamera, fotoğraf, Face ID gibi her izin için Info.plist'te bir amaç metni gerekir; NSFaceIDUsageDescription yoksa biyometrik doğrulama istekleri başarısız olabilir.

Android

  • 31 Ağustos 2026'dan itibaren yeni uygulamalar ve güncellemeler Android 16'yı (API 36) hedeflemeli; ek süre istenirse son tarih 1 Kasım 2026. API 35'in altında kalan mevcut uygulamalar, daha yeni Android kullanan yeni kullanıcılara görünmez.
  • Google Play App Signing'de kullanıcıya giden paketi imzalayan anahtarı Google saklar; siz ayrı bir yükleme anahtarıyla imzalarsınız. Yükleme anahtarı kaybolursa sıfırlatılabilir, ama kimde durduğu teslim belgesinde yazılı olmalı.
  • Testi yalnızca üst segment bir telefonda değil, düşük bellekli eski bir cihazda da yaparız; performans sorunları çoğunlukla orada görünür.

App Store ve Google Play yayın süreci nasıl işler?

  1. Geliştirici hesapları sizin adınıza açılır. Apple Developer Program üyeliği yıllık 99 ABD doları; şirket olarak kayıtta D-U-N-S numarası isteniyor. Google Play'de tek seferlik 25 ABD doları kayıt ücreti var. Bireysel Apple hesabı kişinin yasal adıyla açılır; uygulama şirket adıyla yayınlanacaksa hesabı baştan kurumsal açmak daha kolaydır.
  2. Uygulama adı ve kimliği belirlenir. Paket kimliği (iOS'ta bundle ID, Android'de applicationId) mağaza kaydına bağlanır; yayından sonra değiştirmek yeni bir uygulama açmak demektir. Benzer adlı uygulamalar da kontrol edilir: App Store'da "UDF Mobile" adlı başka bir uygulama bulunduğu için biz her yerde "UDF Mobil (md9)" yazıyoruz.
  3. Gizlilik beyanları doldurulur. App Store Connect'teki gizlilik ayrıntıları ve Google Play'deki Veri güvenliği formu, eklenen reklam ve analitik SDK'larının topladığı veriyi de kapsar. Beyanı SDK listesinden tek tek çıkarır, koddaki davranışla karşılaştırırız. Gizlilik politikası bağlantısı hem mağaza kaydında hem uygulamada bulunmalı (Yönerge 5.1.1(i)).
  4. Test dağıtımı yapılır. iOS'ta TestFlight, Android'de kapalı test kanalı. 13 Kasım 2023'ten sonra açılmış kişisel bir Google Play hesabında üretime geçmeden önce en az 12 test kullanıcısının 14 gün kesintisiz katıldığı kapalı test gerekir; kurumsal hesaplar muaf. Bu iki hafta takvimde yoksa lansman kayar.
  5. İnceleme. Apple'a göre başvuruların ortalama %90'ı 24 saatten kısa sürede inceleniyor; ret gelirse düzeltme süresi eklenir. Giriş gerektiren uygulamada inceleme ekibine demo hesap verilir, arka uç açık tutulur (Yönerge 2.1). Yeni özellikler inceleme notunda somut biçimde tarif edilir; belgelenmemiş özellik ret nedenidir (Yönerge 2.3.1).
  6. Aşamalı yayın. Apple güncellemeyi yedi günde kademeli olarak açar (ilk gün %1), Google Play'de de kademeli dağıtım var. İlk günlerde çökme oranını izler, gerekirse durdururuz.

Reklam ve abonelik entegrasyonunda UDF Mobil'den öğrendiklerimiz

Gelir modelinin bu iki parçası, kullanıcı deneyimini de en kolay bozan parçalardır. UDF Mobil'de koyduğumuz kurallar:

  • Önce rıza, sonra reklam. Sıra şöyle: Google'ın rıza yönetimi SDK'sıyla (UMP) güncel rıza durumu alınır, ardından iOS'ta izleme izni (App Tracking Transparency, Yönerge 5.1.2(i)) istenir, reklam SDK'sı en son başlatılır. İzin yoksa reklamlar kişiselleştirilmeden gösterilir.
  • Reklam işin ortasına girmez. Tam ekran reklam yalnızca bir dönüştürme bitip dosya kaydedildikten sonra, oturum başına üst sınırla gösterilir. Belge düzenleyici ve görüntüleyicide banner yok. Sıklık ayarları Firebase Remote Config ile yönetildiği için yeni sürüm çıkarmadan değiştirilebiliyor.
  • SDK'lar birbirini bozabilir. Reklam SDK'sı açılışta kendi çökme sinyali işleyicilerini kurup Crashlytics'in yerel çökme raporlarını engelliyordu; SDK'nın kendi çökme raporlamasını yerel kodda kapatarak çözdük. Bu, ancak gerçek cihaz günlüğünde görünür.
  • Abonelikte tek doğruluk kaynağı. Premium hakkını (entitlement) RevenueCat'ten okuyoruz; reklam gizleme de premium kilitleri de bu değere bakar. Fiyatlar koda yazılmaz, mağazadan yerelleştirilmiş gelir. "Ücretsiz dene" metni yalnızca mağazada bir deneme teklifi tanımlıysa görünür.
  • Ödeme ekranında zorunlu olanlar. Satın alımları geri yükleme düğmesi (Yönerge 3.1.1), otomatik yenileme notu, gizlilik politikası ve kullanım koşulları bağlantıları. Fiyat karşılığında ne alınacağı abonelikten önce açıkça yazılır (Yönerge 3.1.2). Dijital bir özelliğin kilidini açan satın alma, mağazanın uygulama içi satın alma sistemiyle yapılır.

Mağazalar bu satışlardan komisyon alır: Apple'ın Küçük İşletme Programı'nda yıllık 1 milyon ABD dolarına kadar gelirde oran %15; Google Play'de oran ürün türüne ve bölgeye göre değişiyor.

Gizlilik ve KVKK'ya uygun mobil mimari nasıl kurulur?

En güvenli kişisel veri, sunucuya hiç gitmeyen veridir. KVKK m.4 verinin işlendiği amaçla bağlantılı, sınırlı ve ölçülü olmasını ister; mobilde bunun karşılığı, işi cihazda yapılabildiği her yerde cihazda yapmaktır. Kontrol listemiz:

KararUygulamada ne demekUDF Mobil'deki karşılığı
İşi cihazda yapmakBelge, fotoğraf, konum gibi içerik sunucuya gönderilmeden işlenirDönüştürme, OCR ve KVKK maskeleme çevrimdışı çalışır; belge içeriği ve dosya adı sunucuya gitmez
Gerekmeyen veriyi almamakÖzellik yoksa altyapısı eklenmez; yüklenen fotoğraftaki konum taşıyan EXIF verisi sunucuya gitmeden temizlenirBildirim gerekmediği için ilk sürüme push altyapısı hiç eklenmedi, izin de istenmiyor
Analitikte kişisel veri olmamasıOlaylarda yalnızca kategorik değerler; hata metinleri gönderilmeden temizlenirDosya adı, belge içeriği, kimlik numarası olay parametresi olamaz; çökme mesajlarında dosya yolu, e-posta ve uzun sayılar maskelenir
Vazgeçme hakkıAyarlarda tek anahtarAnalytics, Crashlytics ve performans ölçümü birlikte kapanır
Uygulama kilidiHassas içerikte biyometrik kilit; uygulama arka plandayken içerik örtülürFace ID kilidi; arka planda geçen süre ölçülemezse (süreç askıya alınmış, saat geri alınmış) uygulama kilitlenir
Hesap ve silmeHesap açtıran uygulama hesabı ve verisini uygulama içinden sildirebilmeliUDF Mobil hesap açtırmaz; sunucuda kullanıcıya bağlı belge tutulmaz

Hesap açılan uygulamalarda silme yükümlülüğü üç yerden gelir: Apple Yönerge 5.1.1(v) uygulama içinden hesap silmeyi, Google Play ayrıca uygulamayı yeniden kurmadan kullanılabilecek bir web bağlantısını ister; KVKK m.7 de işlenme sebebi ortadan kalkan verinin silinmesini, yok edilmesini veya anonim hâle getirilmesini öngörür. Bu yüzden "Hesabı sil" düğmesi arka uçta verinin gerçekten silindiği bir iş akışına bağlanır; yedeklerdeki kopyanın ne zaman düşeceği de yazılır.

Analitik, reklam ve çökme raporlama hizmetlerinin sunucuları çoğunlukla yurt dışındadır; KVKK m.9 yurt dışına aktarımı yeterlilik kararına, uygun güvencelere (örneğin standart sözleşme) ya da arızi hâllere bağlar. Aydınlatma metninin içeriği, açık rıza gereken işlemler ve aktarımın dayanağı hukukçunun değerlendirmesidir. Biz bu kararı uygulamanın davranışına çeviririz: rıza gelmeden ilgili SDK başlamaz, rıza geri alınınca toplama durur, aydınlatma ile açık rıza tek onay kutusunda birleştirilmez (Aydınlatma Tebliği m.5/1-f). Oturum anahtarları düz metin depolamaya değil; iOS'ta Keychain'e, Android'de Keystore anahtarıyla şifrelenmiş depolamaya yazılır. KVKK m.12'nin istediği teknik tedbirlerin mobildeki temel karşılığı budur.

Bir uygulamanın veriyi nereye, hangi zaman damgasıyla yazdığını içeriden bilmek, mobil cihaz ve uygulama incelemesi yaparken de yorum hatasını azaltıyor.

Teslimde neler size geçer?

Uygulama sizin hesaplarınızda yaşar. Teslim listemiz:

  • Git geçmişiyle birlikte kaynak kod deposu.
  • App Store Connect ve Google Play Console hesapları sizin adınıza; biz yalnızca davet edilmiş ekip üyesiyiz.
  • İmzalama: Apple sertifika ve profilleri; Android yükleme anahtarı ve parolasının nerede saklandığı.
  • Firebase, RevenueCat, reklam ağı gibi üçüncü taraf hesapların sahipliği ve gizli anahtarların listesi (değerleri ayrı, güvenli bir kanaldan).
  • Derleme talimatı: sıfırdan kurulumda takılınan her adım yazılır. UDF Mobil'de örneğin OCR kütüphanesi simülatör derlemesi için ayrı bir kurulum bayrağı istiyor; bu, talimatın ilk sayfasında.
  • Test senaryoları, sürüm notları, mağaza metinleri.

Bu listeyi sözleşmede kabul ölçütü olarak kullanabilirsiniz; teslimde neden anlaşmazlık çıktığını yazılım teslim uyuşmazlıkları yazımızda anlatıyoruz. Uygulamanın konuşacağı sunucu tarafı, API ve dış sistem bağlantıları için backend, API ve entegrasyon sayfasına bakabilirsiniz.

Sık sorulan sorular

Mobil uygulama yaptırmak ne kadar sürer?

Süreyi ekran sayısından çok entegrasyonlar belirler: ödeme ve abonelik, harita, kamera, mevcut bir sistemle veri alışverişi. Analizden sonra iş kalemlerine bölünmüş yazılı bir takvim veririz. Mağaza tarafı da takvime girer: yeni kişisel Google Play hesaplarında 14 günlük kapalı test zorunlu; Apple incelemesi çoğunlukla bir günde sonuçlansa da ret gelirse düzeltme süresi eklenir. Lansman tarihine bu yüzden birkaç gün pay bırakırız.

Flutter mı React Native mi daha iyi?

Her proje için geçerli bir kazanan yok. React Native platformun yerel arayüz bileşenlerini kullanır; web tarafında React bilen bir ekip için bakımı kolaydır. Flutter arayüzü kendi çizim motoruyla çizer; özel tasarımlı, animasyon ağırlıklı ekranlarda iki platformda aynı görünümü vermesi avantajdır. Karar verirken gereken cihaz özelliklerine, yerel kütüphanelerin olgunluğuna ve uygulamayı yıllarca kimin güncelleyeceğine bakarız.

App Store ve Google Play'e uygulama yüklemek için ne gerekir?

Apple Developer Program üyeliği (yıllık 99 ABD doları; şirket olarak kayıtta D-U-N-S numarası istenir) ve Google Play geliştirici hesabı (tek seferlik 25 ABD doları). Ayrıca gizlilik politikası bağlantısı, gizlilik ve veri güvenliği beyanları, mağaza görselleri, giriş gerektiren uygulamada demo hesap ve güncel SDK ile alınmış bir derleme gerekir. Hesapları baştan sizin adınıza açarız.

Uygulamanın kaynak kodu ve mağaza hesabı kimde olmalı?

Sizde. Mağaza hesabı kimin adınaysa uygulama pratikte onundur. Geliştiricinin hesabında yayınlanmış bir uygulamayı sonradan taşımak mümkün ama zahmetlidir; abonelik ve reklam bağlantılarının yeniden kurulmasını gerektirebilir. Kaynak kod Git geçmişiyle, imzalama bilgileri ve üçüncü taraf servis hesapları da size geçmeli ve sözleşmede ayrı teslim kalemleri olarak yazılmalıdır.

Mobil uygulamada KVKK için teknik olarak neler yapılmalı?

Veriyi mümkün olan her yerde cihazda işlemek, analitik ve çökme raporlarına kişisel veri koymamak, rıza gerektiren SDK'ları rızadan önce başlatmamak, ayarlarda vazgeçme anahtarı sunmak, hesap açtırıyorsanız uygulama içinden silme sağlamak. Yurt dışındaki hizmetlere aktarım KVKK m.9 kapsamında ayrıca değerlendirilir. Aydınlatma metni ve hukuki dayanak hukukçunun işidir; biz bu kararların uygulamanın davranışında karşılık bulmasını sağlarız.

Uygulamaya reklam ve abonelik eklemek için ne gerekir?

Reklam için AdMob gibi bir reklam ağı, rıza yönetimi ve iOS'ta izleme izni akışı; abonelik için mağazada tanımlanmış ürünler ve uygulama içi satın alma entegrasyonu. Apple, dijital bir özelliğin kilidini açan satın almalarda uygulama içi satın almayı şart koşar ve geri yükleme mekanizması ister. Fiyatlar mağazadan gelir, yenileme koşulları açık yazılır, mağaza komisyonu gelir hesabına baştan katılır.

Kaynaklar

  1. App Review Guidelines (2.1, 2.3.1, 3.1.1, 3.1.2, 5.1.1, 5.1.2) — Apple Developer
  2. Upcoming Requirements (Xcode 26 SDK, privacy manifest) — Apple Developer
  3. App privacy details on the App Store — Apple Developer
  4. Target API level requirements for Google Play apps — Google Play Console Help
  5. App testing requirements for new personal developer accounts — Google Play Console Help
  6. Understanding Google Play's app account deletion requirements — Google Play Console Help
  7. 6698 sayılı Kişisel Verilerin Korunması Kanunu (m.4, 7, 9, 12) — mevzuat.gov.tr
  8. Aydınlatma Yükümlülüğünün Yerine Getirilmesinde Uyulacak Usul ve Esaslar Hakkında Tebliğ — Resmî Gazete