Mobil uygulama geliştirme süreci: fikirden mağazaya, mağazadan bakıma

Uygulama bitti, ekran görüntüleri hazırlandı, App Store'a yüklendi ve iki gün sonra ret e-postası geldi: inceleme ekibi giriş ekranını geçememiş, çünkü kimse bir demo hesabı bırakmamış. Google Play tarafındaki durum farklı ama aynı ölçüde can sıkıcı: yeni açılmış kişisel geliştirici hesabı, üretim kanalını ancak on iki kişilik bir kapalı testten sonra açıyor. İki mağazada da kod, işin yalnızca bir kısmı.

Bu yazıda mobil uygulama geliştirme sürecini baştan sona, müşteri tarafının bilmesi gereken düzeyde anlatıyoruz: teknoloji seçimi, tasarım ve platform kuralları, arka uç ve bildirimler, gizlilik formları, mağaza yayını, uygulama içi satın alma kuralları, sürüm yönetimi, çökme raporlama ve bakım. Bir uygulamaya gerçekten ihtiyacınız olup olmadığından emin değilseniz, önce "Mobil uygulama mı, mobil uyumlu web mi?" yazımıza göz atın.

Süreç baştan sona: aşamalar ve teslimler

Aşağıdaki tablo, iki mağazaya birden çıkacak tipik bir iş uygulamasının aşamalarını gösteriyor. Süreleri yazmıyoruz, çünkü projeden projeye çok değişiyor; önemli olan, her aşamanın sonunda elinize somut bir şeyin geçmesi.

Native mi, çapraz platform mu?

Native geliştirmede iOS uygulaması Swift ile (çoğu zaman SwiftUI kullanılarak), Android uygulaması Kotlin ile (Jetpack Compose kullanılarak) ayrı ayrı yazılır. Platformun her yeni özelliğine ilk gün erişirsiniz ve arayüz platformun kendi davranışını birebir taşır. Bedeli, iki ayrı kod tabanı ve çoğu zaman iki ayrı uzmanlıktır.

Çapraz platformda tek bir kod tabanından iki uygulama çıkar. En yaygın iki seçenek şunlar:

• Flutter: Google'ın geliştirdiği, Dart diliyle yazılan ve arayüzü kendi çizim motoruyla oluşturan çatı. Görünüm iki platformda birebir aynı olabilir; platforma özgü hissi yakalamak ise ayrıca emek ister.
• React Native, Meta'nın başlattığı, JavaScript ya da TypeScript ile yazılan ve platformun kendi arayüz bileşenlerini kullanan çatı. 0.76 sürümünden beri "Yeni Mimari" varsayılan, React Native'in belgeleri de yeni projelere Expo gibi bir çatıyla başlamayı öneriyor. Web tarafında React kullanan bir ekip için öğrenme süresi kısadır.

Üçüncü bir yol giderek daha ciddiye alınıyor: Kotlin Multiplatform. Burada iş mantığı paylaşılır, arayüz istenirse her platformda native kalır. JetBrains, Compose Multiplatform'un iOS desteğini Mayıs 2025'te kararlı sürüme taşıdı.

Sipariş, rezervasyon, sadakat, saha ekibi ya da içerik uygulamaları gibi çoğu iş uygulaması için çapraz platform makul ve ekonomik bir tercih. Native ise cihaza çok yakın çalışan ürünlerde öne çıkar: yoğun kamera ve görüntü işleme, Bluetooth cihazlarla sürekli iletişim, yüksek performanslı grafik. Bir uyarı ekleyelim. Çapraz platform seçseniz bile ana ekran bileşenleri (widget), Apple Watch ya da Live Activities gibi özellikler için bir miktar Swift ve Kotlin yazılması gerekir; teklifte bunun kimin işi olduğunu sorun.

Tasarım: platform kuralları ve mağazanın gözü

Apple'ın Human Interface Guidelines (HIG) belgeleri ve Google'ın Material Design 3 rehberi, iki platformun kullanıcıdan beklediği davranışı tarif eder. Bunlar zevk meselesi değil, kullanıcının kas hafızasıdır. Android'de sistemin geri hareketi her ekranda tutarlı çalışmalıdır; iOS kullanıcısı ekranın sol kenarından kaydırarak geri dönmeyi bekler. Sekme çubuğu, uyarı pencereleri ve paylaşım menüleri de iki platformda farklı yerlerde ve farklı biçimlerde durur.

