Uygulamanız Neden Reddedilir? (App Store Red Nedenleri)

App Store inceleme süreçlerinde uygulamalar çoğunlukla eksik meta veriler, teknik çökmeler, zayıf UI/UX standartları ve veri gizliliği ihlalleri sebebiyle reddedilmektedir. Uygulamanız Neden Reddedilir? (App Store Red Nedenleri) sorusu, dijital ürün sahiplerinin, girişimcilerin ve geliştiricilerin pazara çıkış sürelerini (Time-to-Market) doğrudan etkileyen en kritik teknik dönüm noktalarından biridir. Apple ekosisteminin sıkı denetim mekanizması, sadece kod kalitesini değil; iş modelini, kullanıcı sözleşmelerini ve tasarım disiplinini de kapsar. Bu kapsamlı rehberde, Apple App Store Review Guidelines çerçevesinde en sık karşılaşılan ret gerekçelerini, teknik çözüm yöntemlerini, itiraz protokollerini ve onay sürecini kısaltacak operasyonel adımları inceliyoruz.

App Store İnceleme Sürecinin Temel Dinamikleri

Apple'ın uygulama mağazası ekosistemi, kapalı devre ve yüksek denetimli bir pazar yeri felsefesi üzerine kuruludur. Şirket, kullanıcılarının cihazlarına indirdikleri her yazılımın güvenli, kararlı, yüksek performanslı ve gizlilik standartlarına tam uyumlu olduğunu taahhüt eder. Bu durum, Google Play Store gibi platformlara kıyasla çok daha titiz ve çok aşamalı bir denetim sürecini beraberinde getirir. İnceleme süreci hem otomatik statik kod analiz araçları (linterlar, private API tarayıcıları) hem de Apple bünyesindeki insan denetçiler (App Review Team) tarafından yürütülen manuel test adımlarından oluşur.

İnceleme aşamasında bir uygulamanın değerlendirilmesi ortalama 24 ila 48 saat arasında tamamlanır. Ancak karmaşık backend mimarilerine, regülasyona tabi finansal/sağlık servislerine veya kullanıcı tarafından üretilen içerik (UGC) modüllerine sahip projelerde bu süre uzayabilir. Denetçiler, uygulamanın yalnızca arayüzünü gezmekle kalmaz; tüm butonların işlevselliğini, abonelik mekanizmalarını, harici bağlantıların güvenliğini ve arka plan veri transferlerini de titizlikle kontrol eder.

Kurumsal karar vericiler ve ürün yöneticileri için bu süreci öngörülebilir kılmak, ürün yol haritasının aksamaması adına hayati önem taşır. Bir uygulamanın onay alabilmesi için teknik mükemmeliyetin yanı sıra Apple'ın ekosistem vizyonuyla ve dönemsel regülasyon güncellemeleriyle tam bir uyum sergilemesi şarttır.

Apple'ın Kalite Standartlarına Bakış Açısı

Apple, donanım ile yazılım arasındaki kusursuz entegrasyonu en büyük marka değeri olarak konumlandırır. Bu sebeple mağazaya gönderilen bir yazılımın donanım kaynaklarını (pil, bellek, işlemci, ağ bağlantısı) verimli kullanması beklenir. Arka planda aşırı kaynak tüketen, cihazı ısıtan veya bellek sızıntıları (memory leak) sebebiyle iOS işletim sistemi tarafından sonlandırılan uygulamalar doğrudan elenir. Kalite standartları yalnızca çökme olmaması anlamına gelmez; akıcı animasyonlar, dokunmatik tepki süreleri ve sistem fontlarının/ikonlarının doğru kullanımı da bu standardın ayrılmaz parçalarıdır.

Kullanıcı Güvenliği ve Gizliliğin Önemi

