# Mobil Uygulama Nasıl Yaptırılır? Google Play ve App Store Süreci

> Mağaza hesapları, kimlik doğrulama süreleri, native ve cross-platform farkı, gerçek maliyet aralıkları, yayın reddi sebepleri ve güncelleme süreci.

- Kanonik URL: https://algoritmaajans.com/tr/blog/mobil-uygulama-nasil-yaptirilir
- Dil: tr
- Kategori: Yazılım
- Yayın: 2026-08-29
- Güncelleme: 2026-08-30
- Yayıncı: Algoritma Ajans

---

Kısa cevap: Mobil uygulama yaptırmak için önce **iki mağaza hesabı** açmanız gerekiyor — Google Play Console için **25 dolar tek seferlik**, Apple Developer Program için **yıllık 99 dolar**. Hesaplar açılırken kimlik/şirket doğrulaması yapılıyor ve bu adım tek başına 1–3 hafta sürebiliyor. Geliştirme tarafında basit bir uygulama 8–12 hafta, orta karmaşıklıkta bir uygulama 16–24 hafta alıyor. Türkiye'de 2026 itibarıyla maliyetler kabaca **150.000 TL'den başlayıp 800.000 TL ve üzerine** çıkıyor. Yayın incelemesi Apple'da genelde 24–48 saat, Google'da birkaç saatten birkaç güne kadar sürüyor — ama ilk yayında iki mağazanın da sürpriz kuralları var.

Bu yazıyı iki uygulamayı mağazalara çıkardıktan sonra yazdım. Asıl zorluğun kod yazmak olmadığını, sürecin idari kısmında takıldığımızı söyleyerek başlayayım. Aşağıda hangi adımın gerçekten ne kadar sürdüğünü ve neyin reddedildiğini anlattım.

![Uygulama yayın sürecinin zaman çizelgesi: hesap açılışı, kimlik doğrulama, geliştirme, kapalı test, inceleme, yayın — her adımın gerçekçi süresi](/images/blog/mobil-uygulama-yaptirma-inline-1.jpg)

## Önce sorun: gerçekten uygulama mı gerekiyor?

En dürüst tavsiyeyle başlayayım: **çoğu işletmenin mobil uygulamaya ihtiyacı yok.**

Uygulama, kullanıcıdan indirme adımını istiyor. Bu adım büyük bir eleme. Mobil uyumlu bir web sitesi bağlantıya tıklayan herkese açılıyor; uygulama ise yalnızca indirmeye ikna ettiklerinize. İşiniz yılda iki kez temas edilen bir hizmetse, uygulama boş yere geliştirilmiş olur.

Uygulamanın gerçekten kazandırdığı durumlar dar ve belli:

- **Tekrar eden kullanım** var (haftada birkaç kez açılıyor)
- **Bildirim** işin merkezinde (sipariş durumu, randevu, kampanya)
- **Çevrimdışı çalışma** gerekiyor (saha ekibi, depo, kurye)
- **Cihaz özelliği** kullanılıyor (kamera/barkod, konum, NFC)
- **Sadakat/üyelik** programı var

Bunlardan ikisi bile yoksa, aynı bütçeyi siteye ve reklama koymak daha çok iş getirir. Web ile uygulama arasındaki bütçe karşılaştırmasını [web sitesi fiyatları yazısında](/tr/blog/web-sitesi-fiyatlari-neye-gore-degisir) ayrıca ele aldım.

## Mağaza hesapları: gerçek süreler

### Google Play Console

- **Ücret:** 25 dolar, **tek seferlik**
- **Hesap türü:** kişisel veya kuruluş. Kuruluş hesabı için **D-U-N-S numarası** isteniyor
- **Kimlik doğrulama:** kimlik belgesi ve adres doğrulaması. Genelde birkaç gün, bazen daha uzun

