App Store Guideline 2.1 Reddi: Uygulama Tamamlanmamış ve Demo Hesap Hatası Nasıl Çözülür?

App Store Guideline 2.1 ret e-postası geldiğinde panikle yeni bir sürüm yüklemeyin. Önce aşağıdaki sırayı izleyin; böylece aynı hatayla ikinci kez ret almazsınız.

1. App Store Connect içinde uygulamanızın App Review bölümünü açın ve ret mesajını baştan sona okuyun.
2. Mesajda ekran görüntüsü, cihaz modeli ya da işletim sistemi sürümü varsa not alın.
3. Sorunun türünü belirleyin: giriş bilgisi mi, çökme mi, eksik içerik mi, satın alma mı?
4. Demo hesabı kendi cihazınızda, temiz bir kurulumla yeniden deneyin.
5. Arka uç sunucunuzun canlı ortamda açık olduğunu ve inceleme süresince açık kalacağını doğrulayın.
6. Gerekirse yeni derlemeyi yükleyin, App Review Information alanlarını güncelleyin ve ret mesajına kısa bir yanıt yazın.

Guideline 2.1 metni tam olarak ne istiyor?

Kuralın kaynağı Apple'ın App Store İnceleme Yönergeleri sayfasındaki App Completeness bölümüdür. Bu bölüm, incelemeye gönderdiğiniz her şeyin son sürüm olmasını ister. Yani metadata eksiksiz olmalı, bağlantılar çalışmalı ve geçici içerik kalmamalıdır. Ayrıca uygulamayı gerçek cihazda hata ve kararlılık açısından test etmenizi bekler.

Yönergenin özü kısaca şu maddelere iner:

• Gönderimden önce yer tutucu metni, boş web sitelerini ve geçici içeriği kaldırmalısınız.
• Uygulamada giriş varsa demo hesap bilgisi vermeli ve arka uç hizmetini açık tutmalısınız.
• Yasal ya da güvenlik nedeniyle demo hesap veremiyorsanız, Apple'ın önceden onayıyla yerleşik bir demo modu kullanabilirsiniz.
• Demo modu uygulamanın tüm özelliklerini göstermeli.
• Eksik paketler ve çöken ya da bariz teknik sorun gösteren derlemeler ret alır.
• Uygulama içi satın almaları eksiksiz, güncel ve çalışır tutmalı, inceleyicinin onları bulabilmesini sağlamalısınız.

Dolayısıyla App Store Guideline 2.1 tek bir hata türü değildir. Aynı numara altında hem bilgi eksikliği hem de teknik kusur yer alır. Bu yüzden düzeltmeye başlamadan önce sizin ret mesajınızın hangi alt soruna işaret ettiğini netleştirmeniz gerekir.

Ret mesajındaki ipuçlarını nasıl okursunuz?

Apple'ın ret mesajı genellikle ihlal edilen yönerge numarasını, kısa bir açıklamayı ve çoğu zaman inceleyicinin kullandığı cihaz bilgisini içerir. Bazı mesajlar bir ekran görüntüsü de içerir. Bu ayrıntılar, sorunu yeniden üretmeniz için en değerli veridir.

Mesajın tonuna göre iki ana grup görürsünüz. İlk grupta inceleyici yalnızca bilgi ister; örneğin demo hesap çalışmıyordur ya da bir özelliğe nasıl ulaşılacağı belli değildir. İkinci grupta ise uygulama çöker, bir ekran boş gelir ya da bir düğme hiçbir şey yapmaz. İlk grupta çoğu zaman yeni derleme gerekmez, ikinci grupta ise neredeyse her zaman gerekir.

Mesajda cihaz modeli ve işletim sistemi sürümü yazıyorsa, testinizi tam o koşulda tekrarlayın. Örneğin inceleyici iPad üzerinde denemişse, uygulamanızı yalnız iPhone için tasarlamış olsanız bile iPad'de açılış davranışını kontrol edin. Ayrıca mesajdaki saat bilgisine bakarak o sırada sunucu kayıtlarınızda hata olup olmadığını inceleyin.

