Чекліст подання застосунку в App Store (2026): від збірки в Xcode 26 до Submit for Review

Чекліст подання в App Store — це перелік усього, що має бути готове одночасно перед поданням: робоча збірка, точна сторінка застосунку, правдиві відповіді щодо конфіденційності та достатньо контексту, щоб рецензент міг користуватися застосунком. Самої лише успішної збірки недостатньо. Шість розділів нижче йдуть у тому порядку, у якому їх запитує App Store Connect, і кожен починається з короткої відповіді, за якою можна одразу діяти.

Що потрібно для подання в App Store, перш ніж натиснути Submit?

Для подання в App Store потрібні оброблена збірка, прив’язана до версії, обов’язкові метадані версії, скриншоти, політика конфіденційності, контактні дані для App Review і, якщо в застосунку є вхід, робочі облікові дані демо-акаунта. Власний список Apple «Before You Submit» у App Review Guidelines додає ще два пункти: «Увімкніть бекенд-сервіси, щоб вони працювали й були доступні під час перевірки» та пояснюйте неочевидні функції в нотатках для перевірки.

Які налаштування акаунта й запису застосунку мають бути готові?

Вам потрібні активне членство в Apple Developer Program, запис застосунку, bundle ID якого збігається з підписаною збіркою, і хтось у команді з роллю Account Holder, Admin або App Manager. Саме ці ролі сторінка Apple Submit an app вимагає для подання.

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

Які вимоги до збірок діють для завантажень в App Store у 2026 році?

Станом на жовтень 2026 року на сторінці Apple upcoming requirements сказано: «Застосунки, що завантажуються в App Store Connect, мають бути зібрані в Xcode 26 або новішому з SDK для iOS 26, iPadOS 26, tvOS 26, visionOS 26 або watchOS 26» (з 28 квітня 2026 року). Там також зазначено, що застосунки для iOS та iPadOS «мають бути розраховані на iOS 13 або новішу» (з 9 вересня 2026 року).

• Збільшуйте номер збірки під час кожного завантаження й переконайтеся, що номер версії відповідає релізу, який ви плануєте випустити.
• Оновіть образ Xcode в CI (Codemagic, Expo EAS, GitHub Actions тощо), а не лише на власному комп’ютері.
• Після обробки дайте відповідь на запит щодо експортного контролю (export compliance) і прив’яжіть оброблену збірку до версії.
• Встановіть збірку з TestFlight на фізичний пристрій. Перевірте онбординг, вхід, офлайн-стани, покупки та відновлення покупок. Те, що все працює в симуляторі, не доводить, що працює розповсюджувана збірка.
• Прочитайте лист, який App Store Connect надсилає після завантаження. Попередження ITMS про privacy manifest чи версії SDK стають блокерами, якщо їх ігнорувати.

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

Які скриншоти й метадані вимагає App Store Connect?

Станом на жовтень 2026 року специфікації скриншотів Apple вимагають щонайменше один скриншот для «iPhone with Dynamic Island (medium display)», наприклад 1206 × 2622 або 1179 × 2556 у портретній орієнтації. Застосункам, які працюють на iPad, також потрібен щонайменше один скриншот для iPad 13 дюймів, наприклад 2064 × 2752 або 2048 × 2732.

Ви «можете завантажити до 10 скриншотів на кожен розмір пристрою у форматах .jpeg, .jpg або .png», і «зображення не можуть містити альфа-канали чи прозорість». Якщо інтерфейс однаковий на всіх розмірах, завантажте лише найвищу обов’язкову роздільну здатність, і App Store Connect зменшить її. Правило 2.3.3 каже, що скриншоти «мають показувати застосунок у використанні, а не лише титульне зображення, сторінку входу чи заставку».

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

Як узгодити відповіді щодо конфіденційності із застосунком?

Щоб відповіді щодо конфіденційності відповідали застосунку, складіть перелік усіх SDK, які ви постачаєте, і даних, які кожен із них збирає, а потім за цим переліком заповніть App Privacy, напишіть політику конфіденційності й налаштуйте поведінку в застосунку. Правило 2.3 каже, що ваші метадані, «включно з інформацією про конфіденційність», мають точно відображати застосунок.

