App Store Spam Reddi: Guideline 4.3 Neden Olur, Nasıl Geçilir?

App Store spam reddi (Guideline 4.3) nedir ve ilk ne yapmalısınız?

App Store spam reddi, yani Guideline 4.3, Apple'ın inceleme ekibinin uygulamanızı mevcut uygulamalardan ayırt edilemez bulduğunu ya da aynı uygulamayı birden fazla Bundle ID ile gönderdiğinizi söylemesidir. İlk adım olarak reddi kopyalayın, hangi alt maddenin (a veya b) geçtiğini bulun ve ona göre farklılaşma planı çıkarın.

Panik yapmayın, çünkü bu red çoğu zaman düzeltilebilir. Ancak Apple onay garantisi vermez, biz de veremeyiz.

Önce şu adımları sırayla uygulayın:

1. Red mesajını tam metniyle kaydedin ve yönerge numarasını not edin.
2. Mesajda 4.3(a) mı yoksa 4.3(b) mi geçtiğini ayırın.
3. Uygulamanızı kategorinizdeki en yakın üç rakiple yan yana koyun.
4. Gerçekten farklı olan özellikleri yazın, olmayanları dürüstçe eleyin.
5. Düzeltmeden önce yanıt göndermeyin, çünkü zayıf bir yanıt süreci uzatır.

Bu yüzden şunu baştan söyleyelim: reddin kendisi bir ceza değil, bir geri bildirimdir. İnceleyici uygulamanızın mağazadaki yerini sorgular; siz de o soruya somut bir cevap verirsiniz. Bu yazı yalnızca bu tek reddi ele alır. Genel iOS geliştirme için React Native rehberimize ve Swift mülakat sorularına göz atabilirsiniz.

Bu red mesajı neye benzer ve nerede görürsünüz?

Mesajı App Store Connect içindeki inceleme bildirimi alanında, yani Resolution Center diye bilinen yazışma bölümünde görürsünüz. Apple genellikle yönerge numarasını, kısa bir gerekçeyi ve bazen ek sorular ya da örnekleri yazar. Menü adları zamanla değişebilir, bu yüzden panelde ilgili bölüme bakın.

Biz mesajın birebir metnini burada yazmıyoruz. Apple metni sürüm sürüm değiştirebilir; yani sizin gördüğünüz ifade bizimkinden farklı olabilir. Genel kalıp şuna benzer: Apple uygulamanızı spam kapsamında görüyor, mevcut uygulamalardan ayırt edemiyor ya da gereksiz çoğaltma buluyor.

Mesajda dikkat edeceğiniz üç ayrıntı vardır:

• Hangi alt madde geçiyor, (a) mı (b) mi?
• Apple hangi uygulamayı ya da hangi benzerliği örnek gösteriyor?
• Mesaj bir soru içeriyor mu, yoksa yalnızca hüküm mü bildiriyor?

Bu üç cevap, yanıt stratejinizi doğrudan belirler. Örneğin Apple belirli bir rakibi örnek gösteriyorsa, önce o uygulamayı indirip özellik özellik karşılaştırın. Mesaj örnek vermiyorsa, kategorinin en çok indirilen üç uygulamasını kendiniz seçin.

Guideline 4.3(a) ile 4.3(b) arasındaki fark nedir?

Apple App Review Guidelines içinde 4.3 maddesini iki alt maddeye böler. 4.3(a), aynı uygulamanın birden fazla Bundle ID ile çoğaltılmasını hedefler. 4.3(b) ise piyasada yaygın olarak bulunan uygulamalardan ayırt edilemeyen yeni gönderimleri hedefler.

Bu ayrım önemlidir, çünkü çözümleri farklıdır. Birincisinde yapı sorununuz vardır, ikincisinde ise ürün farkı sorununuz.

Aşağıdaki tablo ikisini yan yana koyar:

Mesajınızda hangisi geçiyorsa, yazının ilgili bölümüne gidin.

Aynı uygulamanın birden fazla Bundle ID'si neden sorun olur?

