Wytyczna 4.3(a) Design Spam: jak to naprawić. 4.3(b) i 4.2.6 dla aplikacji z szablonów i AI (2026)

Odrzucenie z Guideline 4.3(a) Design Spam to jedna z najtrudniejszych do obsłużenia wiadomości od App Review, bo rzadko mówi, do której aplikacji Twoja jest podobna. Znacznie częściej niż inne trafia aplikacje z szablonów, aplikacje white-label dla klientów i aplikacje generowane przez AI. Ten poradnik oddziela 4.3(a) od 4.3(b) i 4.2.6, pokazuje, jak inni deweloperzy poradzili sobie z odrzuceniem, i daje Ci szablon odpowiedzi oraz listę kontrolną do wykonania przed ponownym zgłoszeniem. Inne typy odrzuceń opisuje przewodnik po odrzuceniach według wytycznych.

Co oznacza Wytyczna 4.3(a) Design Spam?

Wytyczna 4.3(a) oznacza, że Apple uważa Twoje zgłoszenie za zasadniczo tę samą aplikację co już zgłoszona: albo kilka Bundle ID jednej aplikacji, albo niemal kopię cudzej. Rozwiązaniem jest połączenie duplikatów lub wyraźne odróżnienie głównego doświadczenia.

Według stanu na listopad 2026 App Review Guidelines mówią: „Nie twórz wielu Bundle ID tej samej aplikacji (na przykład zgłaszając osobną aplikację z mapą dla każdego miasta na świecie zamiast jednej ogólnoświatowej mapy, która pozwala użytkownikom wyszukać dowolne miasto)”. Alternatywa sugerowana przez Apple brzmi: „rozważ zgłoszenie jednej aplikacji i udostępnienie wariantów przez zakupy w aplikacji”. Punkt 4.3(a) jest oznaczony ikoną klucza, więc dotyczy także notaryzacji aplikacji na iOS i iPadOS dystrybuowanych poza App Store.

Treść odrzucenia, którą deweloperzy zwykle dostają, brzmi: „Guideline 4.3(a) - Design - Spam. We noticed your app shares a similar binary, metadata, and/or concept as apps submitted to the App Store by other developers, with only minor differences.” (czyli: aplikacja ma podobny plik binarny, metadane i/lub koncepcję jak aplikacje innych deweloperów, z jedynie drobnymi różnicami). W tym zdaniu są trzy wyzwalacze (plik binarny, metadane, koncepcja) i każdy z nich z osobna może spowodować odrzucenie.

Czym 4.3(a) różni się od 4.3(b) i 4.2.6?

4.3(a) dotyczy duplikatów, 4.3(b) aplikacji, które nie wnoszą niczego nowego do już zatłoczonej kategorii, a 4.2.6 aplikacji zbudowanych z szablonów i zgłoszonych z niewłaściwego konta. Każda z nich wymaga innej poprawki, więc najpierw sprawdź dokładny numer wytycznej w odrzuceniu.

Aktualna treść 4.3(b) ostrzega też, że Apple „może w przyszłości usuwać takie aplikacje z App Store, jeśli nie będą aktualizowane, ulepszane lub nie przyciągną klientów”, a niskonakładowe kategorie, takie jak gry alkoholowe czy aplikacje z odgłosami pierdzenia, przy wielokrotnym zgłaszaniu mogą skończyć się usunięciem z Apple Developer Program. Inne niedawno zmienione przez Apple zasady opisujemy w artykule o zmianach w App Review Guidelines z października 2026.

Dlaczego aplikacje z szablonów i generowane przez AI są oznaczane jako spam?

Aplikacje z szablonów i generowane przez AI są oznaczane, ponieważ wiele z nich ma ten sam kod startowy, te same układy ekranów i podobne teksty w sklepie, co pasuje do wszystkich trzech wyzwalaczy: pliku binarnego, metadanych i koncepcji. Bycie właścicielem kodu nie chroni aplikacji, jeśli efekt wygląda jak setki innych.

Kreatory aplikacji AI często generują ten sam onboarding, ten sam pasek kart i ten sam ogólny zestaw funkcji („śledź nawyki, otrzymuj wskazówki od AI”), a wygenerowany opis w App Store też często brzmi tak samo. Jeśli publikujesz przez kreator, sprawdź, kto widnieje jako sprzedawca. 4.2.6 mówi, że usługi szablonowe „nie powinny zgłaszać aplikacji w imieniu swoich klientów”, więc aplikacja powinna zostać opublikowana z konta deweloperskiego właściciela treści. Nasz poradnik publikacji z Base44 i poradnik publikacji z Lovable opisują, co po eksporcie pozostaje Twoim zadaniem.

Co zrobili inni deweloperzy, by naprawić odrzucenie z 4.3(a)?

Publicznie opisane przypadki pokazują, że same zmiany wizualne rzadko działają. Lepiej sprawdza się połączenie zduplikowanych aplikacji i konkretna odpowiedź opisująca, co wyróżnia aplikację.

