Guideline 4.2 Minimum Functionality: Apple відхилила застосунок

Guideline 4.2, «Minimum Functionality», відхиляє застосунок, який не дає нічого понад вебсайт або дає надто мало, щоб його залишили на телефоні. Рішення не в тому, щоб нагромаджувати нативні функції: зроби одну з них центром використання, а потім скажи рев'юеру, де її знайти. Виправлення майже завжди потребує нового білда.

Я публікую власні iOS-застосунки: Solys, TradaZen і Nolera є в App Store. Цей гайд спирається на офіційний текст Apple, який я прочитав 15 жовтня 2026 року, і на відмови за 4.2, які розробники публікували на форумах Apple. Відхилені застосунки нижче наведені як приклади. Загальну картину всіх причин дивись у статті чому Apple відхиляє застосунок.

Що каже guideline 4.2?

Пункт 4.2 входить до розділу 4, «Design», App Review Guidelines. Перше речення задає критерій: «Your app should include features, content, and UI that elevate it beyond a repackaged website.» Тобто твій застосунок має давати функції, контент та інтерфейс, які ставлять його вище за вебсайт, просто запакований у коробку.

Текст додає дві думки. Застосунку, який не є по-справжньому корисним, унікальним або «app-like», не місце в App Store. А застосунок, що не дає ні тривалої розважальної цінності, ні достатньої корисності, можуть відхилити. Отже, 4.2 оцінює дві речі: відмінність від вебу та кількість цінності.

Підпункти, на які може посилатися повідомлення

Підпункт	Що вимагає Apple	Типова відмова
4.2	Вийти за межі вебсайту	Сайт, показаний у WebView
4.2.1	Справжній досвід доповненої реальності	3D-модель, просто поставлена в AR-вид
4.2.2	Не лише маркетинг чи посилання	Застосунок-вітрина, агрегатор, лінки
4.2.3	Самостійний застосунок, зрозумілі завантаження	Застосунок, що вимагає іншого
4.2.6	Жодних застосунків із комерційного шаблону	Шаблон, поданий підрядником

Три уточнення. Для 4.2.2 є виняток для каталогів: «Other than catalogs, apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links.» Тож каталог товарів може пройти. Рекламний буклет ні.

У 4.2.3 два підпункти. (i) вимагає, щоб застосунок працював сам, без встановлення іншого застосунку. (ii) вимагає, якщо застосунок має завантажувати ресурси під час першого запуску, повідомити розмір завантаження й заздалегідь попросити згоди.

Пункт 4.2.6 про комерційні шаблони та сервіси генерації застосунків детально розібраний у гайді з guideline 4.3, бо він іде в парі з правилом проти спаму.

Два найчастіші повідомлення 4.2

Повідомлення Apple починається із заголовка «Guideline 4.2 - Design - Minimum Functionality». Далі видно, яку з двох проблем помітив рев'юер. Ось два формулювання, які розробники опублікували на форумах Apple. Їм уже кілька років: точний текст міг змінитися, дві категорії ні.

Застосунок схожий на сайт. «Your app provides a limited user experience as it is not sufficiently different from a mobile browsing experience.» Це повідомлення, опубліковане на форумах Apple, містить ключову фразу: «Including iOS features such as push notifications, Core Location, and sharing do not provide a robust enough experience to be appropriate for the App Store.»

Застосунок надто бідний. «We found that the usefulness of your app is limited by the minimal amount of content or features it includes.» Це друге повідомлення просить переглянути концепцію і визнає, що жодне числове правило не визначає, що корисне чи розважальне.

Додати сповіщення, геолокацію й кнопку «Поділитися» до загорнутого сайту недостатньо: Apple сама написала це у своїх відмовах.

Чотири типові випадки відмови за 4.2

Чотири випадки нижче вигадані для ілюстрації правила, це не реальні застосунки.

Загорнутий вебсайт

Приклад: спортивний клуб показує свій мобільний сайт у WebView з нативною панеллю вкладок зверху. Розклад, бронювання й акаунт це вебсторінки. Рев'юер бачить те саме, що показав би Safari. Apple пише про це на своїй сторінці App Review: сайт, поданий в iOS-застосунку, вебконтент, не адаптований під iOS, або обмежена вебвзаємодія не роблять якісного застосунку.

Що зробив би я: переписати нативно екрани головної дії, тут це розклад і бронювання. Потім додати те, чого сайт не вміє: нагадування перед тренуванням, розклад без мережі, наступне тренування у віджеті.