Apple yönergesi bu konuda açık bir örnek verir: dünyadaki her şehir için ayrı bir harita uygulaması göndermek yerine, kullanıcının herhangi bir şehri aratabildiği tek bir uygulama göndermelisiniz. Gerekçe de yazılıdır; gereksiz uygulamalar kullanıcının aradığını bulmasını zorlaştırır.

Peki bu sizin işinizde neye benzer? Örnek senaryo: bir spor kulübü ağı her şube için ayrı uygulama gönderiyor. Her uygulama aynı kodu, farklı logoyla taşıyor.

Bu durumda Apple'ın önerisi nettir. Yönergeye göre belirli konumlara, spor takımlarına ya da üniversitelere göre farklı sürümleriniz varsa tek bir uygulama gönderin. Varyasyonları uygulama içi satın alma ile sunmayı düşünün.

Bu yaklaşım geliştirme maliyetini de düşürür, çünkü tek kod tabanı tek bakım demektir. Kendinize şu soruyu sorun: kullanıcı şube değiştirmek için ikinci bir uygulama mı indirmeli, yoksa uygulama içinde seçim mi yapmalı? Cevap ikincisiyse mimariyi tek uygulamaya çevirin.

Hangi uygulama türlerini 4.3(b) doymuş kabul eder?

Apple yönergesi bazı kategorileri "App Store'da köklü" olarak adlandırır. Örnek olarak flört, el feneri, ses efektleri, duvar kağıdı, basit zamanlayıcı ve fal uygulamalarını sayar. Bu kategorilerde anlamlı biçimde farklı ya da daha iyi bir deneyim sunmayan yeni gönderimi Apple kabul etmez.

Yönerge ayrıca şunu da söyler: güncellenmeyen, geliştirilmeyen ya da kullanıcı çekmeyen bu tür uygulamalar mağazadan kaldırılabilir.

Dolayısıyla doymuş bir kategoriye girmeden önce iki şeyi tartın:

• Kategoride yeni bir bakış açınız, veri kaynağınız ya da iş akışınız var mı?
• Farkı ilk açılışta, yani inceleyicinin ilk beş dakikasında görebilir mi?

Farkı tek cümleyle anlatamıyorsanız, inceleyici de büyük ihtimalle göremez. Bunu test etmek kolaydır: uygulamanızı hiç görmemiş birine tek cümleyle anlatın ve "bunu başka uygulamada da yapabilir miyim?" diye sorun. Bu yüzden sunum ve özellik listesini sadeleştirin, farkı öne çıkarın.

Şablon ve white label uygulamalar neden bu reddi alır?

Aynı iskeletten çıkan uygulamalar tipik olarak 4.3'e takılır. Ayrıca yönergenin 4.2.6 maddesi de ilgilidir: ticari bir şablondan ya da uygulama üretim hizmetinden çıkan uygulamalar, içeriğin sağlayıcısı doğrudan göndermedikçe reddedilir.

Aynı maddede kabul edilen seçenekler de vardır. Şablon sağlayıcı, müşterilerine özgün ve yenilikçi uygulama üretme araçları vermelidir. Başka bir seçenek, tüm müşteri içeriğini tek bir ikili dosyada toplayan "seçici" modelidir.

Bu nedenle ajans ya da yazılım şirketiyseniz müşteri adına gönderim yapmadan önce durun. Şu soruları sorun:

• Her müşteri uygulaması gerçekten özgün bir deneyim mi sunuyor?
• Uygulamayı içeriğin sahibi mi gönderiyor, yoksa siz mi adına gönderiyorsunuz?
• Tek bir çatı uygulamada müşterileri toplamak mümkün mü?

Mimari kararlarda mobil uygulama geliştirme hizmetimiz kapsamında ekibimizle konuşabilirsiniz.

Webview sarmalayıcı uygulama 4.2 ile mi, 4.3 ile mi karışır?

İkisi ayrı maddedir. 4.2 Minimum Functionality, uygulamanızın yeniden paketlenmiş bir web sitesinin ötesinde özellik, içerik ve arayüz sunmasını ister. Yönergeye göre yeterince kullanışlı, benzersiz ya da "uygulama gibi" değilse mağazada yeri yoktur.