• Połączenie z istniejącą aplikacją (GitHub). Zespół rozwijający aplikację VoIP opartą na Linphone opisał w zgłoszeniu linphone-iphone #936, że nowy zestaw ikon i kolorystyka nie pomogły przejść 4.3(a). Doszli do wniosku, że konflikt dotyczył innej aplikacji opartej na Linphone na tym samym koncie. Wprowadzili zmiany do tej istniejącej aplikacji jako aktualizację i przeszła „niemal od razu”.
• Wyjaśnienie unikalności (Godot Forum). Twórca gier na Godot Forum podejrzewał, że wspólny plik binarny silnika był dopasowywany do innych gier w Godot. Zarówno zmniejszenie buildu, jak i wyjaśnienie, że gra korzysta z Godot, skończyły się odrzuceniem. Zatwierdzenie przyniosła dopiero odpowiedź „wymieniająca kluczowe obszary, które moim zdaniem czyniły grę przyjemną i unikalną na tle innych gier z tego samego gatunku”.
• Zrzuty ekranu nie wystarczyły (Apple Developer Forums). W wątku na Apple Developer Forums jeden z deweloperów napisał, że przedstawiciel Apple wskazał na zrzuty ekranu i że „metadane” mogą oznaczać nazwę, podtytuł, słowa kluczowe lub zrzuty ekranu. Całkowicie nowe zrzuty ekranu i tak dostały to samo odrzucenie, przy aktualizacji aplikacji, która miała 2–3 lata.

Wspólny wniosek: zmiany kosmetyczne (ikony, kolory, zrzuty ekranu) zawiodły we wszystkich trzech przypadkach. Zadziałało usunięcie duplikatu z konta albo podanie recenzentowi konkretnych, opartych na funkcjach powodów, dla których aplikacja jest inna.

Jak krok po kroku naprawić odrzucenie z 4.3(a)?

Aby naprawić odrzucenie z 4.3(a), najpierw znajdź duplikat, potem wprowadź rzeczywiste zmiany w produkcie, a następnie odpowiedz App Review konkretami, zanim zgłosisz aplikację ponownie. Ponowne zgłoszenie tego samego buildu z nową ikoną to najczęstszy sposób na kolejne odrzucenie.

1. Przeczytaj dokładny numer wytycznej w sekcji App Review w App Store Connect. Jeśli to 4.2.6 lub 4.3(b), postępuj według odpowiedniego wiersza tabeli powyżej.
2. Wypisz wszystkie aplikacje na koncie, aktywne lub usunięte, które mają wspólny kod, szablon, koncepcję lub design z odrzuconą. Jeśli znajdziesz taką, połącz je w jedną aplikację z wariantami w aplikacji albo wypuść zmiany jako aktualizację aktywnej aplikacji.
3. Wyszukaj w App Store słowa kluczowe swojej kategorii i zanotuj najwyższe wyniki. Zapisz, co robi Twoja aplikacja, czego nie robi żadna z nich.
4. Zmień przynajmniej jeden główny przepływ (źródło danych, główną funkcję, model interakcji), a nie tylko motyw.
5. Przepisz nazwę, podtytuł, słowa kluczowe, opis i zrzuty ekranu tak, by opisywały Twoje konkretne funkcje i nie został żaden ogólny tekst z szablonu.
6. Odpowiedz w App Store Connect, korzystając z poniższego szablonu. Strona App Review Apple oferuje też 30-minutowe spotkania przez Webex, jeśli chcesz zapytać recenzenta bezpośrednio o wytyczne.
7. Jeśli uważasz, że recenzent źle zrozumiał aplikację, złóż jedno odwołanie do App Review Board. Apple prosi, by „zgłaszać tylko jedno odwołanie na zgłoszenie, które nie przeszło review”, i by najpierw odpowiedzieć na prośby o informacje.

Co powinna zawierać odpowiedź do App Review?

Dobra odpowiedź wymienia konkretne funkcje, które wyróżniają aplikację, potwierdza, że na koncie nie ma zduplikowanych aplikacji, i wskazuje recenzentowi, gdzie można zobaczyć każdą różnicę. Niech będzie krótka, rzeczowa i uprzejma. Szablon poniżej zostawiamy po angielsku, bo w tym języku zwykle prowadzi się korespondencję z App Review.

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]

Jeśli jakaś funkcja jest dostępna dopiero po zalogowaniu, przekaż recenzentowi działające dane logowania. Nasz poradnik konta demo do review w App Store pokazuje, jak je przygotować.

Co powinna obejmować lista kontrolna wyróżników przed ponownym zgłoszeniem?

Lista kontrolna wyróżników powinna obejmować konto, plik binarny, metadane i koncepcję, czyli cztery miejsca, które sprawdza 4.3. Odhacz każdy punkt, zanim ponownie klikniesz Submit for Review.

• Konto: żadna inna aplikacja, aktywna ani usunięta, nie ma tego samego szablonu, koncepcji ani designu.
• Konto: aplikacja jest zgłaszana z własnego konta deweloperskiego właściciela treści (4.2.6).
• Plik binarny: usunięto przykładowe ekrany z szablonu, dane demo i zastępczy branding.
• Plik binarny: istnieje co najmniej jedna główna funkcja, której brakuje najwyższym wynikom w kategorii.
• Metadane: nazwa, podtytuł i słowa kluczowe opisują Twoją konkretną wartość, a nie kategorię ogólnie.
• Metadane: zrzuty ekranu pokazują funkcje wyróżniające aplikację na pierwszych dwóch kadrach.
• Koncepcja: potrafisz w jednym zdaniu powiedzieć, dlaczego użytkownik wybrałby tę aplikację zamiast pięciu najwyższych wyników.
• Notatki dla recenzenta: różnice i konto demo są wypisane, więc recenzent nie musi ich szukać.

Jeśli aplikacja została odrzucona z 4.3 więcej niż raz i nie wiesz, co zmienić, nasza usługa zgłaszania do App Store przygotowuje zgłoszenie do review i przepracowuje z Tobą uwagi z odrzucenia, za $599 za oba sklepy (opłaty za konta deweloperskie są osobne).