Demo hesap neden App Store Guideline 2.1 retlerinin başında gelir?

Çünkü inceleyici uygulamanızı sıfırdan, sizin hiç düşünmediğiniz bir ortamda açar. Sizin cihazınızda oturum açık kaldığı için fark etmediğiniz bir giriş sorunu, onun ekranında ilk saniyede ortaya çıkar. Giriş ekranını geçemeyen inceleyici uygulamanın geri kalanını göremez ve doğal olarak bilgi eksikliği gerekçesiyle süreci durdurur.

Saha deneyimimizde demo hesap sorunlarını birkaç tekrarlayan kalıpta topluyoruz:

• Şifre geliştirme sırasında değişmiş ama App Store Connect'te güncellenmemiş.
• Hesap test ortamında var, canlı veritabanında yok.
• Hesap e-posta doğrulaması ya da telefonla gelen tek kullanımlık kod bekliyor.
• Hesabın deneme süresi ya da aboneliği dolmuş.
• Hesap boş; içinde inceleyicinin göreceği hiçbir örnek veri yok.
• Hesapta yönetici onayı gerektiren rol eksik.

Bu kalıplardan birini kendi başınıza çözemiyorsanız ya da arka uç yapısı birden fazla ekibe dağılmışsa, gönderim sürecini bir uygulama geliştirme hizmeti ile birlikte planlamak zaman kazandırır. Kendi ekibiniz varsa da aşağıdaki adımlar çoğu durumda yeterli olur.

App Review Information alanlarını nasıl doldurursunuz?

App Store Connect'teki bu bölüm, inceleyiciyle aranızdaki tek resmi köprüdür. Apple'ın App Review Information yardım sayfası üç ana alan tanımlar: iletişim bilgisi, notlar ve giriş bilgisi. Kullanıcılar bu bilgileri göremez ve onaylı bir sürümde bile düzenleyebilirsiniz.

• İletişim: inceleme ekibinin ulaşabileceği kişinin adı, e-postası ve telefonu. Telefon, artı işareti ve ülke koduyla başlayan uluslararası biçimde olmalı.
• Notlar: uygulamaya özel ayarlar, test kaydı ya da hesap ayrıntıları. Alanın bir bayt sınırı var; güncel değeri yardım sayfasından kontrol edin. Notları istediğiniz dilde yazabilirsiniz.
• Giriş gerekli: demo hesabın kullanıcı adı ve şifresi. Hesabın süresi dolmamalı; ek hesaplar notlarda yer almalı.

Ayrıca uygulamanız Facebook gibi tek oturum açma hizmeti kullanıyorsa, yardım sayfası o hizmet için de demo giriş bilgisi istediğini belirtir. Pratikte bu alanları her sürümde yeniden okuyun, çünkü eski bir sürümden kalan bilgi sessizce geçersiz hale gelebilir.

İnceleme notlarına ne yazmalısınız?

Notlar alanı, inceleyicinin uygulamanızda kaybolmamasını sağlayan kısa bir yol haritasıdır. Uzun bir tanıtım metni yazmayın; bunun yerine adım adım ne yapacağını söyleyin. Örneğin aşağıdaki iskelet çoğu uygulamada işe yarar:

1. Uygulamanın tek cümlelik amacı.
2. Demo hesapla giriş adımları ve giriş sonrası açılan ilk ekran.
3. Ana özelliğe ulaşmak için sırayla dokunacağı yerler.
4. Belirli bir rol, konum ya da donanım gerektiren özellikler ve bunların nasıl test edileceği.
5. Uygulama içi satın almaların nerede göründüğü; görünmeyen varsa nedeni.
6. Ek demo hesaplar, örneğin yönetici ve standart kullanıcı.

Yönergelerin 2.3.1 maddesi, yeni özelliklerin ve ürün değişikliklerinin inceleme notlarında net biçimde anlatılmasını ve inceleme için erişilebilir olmasını ister; genel açıklamaların ret alacağını da belirtir. Dolayısıyla notlara "tüm özellikler çalışıyor" gibi bir cümle yazmak yerine, hangi ekranda neyi göreceğini somut olarak yazın.