Webview ile web sitenizi saran bir uygulama bu yüzden önce 4.2 riskine girer. 4.3 ise farklı bir soruyu sorar: bu uygulama zaten bol bulunan uygulamalardan ayırt edilebilir mi?

Pratikte ikisi birlikte gelebilir. Örneğin yalnızca web sitenizi gösteren bir şablon uygulama hem 4.2 hem 4.3 tartışması yaratır.

Mesajda hangi numara geçiyorsa, yanıtınızı ona göre kurun. Web tarafının kalitesi için mobil uyumluluk testi aracımızı ve mobil uyumluluk rehberimizi kullanabilirsiniz.

App Store spam reddi ile 4.1 kopya reddi aynı şey mi?

Hayır, aynı değildir. 4.1 Copycats, popüler bir uygulamayı kopyalamayı ya da başka bir uygulamanın adı veya arayüzünde küçük değişiklikler yapıp kendi uygulamanızmış gibi sunmayı hedefler. Ayrıca fikri mülkiyet riskine de dikkat çeker.

4.3(b) ise kopya olmasa bile "yeterince farklı olmayan" uygulamaları kapsar. Yani özgün kodla yazdığınız bir uygulama, piyasadaki yüzlerce benzerinden ayırt edilemiyorsa yine takılabilir.

Aşağıdaki karşılaştırma farkı özetler:

• 4.1: Başkasının fikrini, adını ya da tasarımını taklit etme sorunu.
• 4.3(a): Kendi uygulamanızı gereksiz çoğaltma sorunu.
• 4.3(b): Kendi emeğiniz olsa bile ayırt edilemezlik sorunu.

Bu ayrım yanıtınızı etkiler. Kopya iddiasında özgün olduğunuzu kanıtlamanız yeter. Ayırt edilemezlik iddiasına ise somut fark göstermeniz gerekir.

Aynı kodla birden fazla geliştirici hesabı kullanmak çözüm olur mu?

Hayır, olmaz; üstelik riskli bir yoldur. Yönergede hesap sayısını ayrıca düzenleyen bir cümle bulmadık. Ancak 4.3(a) zaten uygulama çoğalmasını engellemek için vardır. Aynı uygulamayı farklı hesaplardan göndermek bu amacı atlatmaya çalışmak anlamına gelir.

Yönerge, tekrarlanan gönderimlerin bazı durumlarda Apple Developer Program'dan çıkarılmaya yol açabileceğini söyler. Yeni hesap açarak ya da başkasının hesabını kullanarak reddi aşmaya çalışmak, sistemleri atlatmak anlamına gelir. Bunu önermiyoruz ve bu yolda yardım etmiyoruz. Kurallara uygun yolun bir kısayolu da yoktur; çünkü Apple, aynı geliştiriciden gelen benzer paketleri başka hesaplarla da eşleştirebilir.

Doğru yol şudur:

• Aynı uygulamanın varyantlarını tek Bundle ID altında birleştirin.
• Gerçekten ayrı ürünler için ayrı, gerçekten farklı uygulamalar üretin.
• Sorunuz varsa Apple'a açıkça yazın.

Hesabınızı ilgilendiren bir ihlal şüphesi varsa hukuki danışmanlık için bir avukata başvurun; bu yazı hukuki danışmanlık değildir.

Red geldikten sonra hangi sırayla ilerlemelisiniz?

Sakin ve sıralı ilerlemek en iyi sonucu verir. Aşağıdaki sıra sahada işe yarayan bir iskelettir, ama garanti içermez.

1. Mesajı tam okuyun ve (a) ya da (b) ayrımını belirleyin.
2. Örnek gösterilen uygulamaları indirip karşılaştırın.
3. Farkı yaratacak bir ürün değişikliği listesi çıkarın.
4. Değişiklikleri uygulamaya gerçekten ekleyin, yalnızca açıklama metnini değiştirmeyin.
5. App Store Connect'teki inceleme notlarını güncelleyin.
6. Yeni derlemeyi gönderin ve Resolution Center'da kısa bir yanıt yazın.

Üçüncü adımı atlamak en sık görülen hatadır. Çünkü yalnızca metinle yapılan itiraz, aynı ürünü aynı gerekçeyle tekrar reddettirir.