Надто простий застосунок

Приклад: застосунок, який показує одну цитату на день, і більше нічого. Його вивчаєш за десять секунд. У 4.2 сказано про «lasting entertainment value or adequate utility»: цінність, що триває, або достатню корисність. Щоб виправити, додай глибини головній дії, а не екранів навколо. Тут: історію, обране, нагадування у вибраний час, віджет на головному екрані.

Застосунок, згенерований ШІ, без нічого нативного

Приклад: текстове поле, кнопка, відповідь ШІ простим текстом. Apple оцінює не інструмент, а те, що з'являється на екрані рев'юера. Якщо весь досвід вміщується у вебсторінку, 4.2 цілком імовірно спрацює.

Що ШІ робить добре, а що провалює, я детально пишу в статті створити застосунок за допомогою ШІ. Формат, який видає кожен генератор (вебзастосунок чи мобільний проєкт), порівняно в статті Lovable, Rork чи FlutterFlow.

Оболонка в очікуванні контенту

Приклад: маркетплейс без оголошень, порожній каталог, стрічка з написом «Скоро буде». Рев'юер відкриває застосунок, якому нічого показати. Цей випадок зачіпає й 2.1, що відхиляє тимчасовий контент: дивись гайд з guideline 2.1. Надсилай застосунок, коли в ньому є реальний контент, або дай уже заповнений демо-акаунт.

Мій тест: «А в Safari?»

Перед відправкою я питаю себе, чи міг би вебсайт дати ту саму головну функцію. Якщо так, застосунок під загрозою 4.2. Ось моя таблиця для оцінки нативної функції. Функція рахується, коли служить головній дії, а не прикрашає.

Функція	Рахується, коли...	Недостатня, коли...
Сповіщення	Вони несуть очікувану інформацію	Вони просто анонсують твої статті
Офлайн	Головний контент лишається доступним	Показується лише екран помилки
Віджет	Він показує дані саме цієї людини	Він показує твій логотип
Поширення	Контент надсилають у твій застосунок	Він ділиться лише посиланням
Камера, сенсори	Вони частина головної дії	Вони відкривають твій сайт
Локальні дані	Застосунок рахує, впорядковує й пам'ятає	Усе живе на вебсторінці

Рекомендації Apple кажуть те саме. Віджет показує актуальний контент, який читається з одного погляду. Сповіщення дає корисну інформацію кількома словами і не повинно підштовхувати до якоїсь дії в застосунку.

Що роблять мої застосунки, чого не робить сайт

Кожен свій застосунок я будую навколо головної функції, якої немає в браузері, або цінності, яка змушує повертатися.

• Solys це будильник. Сигнал іде через AlarmKit, сервіс будильників iOS 26: він пробиває беззвучний режим, як будильник Apple. Щоб вимкнути його, треба виграти міні-гру, а вибрані застосунки лишаються на паузі після пробудження. Жодна вебсторінка не змусить iPhone задзвонити в беззвучному режимі.
• TradaZen це симулятор трейдингу: справжній графік на справжню дату, рішення, свічки, що відкриваються, рейтингові дуелі й ранг, що зростає. Тут застосунок тримає не нативна функція. Це та тривала розважальна цінність, про яку говорить 4.2.
• Nolera це гардероб: ти фотографуєш одяг, застосунок вирізає його з фону і впорядковує, а потім щоранку пропонує образ. Камера частина головної дії. Це не бонус.

4.2 не вимагає списку нативних функцій: вона вимагає причини встановити застосунок, а не відкрити сайт.

Як виправити відмову 4.2, крок за кроком

1. Визнач категорію. Вебнавігація: це загорнутий сайт. Мінімальний контент або функції: це надто бідний застосунок. 4.2.3: залежність від іншого застосунку або неоголошене завантаження.
2. Змінюй продукт, а не формулювання. Відповідь, яка сперечається, нічого не змінюючи, не має жодних шансів переконати. Перепиши нативно екрани головної дії або додай глибини, якої бракує.
3. Готуй новий білд. Причина всередині застосунку: віддаленого оновлення не вистачить. Кожна відправка знову проходить чергу, дивись терміни перевірки в App Store.
4. Пиши нотатки для рев'ю, які ведуть за руку. На своїй сторінці про інформацію для повного рев'ю Apple просить описати концепцію, функції та аудиторію. Для оновлення: що змінилося і де це знайти.
5. Апелюй, лише якщо рев'юер щось пропустив. Якщо твоя нативна функція вже була, але її не побачили, відповідай в App Store Connect із коротким відео. Апеляція до App Review Board виправдана, коли твій застосунок зрозуміли неправильно, а не коли він бідний.

