Зміни App Review Guidelines у жовтні 2026: що означають 1.2, 2.3.14, 2.5.19 і 3.1.1(a) для застосунку

Зміни App Review Guidelines у жовтні 2026 Apple оголосила в публікації Updated App Review Guidelines are now available 16 жовтня 2026 року. Два правила нові (2.3.14 і 2.5.19), три фрагменти переформульовано (1.2, 3.1.1(a) і розділ 5), а розділи Before You Submit та After You Submit отримали посилання на додаткову документацію. Нижче — кожна зміна простими словами, хто має діяти, і чекліст для наступної подачі.

Що змінилося в App Review Guidelines 16 жовтня 2026 року?

Apple додала правило 2.3.14 для креативних матеріалів і правило 2.5.19 для прихованих функцій. Також уточнено 1.2 (контент, створений користувачами), 3.1.1(a) (зовнішні посилання на покупки) і розділ 5 (Legal). У журналі змін Apple перелічує правки так:

Apple зазначає, що переклади «будуть доступні на сайті Apple Developer протягом одного місяця». Станом на жовтень 2026 року звіряйтеся з англійськими App Review Guidelines щоразу, коли перекладена версія з ними розходиться.

Чого вимагає нове правило 2.5.19 щодо прихованих функцій?

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

Точний текст: «Не додавайте у свій застосунок жодних прихованих, неактивних або недокументованих функцій; функціональність вашого застосунку має бути зрозумілою кінцевим користувачам і App Review. Спроба приховати недокументовані функції в бінарнику застосунку, наприклад через обфускацію коду чи інші методи, є підставою для видалення вашого застосунку з App Store і припинення дії вашого акаунта розробника». Apple називає цю політику давньою, але раніше вона була в 2.3.1. Чинне 2.3.1(a) і далі вимагає, щоб нові функції були «конкретно описані в розділі Notes for Review». Відмови через приховані функції тепер мають посилатися на 2.5.19.

На практиці перелічіть у нотатках для перевірки кожну функцію, яку може ввімкнути серверний перемикач, інвайт-код, сканування QR, регіон або тариф акаунта. Якщо прапорець увімкне функцію після схвалення, або ввімкніть її у збірці, що йде на перевірку, або не додавайте код до версії, в якій вона з'явиться.

Яких застосунків стосуються зміни правила 1.2?

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

Оновлений текст згадує «інтимні зображення без згоди» поряд із порушенням прав інтелектуальної власності та булінгом. Також додано: «Розробники, які не впроваджують належних запобіжників або не усувають виявлені порушення після повідомлення, можуть вважатися такими, що порушують Developer Code of Conduct». Навіть ШІ-застосунок для зображень чи аватарів, який генерує контент лише для самого користувача, тепер може підпадати під це правило. Фільтрація промптів і результатів, скарги та опубліковані контакти мають бути в збірці, яку ви подаєте, а не в роадмапі.

Що каже правило 2.3.14 про креативні матеріали?

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

Креативні матеріали — це зображення та відео, які Apple представила 5 жовтня 2026 року. Згідно з App Store asset best practices, вони з'являються «в iOS 27 та iPadOS 27 і новіших, зокрема на сторінці продукту, у результатах пошуку і коли ваш застосунок потрапляє в добірки». Ця сторінка йде далі за саме правило. Вона радить не використовувати URL сайтів, символи копірайту, логотипи інших платформ і відзнаки Apple на кшталт «Editor's Choice». Також там сказано, що матеріали «мають відповідати віковому рейтингу 4+, навіть якщо рейтинг вашого застосунку вищий». Header із написом «-50% цього тижня» або «#1 застосунок для бюджету» порушує 2.3.14.

Що змінилося в правилі 3.1.1(a) щодо зовнішніх посилань на покупки?

У правилі 3.1.1(a) більше немає окремого пункту про Music Streaming Services Entitlement. Цей entitlement тепер входить до пункту StoreKit External Purchase Link Entitlements, а текст каже, що посилання можуть вести на «дозволене місце призначення». Схвалені місця призначення можуть відрізнятися залежно від регіону.