Demo hesap SMS kodu ya da iki adımlı doğrulama isterse ne yapmalısınız?

İnceleyici sizin telefon numaranıza gelen kodu göremez. Bu nedenle giriş akışında SMS, e-posta onayı ya da kimlik doğrulama uygulaması varsa demo hesap için bu adımı aşmanın kurallara uygun bir yolunu hazırlamanız gerekir. Aksi halde hesap teknik olarak doğru olsa bile inceleyici içeri giremez.

Uygulanabilir seçenekler şunlardır:

• Demo hesabın doğrulama durumunu arka uçta önceden tamamlamak.
• Yalnız bu hesap için sabit bir test kodu tanımlamak ve kodu notlara yazmak.
• Tek kullanımlık kod gerekiyorsa, inceleme süresince kodu iletebilecek bir iletişim kişisini notlarda belirtmek.

Ancak bu istisnayı canlı kullanıcılara açmayın. Sabit kod yalnız demo hesaba bağlı olmalı ve inceleme bitince kapatılabilir olmalı. Üstelik hesabın süresi dolmamalı; yardım sayfası demo hesabın süresiz geçerli olmasını açıkça ister. Abonelik tabanlı uygulamalarda demo hesabın aboneliğini de inceleme boyunca aktif tutun.

Giriş yapmadan çalışan demo modunu ne zaman kullanabilirsiniz?

Guideline 2.1, yasal ya da güvenlik yükümlülükleri nedeniyle demo hesap veremeyen geliştiricilere bir alternatif tanır: uygulamaya yerleşik bir demo modu. Ancak bu yol Apple'ın önceden onayına bağlıdır. Yani demo modunu kendi kararınızla ekleyip notlara yazmanız yeterli değildir.

Örneğin bankacılık, sağlık kaydı ya da kurumsal kimlik doğrulama gibi gerçek kişisel veriye bağlı uygulamalarda demo hesap vermek zor olabilir. Böyle bir durumda demo modu, gerçek akışın birebir taklidi olmalı ve tüm özellikleri göstermelidir. Yarım bir vitrin ekranı ise yeni bir 2.1 retine yol açar.

Pratikte önce gerçekten demo hesap veremeyeceğinizi sorgulayın. Çoğu durumda arka uçta ayrı bir test kiracısı ya da örnek verilerle dolu bir hesap, demo modundan çok daha az sürtünme yaratır. Demo modu yine de gerekiyorsa, gerekçeyi ret mesajına verdiğiniz yanıtta açıkça anlatın ve onay sürecini oradan yürütün.

Arka uç kapalıyken inceleme neden ret getirir?

İnceleme Apple'ın takviminde ilerler, sizin mesai saatlerinizde değil. Gönderim öncesi kontrol listesi, arka uç hizmetlerinin inceleme sırasında canlı ve erişilebilir olmasını ister. Gece bakım penceresi, test sunucusunun kapatılması ya da süresi dolan bir sertifika, inceleyicinin ekranında boş liste ya da sonsuz yükleme göstergesi olarak görünür.

Sık rastladığımız arka uç kaynaklı tuzaklar şunlardır:

• Derleme hâlâ test ortamının adresini gösteriyor, test sunucusu ise kapalı.
• Sunucu belirli ülkelerden gelen trafiği engelliyor.
• İstek sınırlama kuralı, aynı ağdan gelen inceleme trafiğini saldırı sanıyor.
• Yeni sürümün gerektirdiği API uç noktası henüz canlıya çıkmamış.

Bu yüzden gönderimden önce canlı ortamı, uygulamanın son derlemesiyle uçtan uca deneyin. Arka uç kavramına yabancıysanız API nedir rehberimiz uygulama ile sunucu arasındaki ilişkiyi sade bir dille anlatıyor.

