Uygulama Reddedildi mi? App Store ve Google Play Red Nedenleri

Ret bildirimi geldiğinde çoğu ekibin ilk refleksi sorunu tahmin edip hemen yeni bir build hazırlamak oluyor. Benim önerim tam tersi: ilk yarım saati mesajı okumaya ayırın. Apple'ın mesajında reddin dayandığı kural numarası (ör. Guideline 2.1 - Performance - App Completeness), inceleme ekibinin gördüğü sorunun kısa açıklaması ve çoğu zaman bir ekran görüntüsü ya da ekran kaydı bulunur. Google Play'in e-postasında ise ihlal edilen politikanın adı, sorunun görüldüğü yer (uygulama, mağaza girişi veya beyan) ve bazen örnek bir ekran yer alır.

Mesajın nerede durduğunu bilmek de iş görür. App Store Connect'te uygulamanızın sayfasındaki App Review bölümünde (eski adıyla Resolution Center) inceleme ekibiyle yazışmanın tamamı durur ve yanıtı da oradan verirsiniz. Play Console'da Politika ve programlar → Politika durumu sayfası, Play Console gelen kutusu ve hesabın e-posta adresi birlikte izlenmeli. Ekipte bu e-postaların kime gittiğini bilmemek sık gördüğümüz bir zaman kaybı: bildirim, hesabı yıllar önce açmış ve artık şirkette olmayan birinin kutusuna düşebiliyor.

İkinci adım reddin türünü ayırmak. Apple'da App Rejected sorunun uygulamanın kendisinde olduğunu söyler ve düzeltme çoğu zaman yeni bir build ister. Metadata Rejected ise sorunun açıklama, ekran görüntüsü, gizlilik bilgisi veya inceleme notu gibi mağaza bilgilerinde olduğunu gösterir; build aynı kalır, bilgiyi düzeltip yanıt verirsiniz. Google Play'de tablo biraz farklı: bir güncelleme reddedilebilir, yayındaki uygulama kaldırılabilir, uygulama askıya alınabilir ya da hesabınız henüz üretim erişimine sahip olmayabilir.

Üçüncü adım, aynı build'i değiştirmeden tekrar göndermemek. Başka bir inceleme uzmanı büyük olasılıkla aynı sonuca varır ve siz birkaç gün daha kaybedersiniz. Google Play'de tek bir güncelleme reddi hesabın durumunu etkilemiyor, ama tekrarlanan redler ve kaldırmalar askıya almaya kadar gidebiliyor.

Ret hatalıysa bunu yazışmayla anlatın. Doğruysa düzeltin ve neyi düzelttiğinizi açıkça yazın.

Ret, kaldırma ve üretim erişimi: hangisiyle karşı karşıyasınız?

Google Play'de ilk uygulamasını yayınlamaya çalışan birçok kişi aslında reddedilmiyor; üretim (production) yayını düğmesine hiç ulaşamıyor. Nedeni, 13 Kasım 2023'ten sonra açılan kişisel geliştirici hesaplarına getirilen test şartı: uygulamayı herkese açmadan önce en az 12 test kullanıcısının, son 14 gün boyunca kesintisiz kapalı teste kayıtlı olması gerekiyor. Şart ilk duyurulduğunda kişi sayısı 20'ydi, sonradan 12'ye indirildi.

Burada sayılan şey uygulamayı indirmek değil, test kanalına kayıt (opt-in) olmak. Google'ın yardım sayfası açık: 14 gün dolmadan testten çıkan kişi sayılmaz; çıkıp yeniden katılan birinin 14 günü de baştan başlar. Pratikte bu, tam 12 kişiyle başlamanın risk olduğu anlamına geliyor. Bir kişi sıkılıp çıkarsa sayaç fiilen sıfırlanır. Kişisel hesapla ilerlemek zorunda kalanlara 15–20 kişiyle başlamalarını öneriyoruz.

14 gün dolduktan sonra Play Console kontrol panelinden üretim erişimi için başvuru yapılır. Başvuruda üç bölümlük bir anket var: kapalı testiniz (test kullanıcılarını bulmak ne kadar kolaydı, özellikleri kullandılar mı, geri bildirimi nasıl topladınız), uygulamanız ve üretime hazırlığınız. Google bu incelemenin genellikle 7 gün veya daha kısa sürdüğünü söylüyor. Anket, test kullanıcılarının özellikleri kullanıp kullanmadığını ve kullanımın üretimdeki beklenen davranışa benzeyip benzemediğini de soruyor. Yani kimsenin açmadığı bir test, sayıyı tutturmuş olsa bile başvuruda geri dönebilir.

