Позаду місяці роботи — розробка, тестування, виправлення помилок. І ось застосунок нарешті готовий до завантаження в App Store. Ви йдете на сайт Apple за інструкціями, але хаос статей і крос-посилань викликає паніку. Не допомагають навіть чек-листи від Gemini та ChatGPT.
Тому тримайте покроковий гайд і фінальний чек-ліст, як опублікувати застосунок в App Store і не зловити панічну атаку реджект.
Екосистема релізу в App Store
Перш ніж завантажувати додаток, варто зрозуміти, які інструменти для цього потрібні. У App Store їх три:
-
Xcode — середовище розробки. Тут застосунок збирається, архівується і фізично «народжується» у вигляді білда: коду, UI, логіки, ресурсу.
-
Apple Developer Program — членство в екосистемі Apple. Це юридичний і технічний паспорт, він дає право:
-
підписувати код;
-
створювати сертифікати;
-
публікувати застосунки в App Store.
-
App Store Connect — адмін-панел застосунку. В ній розташовується все, що бачить користувач і рев’юер: метадані, скріншоти, ціни, білди, TestFlight, аналітика.
Починати потрібно не з Xcode і навіть не з App Store Connect, а з реєстрації Apple Developer Program.

Річна підписка ($99/рік) від компанії Apple дає змогу розробникам публікувати застосунки в App Store (iOS, macOS, watchOS, tvOS), тестувати їх через TestFlight, використовувати розширені API та отримувати доступ до бета-версій ПО. Вона необхідна для повноцінної роботи з екосистемою Apple.
Без Apple Developer Program Xcode не дасть зібрати релізний білд, а в App Store Connect не вийде створити сторінку застосунку. Тож перший крок — створення акаунта.
Apple Developer Program: типи акаунтів розробника
В App Store є два типи акаунтів:
-
Individual — для соло-розробників, коли застосунки публікуються під вашим імʼям.
-
Organization — для команд і стартапів, дає змогу розподіляти ролі та доступи. Потребує D-U-N-S номера та юридичних даних.
Індивідуальний акаунт є простішим в оформленні. Для нього знадобиться:
-
обліковий запис Apple з двофакторною автентифікацією;
-
офіційне ім’я та прізвище облікового запису Apple;
-
електронна пошта;
-
номер телефону;
-
поштова адреса.
До акаунту організації вимоги Apple суворіші. Знадобиться:
-
Legal binding authority — ім’я та прізвище особи, яка реєструє організацію в Apple Developer Program. Мають збігатися з даними в Apple ID. Особа має бути власником облікового запису й мати юридичні повноваження для підпису документів та укладання угод. Коротше кажучи, власник або засновник організації, член виконавчої команди, старший керівник проєкту або співробітник із відповідними юридичними повноваженнями.
-
Legal entity name and status — назва й статус компанії. Організація має бути зареєстрована як юридична особа. Не приймаються назви підприємств, вигадані назви компаній, торгові назви чи філії. Назва організації відображатиметься як назва продавця програм в App Store.
-
D-U-N-S Number. Організація (за винятком державних установ) мусить мати DUNS-номер, щоб Apple могли перевірити особу організації, її юридичний статус та адресу. Ці унікальні дев’ятизначні номери присвоюються Dun & Bradstreet і використовуються як стандартні ідентифікатори бізнесу. Ви можете перевірити, чи має ваша організація номер DUNS, і за потреби запросити його через Dun & Bradstreet — це єдиний офіційний провайдер.
-
Phone and Email. Робоча адреса електронної пошти має бути пов’язана з доменним ім’ям організації. Пошти на @gmail.com або @outlook.com для організацій часто стають причиною затримок або перевірок.
-
Website. Сайт організації має бути загальнодоступним і функціональним. Посилання на сторінки соціальних мереж або вебсайти, які містять мінімальний вміст або відображають повідомлення від реєстратора доменів, не приймаються.
Здебільшого перші проблеми із релізом виникають саме через неправильний тип акаунту, коли він не відповідає стратегічним планам розвитку. Наприклад, в Individual-акаунті не можна додавати розробників у розділі Certificates, Identifiers & Profiles, а це означає, що власник має власноруч створювати сертифікати або ділитися своїм Apple ID (що небезпечно).
Також у полі Seller Name в App Store відображається ім’я людини, а не компанії, а це може знижувати довіру користувачів і ускладнювати зміну на назву бренду. Зміна акаунту з Individual в Organizational може тривати кілька тижнів.
Реєстрація в Apple Developer Program безоплатна, але для надсилання застосунку в App Store потрібно сплатити збір $99/рік. Оплату можна зробити безпосередньо перед сабмітом (публікацією застосунку).
Після активації Apple Developer Program ви отримуєте доступ до App Store Connect.
Налаштування App Store Connect
Щоб налаштувати сторінку застосунку, оберіть у меню My Apps — New App. Далі створіть його запис (App Record). Для цього заповніть такі поля:
-
Platform — платформа, для котрої розроблено застосунок (IOS, macOS, tvOS, visionOS).
-
Name — назва.
-
Primary Language — основна мова. Це не просто мова застосунку, а мова, якою Apple буде показувати його сторінку в країнах, для котрих у вас немає локалізації. Як працює Primary Language в App Store, можете дізнатися в довідці.
-
Bundle ID — номер, що створюється в розділі «Certificates, Identifiers & Profiels» за таким шляхом:
- виберіть «Identifiers» зі списку опцій і натисніть «Продовжити»;
- підтвердіть, що тип ідентифікатора програми вибрано автоматично, клікніть «Продовжити»;
- введіть назву або опис для ідентифікатора програми в полі Description.
Після реєстрації номер підтягнеться у випадаючий список відповідного поля.
-
SKU — унікальний внутрішній ідентифікатор для застосунку в App Store Connect. Його треба сформувати самостійно, у зручному для команди форматі, наприклад, APP_NAME_IOS_2026.
-
User Access — доступ для користувачів. Якщо ви оберете «Limited Access», додатково помітьте користувачів, котрі матимуть доступ до цієї програми.
Далі необхідно заповнити три базові розділи інформації про застосунок. Їхнє наповнення можна буде змінювати пізніше.
-
App Information.
Загальна інформація:
-
Name — назва застосунку;
-
Subtitle — короткий опис, що розкриває суть програми;
-
Localizable Information — мови сторінок застосунку, якими він відображатиметься для користувачів;
-
Category;
-
Apple ID (Apple генерує цей номер сам);
-
Content Rights — чи містить контент третіх сторін (так/ні);
-
Age Raiting — чи містить застосунок азартні ігри, елементи насилля тощо, рейтинг проставляється автоматично на основі відміченого вмісту;
-
License & Agreement — сервіс пропонує стандартну угоду Apple Standard EULA, але якщо у вас специфічний сервіс (наприклад, банківський або корпоративний), де потрібні особливі юридичні умови, ви можете вставити текст своєї угоди.
-
App Privacy.
У цьому розділі потрібно чесно вказати, котрі дані збирає застосунок і як вони використовуються. На основі відповідей формується Privacy Nutrition Label, який бачить користувач.
Якщо є підписки або внутрішні покупки — вони створюються тут же й пізніше привʼязуються до білда. Також у цьому розділі необхідно розмістити Privacy Policy URL — посилання на вашу політику конфіденційності.
На цьому етапі у вас уже є «контейнер» для білда, але самого білда ще немає.
-
Pricing & Availability.
У цьому розділі необхідно вказати, де й коли додаток буде доступний в App Store, а також за якою ціною. Можете обрати всі країни або окремі й налаштувати Pre-order. Користувачам, котрі підпишуться на сторінку застосунку, він завантажиться автоматично після релізу.
Після завершення налаштувань під розділом iOS App з’явиться версія застосунку для релізу — Prepare for Submission.
Якщо це перша версія, вона з’явиться автоматично. Наступні необхідно додати вручну, натиснувши «+» біля iOS App.
Зайшовши в неї, ви можете:
-
додати повний опис;
-
заповнити поле ключових слів;
-
додати скріншоти й іконку.
Іконка додається не як окремий файл, вона вже має бути вбудована у ваш каталог ресурсів у проєкті в Xcode.
Після додавання піктограм у Xcode завантажте білд до App Store Connect, у розділ Build. Розділи вище на цій сторінці заповняться автоматично на основі раніше вказаних даних.
Зауважте: title, subtitle, keywords, скріншоти та іконка — це не просто красиві картинки і хештеги. Ці метадані — результат ретельного дослідження: вивчення конкурентів, збору найкращих і найефективніших дизайнерських практик.
Ось тут мої колеги розповідали, як просувати застосунок в App Store, а ось чек-ліст, що допоможе повністю підготувати застосунок до релізу та якісно проаналізувати результати. Також читайте про 75 помилок в ASO-оптимізації.
Xcode і завантаження білда
Xcode — це «тіло застосунку». Він може доставити білд у стор лише за умови, що:
-
членство в Developer Program активне;
-
App Record створений і коректно заповнений;
-
усі поля Bundle ID заповнені.
Для App Store також потрібні distribution-сертифікати, які раніше створювалися вручну на сайті Apple. На момент публікації матеріалу, якщо увімкнено Automatically manage signing, Xcode усе налаштовує сам.
Після завантаження білд проходить обробку в App Store Connect і зʼявляється також у TestFlight — середовищі для бета-тестування.
Фінальна перевірка та відправка на реліз
Поверніться назад на вкладку версії (наприклад, «1.0 Prepare for Submission») і підготуйте застосунок до релізу за подальшими кроками:
-
Build. У секції Build натисніть «+» і виберіть потрібну версію.
-
App Review Information. Це інформація для ревʼюера
Якщо у вашому додатку є реєстрація, ви зобов’язані створити тестовий акаунт і вказати логін/пароль у полі «App Review Information». Якщо рев’юер не зможе увійти — ви отримаєте реджект. Рекомендую пояснити в нотатках, де знаходяться основні функції застосунку, щоб рев’юер зміг їх потестувати. -
Version Release:
- Automatically release — віддає застосунок на реліз одразу, за готовностю всіх полів;
- Manually release — віддає на реліз після натискання кнопки.
Сабміт і контрольні запитання
Перед публікацією Apple поставить стандартні юридичні запитання — чи наявні в програмі:
-
Export Compliance;
-
Content Rights;
-
Advertising Identifier.
Це закриті питання, на які можна відповісти або так, або ні. Вони важливі для рев’ю і дотримання авторських прав. Без відповідей кнопка сабміту не активується.
App Review і що далі
Після сабміту статус застосунку змінюється на Waiting for Review. Зазвичай перевірка триває 24–48 годин.
Найчастіші причини реджектів:
-
нестабільна робота — велика кількість помилок у роботі чи зависання;
-
відсутній тестовий акаунт або рев’юер не зміг ним скористатися;
-
невідповідність метаданих реальному функціоналу.
Реліз в App Store — це не кнопка Launch. Це послідовний процес, де кожна система відповідає за свою частину. Якщо пройти його спокійно й по порядку, App Store перестає бути джерелом паніки й стає передбачуваним інструментом росту.
Чек-ліст публікації застосунку в App Store
-
Визначити тип акаунта: Individual чи Organization.
-
Налаштування App Store Connect:
- додати застосунок;
- вказати, для якої він платформи;
- вказати назву застосунку;
- додати локалізації і Primary Language;
- створити Bundle ID та SKU;
- обрати User Access.
-
Заповнити інформацію про застосунок в App Information від назви до угоди з користувачем.
-
Вказати в App Privacy, які дані збирає застосунок.
-
Вказати доступність застосунку для користувачів в Pricing & Availability.
-
Додати іконку, скріншоти, назву, підзаголовок і ключові слова.
-
Налаштувати distribution-сертифікати в X-code.
Перед ревʼю:
-
додати білд у нову версію;
-
заповнити App Review Information;
-
обрати тип релізу — Manually release чи Automatically release;
-
відповісти на контрольні запитання перед ревʼю;
-
чекати на успішне проходження ревʼю.
Свіжі
UX-аудит для Foundation: що заважає користувачам купувати та як це виправити
Трохи про порожній пошук, зайві дії й оформлення, яке не допомагає рухатися далі
Local campaigns в Meta Ads: від створення локації до запуску кампанії
Як працюють локальні рекламні кампанії в Meta Ads, коли їх варто використовувати та як правильно налаштувати рекламу
Як збільшити трафік на 286% в категорії черевиків: кейс магазину взуття Miraton
Вивели ключову категорію бренду в топ-3 пошуку через розширення структури сайту та роботу з індексацією