Burada çoğu kişinin bilmediği bir kural var ve takvimi doğrudan etkiliyor: **kişisel geliştirici hesabıyla açılan yeni hesaplar, üretime (production) çıkmadan önce kapalı test yapmak zorunda.** En az **12 test kullanıcısının**, **kesintisiz 14 gün** boyunca teste dahil olması gerekiyor. Yani uygulamanız hazır olsa bile mağazada yayınlanması için en az iki hafta daha beklemeniz gerekiyor.

Bunu bilmeden takvim veren ekipler müşterilerine iki hafta gecikme açıklamak zorunda kalıyor. Kuruluş hesabıyla açarsanız bu kural uygulanmıyor — bu tek başına kuruluş hesabı açmak için yeterli sebep.

### Apple Developer Program

- **Ücret:** yılda 99 dolar, **her yıl yenileniyor**
- **Bireysel kayıt:** Apple Kimliği ve kimlik doğrulamasıyla, görece hızlı
- **Kuruluş kaydı:** **D-U-N-S numarası zorunlu.** Numaranız yoksa Dun & Bradstreet'ten ücretsiz alınıyor ama **5 iş gününden birkaç haftaya** kadar sürebiliyor. Şirket bilgilerinizin resmî kayıtlarla birebir aynı olması gerekiyor; unvanda bir kelime farkı bile süreci uzatıyor
- Kuruluş kaydında Apple ayrıca yetkili kişiyi telefonla arayıp doğrulayabiliyor

**En sık düşülen hata burada:** D-U-N-S başvurusunu proje bittikten sonra yapmak. Bunu **projenin ilk haftasında** başlatın; kod yazılırken paralel ilerlesin.

İki mağaza için de vergi bilgileri, banka hesabı ve dağıtım sözleşmelerinin onaylanması gerekiyor. Ücretli uygulama satacaksanız ya da uygulama içi satın alma kullanacaksanız bu adımlar tamamlanmadan gelir tahsil edemiyorsunuz. Ayrıca Avrupa Birliği'ne dağıtım yapacaksanız Apple tarafında **tacir (trader) bilgisi** girmeniz gerekiyor; eksikse uygulamanız AB ülkelerinde görünmüyor.

## Native mi, cross-platform mı?

| | Native (Swift / Kotlin) | Cross-platform (React Native / Flutter) |
|---|---|---|
| Kod tabanı | iOS ve Android ayrı | Tek kod, iki platform |
| Maliyet | Yüksek (iki ekip) | Belirgin şekilde düşük |
| Performans | En iyi | Çoğu uygulama için yeterli |
| Cihaz özelliğine erişim | Anında ve tam | Çoğu var, yenilerde gecikme olabilir |
| Arayüzün platforma uyumu | Doğal | İyi ama fark edilebilir |
| Ekip bulmak | Zor ve pahalı | Kolay |
| Kime uygun | Oyun, ağır grafik, kamera/AR | İş uygulamaları, katalog, sipariş, panel |

İşletme uygulamalarının çoğu için **cross-platform doğru cevap.** Tek kod tabanı hem ilk maliyeti hem bakım maliyetini yarıya yakın düşürüyor. Native'e ihtiyaç duyduğunuz yer, cihazın donanımını sınırda kullandığınız senaryolar.

Bir de üçüncü yol var: mevcut web sitenizi uygulama kabuğuna koymak. Ucuz görünüyor ama dikkat — Apple, yalnızca web sitesini gösteren, uygulamaya özgü hiçbir değer katmayan gönderimleri **minimum işlevsellik** gerekçesiyle reddediyor. Bu yolu seçecekseniz en azından bildirim, çevrimdışı kullanım ve cihaz özelliklerini gerçekten kullanın.

## Maliyet ve süre

| Kapsam | Süre | Maliyet aralığı (2026) |
|---|---|---|
| Basit (katalog, içerik, 5–8 ekran) | 8–12 hafta | 150.000–350.000 TL |
| Orta (üyelik, bildirim, ödeme, panel) | 16–24 hafta | 350.000–800.000 TL |
| Karmaşık (gerçek zamanlı, harita, çok rollü) | 24 hafta+ | 800.000 TL+ |

