Guideline 4.3(a) Design Spam reddi nasıl düzeltilir: şablon ve AI uygulamaları için 4.3(b) ve 4.2.6 (2026)

Guideline 4.3(a) Design Spam reddi, üzerine aksiyon alınması en zor App Review mesajlarından biridir; çünkü uygulamanızın hangi uygulamaya benzediğini nadiren söyler. Şablon uygulamalarını, white-label müşteri uygulamalarını ve yapay zekâyla üretilmiş uygulamaları diğerlerinden çok daha sık vurur. Bu rehber 4.3(a)'yı 4.3(b) ve 4.2.6'dan ayırıyor, diğer geliştiricilerin bu reddi nasıl aştığına bakıyor ve yeniden göndermeden önce tamamlamanız için bir yanıt şablonu ile kontrol listesi sunuyor. Diğer ret türleri için yönerge yönerge ret rehberine bakın.

Guideline 4.3(a) Design Spam ne anlama gelir?

Guideline 4.3(a), Apple'ın gönderiminizi daha önce gönderilmiş bir uygulamayla esasen aynı uygulama olarak gördüğü anlamına gelir: ya tek bir uygulamanın birkaç bundle ID'si ya da başkasının uygulamasının neredeyse kopyası. Çözüm, yinelenenleri birleştirmek veya temel deneyimi açıkça farklı hâle getirmektir.

Kasım 2026 itibarıyla App Review Guidelines şöyle der: "Aynı uygulama için birden fazla Bundle ID oluşturmayın (örneğin, kullanıcıların herhangi bir şehri aramasına olanak tanıyan tek bir dünya haritası yerine dünyadaki her şehir için ayrı bir harita uygulaması göndermek)." Apple'ın önerdiği alternatif ise: "tek bir uygulama göndermeyi ve varyasyonları uygulama içi satın alma ile sunmayı düşünün." 4.3(a) anahtar simgesini taşır; bu nedenle App Store dışında dağıtılan iOS ve iPadOS uygulamalarının notarizasyonu için de geçerlidir.

Geliştiricilerin genellikle aldığı ret metni şudur: "Guideline 4.3(a) - Design - Spam. Uygulamanızın, diğer geliştiriciler tarafından App Store'a gönderilen uygulamalarla yalnızca küçük farklılıklarla benzer bir binary, metadata ve/veya konsept paylaştığını fark ettik." Bu cümlede üç tetikleyici vardır (binary, metadata, konsept) ve bunlardan herhangi biri tek başına redde yol açabilir.

4.3(a), 4.3(b) ve 4.2.6'dan nasıl farklıdır?

4.3(a) yinelenen uygulamalarla, 4.3(b) zaten kalabalık bir kategoriye yeni hiçbir şey katmayan uygulamalarla, 4.2.6 ise yanlış hesaptan gönderilen şablon tabanlı uygulamalarla ilgilidir. Her biri farklı bir çözüm gerektirir; bu yüzden önce reddinizdeki yönerge numarasını tam olarak kontrol edin.

4.3(b)'nin güncel metni ayrıca Apple'ın "güncellenmeyen, geliştirilmeyen veya kullanıcı çekmeyen bu uygulamaları ileride App Store'dan kaldırabileceği" konusunda uyarır; içki oyunları ve osuruk uygulamaları gibi düşük emekli kategorilerin tekrar tekrar gönderilmesi Apple Developer Program'dan çıkarılmaya yol açabilir. Apple'ın yakın zamanda revize ettiği diğer kurallar için Ekim 2026 App Review Guidelines değişiklikleri yazımıza bakın.

Şablon ve yapay zekâyla üretilmiş uygulamalar neden spam olarak işaretlenir?

Şablon ve yapay zekâyla üretilmiş uygulamalar işaretlenir, çünkü bunların çoğu aynı başlangıç kodunu, aynı ekran düzenlerini ve benzer mağaza metinlerini paylaşır; bu da binary, metadata ve konsept tetikleyicilerinin üçüyle birden örtüşür. Sonuç yüzlerce başka uygulamaya benziyorsa, kodun sahibi olmanız uygulamayı muaf tutmaz.