Uygulamanız yalnız IPv6 ağında çalışıyor mu?

Apple'ın IPv6 destek sayfası, App Store'a gönderilen tüm uygulamaların yalnız IPv6 kullanan ağları desteklemesini şart koşar. Uygulamanız IPv4'e özgü programlama arayüzleri ya da koda gömülü IP adresleri kullanıyorsa, bu tür bir ağda bağlantı kuramayabilir. Sonuç inceleyicinin ekranında bağlantı hatası ya da boş ekran olur.

Bu sorun sinsi bir şekilde ortaya çıkar, çünkü ofis ağınızda her şey sorunsuz çalışır. Dolayısıyla ret mesajında ağ hatası ya da veri yüklenmemesi görüyorsanız, IPv6 uyumunu mutlaka kontrol listenize ekleyin. Sunucu adreslerinizi IP yerine alan adıyla çağırmak, sorunu çoğu zaman tek başına çözer.

Hızlı bir ön kontrol için IPv6 testi aracımızı kullanarak alan adınızın IPv6 durumunu görebilirsiniz. Ancak asıl doğrulamayı, uygulamanın kendisini IPv6 ortamında çalıştırarak yapın; araç yalnız sunucu tarafına dair bir fikir verir.

Yer tutucu içerik ve kırık bağlantılar nasıl ret sebebi olur?

Yönerge, yer tutucu metni, boş web sitelerini ve geçici içeriği açıkça yasaklar. Geliştirme sırasında unutulan bir "lorem ipsum" paragrafı, "yakında" yazan bir düğme ya da tasarım şablonundan kalan örnek görsel, inceleyiciye uygulamanın bitmediği izlenimini verir.

Bağlantılar da aynı kapsamdadır. Destek adresi, gizlilik politikası ve uygulama içindeki web görünümleri çalışır durumda olmalı. Örneğin gizlilik politikası bağlantınız boş bir alan adına çıkıyorsa, uygulama kusursuz olsa bile ret alabilirsiniz. Gizlilik tarafındaki diğer gereksinimler için App Store gizlilik etiketleri rehberimize göz atın.

Gönderimden önce şu taramayı yapın: tüm ekranları gezip her metni okuyun, her düğmeye bir kez dokunun ve her bağlantıyı açın. Henüz hazır olmayan bir özelliği gizlemek yerine bu sürümden tamamen çıkarın. Böylece hem inceleyiciye hem kullanıcıya tutarlı bir ürün sunarsınız.

Çöken ekranları gönderimden önce nasıl yakalarsınız?

Apple'ın App Review sayfası, yalnız tamamlanmış ve yayına hazır içeriği göndermenizi, en güncel yazılımı çalıştıran cihazlarda kapsamlı test yapmanızı ister. Simülatörde sorunsuz çalışan bir uygulama, gerçek cihazda bellek, izin ya da ağ koşulları nedeniyle çökebilir.

Bu nedenle son derlemeyi gerçek cihazlarda, temiz kurulumla deneyin. TestFlight ile iOS uygulama testi bu aşamada en pratik yoldur, çünkü derlemeyi incelemeye gidecek haliyle dış test kullanıcılarına açar. Ayrıca şu senaryoları mutlaka deneyin:

• İlk açılış: hiç izin yok, hiç veri yok.
• Tüm izinlerin reddedildiği durum: kamera, konum, bildirim.
• Zayıf ya da kesik internet bağlantısı.
• Farklı ekran boyutları, özellikle iPad.
• Hesaptan çıkış yapıp tekrar giriş.

Çökme raporu varsa, Apple'ın çökme raporlarını edinme ve analiz etme belgelerinden yararlanın; App Review sayfası da ret sonrası bu kaynaklara yönlendirir.

Uygulama içi satın almalar Guideline 2.1 kapsamına nasıl girer?

Yönergenin ikinci alt maddesi, uygulama içi satın almaların eksiksiz, güncel, inceleyiciye görünür ve çalışır olmasını ister. App Store Connect'te tanımladığınız bir ürün uygulamada bulunamıyor ya da incelenemiyorsa, nedenini inceleme notlarında açıklamanız gerekir.