İki tasarım dili de yakın zamanda yenilendi. Apple 2025'te tanıttığı Liquid Glass görsel diliyle iOS 26'nın görünümünü değiştirdi, Google da Material 3'ü "Expressive" güncellemesiyle genişletti. Kurumsal renklerinizi ve yazı karakterinizi korurken bu dillere saygı göstermek, uygulamanın "paketlenmiş bir web sitesi" gibi durmamasını sağlar.

Bu ifadeyi boşuna kullanmadık. App Store İnceleme Kuralları'nın 4.2 numaralı maddesi, yeniden paketlenmiş bir web sitesinin ötesine geçmeyen uygulamaları açıkça geri çeviriyor. Mağaza, uygulamaya özgü bir işlev ve deneyim bekliyor.

Erişilebilirlik de tasarımın parçasıdır. Dokunma alanları için Apple en az 44x44 punto, Material en az 48x48 dp öneriyor. Kullanıcı yazı boyutunu büyüttüğünde (iOS'ta Dynamic Type) ekranlar dağılmamalı, VoiceOver ve TalkBack ekran okuyucuları her düğmenin ne işe yaradığını okuyabilmeli, koyu mod baştan düşünülmüş olmalı.

Arka uç, API ve bildirimler

Kullanıcının gördüğü uygulama işin görünen kısmıdır. Arkasında kimlik doğrulama, veri, ödeme, bildirim ve yönetim paneli için bir arka uç çalışır. Bu, kendi yazdığınız bir API olabileceği gibi Firebase ya da Supabase gibi bir hizmet de olabilir. Hazır hizmetler başlangıcı hızlandırır, ama veri modeliniz ve maliyet yapınız o hizmetin kurallarına bağlanır.

Mobilde web'den farklı bir gerçek var: eski sürümler sahada aylarca yaşar, çünkü kullanıcıların bir kısmı otomatik güncellemeyi kapatmıştır. Bu yüzden API sürümlü tasarlanmalı, eski uygulama sürümleri bir süre daha desteklenmeli ve "bu sürüm artık desteklenmiyor, lütfen güncelleyin" diyebilen bir zorunlu güncelleme mekanizması ilk sürümden itibaren uygulamada bulunmalıdır.

Giriş yöntemlerinde de bir mağaza kuralı var. Apple'ın 4.8 numaralı kuralı, ana hesap için Google ya da Facebook gibi üçüncü taraf bir giriş sunan uygulamalardan, veri toplamayı ad ve e-postayla sınırlayan ve e-postayı gizleme imkânı veren eşdeğer bir seçenek de istiyor. Sign in with Apple bu şartı karşılar. Yalnızca kendi hesap sisteminizi kullanıyorsanız bu şart doğmaz.

Bildirimler

iOS'ta bildirimler Apple Push Notification service (APNs) üzerinden, Android'de çoğunlukla Firebase Cloud Messaging (FCM) üzerinden gider; FCM, iOS cihazlara da APNs aracılığıyla teslim edebilir. Her iki platformda da kullanıcının izni gerekir. Android 13'ten (API 33) beri bildirimler POST_NOTIFICATIONS adlı bir çalışma zamanı iznine bağlıdır ve yeni yüklenen uygulamalarda kullanıcı izin verene kadar kapalı kalır.

Bu yüzden izni ilk açılışta değil, kullanıcının faydasını gördüğü anda isteyin. "Siparişiniz yola çıktığında haber verelim mi?" sorusu, uygulama açılır açılmaz beliren bir sistem penceresinden çok daha fazla onay alır. Bildirimlerin sıklığını, konusunu ve hangi ekrana açılacağını (derin bağlantı) baştan planlayın. Türkiye'de Google servisleri bulunmayan Huawei cihazlar da kullanılıyor; bu kullanıcılara ulaşmak için AppGallery ve Huawei'nin kendi bildirim servisi ayrı bir iş kalemidir.

Gizlilik: etiketler, Veri Güvenliği formu ve hesap silme

İki mağaza da uygulamanın hangi veriyi topladığını kullanıcıya göstermenizi istiyor. Apple'da bu, App Store Connect'te doldurulan "App Privacy" bölümüdür ve mağaza sayfasında gizlilik etiketleri olarak görünür. Google Play'deki karşılığı, Play Console'daki Veri Güvenliği (Data safety) formudur. İkisinde de yalnızca kendi kodunuzun değil, uygulamaya eklediğiniz analitik, reklam, çökme raporlama ve ödeme SDK'larının topladığı veriler de beyan edilir.

Apple ayrıca belirli sistem API'lerini kullanan uygulamalardan ve yaygın üçüncü taraf SDK'lardan bir gizlilik manifestosu (privacy manifest) istiyor; her SDK kendi manifestosunu taşımalı. Kullanıcıyı başka şirketlerin uygulama ve sitelerinde takip edecekseniz App Tracking Transparency izni de gerekir.

Hesap silme iki mağazanın ortak şartıdır. Uygulamada hesap açılabiliyorsa Apple, hesabın uygulamanın içinden silinebilmesini istiyor. Google Play buna ek olarak, kullanıcının uygulamayı yeniden yüklemeden hesabını ve verilerini silme talebinde bulunabileceği bir web bağlantısını Veri Güvenliği formunda görmek istiyor.

Son olarak yaş derecelendirmesi. Apple 2025'te yaş kategorilerini yeniledi: 12+ ve 17+ kalktı, yerlerine 13+, 16+ ve 18+ geldi ve App Store Connect'teki yeni yaş derecelendirmesi sorularının yanıtlanması gerekiyor. Google Play'de derecelendirme IARC anketiyle yapılır. Çocuklara yönelik uygulamalar için iki mağazanın da ayrı ve sıkı kuralları var.

Mağaza yayın süreci: App Store ve Google Play

Geliştirici hesapları

Hesapları ajansın değil, şirketinizin adına açın. Apple Developer Program'a kurum olarak katılmak için tüzel kişiliğiniz, alan adınızla eşleşen bir web siteniz ve D-U-N-S numaranız olmalı; Google Play de yeni kurum hesaplarından D-U-N-S numarası istiyor. Numaranın alınması ya da kayıt bilgilerinin güncellenmesi zaman alabildiği için bu işi geliştirme başlarken yapın, yayın haftasına bırakmayın.

App Store

Test sürümleri TestFlight ile dağıtılır: en fazla yüz iç test kullanıcısı ve on bin dış test kullanıcısı, her derleme doksan gün geçerli. Dış teste giden ilk derleme kısa bir incelemeden geçer.

Apple, başvuruların en az yarısını yirmi dört saatten, yüzde doksanını kırk sekiz saatten kısa sürede incelediğini söylüyor; eksik başvurular daha uzun sürüyor ya da geri çevriliyor. Yine Apple'ın açıklamasına göre çözülemeyen sorunların yüzde kırkından fazlası 2.1 numaralı uygulama bütünlüğü kuralıyla ilgili: çöken ekranlar, yer tutucu içerik, çalışmayan bağlantılar, demo hesabı bırakılmamış giriş ekranları. App Review Information alanına çalışan bir demo hesabı ve gerekli notları yazmak, alabileceğiniz en ucuz önlemdir.

Onaydan sonra güncellemeleri aşamalı yayınlayabilirsiniz. Apple'ın aşamalı yayını yedi güne yayılır ve otomatik güncellemesi açık kullanıcıların sırasıyla yüzde 1, 2, 5, 10, 20, 50 ve 100'üne ulaşır; toplamda otuz güne kadar duraklatılabilir. Bir teknik şartı da hatırlatalım: 28 Nisan 2026'dan beri App Store Connect'e yüklenen uygulamaların Xcode 26 ve iOS 26 SDK ile derlenmesi gerekiyor. Apple bu çıtayı her yıl yükseltiyor.

Google Play

Play Console'da dört kanal vardır: iç test, kapalı test, açık test ve üretim. 13 Kasım 2023'ten sonra açılan kişisel geliştirici hesapları için ek bir şart var: üretime çıkmadan önce en az on iki test kullanıcısının en az on dört gün kesintisiz katıldığı bir kapalı test yapılmalı.

Ardından panodan üretim erişimi için başvurulur; Google bu incelemenin genellikle yedi gün ya da daha kısa sürdüğünü belirtiyor. Kurum hesaplarında bu şart yok, ama D-U-N-S süreci var. Takviminizi hangi hesap türünü kullandığınıza göre kurun.

Google'ın hedef API düzeyi şartı da her yıl yükselir. 31 Ağustos 2026'dan itibaren yeni uygulamalar ve güncellemeler Android 16'yı (API 36) hedeflemek zorunda. Güncellemeleri aşamalı dağıtabilir, bir sorun görürseniz dağıtımı durdurabilirsiniz; aşamalı dağıtım ilk yayında değil, yalnızca güncellemelerde çalışır. Play Console'un ön lansman raporu da uygulamanızı yayından önce gerçek cihazlarda kendiliğinden dener. Bu rapor çoğu zaman ilk çökme listenizdir.

Mağaza sayfasını da son güne bırakmayın. Uygulama adı, kısa açıklama, ekran görüntüleri ve arama için seçilen anahtar kelimeler, uygulamanın mağaza içinde bulunup bulunmayacağını belirler. Uygulama birden fazla dilde yayımlanacaksa, bu metinler her dil için ayrı ve o dilin okuruna göre hazırlanmalıdır.

Uygulama içi satın alma ve mağaza kuralları

Gelir modeliniz uygulama içinde dijital bir şey satmaksa, mağaza kuralları iş modelinizin parçası demektir. Apple'ın 3.1.1 numaralı kuralına göre uygulama içinde özellik ya da içerik kilidi açıyorsanız (abonelik, premium içerik, oyun içi para birimi) uygulama içi satın alma kullanmanız gerekir. Uygulama dışında tüketilen fiziksel ürün ve hizmetlerde ise tersi geçerlidir: kargoyla gelen bir ürün ya da bir kuaför randevusu için uygulama içi satın alma değil, kart ya da Apple Pay gibi yöntemler kullanılır. Google Play'in ödeme politikası da dijital ürünler için Google Play Faturalandırma sistemini esas alır.

Kurallar bölgeden bölgeye değişiyor. ABD vitrininde Apple, 2025'teki mahkeme kararının ardından uygulamaların harici satın alma bağlantıları ve düğmeleri göstermesine izin veriyor. Avrupa Birliği'nde Dijital Piyasalar Yasası (DMA) kapsamında alternatif uygulama pazarları, web üzerinden dağıtım ve alternatif ödeme ya da dış bağlantı seçenekleri açıldı; Google da Avrupa Ekonomik Alanı için alternatif faturalandırma ve dış teklif programları yürütüyor. Bu seçeneklerin her birinin kendi sözleşme ve komisyon koşulları var ve son iki yılda birkaç kez değişti. Avrupa'ya satış yapacaksanız karar vermeden önce iki mağazanın güncel AB koşullarını okuyun ve hukuk danışmanınızla değerlendirin.

Teknik tarafta üç şeyi atlamayın. Geri yüklenebilir satın alımlar için bir "satın alımları geri yükle" düğmesi koyun; Apple'ın kurallarında bu açıkça yazıyor. Satın alma doğrulamasını cihazda değil sunucuda, App Store Server API ve Google Play Developer API ile yapın. Aboneliğin yenileme, iptal, iade ve ödeme sorunu gibi aşamalarını mağazaların sunucu bildirimleriyle takip edin; RevenueCat gibi araçlar bu işin bir kısmını üstlenebilir.

Sürüm yönetimi, çökme raporlama, analitik ve bakım

Sürüm yönetimi

Her yayının iki numarası vardır: kullanıcının gördüğü sürüm numarası (örneğin 2.4.0) ve mağazanın her yüklemede artmasını beklediği derleme numarası. Örneğin iki haftada bir yayın gibi düzenli bir ritim, seyrek ve büyük sürümlerden daha güvenlidir. Yarım kalan özellikleri özellik bayraklarıyla (feature flag) gizlemek, yayın takvimini özelliklerden bağımsız kılar.

React Native ve Expo kullanan ekipler, JavaScript katmanındaki düzeltmeleri mağaza incelemesini beklemeden havadan (OTA) gönderebilir. İyi bir araç, ama sınırı var: Apple'ın 2.5.2 numaralı kuralı, uygulamanın özelliklerini ya da işlevini değiştiren kodun sonradan indirilip çalıştırılmasına izin vermiyor. Hata düzeltmesi evet; yeni ekran ve yeni özellik ise mağaza sürümüyle.

Çökme raporlama ve analitik

Firebase Crashlytics ya da Sentry gibi bir çökme raporlama aracı yayından önce kurulmalı, sonra değil. Google Play'in Android vitals panosu da önemli bir hakemdir. Kullanıcının fark ettiği çökme oranı genelde yüzde 1,09'u, uygulamanın yanıt vermemesi (ANR) oranı yüzde 0,47'yi aşarsa ya da bu oranlardan biri herhangi bir telefon modelinde yüzde 8'in üstüne çıkarsa, Google uygulamanın mağazadaki görünürlüğünü azaltabiliyor. iOS tarafında Xcode Organizer çökme ve enerji raporları sunar.

Analitikte en sık yapılan hata "her şeyi ölçelim" diye başlamaktır. Önce kısa bir ölçüm planı yazın: kullanıcı kaydı tamamlıyor mu, ilk siparişe kaç adımda ulaşıyor, nerede vazgeçiyor? Avrupa'daki kullanıcılar için analitik ve reklam SDK'larının rıza gerektirebileceğini de hesaba katın.

Bakım ve işletim sistemi güncellemeleri

Apple her yıl haziranda WWDC'de yeni iOS sürümünü duyurur ve sürüm genellikle eylülde çıkar. Google da her yıl yeni bir Android sürümü yayımlar ve hedef API şartını yükseltir. Yani yayındaki bir uygulama, hiçbir yeni özellik eklemeseniz bile her yıl en az bir uyum güncellemesi ister: yeni SDK ile derleme, değişen izin modelleri, kaldırılan API'ler, yeni ekran boyutları.

Bakım anlaşmasında bunu açıkça yazın. Beta sürümlerle testi yaz aylarında kim yapacak, kütüphane güncellemeleri hangi sıklıkla geçilecek, mağaza politikası değiştiğinde kim takip edecek? Yıllarca güncellenmeyen uygulamalar önce yeni cihazlarda bozulur, sonra mağazada görünürlüğünü kaybeder.

Nereden başlamalı?

1. Uygulamanın kullanıcıya hangi işi, ne sıklıkla yaptıracağını bir sayfaya yazın.
2. Apple ve Google geliştirici hesaplarını şirketiniz adına açın, D-U-N-S işlemini hemen başlatın.
3. Teknolojiyi, beş yıl sonra kodu kimin bakacağını da düşünerek seçin.
4. Tasarımı iki platformun kurallarına göre yaptırın ve tıklanabilir prototipi gerçek kullanıcılara denetin.
5. API'yi sürümlü kurun, zorunlu güncelleme mekanizmasını ilk sürüme koyun.
6. SDK envanterini çıkarın; gizlilik etiketlerini, Veri Güvenliği formunu ve aydınlatma metnini buna göre hazırlayın.
7. Kişisel bir Google Play hesabıyla yayınlayacaksanız on dört günlük kapalı testi takvime yerleştirin.
8. Çökme raporlamayı ve ölçüm planını yayından önce kurun.
9. Yıllık işletim sistemi uyumunu da kapsayan bakım anlaşmasını yayından önce yapın.

AYTE Digital olarak mobil uygulamaları keşiften mağaza yayınına ve sonrasındaki bakıma kadar yürütüyor, hesapları ve kaynak kodu müşterinin adına açıyoruz. Yolun başındaysanız fikrinizi bu aşamalar üzerinden birlikte geçip hangi teknolojinin ve hangi yayın takviminin size uyduğunu konuşabiliriz.