Apple ekosisteminde gizlilik bir lüks değil, temel bir insan hakkı olarak tanımlanır. Bu vizyon, App Store Review Guidelines'ın veri toplama ve işleme kurallarına katı biçimde yansır. Uygulamanın topladığı her veri parçasının net bir amaca hizmet etmesi ve bu amacın kullanıcıya şeffaf bir dille açıklanması zorunludur. Cihaz parmak izi alma (fingerprinting), yetkisiz arka plan takibi veya üçüncü parti analiz kütüphanelerinin gizlice veri toplaması gibi durumlar sistem tarafından tespit edildiğinde anında ret kararı verilir.

Marka İmajını Koruma Çabası

App Store, sadece bir indirme platformu değil, Apple'ın premium marka kimliğinin vitrinidir. Platformda yer alan düşük kaliteli, yanıltıcı, dolandırıcılık şüphesi taşıyan veya kalitesiz içerik barındıran uygulamalar, doğrudan Apple markasının güvenilirliğini zedeler. Bu nedenle Apple, kurumsal standartları karşılamayan, telif haklarını ihlal eden veya mağazayı çöplüğe dönüştürme potansiyeli taşıyan hiçbir yazılıma tolerans göstermez.

Meta Veri Hataları: Eksik veya Yanıltıcı Bilgiler

App Store Connect paneli üzerinden girilen uygulama başlığı, alt başlık, anahtar kelimeler, açıklamalar, önizleme görselleri ve kategori seçimleri "Metadata" olarak adlandırılır. İstatistiksel olarak en hızlı çözülebilen ancak en sık karşılaşılan ret nedenleri bu grupta yer alır (Özellikle Guideline 2.3 - Accurate Metadata). Apple denetçileri, mağaza sayfasındaki vaatlerin uygulama içindeki gerçeklikle birebir örtüşmesini bekler.

Meta veri ihlalleri çoğunlukla pazarlama ekipleri ile teknik ekipler arasındaki kopukluktan kaynaklanır. Pazarlama departmanının dönüşüm oranlarını artırmak veya ASO (App Store Optimization) sıralaması kazanmak amacıyla eklediği abartılı vaatler, henüz uygulamada aktif olmayan özelliklerin listelenmesi veya rakip marka adlarının anahtar kelime alanına yazılması inceleme ekibinin dikkatinden kaçmaz.

Aşağıdaki tablo, meta veri süreçlerinde en sık karşılaşılan hataları, ilgili kılavuz maddelerini ve standart çözüm yaklaşımlarını özetlemektedir:

Uygulama Açıklamaları ve Anahtar Kelime Sorunları

Uygulama açıklamasında yer alan bilgilerin teknik olarak doğrulanabilir olması gerekir. Örneğin açıklama metninde "Yapay zeka ile anında 3D model oluşturur" yazıyorsa ve bu özellik henüz geliştirme aşamasındaysa veya bir "Coming Soon" uyarısıyla kilitliyse, uygulama Guideline 2.3.2 gereğince reddedilir. Ayrıca keyword alanına virgülle ayrılarak eklenen kelimelerin uygulamanın temel işleviyle alakasız olması (keyword stuffing) da meta veri reddiyle sonuçlanır.

Ekran Görüntüsü ve Önizleme Uyuşmazlıkları

App Store için hazırlanan ekran görüntüleri (screenshots), kullanıcının uygulama içinde karşılaşacağı gerçek deneyimi yansıtmalıdır. UI tasarımlarını göstermeyen, yalnızca soyut pazarlama sloganları veya stok fotoğraflardan oluşan ekran görüntüleri kabul edilmez. Ayrıca en kritik hatalardan biri, ekran görüntülerinde başka bir platformun (örneğin Android durum çubuğu, geri tuşu veya bildirim ikonları) yer almasıdır. Her ekran boyutu (6.7 inç, 6.5 inç, 12.9 inç iPad) için sisteme yüklenen görsellerin doğru çözünürlükte ve piksel bozulması olmadan hazırlanması şarttır.

Yanlış Kategori veya Yaş Sınıflandırması

