Guideline 4.3(a) Design Spam: як виправити, плюс 4.3(b) і 4.2.6 для шаблонних і ШІ-застосунків (2026)

Відхилення за Guideline 4.3(a) Design Spam — одне з найважчих повідомлень App Review, з яким складно щось робити, бо в ньому рідко вказано, на який застосунок схожий ваш. Воно значно частіше спіткає шаблонні застосунки, white-label-рішення для клієнтів і застосунки, згенеровані ШІ. У цьому посібнику ми розмежовуємо 4.3(a), 4.3(b) і 4.2.6, розбираємо, як інші розробники долали це відхилення, а також даємо шаблон відповіді та чекліст, який варто пройти перед повторним поданням. Про інші типи відхилень читайте в посібнику з відхилень за кожним правилом.

Що означає Guideline 4.3(a) Design Spam?

Guideline 4.3(a) означає, що Apple вважає ваше подання по суті тим самим застосунком, що вже був поданий: або це кілька Bundle ID одного застосунку, або майже копія чужого. Рішення — об’єднати дублікати або зробити основний досвід явно іншим.

Станом на листопад 2026 року в App Review Guidelines сказано: «Не створюйте кілька Bundle ID одного й того самого застосунку (наприклад, подаючи окремий застосунок-мапу для кожного міста світу замість однієї світової мапи, яка дає змогу шукати будь-яке місто)». Альтернатива, яку пропонує Apple: «подумайте про подання одного застосунку з наданням варіацій через вбудовані покупки». Правило 4.3(a) позначене значком ключа, тож воно також застосовується до нотаризації застосунків для iOS та iPadOS, що поширюються поза App Store.

Текст відхилення, який зазвичай отримують розробники (англійською): «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.» Тобто: Apple помітила, що ваш застосунок має схожий бінарний файл, метадані та/або концепцію із застосунками інших розробників, лише з незначними відмінностями. У цьому реченні три тригери (бінарний файл, метадані, концепція), і будь-який з них може спричинити відхилення.

Чим 4.3(a) відрізняється від 4.3(b) і 4.2.6?

4.3(a) стосується дублікатів, 4.3(b) — застосунків, які не додають нічого нового до вже переповненої категорії, а 4.2.6 — застосунків, створених із шаблонів і поданих не з того акаунта. Кожен випадок потребує свого рішення, тому спершу перевірте точний номер правила у відхиленні.

Чинна редакція 4.3(b) також попереджає, що Apple «може надалі видаляти такі застосунки з App Store, якщо вони не оновлюються, не покращуються або не залучають користувачів», а повторне подання застосунків із низькозатратних категорій, як-от ігор для вечірок з алкоголем чи «пукалок», може призвести до виключення з Apple Developer Program. Про інші правила, які Apple нещодавно переглянула, читайте в огляді змін App Review Guidelines у жовтні 2026 року.

Чому шаблонні та ШІ-застосунки позначають як спам?

Шаблонні та згенеровані ШІ застосунки позначають тому, що багато з них мають однаковий стартовий код, однакові макети екранів і схожі тексти для магазину, тобто збігаються за всіма трьома тригерами: бінарний файл, метадані та концепція. Те, що код належить вам, не звільняє застосунок від перевірки, якщо результат виглядає як сотні інших.

ШІ-конструктори застосунків часто генерують однаковий онбординг, однакову панель вкладок і однаковий шаблонний набір функцій («відстежуйте звички, отримуйте ШІ-інсайти»), а згенерований опис для App Store нерідко теж звучить однаково. Якщо ви публікували застосунок через конструктор, перевірте, хто вказаний як продавець. Правило 4.2.6 каже, що шаблонні сервіси «не повинні подавати застосунки від імені своїх клієнтів», тож застосунок має виходити з акаунта розробника, що належить власнику контенту. Наші посібники з публікації застосунку Base44 та публікації застосунку Lovable пояснюють, що залишається вашою відповідальністю після експорту.

Як інші розробники виправляли відхилення за 4.3(a)?

Публічно описані випадки показують, що самі лише візуальні зміни рідко допомагають. Краще працюють об’єднання дублікатів і конкретна відповідь про те, чим застосунок відрізняється.