Шаблон нотаток, який я використав би, англійською, адаптуй під себе:

Hello App Review team,

Thank you for your feedback regarding Guideline 4.2.

What changed in build [X]:
- [Main feature] is now fully native: [what the user does].
- [Native feature]: [what it brings]. Where: [screen > button].
- [Second native feature]: [what it brings]. Where: [screen].
- Web content is limited to [legal pages, help].

How to test in two minutes:
1. Launch the app and [main action].
2. Turn on Airplane mode: [content] stays available.
3. Add the widget from the Home Screen: it shows [data].

Best regards,
[Your name]

Пиши лише те, що є в надісланому білді. Оголошена, але ненайдена функція принесе тобі нову відмову, цього разу за 2.1.

Чекліст 4.2 перед відправкою

• Ти можеш одним реченням сказати, що робить твій застосунок, чого не робить сайт.
• Екрани головної дії нативні, а не вебсторінки.
• Кожна нативна функція служить головній дії, і рев'юер натрапляє на неї менш ніж за дві хвилини.
• Застосунок має реальний контент з першого запуску або заповнений демо-акаунт.
• Застосунок працює сам, без встановлення іншого.
• Велике завантаження при першому запуску повідомляє розмір і просить згоди.
• Нотатки для рев'ю описують концепцію, аудиторію та розташування кожної функції.
• Якщо твоя ідея на межі, ти перевірив її до написання коду, з чітко окресленим MVP iOS-застосунку.

Пройди 4.2 з наступної ж відправки

Якщо твій застосунок щойно відхилили за 4.2, Apple Review Kit допоможе знайти згадане правило і що воно вимагає, разом із шаблонами нотаток для тестувальника. Якщо ти ще будуєш, шлях iOS Kit починається з головної функції ще до першого рядка коду. Якщо потрібен живий погляд, забронюй годину зі мною. Повний підхід описано на сторінці застосунок відхилено Apple.

Якщо ти готуєш свій перший реліз, пройди безкоштовну діагностику: вона розставить кроки по порядку й надішле тобі мій чекліст проти відмов Apple. На головній сторінці показано, як створити мобільний застосунок, продуманий під рев'ю з самого початку.

Ніхто не може гарантувати, що Apple прийме твій застосунок. Я можу допомогти тобі дати йому причину існувати в App Store.

Поширені запитання

Що означає «Guideline 4.2 - Design - Minimum Functionality»?

Це заголовок відмови через мінімальну функціональність. Apple вважає, що твій застосунок надто схожий на вебсайт або дає надто мало контенту чи функцій. Той самий заголовок може вказувати на підпункт: «Guideline 4.2.2» для застосунку-вітрини чи списку посилань, 4.2.3 для застосунку, що залежить від іншого.

Застосунок у WebView завжди відхиляють?

Ні. Правило спрямоване проти сайту, запакованого в застосунок, а не проти технології. Рев'юер оцінює головний досвід: якщо його екрани це вебсторінки, що роблять те саме, що й Safari, ризик високий. Сторінка довідки, відкрита в браузері, тут ні до чого.

Чи достатньо додати push-сповіщення, щоб пройти 4.2?

Ні. В одному з повідомлень про відмову, опублікованому на її форумах, Apple пише, що сповіщення, геолокація й поширення не роблять досвід достатньо багатим. Сповіщення рахується, коли служить головній функції, як будильник чи нагадування, яке обрала сама людина.

Яка різниця між guideline 4.2 і 4.3?

4.2 оцінює твій застосунок сам по собі: чи дає він достатньо порівняно з вебсайтом? 4.3 порівнює його з іншими: чи це копія, варіант чи ще один застосунок у перенасиченій категорії? Один застосунок може отримати обидві відмови, але виправляються вони по-різному.

Чи потрібен новий білд після відмови 4.2?

Майже завжди, бо причина в самому застосунку. Єдиний виняток: рев'юер не знайшов функцію, яка вже існувала. У такому разі відповідай в App Store Connect із точними нотатками й коротким відео, не змінюючи білд.