Як опублікувати застосунок в App Store без програміста: TestFlight, рев'ю і що робити після відмови

Я Дмитро Ніколаєнко, 15 років у продуктовому дизайні, вів дизайн восьми мобільних банків. Роками мої екрани в App Store відправляли інші люди. Тепер відправляємо самі: Heroco, наша платформа, де діти 7-15 років створюють з AI, вийшла в App Store двома застосунками, для батьків і для дітей. Код писав Claude Code, кнопки в App Store Connect натискали ми.

Як зібрати сам застосунок у Xcode, я розписав у кейсі мій перший iOS-застосунок з Claude Code. Там App Store зайняв п'ять пунктів списком. Тут усе, що за ними: від запису в App Store Connect до листа з відмовою і другої подачі.

Що потрібно, щоб опублікувати застосунок в App Store без програміста?

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

• Mac з актуальним Xcode. Apple періодично піднімає мінімальну версію Xcode для завантаження в стор, тож оновлюйся до подачі, а не після помилки.
• Платний акаунт Apple Developer Program. Річна підписка. Для фізособи потрібен Apple Account з двофакторною автентифікацією, для компанії ще й номер D-U-N-S. Заявку подавай одразу: без акаунта не буде ні TestFlight, ні App Store.
• Застосунок, який не падає і не має заглушок.
• Публічна сторінка з політикою конфіденційності. Обов'язкова для всіх, навіть якщо ти нічого не збираєш.
• Іконка, скріншоти і тексти сторінки.

Claude Code закриває код, тексти і пояснення. Тобі лишаються акаунт, юридичні галочки, кнопки в App Store Connect і перевірка на живому телефоні. Термінал не обов'язковий, про це стаття Claude Code без терміналу.

Що підготувати в App Store Connect?

App Store Connect - кабінет зі сторінкою застосунку, збірками, тестерами і листуванням з рецензентом. Порядок, який у нас спрацював:

1. Bundle ID. Формат зворотного домену, наприклад com.yourname.app. Задаєш у Xcode, після першої завантаженої збірки вже не змінити, тож ніяких «test123».
2. Запис застосунку. Apps → «+» → New App: платформа, назва (унікальна на весь стор), мова, bundle ID і SKU, будь-який твій внутрішній код.
3. Іконка 1024×1024 без прозорості.
4. Скріншоти. Точні розміри дивись у специфікаціях Apple. Не адаптуєш під iPad - прибери його в Xcode із Supported Destinations: менше скріншотів і приводів для відмови.
5. Тексти. Назва і підзаголовок до 30 символів, ключові слова до 100 байтів, опис і категорія. Саме байтів: кирилична літера займає два, тож українських ключових слів влізе вдвічі менше. Без згадок Android та інших платформ.
6. Privacy Policy URL і анкета App Privacy. Які дані збираєш, чи пов'язуєш їх з людиною, чи трекаєш. Сюди ж аналітика і сторонні SDK.
7. Віковий рейтинг. Анкета про контент, відповідай як є.
8. Шифрування. Якщо застосунок використовує тільки стандартний HTTPS, зазвичай у Info.plist ставлять ITSAppUsesNonExemptEncryption = NO. Тоді збірка не зависає зі статусом Missing Compliance.

Найбільше Claude рятує на пунктах 5 і 6. Тексти пише під ліміти, а довжину попроси перевірити скриптом: на око моделі рахують погано. А для App Privacy я прошу його пройтись по коду, щоб заповнювати анкету не з пам'яті:

Пройдись по коду застосунку і склади таблицю для анкети App Privacy:
які дані збираємо, де саме в коді, чи прив'язані вони до акаунта,
чи йдуть у сторонні SDK (аналітика, крашрепорти, оплати).
Нічого не змінюй, тільки список.

Що таке TestFlight і як роздати збірку друзям чи замовнику?

TestFlight - це бета твого застосунку на реальних телефонах до релізу. Людина ставить застосунок TestFlight, приймає запрошення і отримує твою збірку.

Шлях збірки: у Xcode Any iOS Device → Product → Archive → Distribute App → App Store Connect. Кожне завантаження має більший build number. Після обробки збірка з'являється у вкладці TestFlight. Тестери бувають двох типів:

Кожна збірка доступна тестерам 90 днів. Цифри з документації TestFlight станом на жовтень 2026, перед стартом звір.