Uygulamanın birincil ve ikincil kategorilerinin doğru seçilmesi zorunludur. Örneğin basit bir hesap makinesi uygulamasının "Finans" veya "İş" kategorisine yerleştirilmesi yanıltıcı kabul edilebilir. Benzer şekilde, App Store Connect'te doldurulan Yaş Sınıflandırması Anketi (Age Rating Questionnaire) gerçeği yansıtmalıdır. İçerisinde kullanıcı etkileşimi, kontrolsüz web erişimi veya yetişkin temaları barındıran bir uygulamanın "4+" olarak işaretlenmesi doğrudan ret gerekçesidir.

Performans Sorunları: Çökmeler, Bug'lar ve Teknik Yetersizlikler

Apple'ın en tavizsiz olduğu alanların başında Guideline 2.1 (App Completeness) gelir. İnceleme uzmanları, kendilerine sunulan sürümün nihai, üretime hazır (production-ready) bir ürün olmasını bekler. Test ortamında unutulmuş "lorem ipsum" metinleri, tıklanıldığında tepki vermeyen butonlar veya uygulamanın açılışta beyaz ekranda kalması incelemenin ilk dakikasında sonlanmasına yol açar.

Uygulamanın incelendiği ortamlar genellikle hem fiziksel test cihazlarını (en son çıkan iPhone ve iPad modelleri) hem de farklı ağ hızlarını (düşük bant genişliği simülasyonları) kapsar. Geliştirici ortamında hızlı bir Wi-Fi ağı altında sorunsuz çalışan bir API çağrısı, Apple'ın kurumsal ağında veya zayıf bağlantı koşullarında zaman aşımına (timeout) uğrayarak çökmeye neden olabilir.

Teknik ekiplerin crash loglarını (özellikle .ips uzantılı Apple çökme raporlarını) doğru analiz edebilmesi ve sembolize edilmiş (symbolicated) loglar üzerinden hatanın hangi sınıfta ve satırda gerçekleştiğini tespit etmesi gerekir.

Örnek Apple Crash Log Kesiti (Guideline 2.1 Analizi İçin):
Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Termination Reason: Namespace SIGNAL, Code 6 Abort trap: 6
Triggered by Thread:  0

Thread 0 Crashed:
0   libsystem_kernel.dylib        0x00000001df92f3a8 __pthread_kill + 8
1   libsystem_c.dylib             0x000000019e0783f4 abort + 180
2   MyAppCore                     0x00000001045a1c20 LoginViewController.viewDidLoad() + 348

Uygulama Çökmeleri ve Donmalar (Crash/Bug)

Uygulamanın başlatma anında (launch/splash screen) main thread üzerinde ağır işlemler yapması, iOS Watchdog mekanizmasının devreye girmesine ve uygulamanın sistem tarafından zorla kapatılmasına neden olur. Benzer şekilde, null-pointer istisnaları, bellek aşımı (OOM - Out of Memory) ve senkron ağ çağrılarının arayüzü kilitlemesi doğrudan Guideline 2.1 ihlalidir. Uygulamanın tüm uç senaryolarda (çevrimdışı mod, zayıf sinyal, uçak modu) çökmek yerine kullanıcıya anlamlı bir hata mesajı döndürmesi gerekir.

Bozuk Bağlantılar ve İşlevsellik Eksiklikleri

Uygulama içerisindeki "Kullanım Koşulları", "Gizlilik Politikası" veya "Destek" linklerinin 404 hatası vermesi, incelemenin durdurulması için yeterlidir. Ayrıca arayüzde yer alan herhangi bir sekmenin "Yapım Aşamasında" (Under Construction) ibaresi taşıması veya bir özelliğin tıklanmasına rağmen hiçbir işlem yapmaması uygulamanın tamamlanmadığı şeklinde yorumlanır.

Test Hesapları ve Demo Bilgilerinin Eksikliği