Ayrıca düzeltme sürecinde mağaza listesini de gözden geçirin. Başlık, alt başlık ve açıklama uygulamanın gerçek işlevini yansıtmalı; abartılı ya da yanıltıcı ifadeler yeni bir red sebebi olabilir. Anahtar kelime doldurmak da işe yaramaz. İnceleyici önce uygulamanın kendisine, sonra listeye bakar, bu yüzden ikisinin tutarlı olması gerekir.

Bir de zamanlama vardır. Acele edip aynı derlemeyi yeniden göndermek yerine, farkı gerçekten kodlayın.

Uygulamanızı mevcut uygulamalardan nasıl farklılaştırırsınız?

Farklılaşma bir slogan değil, inceleyicinin ilk dakikalarda gördüğü işlevdir. Bu yüzden sorulması gereken soru "farkım ne?" değil, "inceleyici bunu açıp neyi görecek?" sorusudur.

Somut farklılaşma yolları şunlardır:

• Kategoride bulunmayan bir veri kaynağı ya da entegrasyon eklemek.
• Kullanıcının zamanını gerçekten kısaltan bir iş akışı kurmak.
• Cihaz özelliklerini (kamera, bildirim, widget) uygulamanın çekirdeğinde kullanmak.
• Çevrimdışı çalışma, senkronizasyon ya da kişiselleştirme gibi kalıcı değer sunmak.
• Belirli bir kullanıcı grubuna özel, tutarlı bir deneyim tasarlamak.

Örnek senaryo: basit bir hatırlatıcı uygulaması, yalnızca bir kurs takvimiyle entegre çalışıyorsa niş ve ayırt edilebilir olur. Aynı mantık bir yemek tarifi uygulamasında da işler: belirli bir mutfağa, malzeme stokuna ve haftalık menüye bağlanan uygulama, genel tarif listesinden ayrışır.

Marka tarafında da tutarlılık gerekir. İsim, ikon ve ekran görüntüleri ürün farkını anlatmalı; bunun için marka kimliği hizmetimize bakabilirsiniz.

Resolution Center'da App Store spam reddi yanıtını nasıl yazarsınız?

Yanıt kısa, olgusal ve kanıta dayalı olmalıdır. Kızgın ya da savunmacı bir ton, süreci hızlandırmaz. İnceleyici sizi tanımaz; yalnızca yazdığınıza ve uygulamanın içinde gördüğüne bakar.

İyi bir yanıtın bölümleri şunlardır:

1. Bir cümlelik özet: ne değiştirdiniz.
2. Reddedilen yönerge numarasına doğrudan atıf.
3. Somut farklılıkların madde madde listesi.
4. İnceleyicinin bunları nerede göreceği, adım adım.
5. Gerekliyse demo hesap ve giriş bilgisi.

Yönerge, inceleme notlarında yeni özellikleri ayrıntılı anlatmanızı ister; Apple genel ve belirsiz açıklamaları kabul etmez. Dolayısıyla "uygulamamız benzersizdir" demek yerine "ana ekrandaki şu akış kategoride bulunmayan şunu yapar" yazın.

Gönderimden önce uygulamayı sıfır bilgili bir kişiye vererek ilk beş dakikasını izleyin. Kişi farkı kendiliğinden bulamıyorsa, inceleyici de bulamayabilir. Ayrıca site yayın öncesi test listemizdeki mantığı uygulayın: göndermeden önce her adımı kendiniz deneyin.

Örnek bir yanıt iskeleti neye benzer?

Aşağıdaki, tamamen kurgusal bir örnek senaryodur; kendi uygulamanıza göre uyarlayın.

Senaryo: Apple bir kurs takip uygulamasını 4.3(b) gerekçesiyle reddetti. Uygulama basit bir hatırlatıcı gibi görünüyordu.

Yanıtın akışı şöyle olabilir:

• Selamlama ve teşekkür: tek kısa cümle.
• Ne değişti: kurs takvimi entegrasyonunu ve ders başına yoklama kaydını ekledik.
• Nereye bakacaksınız: ana ekran, ardından takvim sekmesi, ardından bir kurs seçimi.
• Neden farklı: genel hatırlatıcılar kurs yapısını bilmez, bu uygulama bilir.
• Test erişimi: demo hesap bilgileri inceleme notlarında.