Google bu şartı yalnız kişisel hesaplar için tanımlıyor; şirket adına açılan kuruluş (organization) hesapları kapsamda değil. Kuruluş hesabı için D-U-N-S numarası (Dun & Bradstreet'in şirketlere verdiği dokuz haneli kimlik) ve şirket doğrulaması gerekiyor. Numara yoksa başvurusu birkaç günden birkaç haftaya uzayabiliyor, bu yüzden lansman tarihinden geriye doğru planlayın.

Şirket adına uygulama çıkaracaksanız hesabı baştan kuruluş hesabı olarak açmak hem bu engeli hem ileride hesap devri derdini ortadan kaldırır. Bizim mobil uygulama projelerimizde mağaza hesaplarının müşteri adına açılması, kod yazılmadan önce kapanan ilk iş. Hesap açılışını ve yayın sürecini mobil uygulama geliştirme süreci yazımızda da anlatmıştık.

Google Play incelemesi büyük ölçüde beyan ile davranışın karşılaştırılmasına dayanır. Play Console'daki Uygulama içeriği sayfasında doldurduğunuz Veri güvenliği (Data safety) formu, izin beyanları, hedef kitle ve reklam beyanı, uygulamanın gerçekte ne yaptığıyla yan yana konur. En sık gördüğümüz ret bu iki taraf arasındaki açıktan çıkıyor: formda “konum toplanmıyor” yazıyor, ama uygulamaya eklenen bir reklam ya da analitik SDK'sı konum verisi gönderiyor.

İkinci büyük başlık hassas izinler. SMS ve arama kaydı izinleri, arka plan konumu, cihazdaki tüm uygulamaları listeleme (QUERY_ALL_PACKAGES), geniş dosya erişimi ve fotoğraf/video izinleri ayrı beyan ister; Google bu izinleri yalnız uygulamanın ana işlevi gerçekten gerektiriyorsa kabul eder. “Belki ileride lazım olur” diye manifest'te bırakılmış bir izin tek başına ret nedeni olabilir. Çoğu zaman çözüm, izni kaldırıp sistemin sunduğu daha dar seçeneği (ör. fotoğraf seçici) kullanmaktır.

• Kullanıcı verileri / Veri güvenliğiÇoğu zaman yalnız beyanTetikleyici: Form ile SDK'ların gerçek veri akışı uyuşmuyor; gizlilik politikası bağlantısı yok ya da açılmıyor.Çözüm: SDK envanteri çıkarın, formu gerçek akışa göre güncelleyin, politikayı hem uygulamada hem mağaza girişinde erişilebilir kılın.
• İzinlerYeni sürümTetikleyici: SMS, arama kaydı, arka plan konumu, QUERY_ALL_PACKAGES veya geniş medya erişimi ana işlev olmadan isteniyor.Çözüm: Gereksiz izni manifest'ten kaldırın; gerçekten gerekiyorsa beyan formunu ve kullanımı gösteren videoyu hazırlayın.
• Hedef API seviyesiYeni sürümTetikleyici: targetSdkVersion güncel şartın altında kalmış.Çözüm: Derleme ayarlarını yükseltin, yeni Android sürümünün davranış değişikliklerini test edin.
• Hesap silmeYeni sürüm ve beyanTetikleyici: Hesap açılabiliyor ama uygulama içinde silme yok ya da web bağlantısı eksik.Çözüm: Uygulama içi silme akışı ekleyin, web silme sayfasını Veri güvenliği formundaki alana girin.
• Yanıltıcı davranışYeni sürümTetikleyici: Uygulama açıklamada vaat ettiğini yapmıyor, sahte sistem uyarısı gösteriyor veya gizli bir işlev barındırıyor.Çözüm: Açıklamayı gerçek işlevle eşleyin, beyan edilmemiş davranışı kaldırın.
• Meta veriYalnız mağaza girişiTetikleyici: Anahtar kelime doldurma, kanıtsız “en iyi” iddiası, ilgisiz marka adları.Çözüm: Mağaza girişini sadeleştirin, iddiaları kaldırın.
• AilelerÇoğu zaman yeni sürümTetikleyici: Hedef kitlede çocuklar seçili, ama reklam ve SDK'lar aile politikasına uygun değil.Çözüm: Hedef kitleyi gözden geçirin; gerekirse aile programına uygun SDK'lara geçin.
• ÖdemelerYeni sürümTetikleyici: Dijital içerik veya abonelik Google Play Faturalandırma dışında satılıyor.Çözüm: Dijital ürünleri Play Faturalandırma'ya taşıyın; fiziksel ürünler bu kuralın dışında.

Üçüncü başlık takvim. Google Play hedef API seviyesini her yıl yükseltiyor: 31 Ağustos 2026'dan bu yana yeni uygulamaların ve güncellemelerin Android 16'yı (API 36) hedeflemesi gerekiyor; mevcut uygulamaların daha yeni Android sürümlü cihazlarda yeni kullanıcılara görünmeye devam etmesi için de en az Android 15 (API 35) şart. Uzatma isteyen geliştiriciler 1 Kasım 2026'ya kadar süre alabiliyor. Bakımı yapılmayan bir uygulamanın ilk “reddi” çoğu zaman buradan gelir: kodda hiçbir şey değişmemiştir ama güncelleme gönderilemez.

Mağaza girişindeki metinler de ret nedeni olabilir: anahtar kelime doldurma, “1 numaralı” ya da “en iyi” gibi kanıtsız üstünlük iddiaları, başka markaların adları, ekran görüntüsüne gömülmüş kampanya ifadeleri. Bu konuyu sıralama açısından ASO rehberimizde ayrıntılı ele alıyoruz. Burada yalnız şunu söyleyeyim: metadata ihlali yeni build istemez, ama düzeltilene kadar güncelleme yayına çıkmaz.

Apple'ın App Review sayfasına göre çözülmemiş sorunların ortalama %40'tan fazlası 2.1 App Completeness (uygulamanın eksiksizliği) maddesinden çıkıyor: çökme, yer tutucu içerik, eksik bilgi. Aynı sayfa, gönderimlerin en az yarısının 24 saatten, %90'ının 48 saatten kısa sürede incelendiğini söylüyor. İlk rakam bizim gözlemimizle de örtüşüyor. Redlerin büyük kısmı kural yorumundan değil, inceleme ekibinin uygulamayı çalıştıramamasından doğuyor.

Aşağıdaki tablo sahada en sık karşılaştığımız App Store red nedenlerini; her maddenin tipik tetikleyicisini, çözümünü ve yeni build gerekip gerekmediğini gösteriyor. Madde numaraları App Store İnceleme Yönergeleri'nin (App Store Review Guidelines) Ekim 2026'daki hâline göre. Apple yönergeleri yılda birkaç kez güncelliyor, bu yüzden gönderimden önce ilgili maddenin güncel metnine beş dakika ayırın.

Tabloyu okurken şunu akılda tutun: Apple tek bir ret mesajında birden çok madde sayabilir. Hem 2.1 hem 5.1.1 içeren bir mesajda yalnız birini düzeltip göndermek, ikinci turda diğerinden yine ret almak demek. Mesajdaki her madde numarasını ayrı satır olarak listeleyin ve yanıtta her birine ayrı paragrafla cevap verin.

2.1 reddi “uygulamanız kötü” demek değil; “uygulamanızı inceleyemedik ya da incelediğimiz hâli bitmiş değildi” demek. Yönergelerin ifadesi net: gönderim son sürüm olmalı, bağlantılar çalışmalı, giriş gerektiren uygulamada demo hesabı verilmeli ve inceleme süresince backend açık olmalı. Bu dört maddeden biri eksikse inceleme ekibi uygulamanın büyük kısmını göremez ve mesaj 2.1 ile döner.

Türkiye'de geliştirilen uygulamalarda 2.1'in yerel bir versiyonu var ve sık karşılaşıyoruz: inceleme ekibi Türkiye'de değil. Girişte yalnız +90 numaraya SMS doğrulama kodu gönderen, TC kimlik numarası ya da e-Devlet ile kimlik doğrulama isteyen, güvenlik gerekçesiyle backend'e yalnız Türkiye IP'lerinden erişim veren uygulamalar inceleme cihazında ilk ekranda kalıyor ve ekip bunu “giriş yapılamıyor” diye raporluyor. Çözüm; inceleme için sabit doğrulama kodlu bir demo hesabı tanımlamak, coğrafi kısıtta inceleme süresince istisna açmak ya da yasal zorunluluk varsa Apple'ın önceden onayıyla uygulamanın tüm işlevlerini gösteren yerleşik bir demo modu sunmak.

Çökme kaynaklı 2.1 redlerinde Apple çoğu zaman çökme günlüğünü mesaja ekler. Günlüğü Xcode ile sembolize edin (bunun için dSYM dosyalarının arşivde olması gerekir) ve hatayı temiz bir cihazda, uygulamayı ilk kez kuran biri gibi yeniden üretmeye çalışın. Geliştirici cihazında çıkmayan çökmelerin çoğu ilk kurulumdan, izin reddinden, boş veriden ya da farklı dil ve bölge ayarından gelir. TestFlight'ta harici bir test grubuyla tek tur yapmak bu senaryoların çoğunu yakalar.

Gözden kaçan iki madde daha var. Birincisi IPv6: yönergelerin 2.5.5 maddesi uygulamanın yalnız IPv6 kullanan bir ağda da tam çalışmasını ister ve koda gömülmüş IPv4 adresleri burada sorun çıkarır. İkincisi uygulama içi satın alma ürünleri: uygulamada satış varsa IAP ürünlerinin de incelemeye gönderilmiş ve sandbox ortamında satın alınabiliyor olması gerekir; aksi hâlde inceleme ekibi boş bir satın alma ekranı görür.

Yeniden göndermeden önce 2.1 kontrolü

• ✓Demo hesabının kullanıcı adı, şifresi ve gerekiyorsa sabit doğrulama kodu inceleme notunda yazıyor.
• ✓Demo hesabında örnek veri var: boş liste yerine sipariş, mesaj veya kayıt görünüyor.
• ✓Backend, API ve üçüncü taraf servisler inceleme süresince açık; o günlere bakım penceresi planlanmadı.
• ✓Coğrafi IP kısıtı veya WAF kuralı inceleme ekibinin bağlantısını engellemiyor.
• ✓Uygulama temiz kurulumda, izinler reddedildiğinde ve İngilizce cihaz dilinde açılıyor.
• ✓Yer tutucu metin, “yakında” ekranı veya hiçbir yere gitmeyen menü öğesi kalmadı.
• ✓IAP ürünleri incelemeye gönderildi ve sandbox'ta satın alınabiliyor.
• ✓Uygulama yalnız IPv6 kullanan bir ağda denendi (macOS'taki NAT64 test ağı bu iş için yeterli).

Demo account
  Username: review@ornekfirma.com
  Password: ********
  Verification code for this account: 000000 (fixed for App Review)

How to test the main flow
  1. Log in with the demo account above.
  2. Tap "Siparişlerim" (My Orders) to see sample orders.
  3. Open any order and tap "Kargo Takibi" (Shipment Tracking).

Notes
  - The app UI is in Turkish. Main tabs: Ana Sayfa (Home),
    Siparişlerim (My Orders), Hesabım (Account).
  - Account deletion: Hesabım > Hesabı Sil (Account > Delete Account).
  - Our backend is available 24/7 during review and the demo
    account is not subject to regional restrictions.

Teklif görüşmelerinde en sık duyduğum cümlelerden biri şu: “Web sitemiz zaten mobil uyumlu, onu uygulama olarak mağazaya koyalım.” Teknik olarak mümkün; bir WebView (uygulamanın içinde web sayfası gösteren bileşen) siteyi açar, simge de telefonda durur. Ama Apple'ın 4.2 maddesi tam bu senaryoyu hedefler: uygulama, yeniden paketlenmiş bir web sitesinin ötesine geçen özellik, içerik ve arayüz sunmalıdır. 4.2.2 de kataloglar dışında, ağırlıklı olarak pazarlama malzemesi, reklam, web kırpıntısı veya bağlantı koleksiyonu olan uygulamaları kabul etmez.

WebView kullanmak tek başına ret nedeni değil; birçok iyi uygulama bazı ekranlarını web içeriğiyle gösterir. Belirleyici olan, kullanıcının uygulamayı siteye tercih etmesi için bir nedenin olup olmadığı. İnceleme ekibine bu nedeni gösteren özellikler genellikle aşağıdakiler. Hiçbiri yoksa dürüst cevap çoğu zaman bir PWA'dır (Progressive Web App: ana ekrana eklenebilen, bildirim alabilen web uygulaması).

• 1.Anlamlı push bildirimiSipariş durumu, randevu hatırlatma, kargo çıkışı. Kampanya duyurusu tek başına yetmez.
• 2.Çevrimdışı bölümBağlantı yokken de açılan sepet, kayıtlı belgeler, son görüntülenen içerik.
• 3.Kamera ve barkodÜrün okutma, fiş fotoğrafı, belge tarama; web'de zahmetli olan işler.
• 4.Biyometrik girişFace ID veya parmak iziyle hızlı ve güvenli oturum açma.
• 5.Widget ve kısayollarAna ekranda bakiye, sipariş sayısı veya günün randevusu.
• 6.Derin bağlantı ve native gezinmeE-postadaki bağlantının doğrudan ilgili ekranı açması, sistemle uyumlu sekmeler.

4.3 başka bir soruna bakar. 4.3(a) aynı uygulamanın birden çok paket kimliğiyle (Bundle ID) gönderilmesini yasaklar: her şube, şehir veya bayi için ayrı uygulama yerine tek uygulama ve içinde seçim. 4.3(b) ise zaten çok sayıda benzeri olan uygulamaları hedefler. Apple flört, el feneri, ses efekti, duvar kâğıdı, basit zamanlayıcı ve fal kategorilerinde anlamlı biçimde farklı bir deneyim sunmayan yeni gönderimleri kabul etmeyeceğini açıkça yazıyor. İçme oyunları gibi “düşük emekli” saydığı türlerde tekrarlanan gönderimlerin geliştirici programından çıkarılmaya kadar gidebileceğini de ekliyor.

Şablon uygulamaların sorunu 4.2.6 maddesinde: ticari bir şablondan ya da uygulama oluşturma servisinden çıkan uygulamalar, içerik sahibi tarafından doğrudan gönderilmedikçe reddedilir. Yani bir ajansın kendi hesabından, onlarca müşteri için aynı şablonla uygulama göndermesi Apple'ın açıkça kapattığı bir yol. Yönerge şablon sağlayıcılarına iki yol bırakıyor: müşterinin kendi hesabından göndereceği gerçekten özelleştirilmiş uygulama ya da tüm müşterileri tek uygulamada toplayan “seçici” model (her restoranın ayrı sayfası olan bir restoran bulucu gibi). Çok düşük fiyatlı uygulama tekliflerinde bu riskin nasıl saklandığını mobil uygulama yaptırma fiyatları yazımızda anlattık.

WebView kabuğu, PWA ve gerçek uygulama

Mevcut bir web ürününe mobil kanal ekliyorsanız hangi ekranların native, hangilerinin web kalacağını baştan planlamak 4.2 riskini büyük ölçüde ortadan kaldırır. Bu kararı nasıl verdiğimizi web'den mobile geçenler için mobil uygulama sayfamızda anlatıyoruz.

Gizlilik redleri en çok sinir bozan redlerdir, çünkü çoğu zaman uygulama düzgün çalışır; sorun uygulamanın kendini nasıl anlattığındadır. App Store tarafında 5.1.1(i) her uygulamanın hem App Store Connect'teki alanda hem de uygulama içinde kolayca bulunan bir gizlilik politikası bağlantısı taşımasını ister. Politika; hangi verinin nasıl ve neden toplandığını, üçüncü taraflarla paylaşımı, saklama süresini ve kullanıcının veriyi nasıl sildirebileceğini anlatmalıdır. Türkiye'de bu metnin KVKK aydınlatma metniyle aynı belge olması gerekmiyor, ama ikisi birbiriyle çelişmemeli.

İzin redlerinin çoğu amaç metninden (purpose string) gelir. iOS bir izni isterken sizin yazdığınız gerekçe cümlesini gösterir ve 5.1.1(ii) bu cümlenin veri kullanımını açık ve eksiksiz anlatmasını bekler. “Uygulama kameranıza erişmek istiyor” bir gerekçe değil. “Teslimat fişinin fotoğrafını çekip siparişe eklemek için kamerayı kullanırız” bir gerekçe. Uygulamanız Türkçeyse metin de Türkçe olmalı ve izin reddedildiğinde uygulama kilitlenmemeli; kullanıcıya izni sonradan verebileceği bir yol kalmalı.

İzin gerekçe metni: ret alan ve geçen örnekler

• KameraRet alanUygulama kameranıza erişmek istiyor.GeçenTeslimat fişinin fotoğrafını çekip siparişinize eklemek için kamerayı kullanırız.
• Konum (kullanım sırasında)Ret alanDaha iyi hizmet için konumunuz gerekli.GeçenSize en yakın şubeyi ve tahmini teslim süresini göstermek için konumunuzu yalnız uygulama açıkken kullanırız.
• FotoğraflarRet alanFotoğraflarınıza erişim gerekli.GeçenProfil fotoğrafınızı seçmeniz için galeriyi açarız; yalnız seçtiğiniz fotoğraf yüklenir.
• KişilerRet alanKişilerinize erişmemiz gerekiyor.GeçenArkadaşınızı davet etmek için seçtiğiniz kişinin numarasını kullanırız; rehberiniz sunucularımıza yüklenmez.

Hesap silme iki mağazada da zorunlu ve en sık ret nedenlerinden biri. Apple'ın 5.1.1(v) maddesi, hesap oluşturmayı destekleyen her uygulamanın hesabın silinmesini de uygulama içinden sunmasını ister. “Bize e-posta atın, silelim” ya da yalnız hesabı dondurmak bu şartı karşılamaz. Silme işlemi bir web sayfasında tamamlanacaksa uygulama doğrudan o sayfaya götürmeli. Apple telefon, e-posta veya destek sohbetine yönlendirmeyi yalnız bankacılık gibi sıkı düzenlenen sektörlerde ek doğrulama adımı olarak kabul ediyor; otomatik yenilenen aboneliği olan kullanıcıya da faturalamanın Apple üzerinden süreceği hatırlatılmalı. Google Play aynı şeyi ister ve bir adım ileri gider: uygulamayı kaldırmış kullanıcının da hesap ve veri silme talebinde bulunabileceği bir web sayfası, Veri güvenliği formundaki alana girilmelidir. Yasal saklama yükümlülüğü olan veriler (ör. fatura kayıtları) varsa hangilerinin ne kadar saklandığı politikada açıklanır.

Hesap silme: iki mağazanın beklentisi

Takip tarafında Apple'ın 5.1.2 maddesi, kullanıcıyı başka şirketlerin uygulama ve siteleri arasında izlemek için App Tracking Transparency (ATT) izni ister. Reklam SDK'sı ekleyip ATT akışını kurmamak ve App Privacy etiketinde beyan edilmemiş veri toplamak bu başlıktaki redlerin tipik nedenleri. Gizlilik manifestosu (privacy manifest: SDK'nın hangi veriyi neden kullandığını bildiren dosya) olmayan eski bir SDK sürümü ise çoğu zaman inceleme beklenmeden, build yüklenirken App Store Connect'in gönderdiği uyarı e-postasıyla kendini gösterir. Google Play'de karşılığı yine Veri güvenliği formu ve aynı tutarlılık beklentisi.

Bu redlerin arkasında çoğu zaman teknik değil organizasyonel bir boşluk var: pazarlama bir SDK ekliyor, geliştirici beyanı güncellemiyor, politika bir yıl önce yazılmış. Uygulamanın kişisel veri envanterini KVKK tarafındaki çalışmayla birlikte tutmak bu boşluğu kapatıyor; şirket genelinde beklenen tedbirleri KVKK teknik ve idari tedbirler listesi yazımızda madde madde topladık. Sağlık verisi gibi özel nitelikli veri işleyen uygulamalarda kapsam genişliyor; sağlık sektörü için mobil uygulama sayfamızda bu ayrıntılara değiniyoruz.

Ödeme redlerinin mantığı tek bir soruya dayanıyor: satılan şey uygulamanın içinde mi tüketiliyor, dışında mı? Apple'ın 3.1.1 maddesine göre uygulama içindeki bir özellik veya içeriğin kilidini açan her satış (abonelik, oyun içi para, seviye, premium içerik, tam sürüm) uygulama içi satın alma (IAP) ile yapılmalı. Lisans anahtarı ya da QR kodla kilit açmak da bu kuralı aşmanın yolu değil; yönerge bu yöntemleri adıyla sayıyor.

Fiziksel ürün ve uygulamanın dışında tüketilen hizmet ise tam tersine 3.1.3(e) kapsamında: bunlar için IAP kullanılmaz; Apple Pay veya kartla ödeme gibi başka yöntemler kullanılır. Türkiye'de bu, e-ticaret, yemek siparişi, kargo, bilet ve randevu uygulamalarında iyzico, PayTR ya da bankanızın sanal POS altyapısını kullanmanın önünde mağaza açısından bir engel olmadığı anlamına geliyor. Mağaza komisyonu da bu satışlara uygulanmıyor.

Örnek senaryolar

• Premium üyelikle reklamsız kullanım ve ek özelliklerIAP zorunlu
• E-ticaret uygulamasında kargoyla gelen ürüniyzico, PayTR veya sanal POS
• Restoran rezervasyonu ön ödemesiUygulama dışı hizmet: harici ödeme
• Kayıtlı videolardan oluşan online kurs paketiIAP zorunlu
• Birebir canlı özel dersKişiden kişiye hizmet: harici ödeme mümkün
• Uygulama içi jetonla ilan öne çıkarmaIAP zorunlu (dijital özellik)
• Fatura, aidat veya bağış ödemesiDijital içerik değil: harici ödeme

Gri alanlar da var. Gerçek zamanlı, birebir kişiden kişiye hizmetlerde (özel ders, online danışmanlık gibi) Apple başka ödeme yöntemlerine izin veriyor; bire çok canlı yayınlar ise IAP istiyor. Daha önce satın alınmış içeriğe erişim veren “okuyucu” uygulamaları (dergi, müzik, video) 3.1.3(a) kapsamında ayrı kurallara tabi. ABD ve AB gibi bazı mağazalarda son yıllardaki dava ve düzenlemelerle harici ödeme bağlantılarına yönelik istisnalar doğdu. Bunlar mağazaya özgü; Türkiye mağazası için aynı istisnayı varsaymayın ve gönderimden önce 3.1 maddelerinin güncel metnine bakın.

Abonelik redleri genellikle satış ekranından geliyor: fiyat, süre, otomatik yenileme ve iptal bilgisi satın alma düğmesinin yakınında açıkça görünmeli; kullanım koşulları ve gizlilik politikası bağlantıları bulunmalı; ücretsiz deneme varsa deneme bitince ne kadar ücret alınacağı yazmalı. Google Play tarafındaki karşılık Google Play Faturalandırma politikası: dijital ürün ve abonelikler Play'in faturalandırma sistemiyle satılıyor, fiziksel ürünler kapsam dışında. Para hareketi olan uygulamalarda mimari ve güvenlik tarafını fintech ve ödeme uygulamaları sayfamızda anlatıyoruz.

“İtiraz” kelimesi kavgacı bir tonu çağrıştırıyor, ama mağaza yazışmasında işe yarayan şey tam tersi: kısa, nazik, kanıtlı ve doğrulanabilir bir mesaj. İnceleme ekibi günde çok sayıda uygulamaya bakıyor; mesajınızın tek işi, sorunun çözüldüğünü birkaç dakikada görmelerini sağlamak. İyi bir yanıtın dört parçası var: reddi anladığınızı gösteren bir cümle, yaptığınız değişikliklerin madde madde listesi, inceleme ekibinin bunu doğrulayacağı adımlar ve gerekiyorsa demo hesabı ya da ekran kaydı.

Dil konusunda net bir önerim var: uygulama Türkçe olsa bile yanıtı İngilizce yazın. Google'ın yardım sayfasına göre itiraz her dilde gönderilebiliyor, ama yanıt şimdilik yalnız İngilizce, Çince, Japonca ve Korece veriliyor. Apple'la yürüttüğümüz yazışmalar da hep İngilizce oldu. İleri düzey İngilizce gerekmiyor; kısa cümleler ve numaralı adımlar yeterli. Aşağıdaki sihirbaz taslağı bu yüzden İngilizce üretiyor.

Apple'da yanıt App Store Connect'teki App Review mesajlarından verilir. Uygulamanızın yanlış anlaşıldığını ya da kuralın hatalı yorumlandığını düşünüyorsanız App Review Board'a (inceleme kurulu) resmi itiraz açabilirsiniz. Bu, aynı inceleme ekibine tekrar yazmaktan farklı bir kanal. Apple burada uygulamanın yönergelere neden uyduğunu somut gerekçeyle anlatmanızı, reddedilen her gönderim için yalnız bir itiraz yapmanızı ve önce inceleme ekibinin ek bilgi taleplerini yanıtlamanızı istiyor. Kural yorumunu gönderimden önce konuşmak isterseniz Apple'ın 30 dakikalık Webex görüşmeleri (Meet with App Review) de var.

Hata düzeltme güncellemelerinde ayrıca bir kolaylık var. Yayındaki uygulamanın düzeltme sürümünde inceleme ekibi başka bir sorun bulursa ve konu yasal ya da güvenlikle ilgili değilse, Apple bu sorunu bir sonraki gönderimde çözmenizi teklif ediyor. App Store Connect'teki teklif mesajını yanıtlayıp mevcut gönderimin onaylanmasını istemeniz yeterli; acil bir çökme düzeltmesi böylece başka bir maddeye takılıp beklemez.

Google Play'de itiraz, bildirimdeki bağlantıdan veya Politika durumu sayfasından açılan itiraz formuyla yapılır ve her yaptırım için yalnız bir itiraz hakkınız vardır. Bu yüzden formu aceleyle doldurmayın: önce gerçekten ihlal olup olmadığını kontrol edin, varsa düzeltip uyumlu sürümü gönderin; itirazı yalnız kararın hatalı olduğundan eminseniz ve bunu gösterebiliyorsanız kullanın.

Tek bir uygulamanın reddi can sıkar; geliştirici hesabının kapatılması ise işi durdurur. Google Play'in yaptırım sayfası sıralamayı açıkça veriyor: ret hesabın durumunu etkilemiyor, kaldırma hemen etkilemiyor ama tekrarlanırsa askıya almaya dönüşebiliyor, askıya alma ise hesaba ihlal kaydı (strike) olarak işleniyor. Birden çok ihlal kaydı ya da tek bir ağır ihlal hesabın feshine gidebiliyor; fesihte katalogdaki bütün uygulamalar kaldırılıyor ve ilişkili geliştirici hesapları da kalıcı olarak askıya alınıyor. Google ilişkiyi hangi ölçütlerle kurduğunu ayrıntılı açıklamıyor. Apple tarafında da program sözleşmesine aykırı davranış, sahtecilik veya 4.3(b)'de anılan türden tekrarlanan düşük kaliteli gönderimler Apple Developer Program üyeliğinin sona erdirilmesine yol açabiliyor.

Bu senaryonun Türkiye'de en sık görülen biçimi, ajansın veya serbest geliştiricinin müşteri uygulamalarını kendi kişisel hesabından yayınlaması. Hesaptaki başka bir uygulama, örneğin başka bir müşterinin hassas izin kullanan uygulaması sorun çıkardığında sizin uygulamanız da aynı hesapla birlikte risk altına giriyor. Hesap sizin değilse uygulamayı başka bir hesaba taşımak bile tedarikçinin iyi niyetine kalıyor. Tedarikçi seçerken bu konuyu nasıl soracağınızı yazılım firması seçerken dikkat edilmesi gerekenler rehberinde anlattık.

1. 1Hesap şirketin olsunApple Developer ve Play Console hesaplarını şirket tüzel kişiliği adına açın; yönetici e-postası kişiye değil şirkete ait bir adres olsun.
2. 2Şifre değil rol verinTedarikçiye App Store Connect'te Kullanıcılar ve Erişim, Play Console'da Kullanıcılar ve izinler üzerinden yalnız gereken rolü verin.
3. 3SDK'yı içeri almadan inceleyinKaynağını bilmediğiniz reklam veya “gelir artırıcı” kütüphaneler hem politika hem güvenlik riski taşır.
4. 4Bildirimleri kaçırmayınPolitika e-postalarının birden fazla kişiye ulaştığından ve Politika durumu sayfasının düzenli kontrol edildiğinden emin olun.
5. 5İhlal geçmişini kayda alınHer ret ve yaptırımı tarihiyle not edin; tekrarlanan ihlal örüntüsünü erken fark edersiniz.

Askıya alma veya fesih bildirimi geldiyse önce bildirimin gerçekten Google'dan veya Apple'dan geldiğini doğrulayın; “hesabınız kapatılacak” temalı sahte e-postalar da dolaşıyor. Ardından ihlal edilen politikayı ve etkilenen uygulamaları listeleyin. İtirazı hazırlarken uygulamanın neden bu politikayı ihlal etmediğini ya da ihlalin nasıl kalıcı olarak giderildiğini somut kanıtla anlatın. Hesap feshi itirazında acele en büyük düşman.

Yayın öncesi genel kontrol listesini mobil uygulama geliştirme süreci yazımızda verdik; burada tekrar etmeyeceğim. Aşağıdaki liste ret aldıktan sonra, yeniden göndermeden önce bakılacak maddeler. İşaretledikçe yan paneldeki sayaç ilerliyor.

Ret sonrası gönderimde iki alışkanlık işinizi kolaylaştırır. Birincisi aşamalı yayın: App Store'da güncellemeyi kademeli yayınlamak (phased release), Google Play'de yüzdeyle dağıtmak (staged rollout), düzeltmenin canlıda yeni bir sorun yaratmadığını küçük bir kullanıcı grubunda görmenizi sağlar. İkincisi açık sürüm notu: “hata düzeltmeleri ve iyileştirmeler” yerine neyin değiştiğini yazmak hem kullanıcıya hem inceleme ekibine yardımcı olur.

Destek almanın mantıklı olduğu durumlar

• Aynı uygulama 4.3 ile ikinci kez döndüyse
• Hesap askıya alma veya fesih bildirimi geldiyse
• SMS, arka plan konumu veya erişilebilirlik gibi hassas izin beyanı gerektiren bir uygulama yapıyorsanız
• Uygulamada dijital içerik ile fiziksel ürün satışı iç içeyse ve IAP sınırı netleşmiyorsa
• Kişisel hesapta kapalı test şartı lansman tarihinizle çakışıyorsa

Bu durumlarda dışarıdan bir göz zaman kazandırır. W3 olarak mobil yazılım geliştirme projelerimizde mağaza yayınını teslimatın parçası sayıyoruz: demo hesabı, inceleme notu, gizlilik beyanları ve aşamalı yayın planı bizim iş listemizde. Backend'in inceleme sırasında da çalışması gerektiği için API geliştirme tarafını, izin ekranlarının metin ve akışlarını da UI/UX tasarım çalışmasında baştan birlikte ele alıyoruz.