Buna eklenecekler: mağaza hesap ücretleri, sunucu/altyapı gideri, bildirim servisi, yıllık bakım. **Bakımı hafife almayın** — kaba bir ölçü olarak geliştirme bedelinin yıllık %15–25'i. Bakım isteğe bağlı da değil: iki mağaza da uygulamanızın güncel platform sürümlerini hedeflemesini istiyor. Google Play, hedeflenen Android API seviyesi eskidiğinde uygulamayı yeni kullanıcılara kapatıyor. Yani "bir kez yaptırdım, bitti" diye bir şey yok; güncellenmeyen uygulama bir–iki yıl içinde mağazadan düşüyor.

> Rakamlar 2026 ortasındaki teklif aralıklarını yansıtıyor ve kurla birlikte hızla değişiyor. Mağaza ücretleri dolar bazlı olduğu için TL karşılığı da oynuyor.

![App Store ve Google Play'in en sık ret gerekçeleri, karşılarında düzeltme yöntemiyle birlikte bir tablo](/images/blog/mobil-uygulama-yaptirma-inline-2.jpg)

## Yayın neden reddediliyor?

En sık karşılaşılan gerekçeler ve nasıl önleneceği:

**Eksik veya çalışmayan uygulama.** İnceleyen kişi uygulamayı gerçekten açıp deniyor. Çöken ekran, boş sayfa, "yakında" yazan bölüm ret sebebi. Gönderimden önce temiz bir cihazda baştan sona test edin.

**Test hesabı verilmemesi.** Uygulamanız girişle açılıyorsa, inceleme notlarına **çalışan bir test hesabı** bırakın. Bunu unutmak, tek başına en yaygın gecikme sebebi. Doğrulama kodu (OTP) ile giriş varsa incelemeciye alternatif bir yol sunun.

**Yetersiz işlevsellik.** Yalnızca web sitesini gösteren, birkaç sayfadan ibaret uygulamalar reddediliyor.

**Gizlilik ve veri beyanı uyuşmazlığı.** Apple'da uygulama gizlilik etiketleri, Google'da **Veri Güvenliği formu** var. Beyan ettiğiniz veri toplama ile uygulamanın gerçekte yaptığı iş uyuşmuyorsa ret geliyor. Reklam/analitik kütüphanelerinin topladığı veriyi de beyan etmeniz gerekiyor — çoğu ekip bunu atlıyor.

**Gizlilik politikası bağlantısının olmaması.** İki mağaza da erişilebilir bir gizlilik politikası URL'si istiyor.

**Hesap silme seçeneğinin bulunmaması.** Uygulama içinde hesap açılabiliyorsa, **hesabın uygulama içinden silinebilmesi** gerekiyor. Görece yeni bir kural ve çok sayıda gönderim buradan dönüyor.

**İzin gerekçelerinin açıklanmaması.** Kamera, konum, rehber gibi izinleri isterken neden istediğinizi açıklayan metni yazmadıysanız ret alırsınız.

**Yanıltıcı mağaza bilgisi.** Ekran görüntüleri uygulamayla uyuşmuyorsa, açıklamada olmayan özellik anlatılıyorsa sorun çıkıyor.

**Uygulama içi satın almayı atlatmak.** Dijital içerik satıyorsanız mağazanın ödeme sistemini kullanmanız isteniyor. Fiziksel ürün ve hizmet satışında bu kural uygulanmıyor.

İyi haber: ret dünyanın sonu değil. Gerekçe açık yazılıyor, düzeltip yeniden gönderiyorsunuz ve yeniden inceleme genelde ilkinden hızlı sonuçlanıyor.

## Adım adım süreç

1. **İhtiyacı netleştirin.** Uygulamanın çözeceği tek bir işi yazın.
2. **D-U-N-S başvurusunu hemen yapın.** Kuruluş hesabı açacaksanız ilk gün.
3. **Mağaza hesaplarını açın**, kimlik doğrulamasını başlatın.
4. **Ekranları tasarlayın**, geliştirmeden önce onaylayın.
5. **Geliştirme** — iki haftada bir çalışan sürüm görün, sonunda tek seferde teslim beklemeyin.
6. **Dahili test:** Apple'da TestFlight, Google'da dahili test kanalı.
7. **Kapalı test:** Google'ın 12 kullanıcı / 14 gün kuralı için zamanında başlatın.
8. **Mağaza sayfasını hazırlayın:** ikon, ekran görüntüleri, açıklama, anahtar kelimeler, yaş derecelendirmesi, gizlilik beyanı.
9. **Gönderin.** İnceleme notlarına test hesabı ekleyin.
10. **Kademeli yayın.** Google'da aşamalı dağıtımla %10'dan başlayın; sorun çıkarsa durdurun.
11. **Güncelleme planı kurun.** En azından yılda birkaç sürüm.

## Sözleşmede mutlaka olması gerekenler

Uygulama geliştirmede web'e göre daha fazla şeyin el değiştirmesi gerekiyor. Bunları yazılı hale getirin:

**Mağaza hesapları sizin adınıza açılsın.** Bu maddeyi en başa koyuyorum çünkü en pahalı hata bu. Uygulama, geliştirici ajansın hesabında yayınlanırsa yollarınız ayrıldığında uygulamayı taşımak Apple/Google'ın onayına bağlı, zahmetli bir süreç oluyor; bazı durumlarda indirme ve yorum geçmişini kaybediyorsunuz. Hesap sizin, ajans sizin hesabınıza yetkilendirilmiş kullanıcı olsun.

**İmzalama anahtarları teslim edilsin.** Android tarafında uygulama imzalama anahtarını kaybederseniz aynı uygulamayı güncelleyemezsiniz — yeni bir uygulama olarak yayınlamak zorunda kalırsınız ve mevcut kullanıcılarınız güncellemeyi hiç görmez. Anahtarların yedeği sizde olsun.

**Kaynak kod deposu erişimi.** Teslimde kod deposuna erişiminiz olsun, sadece derlenmiş dosya değil.

**Sunucu tarafı da kapsamda mı?** Uygulama bir sunucuyla konuşuyorsa o sunucunun kodu, barındırma hesabı ve verinin sahipliği de yazılı olsun.

**Teslim sonrası hata düzeltme süresi.** 30–90 gün makul.

**Mağaza reddi durumunda ne olacak?** Reddin düzeltilmesi kapsam içinde mi, ek ücret mi? Bunu baştan netleştirin.

**Üçüncü taraf servis maliyetleri.** Bildirim servisi, harita, analitik — kimin hesabından, kimin ödemesiyle?

## Yayından sonra ne oluyor?

Uygulamanın yayınlanması bitiş değil, başlangıç. Yayından sonraki üç ay için plan yapın.

**İndirme kendiliğinden gelmiyor.** Mağazada olmak, bulunmak demek değil. Kullanıcıyı uygulamaya yönlendiren şey genelde sizin kendi kanallarınız oluyor: web siteniz, faturanız, mağaza içi yönlendirme, mesajlaşma. Mevcut müşterilerinize duyuru yaparken ticari ileti kurallarına dikkat edin — bu konuyu [WhatsApp toplu mesaj yazısında](/tr/blog/whatsapp-toplu-mesaj-nasil-gonderilir) anlattım.

**Mağaza sayfası bir açılış sayfasıdır.** Başlık, ilk iki ekran görüntüsü ve açıklamanın ilk satırı indirme oranını doğrudan etkiliyor. Ekran görüntülerine kısa açıklama metinleri ekleyin; boş arayüz fotoğrafı iş görmüyor.

**Yorumlara cevap verin.** İki mağazada da yorumlara yanıt verebiliyorsunuz. Düşük puanlı yorumun altına verilen makul bir cevap, çoğu zaman puanın yükseltilmesiyle sonuçlanıyor.

**Çökme oranını izleyin.** Her iki konsol da çökme ve yanıt vermeme oranını raporluyor. Bu oranlar belirli eşikleri aşarsa mağaza uygulamanızı öne çıkarmayı bırakıyor.

**Bildirimi ölçülü kullanın.** Uygulama silinmesinin bir numaralı sebebi gereksiz bildirim. Ayarlardan bildirim türlerini kullanıcının seçebilmesini sağlayın.

**Güncelleme takvimi kurun.** Yılda en az iki–üç sürüm çıkarın. Uzun süre güncellenmeyen uygulama hem kullanıcı gözünde terk edilmiş görünüyor hem de platform gereklilikleri yüzünden risk altına giriyor.

## Sık yapılan hatalar

**Mağaza hesaplarını sona bırakmak.** Doğrulama süreleri geliştirmeden bağımsız işliyor; paralel başlatın.

**Google'ın 12 kullanıcı / 14 gün kuralını hesaba katmamak.** Lansman tarihinizi iki hafta kaydırır.

**Test hesabı bırakmamak.** Bir gün kaybettiren en kolay önlenebilir hata.

**Tek platformla başlayıp diğerini "sonra" demek.** Cross-platform seçtiyseniz ikisini birlikte çıkarın; sonradan eklemek yeni test ve yeni ret riski demek.

**Bildirim iznini ilk açılışta istemek.** Kullanıcı neden gerektiğini bilmeden reddediyor ve bir daha sormak zorlaşıyor. İzni, faydası ortaya çıktığı anda isteyin.

**Bakım bütçesi ayırmamak.** Güncellenmeyen uygulama mağazadan düşüyor.

**Uygulamayı sitenin kopyası yapmak.** Hem reddediliyor hem kimse indirmiyor.

**Her şeyi ilk sürüme sığdırmaya çalışmak.** İlk sürüm tek bir işi iyi yapsın. Kapsamı şişen projeler hem geç çıkıyor hem de kullanılmayan özelliklerin bakımını yıllarca ödüyorsunuz. Kullanıcının gerçekte ne yaptığını yayından sonra ölçüp ona göre eklemek çok daha ucuz.

**Analitik kurmadan yayınlamak.** Hangi ekranda kaç kişi düşüyor, nerede vazgeçiliyor — bunu ölçmeden yapılan her geliştirme tahmine dayanıyor.

## Sonuç

Mobil uygulamada zaman kaybettiren şey kod değil; D-U-N-S beklemek, kapalı test süresini doldurmak, veri beyanını düzeltmek ve test hesabı unutmak. Bu dört kalemi baştan takvime koyarsanız süreç öngörülebilir hale geliyor.

Bir de sık atlanan bir gerçek var: uygulama, ancak arkasındaki iş düzgün çalışıyorsa işe yarıyor. Siparişi karşılayamayan bir mutfak, randevuyu tutmayan bir salon, stoğu yanlış gösteren bir depo — uygulama bu sorunları çözmüyor, sadece daha çok kişiye gösteriyor. Uygulamaya başlamadan önce arkadaki sürecin ayakta olduğundan emin olun.

Uygulamanın işinize gerçekten katkı verip vermeyeceğini konuşmak isterseniz [bize yazın](/tr/iletisim) — gerekmiyorsa gerekmediğini söylüyoruz. Daha önce çıkardığımız işleri [projeler sayfasında](/tr/projeler), sunduğumuz kapsamı [hizmetler sayfasında](/tr/hizmetler) bulabilirsiniz. Randevu ve üyelik gibi tekrar eden kullanımın olduğu senaryolarda uygulamanın nasıl konumlandığını [randevu programı yazısında](/tr/blog/randevu-programi-nasil-kurulur) da ele aldım.