Yapay zekâ uygulama oluşturucuları çoğu zaman aynı onboarding'i, aynı sekme çubuğunu ve aynı genel özellik setini ("alışkanlıkları takip et, yapay zekâ içgörüleri al") üretir; oluşturulan App Store açıklaması da çoğunlukla birbirinin aynısıdır. Bir oluşturucu üzerinden yayınladıysanız, satıcı olarak kimin göründüğünü kontrol edin. 4.2.6, şablon hizmetlerinin "müşterileri adına uygulama göndermemesi gerektiğini" söyler; dolayısıyla uygulama içerik sahibinin geliştirici hesabı altında yayınlanmalıdır. Base44 yayınlama rehberimiz ve Lovable yayınlama rehberimiz, dışa aktarmadan sonra hâlâ sizin sorumluluğunuzda kalan işleri ele alıyor.

Diğer geliştiriciler 4.3(a) reddini düzeltmek için ne yaptı?

Kamuya açık olarak paylaşılan vakalar, yalnızca görsel değişikliklerin nadiren işe yaradığını gösteriyor. Yinelenen uygulamaları birleştirmek ve uygulamayı neyin farklı kıldığını somut olarak anlatan bir yanıt yazmak daha iyi sonuç veriyor.

• Mevcut bir uygulamayla birleştirme (GitHub). Linphone tabanlı bir VoIP uygulaması yayınlayan bir ekip, linphone-iphone issue #936 kaydında yeni bir simge seti ve renk şemasının 4.3(a)'yı aşmaya yetmediğini bildirdi. Çakışmanın aynı hesaptaki başka bir Linphone tabanlı uygulamadan kaynaklandığı sonucuna vardılar. Değişiklikleri o mevcut uygulamaya güncelleme olarak eklediler ve uygulama "neredeyse anında" onaylandı.
• Benzersizliği açıklama (Godot Forum). Bir oyun geliştiricisi Godot Forum'da paylaşılan motor binary'sinin diğer Godot oyunlarıyla eşleştiğinden şüphelendi. Build boyutunu küçültmek de Godot kullandığını açıklamak da reddedildi. "Oyunumu eğlenceli ve aynı türdeki diğer oyunlardan benzersiz kıldığını düşündüğüm temel alanları listeleyen" bir yanıt ise onay getirdi.
• Ekran görüntüleri yetmedi (Apple Developer Forums). Bir Apple Developer Forums başlığında bir geliştirici, bir Apple temsilcisinin ekran görüntülerini işaret ettiğini ve "metadata"nın ad, alt başlık, anahtar kelimeler veya ekran görüntüleri anlamına gelebileceğini söyledi. Tamamen yeni ekran görüntüleri bile 2–3 yıllık bir uygulamanın güncellemesinde aynı reddi aldı.

Ortak nokta: kozmetik değişiklikler (simgeler, renkler, ekran görüntüleri) üç vakanın hepsinde başarısız oldu. İşe yarayan şey, hesaptaki yinelenen uygulamayı kaldırmak veya inceleyiciye uygulamanın neden farklı olduğuna dair özellik düzeyinde somut gerekçeler sunmaktı.

4.3(a) reddi adım adım nasıl düzeltilir?

4.3(a) reddini düzeltmek için önce yinelenen uygulamayı bulun, ardından gerçek ürün değişiklikleri yapın, sonra yeniden göndermeden önce App Review'a somut ayrıntılarla yanıt verin. Aynı build'i yeni bir simgeyle yeniden göndermek, tekrar reddedilmenin en yaygın yoludur.