Замовнику не потрібен доступ до кабінету: додай його в зовнішні тестери або кинь публічне посилання. Бонус: перша збірка для зовнішніх тестерів проходить Beta App Review. Перевірка легша за головну, але це перша зустріч з рецензентом Apple ще до подачі в стор.

Як проходить рев'ю Apple і скільки чекати?

Коли збірка перевірена в TestFlight, обираєш її на сторінці версії, заповнюєш App Review Information і відправляєш. Далі статуси: Waiting for Review, In Review, а потім або схвалення, або Rejected. Три поля вирішують більше, ніж здається:

• Sign-in information. Є вхід - дай рецензенту робочий демо-акаунт. Вхід за кодом з пошти він не пройде, твоєї пошти в нього немає. Зроби тестовий акаунт з фіксованим кодом.
• Notes. Англійською: що робить застосунок, як увійти, де нативні функції. Claude пише це за хвилину.
• Version Release. Обери ручний реліз. Інакше застосунок вийде одразу після схвалення, навіть о третій ночі, коли пости про запуск ще не написані.

Скільки чекати? Apple на сторінці App Review пише, що зазвичай розглядає щонайменше 50% заявок до 24 годин і 90% до 48 годин. Це середня температура по лікарні. Персонально тобі ніхто нічого не обіцяв. Неповна заявка, за словами самої Apple, може розглядатись довше. Горить критичний баг - можна попросити expedited review.

Чому Apple відхиляє застосунки інді-розробників?

Пункти, які стосуються майже кожного першого застосунку. Номери звірені з App Review Guidelines у жовтні 2026.

• 2.1, повнота. Краші, заглушки, мертві посилання, рецензент не зміг увійти. Покупки, якщо є, мають працювати і бути видимі рецензенту.
• 4.2, мінімальна функціональність. Застосунок має давати більше, ніж перепакований сайт. Головний ризик для обгорток на Capacitor чи WebView. Додай те, чого немає в браузері: нагадування, haptics, нативне «Поділитись», офлайн.
• 5.1.1, приватність. Посилання на privacy policy і в метаданих, і всередині застосунку. Акаунт не потрібен - не змушуй логінитись. Акаунт можна створити - його має бути можна і видалити прямо в застосунку, пункт 5.1.1(v).
• 4.8, сервіси входу. Вхід через Google чи іншу соцмережу вимагає ще одного рівноцінного варіанта з обмеженим збором даних. Sign in with Apple цю вимогу закриває.
• 3.1.1, цифрові покупки. Підписки, преміум-контент, розблокування функцій ідуть через In-App Purchase. Правила щодо зовнішніх оплат у США і ЄС змінювались, тож перед рішенням читай актуальний розділ 3.1.
• 2.3.10, метадані. Жодного «також на Android» в описі і на скріншотах iOS-сторінки.

Якщо застосунок для дітей, як Heroco, читай ще пункти 1.3 (Kids Category) і 5.1.4 про дані дітей.

Apple відхилив застосунок. Що робити після відмови?

Відмова на першій подачі - нормальна річ. Виглядає страшно рівно до моменту, коли знаходиш у листі номер пункту.

Листування з рецензентом живе в App Store Connect, на сторінці App Review (за звичкою її називають Resolution Center). Спершу визнач, що саме не так:

Відповідай англійською, коротко, по пунктах. Без емоцій і без «а інші застосунки так роблять». Друга відмова за тим самим пунктом зазвичай означає, що виправлено не те: перечитай пункт в оригіналі і попроси рецензента уточнити.

Застосунок уже в сторі, ти випускаєш виправлення бага, а рецензент знайшов ще щось? Apple може запропонувати закрити решту в наступній версії, якщо там немає юридичних чи безпекових питань. Погоджуєшся відповіддю на це повідомлення в App Store Connect.

Як Claude допомагає з листом від App Review?

Claude Code читає і лист, і твій код. Промпт, який можна брати як є:

Ось лист від App Review для [назва застосунку]:
[встав лист повністю]

1. Поясни простими словами, що не так і який пункт
   App Review Guidelines цитує рецензент.
2. Знайди в коді і в текстах сторінки, що саме порушує цей пункт.
3. Склади план виправлень: що в коді, що в App Store Connect,
   чи потрібна нова збірка.
4. Напиши чернетку відповіді рецензенту англійською:
   коротко, ввічливо, по пунктах.
Нічого не змінюй, поки я не погоджу план.

Останній рядок важливий: без нього агент кинеться правити все підряд. І звір номер пункту з оригіналом. Claude може переплутати підпункти, рецензент не переплутає. Після правок пройдись по змінах чеклістом зі статті як дизайнеру перевірити код від AI. Друга відмова через новий баг - найприкріший сценарій.