Yanıtta rakip uygulamaları kötülemeyin; ayrıca tehdit ya da suçlama içeren cümlelerden kaçının. Bunun yerine kendi değer önerinizi gösterin. Örneğin "kurs yoklamasını tek dokunuşla kaydediyoruz" gibi doğrulanabilir bir cümle, genel bir övgüden çok daha güçlüdür.

Uzun paragraflar yazmayın. İnceleyici kısa, taranabilir bir mesajı daha iyi anlar. Her satırın bir kanıtı olsun.

İtiraz ne zaman mantıklıdır ve nasıl yaparsınız?

Apple yönergesi bir itiraz yolu tarif eder: incelemenin sonucuna katılmıyorsanız itiraz gönderebilirsiniz. Bu, uygulamanızın mağazaya girmesine yardımcı olabilir, ama garanti etmez. Geliştiriciler bu süreci çoğunlukla App Review Board diye anar; ayrıntıyı Apple'ın güncel sayfasından kontrol edin.

İtiraz şu durumlarda mantıklıdır:

• Apple'ın yönergeyi yanlış uyguladığını somut kanıtla gösterebiliyorsanız.
• Uygulamanız tek Bundle ID'de ve gerçekten farklıysa.
• Resolution Center'daki yazışma sonuç vermediyse.

Şu durumlarda mantıksızdır:

• Hiçbir ürün değişikliği yapmadıysanız.
• Aynı gerekçeyi tekrarlıyorsanız.
• Öfkeli bir dil kullanıyorsanız.

İtirazı yazarken yanıt iskeletindeki kanıtları kullanın; ekran akışı, özellik karşılaştırması ve değişiklik listesi yeterlidir. Yani önce düzeltin, sonra itiraz edin; çünkü kanıtsız itiraz sonucu değiştirmez. İtiraz süresi ve koşulları değişebildiği için güncel kuralları resmî sayfadan kontrol edin.

Çok sayıda varyasyonu tek uygulamada nasıl birleştirirsiniz?

4.3(a) için Apple'ın önerdiği çözüm basittir: tek uygulama gönderin ve varyasyonları uygulama içi satın alma ile sunun. Bunu planlarken önce mevcut ürünlerinizi envanterleyin.

Bir birleştirme planı şu adımlardan oluşur:

1. Hangi uygulamaların aynı koddan çıktığını listeleyin.
2. Farkın nerede olduğunu belirleyin: içerik mi, bölge mi, marka mı?
3. Farkı veri katmanına taşıyın; kod tek, içerik ayrı olsun.
4. Kullanıcıya uygulama içinde seçim ekranı sunun.
5. Eski uygulamaların kullanıcılarını yeni uygulamaya yönlendirin.

Geçişte kullanıcı verisini kaybetmemek en kritik noktadır. Hesaplar, satın almalar ve tercihler yeni yapıda da çalışmalı; bunu yayından önce test edin. Bu geçiş mimari bir iştir. Küçük bir değişiklik gibi görünse de test, veri taşıma ve yayın planı ister.

Karmaşık geçişlerde özel yazılım geliştirme hizmetimiz devreye girebilir. Ancak ücret ya da süre konusunda burada rakam vermiyoruz, çünkü proje kapsamına göre değişir.

App Store spam reddi için hangi yolu izlersiniz?

Kafanızı toplamak için aşağıdaki tablo mesaj türüne göre yol haritası verir. Örnekler genel bir çerçevedir; Apple her başvuruyu kendi koşullarıyla değerlendirir.

Bu tablodaki eşleşmeler kesin hüküm değildir. Mesajdaki yönerge numarası her zaman önceliklidir.

Göndermeden önce hangi kontrol listesini uygulamalısınız?

Aşağıdaki liste yeni gönderimlerde reddi azaltmaya yardım eder. Elbette hiçbir liste onayı garanti etmez.