Uygulama bir üyelik veya oturum açma mekanizması gerektiriyorsa, App Store Connect alanında çalışan, geçerli ve tüm yetkileri tanımlanmış bir test hesabı (kullanıcı adı ve şifre) sunulmalıdır. İki faktörlü kimlik doğrulama (2FA) veya SMS doğrulaması kullanan sistemlerde, denetçinin giriş yapabilmesi için statik bir test kodu (bypass OTP) tanımlanmalı veya ilgili telefon numarası Apple inceleme notlarına eklenmelidir. Denetçinin giriş yapamadığı her başvuru gecikmeksizin reddedilir.

Zayıf Kullanıcı Arayüzü (UI) ve Deneyimi (UX) Standartları

Apple ekosistemi, kullanıcı arayüzü konusunda dünyanın en katı standartlarına sahiptir. Şirket tarafından yayımlanan Human Interface Guidelines (HIG), iOS platformunda yer alacak uygulamaların görsel hiyerarşisini, navigasyon yapısını, dokunma hedeflerini ve tipografisini tanımlar. Guideline 4.0 (Design) kapsamında yapılan incelemelerde, bir uygulamanın yalnızca teknik olarak çalışması yetmez; iOS tasarım diline saygı duyması ve profesyonel bir deneyim sunması beklenir.

Mobil cihazların farklı ekran form faktörlerine (Dynamic Island, çentik, yuvarlatılmış köşeler, home bar) uyum sağlamayan tasarımlar derhal elenir. Örneğin bir butonun home bar çizgisinin altında kalması ve kullanıcının butona basarken yanlışlıkla uygulamayı ana ekrana göndermesi, doğrudan tasarım yetersizliği olarak işaretlenir.

Geliştiricilerin sıklıkla düştüğü hata, web arayüzlerini veya Android Material Design kalıplarını olduğu gibi iOS uygulamasına aktarmaya çalışmaktır. iOS kullanıcıları geri gitmek için ekranın sol kenarından kaydırma (interactive pop gesture) hareketine veya alt navigasyon çubuğuna (tab bar) alışkındır; bu kalıpları bozan uygulamalar düşük puan alır.

Human Interface Guidelines (HIG) İhlalleri

HIG uyumsuzlukları genellikle dokunma hedeflerinin (touch targets) çok küçük tutulması (Apple standardı minimum 44x44 piksellik etkileşim alanıdır), metin kontrast oranlarının düşük olması veya karanlık mod (Dark Mode) desteğinin bozuk çalışması şeklinde kendini gösterir. Kullanıcı açık temadan koyu temaya geçtiğinde okunamaz hale gelen metinler veya kaybolan ikonlar doğrudan tasarım reddine yol açar.

Gelişmiş Deneyim Sunamayan Web-view Uygulamaları

En yaygın ret maddelerinden biri Guideline 4.2'dir (Minimum Functionality). Bir web sitesini yalnızca WKWebView içine gömerek oluşturulan ve donanım yeteneklerinden (kamera, bildirimler, yerel depolama, haptik geri bildirim) faydalanmayan hibrit uygulamalar Apple tarafından "uygulama niteliği taşımayan içerik" olarak değerlendirilir. Apple, bu tür çözümlerin App Store yerine Safari üzerinden bir web sitesi veya PWA (Progressive Web App) olarak sunulmasını talep eder.

Karmaşık veya İşlevsiz Tasarım

Kullanıcıyı sürekli çıkmaz sokaklara (dead-end) sokan, geri dönüş butonu barındırmayan modallarla kilitleyen veya aşırı karmaşık üyelik adımları dayatan arayüzler reddedilir. Kullanıcı deneyimi doğrusal, sezgisel ve zahmetsiz olmalıdır.

Veri Gizliliği İhlalleri ve Güvenlik Standartları