Що перевірити перед кнопкою Submit for Review?

1. Застосунок не падає на чистому встановленні з TestFlight.
2. Немає заглушок, «Lorem ipsum», «скоро буде» і мертвих кнопок.
3. Демо-акаунт працює без доступу до пошти і вписаний у Sign-in information.
4. У Notes англійською: що робить застосунок і як увійти.
5. Privacy policy відкривається публічно і є посилання в застосунку.
6. Анкета App Privacy заповнена чесно, разом з аналітикою і SDK.
7. Є акаунт - є кнопка «Видалити акаунт», що справді видаляє дані.
8. Є вхід через Google - є і Sign in with Apple або інший рівноцінний варіант за пунктом 4.8.
9. Цифрові покупки йдуть через In-App Purchase і видимі рецензенту.
10. Скріншоти показують реальний застосунок, без згадок Android.

Що робити, якщо немає Mac?

Нативний iOS-застосунок локально без Mac не зібрати. Але шлях до користувача є, а як обрати між варіантами, я розписав у статті PWA чи нативний:

• PWA. Ставиться з браузера на головний екран, без сторів і рев'ю. Пайплайн є в статті як створити застосунок з Claude Code без команди.
• Android першим. Android Studio працює на Windows і Linux. У Google Play для нових особистих акаунтів перед релізом потрібен закритий тест: 12 тестерів протягом 14 днів. Як його пройти, у статті як опублікувати застосунок у Google Play.
• Expo з хмарною збіркою EAS. Збирає iOS у хмарі, без Mac. Акаунт Apple Developer однаково потрібен.

Де пройти цей шлях разом з нами?

Весь маршрут від ідеї до App Store і Google Play ми розклали в курсі «Застосунки з AI»: свій мобільний застосунок з Claude Code, від PWA до оплат, iOS і Android. Лекція про iOS: Capacitor або Expo, TestFlight, рев'ю App Store і що робити з відмовою за 4.2. Курс - це воркбук, де кожен крок, промпт і перевірка записані. Студентка іншого нашого курсу сказала: «воркбук - супер річ, якої ніхто не дає». Старт продажу 26 жовтня.

А в четвер 12 листопада о 19:00 на безкоштовному ефірі #7 «Свій застосунок з Claude Code: від ідеї до деплою за ефір» покажу цей шлях наживо. Реєстрація в боті @uxhero_bot.

Часті питання

Чи можна опублікувати застосунок в App Store без Mac?

Зібрати нативний iOS-застосунок локально без Mac не вийде, бо Xcode працює тільки на macOS. Обхідний шлях - Expo з хмарною збіркою EAS, але акаунт Apple Developer однаково потрібен. Без Mac простіше почати з PWA або з Android.

Чи потрібен програміст, щоб пройти рев'ю App Store?

Ні. Рецензент Apple перевіряє застосунок, хто писав код, його не цікавить. Ми так провели свій Heroco через TestFlight і рев'ю App Store з Claude Code, без команди розробників. Важливіше інше: застосунок без крашів і заглушок, демо-акаунт для рецензента, політика конфіденційності і чесна анкета App Privacy.

Що робити, якщо Apple відхилив застосунок вдруге?

Перечитай в оригіналі пункт App Review Guidelines з листа: друга відмова за тим самим пунктом зазвичай означає, що виправлено не те. Попроси рецензента в App Store Connect уточнити, чого бракує. Якщо впевнений, що правила дотримано, подай апеляцію до App Review Board з конкретними аргументами.

Чи можна тестувати застосунок на своєму iPhone без акаунта розробника?

Так. З безкоштовним Apple Account у Xcode можна поставити застосунок на свій iPhone з увімкненим Developer Mode. Але збірка працює 7 днів, потім її треба перевстановити, і таких застосунків на пристрої не більше 3. Для TestFlight і App Store потрібен платний Apple Developer Program.

Скільки триває рев'ю App Store?

За даними Apple, зазвичай щонайменше 50% заявок розглядають менше ніж за 24 години, а 90% менше ніж за 48 годин. Неповну заявку можуть розглядати довше. Для критичного бага можна попросити прискорене рев'ю (expedited review).

---

Застосунок в App Store без програміста - вже нормальна історія. Код напише Claude. Від тебе потрібні чесні відповіді про дані і спокій, якщо прийде лист з відмовою. Це просто список правок з номерами пунктів.