1. App Store Connect'in App Review bölümündeki yönerge numarasını tam olarak okuyun. 4.2.6 veya 4.3(b) yazıyorsa, bunun yerine yukarıdaki tablonun ilgili satırını izleyin.
2. Hesabınızdaki, yayında olan veya kaldırılmış, reddedilen uygulamayla kod, şablon, konsept veya tasarım paylaşan tüm uygulamaları listeleyin. Bir tane bulursanız, bunları uygulama içi varyasyonlara sahip tek bir uygulamada birleştirin veya değişiklikleri yayındaki uygulamaya güncelleme olarak gönderin.
3. App Store'da kategori anahtar kelimelerinizi aratın ve en üstteki sonuçları not edin. Uygulamanızın bunların hiçbirinin yapmadığı neyi yaptığını yazın.
4. Yalnızca temayı değil, en az bir temel akışı (veri kaynağı, ana özellik, etkileşim modeli) değiştirin.
5. Adı, alt başlığı, anahtar kelimeleri, açıklamayı ve ekran görüntülerini, kendi özelliklerinizi anlatacak ve hiçbir genel şablon metni kalmayacak şekilde yeniden yazın.
6. Aşağıdaki şablonu kullanarak App Store Connect'te yanıt verin. Apple'ın App Review sayfası, yönergeleri doğrudan bir inceleyiciye sormak isterseniz 30 dakikalık Webex randevuları da sunar.
7. İnceleyicinin uygulamayı yanlış anladığını düşünüyorsanız, bir App Review Board itirazı yapın. Apple, "İncelemeyi geçemeyen her gönderim için yalnızca bir itiraz göndermenizi" ve önce bilgi taleplerine yanıt vermenizi ister.

App Review'a yazılacak yanıtta ne olmalı?

İyi bir yanıt, uygulamayı farklı kılan özellikleri tek tek adlandırır, hesabınızda yinelenen uygulama olmadığını teyit eder ve inceleyiciye her farkın nerede görülebileceğini gösterir. Kısa, olgulara dayalı ve nazik tutun.

Hello App Review,

Thank you for the feedback on Guideline 4.3(a). We have reviewed our account
and confirm [App Name] is our only app in this category. [We removed /
merged "Old App" into this app in version X.Y.]

What [App Name] does that similar apps do not:
1. [Feature] - e.g. syncs with the user's school timetable via [API];
   see Home > Schedule.
2. [Feature] - e.g. offline lesson plans authored by our team, not
   generated or scraped; see Library.
3. [Feature] - e.g. teacher-to-parent messaging; see the demo account.

This version also changes [core flow] and replaces all metadata and
screenshots to reflect these features.

Demo account: [username] / [password]

We are happy to provide more detail or join a call.

Thank you,
[Name]

Bir özellik giriş gerektiriyorsa, inceleyiciye çalışan kimlik bilgileri verin. App Store inceleme demo hesabı rehberimiz bunun nasıl kurulacağını gösteriyor.

Yeniden göndermeden önce farklılaştırma kontrol listesi neleri kapsamalı?

Farklılaştırma kontrol listesi; 4.3'ün baktığı dört alanı, yani hesabınızı, binary'nizi, metadata'nızı ve konseptinizi kapsamalıdır. Submit for Review'a tekrar basmadan önce her maddeyi işaretleyin.

• Hesap: yayında olan veya kaldırılmış başka hiçbir uygulama aynı şablonu, konsepti veya tasarımı paylaşmıyor.
• Hesap: uygulama, içerik sahibinin kendi geliştirici hesabından gönderiliyor (4.2.6).
• Binary: şablonun örnek ekranları, demo verileri ve yer tutucu markalama kaldırıldı.
• Binary: kategorideki üst sıralardaki sonuçlarda bulunmayan en az bir temel özellik var.
• Metadata: ad, alt başlık ve anahtar kelimeler genel olarak kategoriyi değil, sizin özgün değerinizi anlatıyor.
• Metadata: ekran görüntüleri, sizi farklılaştıran özellikleri ilk iki karede gösteriyor.
• Konsept: bir kullanıcının bu uygulamayı neden ilk beş sonuca tercih edeceğini tek cümleyle söyleyebiliyorsunuz.
• İnceleme notları: farklılıklar ve bir demo hesap listelenmiş, böylece inceleyicinin bunları aramasına gerek kalmıyor.

4.3 kapsamında birden fazla kez reddedildiyseniz ve neyi değiştireceğinizden emin değilseniz, App Store gönderim hizmetimiz incelemeyi hazırlar ve ret geri bildirimlerini sizinle birlikte ele alır; iki mağazayı da kapsayan ücret $599'dır (geliştirici hesabı ücretleri ayrıdır).