Apple'ın 5.1 (Privacy and Data Security) yönergeleri, platformun en kritik regülasyon alanını oluşturur. iOS 14.5 ile hayatımıza giren ve sonraki sürümlerde kapsamı genişletilen App Tracking Transparency (ATT) çerçevesi, kullanıcıların reklam ve analiz amaçlı takip edilmeden önce açık rızalarının alınmasını zorunlu kılar. Geliştiricilerin IDFA (Identifier for Advertisers) değerine erişmek istemesi durumunda sistem izin penceresini göstermemesi veya kullanıcı reddettiği halde alternatif takip yöntemlerine başvurması hesabın kapatılmasına kadar varan yaptırımlar doğurur.

Ayrıca App Store Connect üzerinde doldurulan "App Privacy" (Uygulama Gizlilik Besin Değerleri) etiketlerinin, uygulamanın kullandığı üçüncü parti SDK'ların (Firebase, Facebook SDK, AppsFlyer vb.) topladığı verilerle %100 uyumlu olması şarttır. Apple, statik kod analiziyle projenizde yer alan kütüphaneleri tarar; örneğin Facebook SDK projenizde mevcutsa ve siz "Kullanıcı takibi yapmıyoruz" beyanında bulunduysanız, sistem çelişkiyi anında yakalayarak sürümü askıya alır.

Örnek Info.plist Gizlilik İzin Metinleri Doğru/Yanlış Kullanımı:

<!-- YANLIŞ: Yetersiz ve jenerik açıklama (Doğrudan Ret) -->
<key>NSCameraUsageDescription</key>
<string>Uygulamanın kameraya erişmesi gerekiyor.</string>

<!-- DOĞRU: Amaca yönelik, şeffaf ve kurumsal açıklama (Kabul Edilir) -->
<key>NSCameraUsageDescription</key>
<string>Profil fotoğrafınızı güncellemek ve fatura tarama işlemlerini gerçekleştirmek için kameranıza erişim gereklidir.</string>

App Tracking Transparency (ATT) Uyumluluğu

Kullanıcıyı diğer şirketlere ait uygulamalar ve web siteleri genelinde takip eden her türlü analitik ve reklam aracı için AppTrackingTransparency.framework kullanılmalıdır. Bu izin, kullanıcı uygulamayı açar açmaz agresif biçimde ekrana dayatılmamalı; kullanıcının bağlamı anlayabileceği uygun bir deneyim anında tetiklenmelidir. İzin isteme metninde kullanıcıyı izne zorlayan veya izni kabul etmediğinde hizmeti engelleyen şartlar sunulamaz.

Yetersiz veya Yanlış Gizlilik Politikası

Her uygulamanın geçerli, kamuya açık ve doğrudan erişilebilir bir Gizlilik Politikası URL'sine sahip olması zorunludur. Bu politika metninde hangi verilerin toplandığı, nasıl saklandığı, üçüncü partilerle paylaşılıp paylaşılmadığı ve kullanıcının verilerini silme hakkını (GDPR/KVKK uyumu) nasıl kullanacağı açıkça belirtilmelidir. Özellikle hesap oluşturma imkanı sunan tüm uygulamalarda, kullanıcıya hesap silme ve buna bağlı tüm verilerini kalıcı olarak yok etme mekanizması doğrudan uygulama içerisinden sunulmalıdır (Guideline 5.1.1(v)).

Gereksiz İzin Talepleri ve Veri Toplama

Uygulamanın temel işleviyle ilgisi olmayan izinlerin talep edilmesi yasaktır. Örneğin bir el feneri veya not defteri uygulamasının kullanıcının konum bilgisine, rehberine veya mikrofonuna erişim istemesi Guideline 5.1.1 ihlalidir. İstenen her donanım izni için Info.plist dosyasına eklenen açıklama metni (Usage Description) jenerik olmamalı, verinin tam olarak hangi özelliğin çalışması için gerektiği açık bir dille yazılmalıdır.

Spam, Kopya İçerik ve Düşük Değer Üreten Uygulamalar