• Uygulama başka bir Bundle ID ile aynı işi yapmıyor.
• İlk açılışta görünen en az bir belirgin fark var.
• İsim, ikon ve ekran görüntüleri başka bir uygulamayı taklit etmiyor.
• Uygulama yalnızca web sitesini göstermiyor.
• Şablon üretimiyse, gönderen içeriğin sahibi.
• İnceleme notları özelliklerin yerini adım adım açıklıyor.
• Demo hesap ve arka uç hizmetleri inceleme sırasında çalışıyor.
• Açıklama metni uygulamanın yapmadığı bir şeyi vaat etmiyor.

Ayrıca uygulamanın web karşılığı için UX denetimi rehberimizdeki adımları da deneyebilirsiniz. Böylece kullanıcıya görünen akışları önceden temizlersiniz.

Reddi tekrarlatan en sık hatalar neler?

Sahada gördüğümüz tekrar eden hatalar şunlardır. Her biri ayrı bir kayıp zamandır, çünkü yeni bir gönderim yeni bir inceleme demektir. Bunlar bir istatistik değil, gözlem niteliğindedir.

• Yalnızca açıklama metnini ve ekran görüntülerini değiştirip ürüne dokunmamak.
• İncelemeciye aynı gerekçeyi birkaç kez yazmak.
• Rakibin adını ya da markasını anarak karşılaştırma yapmak.
• Tek koddan çıkan uygulamaları sırayla yüklemeye devam etmek.
• Yönerge numarasını yanlış okuyup yanlış probleme çözüm aramak.
• Reddi kişisel algılayıp tonu sertleştirmek.

Bunların çoğu, sorunun yapısal olduğunu kabul etmemekten doğar. Dolayısıyla önce mimariye, sonra metne bakın.

Ayrıca hesap kurtarma ya da onay vaat eden, tanımadığınız kişilerden para karşılığı hizmet almayın. Apple'ın kararını dışarıdan kimse garanti edemez.

Ürün farkını nasıl ölçer ve kanıtlarsınız?

Farkı hissetmek yetmez; gösterebilmeniz gerekir. Bunun için kategorinizdeki üç dört uygulamayı seçin ve basit bir karşılaştırma matrisi çıkarın. Matris, hem sizin hem de inceleyicinin aynı tabloya bakmasını sağlar.

Aşağıdaki örnek matris, tamamen kurgusal bir örnek senaryodur:

Matrisi okuduğunuzda "Var" olan ortak satırlar fark yaratmaz. Fark yaratan satırlar yalnızca sizde olanlardır. Bu yüzden ürün çalışmanızı o satırlara yoğunlaştırın, ayrıca inceleme notunda aynı satırları öne çıkarın.

Bir uyarı ekleyelim: matrise yazdığınız her satır uygulamada gerçekten çalışmalı. Çalışmayan bir özelliği yazmak, yönergenin yanıltıcı pazarlama konusundaki hükmüne takılır.

Hangi senaryolar 4.3 riski taşır?

Sahada en sık gördüğümüz senaryolar şunlardır. Hepsi örnek senaryodur, gerçek bir müşteriye ait değildir.

• Şubesi çok olan bir işletme, her şube için ayrı uygulama göndermek ister.
• Ajanslar çoğu zaman aynı iskeleti on farklı müşteriye uygular.
• Etkinlik uygulamaları her etkinlik için yeni bir Bundle ID açabilir.
• Girişimciler bazen doymuş bir kategoride yalnızca renk ve ikon değiştirip yeni uygulama yayımlar.
• Markalar kimi zaman web sitesini hiçbir yerel özellik eklemeden uygulamaya sarar.

İlk üç senaryoda genelde 4.3(a) ya da şablon sorunu vardır. Son ikisinde ise 4.3(b) ve 4.2 gündeme gelir.

Kendi senaryonuzu bu listeyle karşılaştırın. Eşleşme varsa çözüm çoğu zaman üründe değil mimaridedir; yani sorun kodun düzeninde, metinde değildir.

İnceleme notlarını nasıl hazırlarsınız?

İnceleme notları, uygulamanızı ilk kez gören biri için yazılmış bir kullanım kılavuzudur. Yönerge, kısıtlı ya da belirsiz açıklamaları kabul etmediğini ve ayrıntı istediğini söyler. Bu nedenle notlarınızı kısa ama somut tutun.