Tipik bir senaryo şöyledir: yeni bir abonelik paketini App Store Connect'e eklersiniz ama satın alma ekranı yalnız belirli bir kullanıcı grubuna görünür. İnceleyici bu gruba girmediği için ürünü bulamaz. Çözüm, notlarda ürünün hangi ekranda ve hangi koşulda göründüğünü yazmak ya da demo hesabı o koşulu sağlayacak şekilde hazırlamaktır.

Ödeme modelinin kendisini henüz netleştirmediyseniz, uygulama içi satın alma mı web ödeme mi yazımız iki yolun farklarını anlatıyor. Satın alma akışında da sunucu doğrulaması varsa, arka ucun inceleme sırasında açık olduğundan emin olun.

Donanım, konum ya da QR kodu gerektiren uygulamalarda ne yapmalısınız?

Bazı uygulamalar inceleyicinin elinde olmayan bir şeye bağlıdır: akıllı bir cihaz, fiziksel bir mağaza, belirli bir şehir ya da masadaki bir QR kodu. Gönderim öncesi kontrol listesi, bu tür durumlarda donanım ya da örnek QR kodu gibi gereken kaynakları sağlamanızı ister.

App Review sayfası ayrıca, tekrar üretilmesi zor bir ortam ya da özel donanım gerektiren özellikler için demo videosu ya da donanımın kendisini sağlamaya hazır olmanızı önerir. Pratikte şu yaklaşımlar işe yarar:

1. Örnek QR kodunu görsel olarak eke koyun ve notlarda nereden okutulacağını yazın.
2. Konuma bağlı özellikler için demo hesabı sabit bir test bölgesine bağlayın.
3. Donanımla eşleşme adımlarını gösteren kısa bir ekran kaydı hazırlayın.
4. Donanım olmadan da görülebilen ekranları notlarda listeleyin.

Böylece inceleyici, fiziksel bağımlılığa takılmadan uygulamanın mantığını değerlendirebilir.

Demo hesabı inceleme için nasıl hazırlarsınız?

App Store Guideline 2.1 açısından iyi bir demo hesap, yalnız giriş yapabilen bir hesap değildir. İnceleyici giriş yaptıktan sonra uygulamanın değer önerisini birkaç dakika içinde görebilmeli. Boş bir ana sayfa, "henüz içerik yok" uyarısı ya da ilk kurulum sihirbazının sonsuz adımları, inceleyiciye uygulamanın bitmediğini düşündürebilir.

Bu yüzden demo hesabı gerçek bir kullanıcının birkaç hafta kullanmış hali gibi doldurun. Örneğin bir randevu uygulamasında geçmiş ve gelecek randevular, bir e-ticaret uygulamasında sepet ve sipariş geçmişi, bir ekip uygulamasında örnek mesajlar bulunsun. Kişisel veri yerine tamamen kurgusal içerik kullanın.

Ayrıca uygulamanızda birden fazla rol varsa, her rol için ayrı bir hesap hazırlayın. Ana hesabı giriş alanlarına, diğerlerini notlara yazın. Son olarak demo hesabı inceleme sırasında kimsenin değiştirmeyeceğinden emin olun; ekipten biri şifreyi sıfırlarsa bütün hazırlık boşa gider.

Gönderim sorumluluğunu ekip içinde nasıl paylaşırsınız?

Guideline 2.1 retlerinin önemli bir kısmı teknik değil, iletişim kaynaklıdır. Mobil geliştirici derlemeyi yükler, arka uç ekibi o gece sunucuyu taşır, ürün sorumlusu da notları eski sürümden kopyalar. Sonuçta herkes kendi işini doğru yapmıştır ama inceleyici çalışmayan bir uygulama görür.

Bunu önlemek için gönderim gününü küçük bir yayın süreci gibi ele alın:

1. Gönderimden sorumlu tek bir kişi belirleyin.
2. Arka uç ekibine inceleme süresince değişiklik yapmamalarını bildirin.
3. Demo hesabın şifresini ortak bir parola kasasında tutun.
4. Notları her sürümde yeniden yazın, eski metni kopyalamayın.
5. Onay gelene kadar iletişim e-postasını düzenli kontrol edin.

Böylece inceleyiciden gelen bir soruya saatler içinde yanıt verirsiniz ve süreci uzatmazsınız.

App Store Guideline 2.1 ret türleri ve çözüm tablosu

Aşağıdaki tablo, ret mesajında gördüğünüz belirtiyi olası nedene ve ilk adıma bağlar. Tablo bir başlangıç noktasıdır; kesin teşhis için kendi kayıtlarınızı inceleyin.

Kısacası, sorunun bilgi mi yoksa kod mu olduğunu ayırmak, gereksiz derleme yüklemenizi ve inceleme kuyruğunda vakit kaybetmenizi önler.

Ret sonrası App Review ekibine nasıl yanıt verirsiniz?

Apple'ın App Review mesajlarına yanıt verme sayfasına göre, yeniden gönderene kadar ekran görüntüsü ve destekleyici belge ekleyerek Apple ile yazışabilirsiniz. Ret yalnız metadata kaynaklıysa, sorunu çözdükten sonra aynı derlemeyi yeniden gönderebilirsiniz.

Yanıt adımları özetle şöyledir:

1. App Store Connect'te Apps bölümünden uygulamanızı seçin.
2. Sayfanın üstündeki açık sorunlara giden bağlantıya tıklayın.
3. Devam eden gönderimin yanındaki Resolve seçeneğini açın.
4. Reply to App Review ile yanıt alanını açın, metninizi yazın.
5. Gerekirse Attach File ile ekran görüntüsü ya da belge ekleyin ve yanıtı gönderin.

Yanıtınızı kısa ve somut tutun: neyi düzelttiğinizi, demo hesabın hangi ekranlarda denendiğini ve inceleyicinin hangi adımı izlemesi gerektiğini yazın. Savunma tonu yerine yardımcı bir ton kullanmak, yazışmayı hızlandırır.

App Review Board itirazı ne zaman mantıklıdır?

Apple'ın App Review sayfası, uygulamanızın konseptinin ya da işlevinin yanlış anlaşıldığını düşünüyorsanız App Review Board'a itiraz edebileceğinizi belirtir. Ancak aynı sayfa, itiraz öncesinde ek bilgi taleplerine yanıt vermenizi ve her ret için tek itiraz göndermenizi ister.

App Store Guideline 2.1 retlerinde itiraz nadiren ilk adımdır. Çünkü bu retler çoğu zaman gerçek bir erişim ya da kararlılık sorununu gösterir. Sorunu yeniden üretebiliyorsanız itiraz yerine düzeltme yapın. Buna karşılık her şeyi doğruladığınız halde aynı ret tekrar geliyorsa, önce ret mesajına ayrıntılı bir yanıt yazın; sonuç alamazsanız itirazı düşünün.

Ayrıca App Review sayfası, yönergeleri konuşmak için App Review ekibiyle görüntülü randevu seçeneğinden de söz eder. Karmaşık bir giriş akışınız varsa, bu görüşme itirazdan daha verimli olabilir.

Guideline 2.1 retinden sonra neleri yapmamalısınız?

Ret sonrası en büyük hata, sorunu çözmek yerine incelemeyi atlatmaya çalışmaktır. Aşağıdaki davranışlar sorunu büyütür:

• Aynı uygulamayı farklı bir geliştirici hesabıyla ya da yeni bir paket kimliğiyle yeniden yüklemek.
• Sorunlu özelliği inceleme sırasında gizleyip onaydan sonra uzaktan açmak.
• Notlara gerçeği yansıtmayan bilgi yazmak.
• Hiçbir şeyi değiştirmeden aynı derlemeyi tekrar tekrar göndermek.