App Store'da milyonlarca uygulama bulunması, Apple'ın yeni gelen başvurularda "özgünlük" ve "katma değer" kriterlerini çok daha sert uygulamasına yol açmıştır. Guideline 4.3 (Spam) ve Guideline 5.2 (Intellectual Property), mağazanın kalitesini düşüren, aynı kaynak kodun farklı temalarla yüzlerce kez yayınlandığı şablon (white-label) projeleri veya popüler oyun/uygulamaların klonlarını temizlemek için tasarlanmıştır.

Özellikle SaaS platformları veya dijital ajanslar tarafından müşterilerine sunulan "her işletmeye özel mobil uygulama" modeli, tek bir geliştirici hesabı üzerinden sunulduğunda doğrudan spam filtresine takılır. Apple, benzer şablonları kullanan uygulamaların tek bir çatı altında toplanmasını (örneğin tek bir pazar yeri uygulaması olarak) ya da her işletmenin kendi adına açılmış kurumsal Apple Developer Program hesabı üzerinden yayın yapmasını zorunlu kılar.

Şablon veya Benzer Uygulamaların Reddi

Piyasada satılan hazır şablonları (app templates) neredeyse hiç değiştirmeden, yalnızca logo ve renk paletini güncelleyerek mağazaya göndermek ret ile sonuçlanır. İnceleme ekibi, uygulamanın sunduğu deneyimin mağazada halihazırda bulunan binlerce benzer uygulamadan nasıl ayrıştığını değerlendirir. Yeterli fonksiyonel derinliğe sahip olmayan uygulamalar "Spam" kategorisinde değerlendirilir.

Özgün İçerik veya Değer Eksikliği

Bir uygulamanın birincil amacı kullanıcıya kalıcı bir etkileşim veya değer sağlamak olmalıdır. Sadece birkaç statik sayfadan, bir PDF kataloğundan veya harici link koleksiyonundan ibaret olan ürünler Guideline 4.2 ve 4.3 kapsamında elenir. Uygulamanın cihaz yeteneklerini kullanan, kişiselleştirilebilir ve sürekli güncellenen dinamik bir yapıya sahip olması şarttır.

Fikri Mülkiyet İhlalleri

Yetkisiz logo kullanımı, tescilli marka isimlerinin izinsiz geçirilmesi veya telif hakkı korunan medya içeriklerinin (müzik, video, oyun karakterleri) uygulamaya dahil edilmesi Guideline 5.2 ihlalidir. Eğer kurumsal bir müşteri adına veya üçüncü parti bir markanın lisanslı içeriğini sunuyorsanız, inceleme notlarına resmi lisans sözleşmelerini veya yetkilendirme belgelerini (Authorization Letter) PDF formatında eklemeniz gerekir.

Uygulama İçi Satın Alma (IAP) Kural İhlalleri

Apple'ın gelir modelinin ve regülatif tartışmaların merkezinde yer alan Guideline 3.1.1 (In-App Purchase), dijital içerik, premium özellik veya abonelik satışı yapan uygulamalar için en hassas alandır. Kuralın temel prensibi son derece nettir: Uygulama içerisinde tüketilen her türlü dijital mal ve hizmet (oyun paraları, dijital kitaplar, bulut depolama, premium filtreler, SaaS abonelikleri) yalnızca Apple'ın In-App Purchase (IAP) altyapısı üzerinden satılabilir.

Fiziksel ürün veya hizmet satışları (e-ticaret sepetleri, yemek siparişi, taksi çağırma gibi reel dünyada karşılığı olan servisler) bu kuralın istisnasıdır ve harici kredi kartı ağları (Stripe, iyzico vb.) veya Apple Pay ile işlenebilir. Ancak konu dijital bir yetki olduğunda harici ödeme sayfası açmak doğrudan hesap feshine yol açabilir.

Aşağıdaki süreç akışı, ürününüzün gelir modeline göre doğru ödeme altyapısını seçmeniz için izlenmesi gereken mantıksal karar yolunu göstermektedir:

1. Satılan Değerin Niteliğini Belirleyin: Ürün fiziksel bir mal/hizmet mi yoksa dijital bir içerik/özellik mi?