Правило 5.1.1(i) встановлює: «Усі застосунки мають містити посилання на свою політику конфіденційності в полі метаданих App Store Connect і в самому застосунку в легкодоступному місці». Правило 5.1.1(v) додає: «Якщо ваш застосунок підтримує створення облікового запису, ви також маєте надати можливість видалити обліковий запис у застосунку». SDK для аналітики, звітів про збої, реклами та входу зазвичай змінюють ваші відповіді, тож перевірте їх за допомогою нашого аудиту SDK для privacy labels. Також переконайтеся, що ваш застосунок і кожен вбудований SDK містять privacy manifest PrivacyInfo.xcprivacy, який охоплює всі використані required-reason API.

Що має містити App Review Information?

App Review Information має містити контакт, який справді відповідатиме, робочі облікові дані демо-акаунта без терміну дії та нотатки, що ведуть рецензента прямо до ключових функцій. Правило 2.1(a) просить «додати дані демо-акаунта (і ввімкнути свій бекенд-сервіс!), якщо в застосунку є вхід»; для вбудованого демо-режиму замість акаунта потрібне попереднє схвалення Apple.

Ось приклад нотаток для перевірки: «Увійдіть за допомогою наданого акаунта для перевірки. Відкрийте Library, виберіть приклад проєкту й натисніть Export. В акаунті розблоковано всі преміум-функції. Функції геолокації використовують змодельоване місто, тож нікуди їхати не потрібно». Не відправляйте рецензентів у порожній акаунт, до одноразового коду, термін дії якого спливає, чи до сценарію, який працює лише тоді, коли ви онлайн і можете його підтвердити. Наш посібник із налаштування демо-акаунта показує, як створити надійний вхід для рецензента.

Як подати застосунок на перевірку в App Store Connect?

Щоб подати застосунок на перевірку, прив’яжіть збірку до версії, натисніть Add for Review, а потім Submit for Review. Сама лише кнопка Add for Review нічого не надсилає до Apple. Послідовність нижче відповідає сторінці Apple «Submit an app» станом на жовтень 2026 року.

1. У розділі Apps виберіть застосунок, а потім натисніть версію застосунку на бічній панелі.
2. Прокрутіть до розділу Build і переконайтеся, що прив’язано правильну збірку.
3. У розділі App Store Version Release виберіть ручний реліз, якщо хочете самі контролювати день запуску, і натисніть Save.
4. Натисніть Add for Review і виберіть наявну чернетку подання або створіть нову. Статус зміниться на Ready for Review.
5. Натисніть Submit for Review. Коли перевірка почнеться, статус зміниться на In Review.
6. Збережіть копію поданих метаданих і нотаток та стежте за поштою контакту для перевірки, щоб не пропустити запитання.

Якщо подання відхилили, прочитайте номер правила й пояснення рецензента, перш ніж щось змінювати. Деякі виправлення стосуються лише метаданих. Інші потребують нової збірки. Наш посібник із відмов в App Store пояснює, як визначити, який у вас випадок.

Що пішло не так в інших розробників під час подання?

В обох публічних випадках нижче застосунок працював у розробника, а проблема проявилася лише в завантаженій збірці або під час першої сесії рецензента.

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

Розробник на форумі JUCE після завантаження отримав «ITMS-91053: Missing API declaration» з повідомленням, що нові завантаження «мають містити масив NSPrivacyAccessedAPITypes у privacy manifest застосунку». Позначеними категоріями були SystemBootTime і FileTimestamp, а інший користувач повідомив про UserDefaults. Рішенням став файл PrivacyInfo.xcprivacy із затвердженими кодами причин, доданий як ресурс Xcode. В одного користувача в першій версії бракувало ключа типу, що викликало ITMS-91056 через невалідний manifest, доки він це не виправив.

Обидва розробники тестували лише на власному середовищі. Перш ніж натиснути Submit for Review, протестуйте саме ту збірку, яку отримує Apple, зі свіжим входом і прочитайте кожен лист після завантаження. Якщо хочете, щоб хтось іще раз перевірив ваш пакет, ознайомтеся з нашими послугами з подання.