Правила щодо того, де посилання дозволені, цим оновленням не змінено. Entitlements і далі обмежені певними вітринами. Вітрина США залишається винятком, де кнопки, зовнішні посилання та інші заклики до дії дозволені без entitlement. Якщо ви вже використовуєте будь-який із цих entitlements, перевірте, що ваше посилання досі веде на дозволене місце призначення в кожній вітрині, де ви публікуєтеся.

Як розробники на практиці виправляють відмови через приховані функції та UGC?

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

• У березні 2026 року розробник на Apple Developer Forums повідомив, що нативний соціальний застосунок-будильник відхилили за «Guideline 2.3.1(a) - Hidden Features» і 4.2. За їхніми словами, WebView використовувалися лише для політики конфіденційності, умов і FAQ, і вони подали апеляцію. App Review відповів, що App Review Board надав відповідь. Потім розробник попросив указати конкретні екрани, і рішення так і не було опубліковано.
• У issue на GitHub Flutter кілька розробників отримали повідомлення «We discovered that your app contains hidden features» для простих застосунків. Контриб'ютор Flutter назвав фреймворк «хибним слідом» і вказав на недокументовані API в коді застосунку або плагінах. Двоє розробників повідомили про схвалення після апеляції без змін у коді.
• Розробника на Apple Developer Forums відхилили за 1.2, попри наявність EULA, фільтрації, скарг і блокування. Його попросили погодити умови з «нульовою толерантністю до неприйнятного контенту» і «реагувати на скарги щодо неприйнятного контенту протягом 24 годин». Друга відмова додала вимоги щодо рейтингу 18+, миттєвого видалення дописів і контактної інформації в застосунку. У відповідь розробник задокументував кожен запобіжник і надав облікові дані адміністратора в нотатках для перевірки.

Висновок: в усіх трьох випадках рецензенти не могли побачити чи перевірити функції, які розробники вважали очевидними. За 2.5.19 і суворішого 1.2 нотатки для перевірки та демо-акаунт важать стільки ж, скільки код. Наш посібник із демо-акаунта для перевірки App Store пояснює, як їх налаштувати.

Що перевірити перед наступною подачею?

Перед наступною збіркою звірте feature flags, запобіжники для UGC, креативні матеріали та зовнішні посилання з новим текстом, а потім напишіть нотатки для перевірки, що вказують на кожен із них. Чекліст нижче охоплює зміни жовтня 2026 року.

1. Складіть перелік усіх серверних прапорців, ключів remote config і прихованих меню. Увімкніть кожен для рецензента або видаліть код, яким він керує.
2. Конкретно опишіть кожну нову функцію в Notes for Review, як вимагає 2.3.1(a), зокрема як дістатися до всього, що прихована за інвайтами, скануванням або платними тарифами.
3. Якщо користувачі можуть публікувати, спілкуватися або генерувати контент, переконайтеся, що фільтрація, скарги, блокування та опубліковані контакти є у збірці, і задокументуйте свій процес реагування на скарги.
4. Для ШІ-генерації зображень чи відео додайте фільтри промптів і результатів, що блокують сексуальні зображення реальних людей, і дайте користувачам змогу скаржитися на результати.
5. Перевірте кожен креативний матеріал на ціни, знижки, URL, заяви про нагороди, логотипи інших платформ і все, що виходить за рейтинг 4+.
6. Якщо ви використовуєте entitlement для зовнішнього посилання на покупку або для музичного стримінгу, переконайтеся, що посилання веде на дозволене місце призначення в кожній вітрині.
7. Перечитайте англійські правила для кожного розділу, на який ви спираєтеся, бо переклади можуть запізнюватися до місяця.

Приклад: візьмімо ШІ-застосунок для аватарів із публічною галереєю та пакетом стилів «Pro», який вмикається через remote config після запуску. За новим текстом йому потрібні модерація галереї та скарги (1.2). Пакет Pro має бути або видимим у збірці на перевірці, або відкладеним до пізнішої версії (2.5.19). Його header-матеріал для iOS 27 не може містити «Pro зараз зі знижкою 40%» (2.3.14). Якщо ви вже отримали відмову, наш посібник із виправлення за кожним правилом пояснює, як відповісти в App Store Connect. Якщо потрібен свіжий погляд перед подачею, перегляньте наші послуги.