2. Fiziksel İse: Geleneksel ödeme ağ geçitlerini (iyzico, Stripe, Braintree) veya Apple Pay'i entegre edin (IAP zorunlu değildir).

3. Dijital İse: StoreKit 2 framework'ünü kullanarak Apple In-App Purchase mekanizmasını kurun.

4. Harici Buton Kontrolü: Uygulama içinde "Web sitemizden daha ucuza satın alın" benzeri yönlendirme linklerinin ve butonlarının bulunmadığını doğrulayın.

5. Abonelik Şeffaflığı: Ödeme ekranında (Paywall) fiyat, yenilenme periyodu ve iptal koşullarını açıkça gösterin; "Satın Alımları Geri Yükle" (Restore Purchases) butonunu ekleyin.

Harici Ödeme Sistemlerine Yönlendirme

Dijital ürün satan bir uygulamanın kullanıcıyı Safari tarayıcısına yönlendirerek kendi web sitesi üzerinden ödeme almaya çalışması veya uygulama içine harici kredi kartı formu gömmesi en ağır ihlallerden biridir (Anti-Steering kuralları gereği belirli bölgelerdeki yasal istisnalar hariç globalde IAP zorunludur). Benzer şekilde, kullanıcıya "Web sitemizden kaydolursanız %20 daha ucuz" gibi yönlendirme metinleri göstermek Guideline 3.1.1 uyarınca anında ret getirir.

Abonelik Modellerinin Yetersiz Açıklanması

Otomatik yenilenen aboneliklerde (Auto-Renewable Subscriptions) kullanıcıya sunulan ödeme ekranının (Paywall) belirli yasal gereksinimleri karşılaması zorunludur (Guideline 3.1.2). Kullanıcının net olarak görebileceği şekilde:

• Abonelik ücreti ve faturalandırma dönemi (Örn: Haftalık ₺49,99 / Yıllık ₺899,99),

• Deneme süresi varsa sürenin uzunluğu ve deneme bitiminde karttan tahsilat yapılacağı bilgisi,

• Aboneliğin nasıl iptal edileceğine dair net açıklama,

• Kullanım Koşulları (EULA) ve Gizlilik Politikası bağlantıları,

• "Satın Alımları Geri Yükle" (Restore Purchases) butonu ekranda eksiksiz yer almalıdır.

Yanlış Ürün veya Fiyatlandırma Bilgileri

App Store Connect'te oluşturulan IAP ürün kimliklerinin (Product IDs) uygulama içerisindeki kodlarla uyuşmaması veya test ortamında (Sandbox) ürün fiyatlarının çekilememesi de reddedilme sebebidir. StoreKit entegrasyonunun @@CODE0@@ veya @@CODE1@@ üzerinden eksiksiz test edildiğinden emin olunmalıdır.

Reddedilen Uygulamalar İçin Kurumsal Aksiyon Planı

Uygulamanız reddedildiğinde panik yapmak veya aynı sürümü hiçbir değişiklik yapmadan tekrar tekrar incelemeye göndermek yapılabilecek en büyük operasyonel hatadır. Red kararı, App Store Connect panelinde yer alan Resolution Center (Çözüm Merkezi) üzerinden gerekçesi, ilgili Guideline maddesi ve çoğu zaman ekran görüntüleri ya da çökme raporlarıyla birlikte iletilir.

Sürecin profesyonelce yönetilmesi, geliştirici hesabının itibarını korur ve çözüm süresini günler mertebesine indirir. Çözüm Merkezi üzerinden iletişim kurarken suçlayıcı, agresif veya amatör bir dil yerine; teknik detayları açıklayan, ekran kayıtları (video demo) veya mimari açıklamalar içeren kurumsal bir yaklaşım benimsenmelidir.

Aşağıdaki şablon, ret bildirimine verilecek profesyonel yanıtın yapısını göstermektedir:

[Örnek Resolution Center Yanıt Formatı]