İyi bir notun bölümleri şunlardır:

1. Uygulamanın tek cümlelik amacı.
2. Kategorideki benzerlerden farkı, üç maddeyle.
3. Farkı görmek için izlenecek ekran akışı.
4. Demo hesap bilgileri ve gerekiyorsa örnek veri.
5. Arka uç hizmetlerinin inceleme sırasında açık olduğunu belirten bir cümle.

Yönerge ayrıca giriş bilgisi gerektiren uygulamalarda demo hesap ya da tam özellikli demo modu istediğini söyler. Dolayısıyla erişim engeli yüzünden reddi artırmayın.

Notu yazdıktan sonra bir arkadaşınıza verin ve yalnızca bu notla uygulamayı gezmesini isteyin. Takıldığı her yer, inceleyicinin de takılacağı yerdir.

Reddi ekip içinde nasıl yönetirsiniz?

Red geldiğinde ekipteki herkes aynı dili konuşmalı. Aksi halde ürün, geliştirme ve pazarlama farklı şeyler anlar, yanıt da dağınık çıkar.

Basit bir iş bölümü işinizi kolaylaştırır:

• Ürün sorumlusu farkı tanımlar ve rakip matrisini hazırlar.
• Geliştirici yapısal değişikliği ya da yeni özelliği uygular.
• İçerik sorumlusu mağaza açıklamasını ve ekran görüntülerini günceller.
• Tek bir kişi Resolution Center yazışmasını yürütür.

Tek ses önemlidir. Çünkü aynı konuya iki farklı kişi iki farklı yanıt yazarsa, inceleyici tutarsızlık görür.

Ayrıca her adımı bir kayıt defterine yazın: ne zaman ne gönderdiniz, Apple ne yanıtladı. Böylece bir sonraki gönderimde aynı hatayı tekrarlamazsınız. Bu yaklaşım, benzer mağaza reddi için de işe yarar.

Benzer hata mesajlarında aynı mantığı nasıl uygularsınız?

Spesifik bir hata mesajı gördüğünüzde yöntem hep aynıdır: mesajı tam okuyun, tek nedene inin, sonra ölçülebilir bir düzeltme yapın. Mağaza reddinde yönerge numarası, altyapı hatalarında hata kodu bu işi görür.

Örneğin bir dosya paylaşımında indirme kotası hatası alıyorsanız, Google Drive indirme kotası rehberimize bakabilirsiniz. Sitenizde Cloudflare tarafında bağlantı zaman aşımı görüyorsanız, Cloudflare 522 çözüm yazımız işinize yarar.

Her iki durumda da önce kodu okur, sonra varsayım yerine kanıtla ilerlersiniz. Aynı disiplin App Store spam reddi için de geçerlidir.

Daha fazla bilgi için Apple'ın App Review Guidelines sayfasını, arayüz kalitesi için Human Interface Guidelines belgesini ve App Store Connect Yardım sayfalarını resmî kaynak olarak kullanın.

Bu süreçte ekip olarak nasıl destek oluruz?

Talha Aslan ve ekibi olarak mobil uygulama mimarisi, ürün farklılaştırma ve yayın hazırlığı konularında destek veririz. Bununla birlikte Apple'ın inceleme kararını biz veremeyiz ve onay sözü vermeyiz.

Genellikle şu işlerde yardımcı oluruz:

• Red mesajının hangi yapısal soruna işaret ettiğini birlikte okumak.
• Tek uygulamada birleştirme ve varyasyon mimarisi planlamak.
• Farkı gösteren ekran akışlarını ve inceleme notlarını hazırlamak.
• Yayın öncesi kalite kontrolünü yapmak.

Kısacası amaç, reddi tek seferde "atlatmak" değil, uygulamayı gerçekten ayırt edilebilir kılmaktır. Bunun için mobil uygulama geliştirme sayfamıza göz atabilirsiniz.

Not: Bu yazı hukuki ya da resmî danışmanlık değildir. Güncel yönergeyi her zaman Apple'ın resmî sayfasından kontrol edin.