• Об’єднання з наявним застосунком (GitHub). Команда, що випускала VoIP-застосунок на основі Linphone, повідомила в linphone-iphone issue #936, що новий набір іконок і колірна схема не допомогли пройти 4.3(a). Вони дійшли висновку, що конфлікт виникав з іншим застосунком на основі Linphone на тому самому акаунті. Вони внесли зміни в цей наявний застосунок як оновлення, і воно пройшло перевірку «майже одразу».
• Пояснення унікальності (Godot Forum). Розробник гри на Godot Forum припустив, що спільний бінарний файл рушія збігається з іншими іграми на Godot. І зменшення збірки, і пояснення, що гра зроблена на Godot, закінчилися відхиленням. Схвалення принесла відповідь, у якій він «перелічив ключові аспекти, що, на мою думку, робили гру цікавою та унікальною порівняно з іншими іграми того ж жанру».
• Скриншотів виявилося замало (Apple Developer Forums). В обговоренні на Apple Developer Forums один розробник розповів, що представник Apple вказав на скриншоти і що «метадані» можуть означати назву, підзаголовок, ключові слова або скриншоти. Повністю нові скриншоти все одно отримали те саме відхилення — для оновлення застосунку, якому було 2–3 роки.

Спільне в усіх випадках: косметичні зміни (іконки, кольори, скриншоти) не спрацювали в жодному з трьох випадків. Спрацювало видалення дубліката з акаунта або надання рецензенту конкретних причин на рівні функцій, чому застосунок відрізняється.

Як покроково виправити відхилення за 4.3(a)?

Щоб виправити відхилення за 4.3(a), спершу знайдіть дублікат, потім внесіть реальні зміни в продукт, а тоді відповідайте App Review з конкретикою перед повторним поданням. Повторне подання тієї самої збірки з новою іконкою — найпоширеніший спосіб отримати відхилення знову.

1. Прочитайте точний номер правила в розділі App Review в App Store Connect. Якщо там 4.2.6 або 4.3(b), дотримуйтеся відповідного рядка таблиці вище.
2. Складіть список усіх застосунків на вашому акаунті, опублікованих чи видалених, які мають спільний код, шаблон, концепцію чи дизайн із відхиленим. Якщо такий знайдеться, об’єднайте їх в один застосунок із варіаціями всередині або випустіть зміни як оновлення опублікованого застосунку.
3. Пошукайте в App Store за ключовими словами вашої категорії та занотуйте топові результати. Запишіть, що робить ваш застосунок такого, чого не робить жоден із них.
4. Змініть щонайменше один основний сценарій (джерело даних, головну функцію, модель взаємодії), а не лише тему оформлення.
5. Перепишіть назву, підзаголовок, ключові слова, опис і скриншоти так, щоб вони описували саме ваші функції і не залишилося жодного шаблонного тексту.
6. Відповідайте в App Store Connect за шаблоном нижче. На сторінці App Review Apple також пропонує 30-хвилинні зустрічі у Webex, якщо ви хочете поставити рецензенту запитання щодо правил безпосередньо.
7. Якщо ви вважаєте, що рецензент неправильно зрозумів застосунок, подайте одну апеляцію до App Review Board. Apple просить «подавати лише одну апеляцію на кожне подання, яке не пройшло перевірку» і спершу відповідати на запити інформації.

Що написати у відповіді App Review?

Хороша відповідь називає конкретні функції, що вирізняють застосунок, підтверджує, що на вашому акаунті немає дублікатів, і вказує рецензенту, де саме можна побачити кожну відмінність. Пишіть коротко, по суті та ввічливо. Шаблон нижче — англійською, оскільки саме цією мовою зазвичай ведеться листування з 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]

Якщо функція доступна лише після входу, надайте рецензенту робочі облікові дані. Як їх налаштувати, показано в нашому посібнику з демо-акаунта для перевірки в App Store.

Що має охоплювати чекліст відмінностей перед повторним поданням?

Чекліст відмінностей має охоплювати ваш акаунт, бінарний файл, метадані та концепцію — чотири місця, які перевіряє 4.3. Позначте кожен пункт, перш ніж знову натиснути Submit for Review.

• Акаунт: жоден інший застосунок, опублікований чи видалений, не має того самого шаблону, концепції чи дизайну.
• Акаунт: застосунок подано з власного акаунта розробника, що належить власнику контенту (4.2.6).
• Бінарний файл: прибрано демонстраційні екрани шаблону, демо-дані та брендинг-заглушки.
• Бінарний файл: є щонайменше одна основна функція, якої немає в топових результатах категорії.
• Метадані: назва, підзаголовок і ключові слова описують саме вашу цінність, а не категорію загалом.
• Метадані: скриншоти показують ваші відмінні функції на перших двох кадрах.
• Концепція: ви можете одним реченням пояснити, чому користувач обере цей застосунок, а не будь-який із п’яти топових результатів.
• Нотатки для перевірки: перелічено відмінності та надано демо-акаунт, щоб рецензенту не довелося їх шукати.

Якщо вас відхиляли за 4.3 більше одного разу і ви не впевнені, що змінити, наш сервіс подання в App Store підготує все до перевірки та разом із вами опрацює відгуки щодо відхилення — за $599 для обох магазинів (внески за акаунти розробника оплачуються окремо).