Sayın Apple İnceleme Ekibi,

[Uygulama Adı] (Version X.X.X, Build XXX) başvurumuza ilişkin Guideline [İlgili Madde, Örn: 2.1] kapsamındaki geri bildiriminiz için teşekkür ederiz.

Belirtilen durumla ilgili teknik incelememiz tamamlanmış olup gerekli aksiyonlar alınmıştır:

1. Tespit Edilen Durum: [İnceleme ekibinin belirttiği hata özeti]
2. Yapılan Düzeltme: [Uygulanan teknik düzeltme veya Info.plist güncellemesi]
3. Test Adımları: [Denetçinin hatayı yeniden üretmeden doğrulayabilmesi için adım adım yönerge]
4. Ek Kaynaklar: [Gerekiyorsa yeni test hesabı veya ekran kayıt videosu linki]

Yeni build (Build XXX) sisteme yüklenmiştir. Bilgilerinize arz eder, iyi çalışmalar dileriz.

Resolution Center Üzerinden Doğru İletişim

İnceleme ekibinin bir özelliği yanlış anladığını veya test hesabının yetkilerini yanlış kullandığını düşünüyorsanız, durumu kanıtlarla açıklayan kısa bir video kaydı (YouTube/Vimeo gizli linki veya doğrudan MP4 eki) paylaşabilirsiniz. Eğer hata tamamen kod kaynaklıysa, hatayı kabul edip düzeltildiğini ve yeni bir derleme (build) yüklendiğini net adımlarla belirtmek onay sürecini hızlandırır.

Teknik Revizyonlar ve Yeni Sürüm Gönderimi

Koddaki hata giderildikten sonra Xcode üzerinden CFBundleVersion (Build numarası) artırılarak yeni bir arşiv oluşturulmalı ve App Store Connect'e gönderilmelidir. Sadece ikili dosyayı (binary) güncellemek yetmez; eğer ret gerekçesi meta veri veya gizlilikle ilgiliyse, mağaza form alanlarının da güncellenmesi ve ardından "Submit for Review" butonuna basılması gerekir.

App Review Board Sistemine İtiraz Süreci

Eğer uygulamanızın kurallara tam uyumlu olduğundan kesinlikle eminseniz ve inceleme ekibinin haksız veya hatalı bir karar verdiğini düşünüyorsanız, resmi App Review Board İtiraz Formu (Appeal) doldurabilirsiniz. Bu süreç, başvurunun kıdemli bir inceleme heyeti tarafından yeniden değerlendirilmesini sağlar. Ancak itiraz hakkı yalnızca kural yorumu uyuşmazlıklarında kullanılmalıdır; bariz kod hatalarında itiraz etmek yalnızca zaman kaybına yol açar.

Yayına Sunmadan Önce Alınması Gereken Tedbirler

Başvurunun ilk seferde onaylanması (First-Pass Approval), ürün fırlatma lansmanlarının başarısı için kritik bir KPI'dır. Bu başarıyı yakalamak için geliştirme döngüsünün sonuna kapsamlı bir "Release Readiness" (Yayına Hazırlık) fazı eklenmelidir. Bu aşama hem teknik kalite güvence (QA) testlerini hem de mağaza varlıklarının hukuki ve tasarımsal denetimini kapsar.

Aşağıdaki kontrol listesi, derlemenizi App Store Connect üzerinden incelemeye göndermeden önce tamamlamanız gereken operasyonel adımları listelemektedir:

Yayın öncesi süreçlerde TestFlight platformunun aktif kullanımı, simülatörlerde yakalanamayan donanım bazlı kilitlenmeleri (Memory Leaks, Metal/GPU render hataları) tespit etmenin en güvenilir yoludur. Ekibiniz dışındaki gerçek kullanıcıların uygulamayı farklı iOS sürümlerinde (özellikle en güncel ana sürüm ve bir önceki sürüm) test etmesini sağlamak beklenmeyen çökmelerin önüne geçer.