Gizli özellikler ve yanıltıcı bilgi, yönergelerin başka maddelerini de devreye sokabilir ve hesap düzeyinde yaptırıma kadar uzanabilir. Örneğin Google tarafında ilişkili hesaplarla politikayı atlatma girişimlerinin nasıl sonuçlandığını Google Play geliştirici hesabı kapatıldı yazımızda anlattık. Benzer şekilde veri toplama gerekçeli bir ret alıyorsanız, Guideline 5.1.1 veri toplama reddi rehberine bakın; konular sık sık birlikte gelir.

Guideline 2.1 başka hangi ret nedenleriyle karışır?

Guideline 2.1 bazen diğer retlerle aynı mesajda gelir. Örneğin hesap oluşturma sunan bir uygulamada hesap silme seçeneği yoksa ayrı bir madde devreye girer; ayrıntılar Apple hesap silme kuralı yazımızda. Üçüncü taraf girişler kullanıyorsanız Apple ile giriş zorunlu mu sorusunu da kontrol edin.

Tüm ret nedenlerine geniş bir bakış istiyorsanız en sık uygulama reddi nedenleri rehberimiz iyi bir başlangıçtır. Android tarafında ise kapalı test şartı ve politika kaldırmaları farklı işler; bunlar için Google Play 12 test kullanıcısı şartı ve Google Play politika ihlali itirazı yazılarımıza bakabilirsiniz.

Bu ayrım önemlidir, çünkü her madde farklı bir düzeltme ister. Ret mesajındaki tüm numaraları listeleyip her birini ayrı ayrı ele almak, eksik düzeltmeyle yeniden ret alma riskini azaltır.

Gönderimden önce son kontrol listesi

Aşağıdaki listeyi her sürümde, gönderim düğmesine basmadan hemen önce uygulayın:

• Demo hesap canlı ortamda var, şifre güncel, süresi dolmuyor.
• Demo hesapta inceleyicinin göreceği örnek veri mevcut.
• Doğrulama kodu adımı demo hesap için aşılabilir durumda.
• Derleme canlı sunucu adresini kullanıyor; arka uç inceleme süresince açık.
• Uygulama yalnız IPv6 ağında da bağlantı kuruyor.
• Hiçbir ekranda yer tutucu metin ya da çalışmayan düğme yok.
• Gizlilik politikası ve destek bağlantıları çalışıyor.
• İnceleyici uygulama içi satın almaları bulabiliyor; bulamayacağı ürünün nedeni notlarda yazılı.
• Notlarda adım adım test yolu ve iletişim bilgisi güncel.

Bu liste beş dakikanızı alır ama birkaç günlük inceleme döngüsünü kurtarabilir. Üstelik ekibinizde gönderimi her seferinde farklı kişi yapıyorsa, listeyi ortak bir belgeye koymak süreci tutarlı hale getirir.

Ne zaman profesyonel destek almalısınız?

Çoğu App Store Guideline 2.1 reddi, yukarıdaki adımlarla kendi ekibiniz tarafından çözülebilir. Ancak bazı durumlarda dışarıdan bir göz işe yarar: aynı ret birkaç kez tekrar ediyorsa, çökme yalnız inceleme ortamında oluşuyorsa ya da arka uç ve mobil taraf farklı tedarikçilerin elindeyse sorunun nerede olduğunu bulmak zorlaşır.

Biz Talha Aslan ve ekibi olarak bu tür durumlarda önce ret mesajını, demo hesabı ve canlı ortamı birlikte inceliyoruz. Ardından eksik olanı düzeltip gönderim notlarını yeniden yazıyoruz. Onay kararı her zaman Apple'a aittir; bu yüzden kimsenin size kesin onay sözü vermemesi gerekir.

Yeni bir uygulamayı baştan incelemeye hazır biçimde kurmak ya da mevcut uygulamanızın gönderim sürecini düzene sokmak istiyorsanız, iOS ve Android uygulama geliştirme sayfamızdan nasıl çalıştığımızı inceleyebilir ve bize ulaşabilirsiniz.