1. Високорівневий погляд на процес рецензії
Публікація ChatGPT App у Store — це не «залив посилання й забув», а цілком живий процес. У спрощеному вигляді він має такий вигляд: ви готуєте App, надсилаєте його на рецензію, рецензенти перевіряють за своїми чек‑листами, ви отримуєте зауваження, допрацьовуєте — і подаєте знову. І так кілька разів, доки результат не влаштує всіх.
Найзручніше уявляти це як невеликий робочий процес (workflow):
flowchart TD A[Dev Mode / Internal beta] --> B[Submit to Store] B --> C[Under review] C -->|Approved| D[Published] C -->|Changes requested| E[Fixes & Iteration] E --> B D --> F[Updates] F --> C D --> G[Paused / Unpublished]
На ранніх етапах (Dev Mode, внутрішній бета‑тест) ви виявляєте технічні та UX‑проблеми. Коли натискаєте «Submit to Store», починається формальніша рецензія. Перевіряють відповідність політикам контенту, дозволи, стабільність, а також те, що написано в лістингу й юридичних документах.
Корисно одразу прийняти таку філософію: рецензія — не іспит, де ви або «склали» й більше ніколи сюди не повертаєтеся, або «провалили». Це постійний канал зворотного звʼязку між вами та платформою. Store хоче, щоб ваш App був безпечним, зрозумілим і стабільним. А ви хочете, щоб вас допустили до користувачів і не зняли за тиждень. І так, ваші інтереси тут справді збігаються.
2. Що ви надсилаєте на рецензію
Перш ніж хтось на боці платформи відкриє ваш App, ви заповнюєте доволі стандартний набір даних:
- Метадані App: назва, підзаголовок, категорія, іконка.
- Опис лістингу: короткий і повний описи, приклади сценаріїв.
- Посилання на Privacy Policy, Terms, Support/Contact.
- Налаштування дозволів: які доступи запитує App (наприклад, OAuth, зовнішні API, платіжні режими тощо).
- Іноді — опис тестових сценаріїв та облікових записів для рецензента.
- Власне App: MCP‑сервер, UI‑бандл, system‑prompt і описи tools, які платформа вже знає з Dev Mode/production‑URL.
Технічно на цьому етапі ви вже розгортаєте production‑версію (зазвичай на Vercel або аналогу), до якої Store і звертатиметься. Тобто кнопка «Submit» — це не про деплой коду, а про зміну його статусу: «цей код уже працює у вашому продакшні, тож тепер, будь ласка, перевірте його й відкрийте доступ користувачам».
Щоб повʼязати всі частини, зазвичай зручно мати невеликий конфіг у репозиторії, де ви явно фіксуєте, що саме входить у версію «кандидата на рецензію». Наприклад, проста TypeScript‑структура:
// config/release-candidate.ts
export const releaseCandidate = {
version: "1.0.0",
apiBaseUrl: process.env.API_BASE_URL,
enableCommerce: true,
privacyPolicyUrl: "https://example.com/legal/privacy",
termsUrl: "https://example.com/legal/terms",
supportUrl: "https://example.com/support",
};
Такий файл не замінює форму Store, але допомагає команді чітко розуміти, що саме ви зараз «показуєте» рецензентам і користувачам.
3. Як рецензенти дивляться на ваш App
Отже, ви заповнили форми, підготували посилання й натиснули Submit. Що відбувається по той бік Store? Уявіть, що ви самі — рецензент. Ви не бачили вашого коду, не знаєте всієї історії проєкту, зате маєте чек‑лист і обмежений час. Зазвичай на App дивляться з кількох ракурсів.
По‑перше, перевіряють відповідність політикам контенту та бренду. Не можна пропонувати заборонені категорії, порушувати правила щодо медицини, права чи фінансів без потрібних дисклеймерів і «human in the loop». Також не можна видавати себе за OpenAI або використовувати їхній бренд так, ніби це офіційний продукт.
По‑друге, аналізують дозволи. Якщо ви просите доступ до чогось чутливого (профілі користувачів, платежі, сторонній акаунт через OAuth), вас запитають: чи справді це потрібно? І чи зрозуміло це користувачеві з опису та з поведінки App? Ідеальний варіант — коли дозволи мінімальні й чітко відповідають заявленим сценаріям.
По‑третє, оцінюють UX і стабільність. App не має «захоплювати» весь екран ChatGPT: якщо він без кінця розгортається у fullscreen з будь‑якого приводу та без зрозумілого пояснення, це буде мінус. Якщо бекенд регулярно повертає помилки, а інструменти ламаються через раз, довіри теж не буде.
Нарешті, перевіряють чесність лістингу: чи збігається опис App із тим, що рецензент реально бачить у чаті. Якщо ви обіцяєте «блискавичний підбір ідеального подарунка та миттєвий checkout», а на практиці App тричі падає на кроці пошуку й не вміє оформлювати замовлення, рецензія завершиться швидко й невесело.
Щоб рецензентам було простіше, варто заздалегідь підготувати їм «маршрут»: список кроків, які треба спробувати, та очікувані результати. Це буде корисно й для вашої власної регресії.
Найпростіший приклад такого опису в коді — структура з тестовими сценаріями, на яку можна посилатися у внутрішній документації:
// test/review-scenarios.ts
export const reviewScenarios = [
{
id: "gift-basic",
title: "Підбір подарунка без купівлі",
steps: [
"Попросити: Підбери подарунок для друга, любить настільні ігри, бюджет 50$",
"Переконатися, що App пропонує варіанти і не вимагає логіна",
],
},
{
id: "gift-checkout",
title: "Підбір подарунка з тестовим checkout",
steps: [
"Вибрати будь-який подарунок зі списку",
"Перейти до оформлення, використовуючи тестову картку",
],
},
];
Ця структура не потрапляє у Store напряму, зате дисциплінує команду й згодом допомагає оновлювати описи для рецензентів і техпідтримки.
4. Тестові акаунти та дані: без них рецензія не зрушить з місця
Щойно в сценаріях зʼявляються гроші, персональні дані або зовнішні акаунти, рецензенти очікують, що ви надасте безпечний спосіб пройти весь шлях — без використання їхньої реальної картки, особистої пошти чи справжнього Slack/Google/чого‑завгодно.
Умовно можна виокремити два великі типи тестових сутностей.
Перший тип — тестові користувачі/організації у вашій системі. Наприклад, для GiftGenius ви можете створити спеціальну «рецензійну організацію» із заздалегідь підготовленим демо‑каталогом і привʼязаними тестовими платіжними методами в sandbox‑режимі платіжного провайдера. Важливо, щоб рецензент не проходив складне первинне налаштування: у ідеалі він отримує логін/пароль або «магічне» посилання — і відразу потрапляє в готову «пісочницю».
Другий тип — тестові дані зовнішніх провайдерів. Платежі, як правило, мають sandbox‑режим (test cards, test accounts). Якщо ваш App делегує оплату через ACP/Instant Checkout, ви маєте бути впевнені, що під час рецензії використовується тестове середовище — і ніхто не платить реальними грошима. Це вже зачіпає архітектуру commerce‑частини, але ідея проста: додати в бекенд прапорець «review/test mode».
У термінах коду це може виглядати як простий прапорець середовища та конфіг:
// config/env.ts
export const env = {
nodeEnv: process.env.NODE_ENV,
reviewMode: process.env.REVIEW_MODE === "true",
paymentProviderEnv: process.env.REVIEW_MODE === "true" ? "sandbox" : "production",
};
А в місці, де ви ініціалізуєте клієнта платіжної системи:
// lib/payments/client.ts
import { env } from "@/config/env";
export const paymentClient = createPaymentClient({
environment: env.paymentProviderEnv, // "sandbox" чи "production"
apiKey: process.env.PAYMENT_API_KEY!,
});
Така дрібниця помітно полегшує життя: ви можете запускати App у режимі, максимально схожому на продакшн, але водночас рецензенти не торкатимуться справжніх грошей.
Окремо варто продумати тестові сценарії для інтеграцій на кшталт Gmail, Slack, Notion тощо. Там, де використовується OAuth, рецензія часто очікує або спільний демо‑акаунт, або дуже просту інструкцію, як створити тестовий робочий простір. Намагайтеся уникати сценаріїв на кшталт «напишіть у support, ми вручну вам щось увімкнемо» — рецензія нерідко автоматизована й обмежена в часі, тож чекати на ваш лист ніхто не буде.
5. Типові зауваження від рецензії та як на них реагувати
Тепер, можливо, неприємна новина: імовірність того, що перший прохід через рецензію буде ідеальним, близька до імовірності того, що програміст одразу напише код без багів. Тобто десь поблизу нуля. І це нормально.
Зауваження найчастіше зводяться до кількох передбачуваних категорій.
Перша категорія — дозволи та приватність. Наприклад, ви просите доступ до електронної пошти користувача, але в лістингу не пояснюєте, навіщо. Або в Privacy Policy написано, що ви «не зберігаєте дані чату», тоді як логи MCP‑сервера спокійно записують увесь запит разом із PII. Рецензент може попросити або уточнити документи, або змінити поведінку App — або і те, і інше.
Друга категорія — UX і поведінка в чаті. App може «захоплювати» діалог: агресивно відкривати fullscreen там, де можна обійтися inline, не залишати текстового резюме після дій, не давати користувачеві зрозумілого способу «повернутися до чату». У таких випадках найімовірніше попросять спростити UX і поважати основний діалоговий інтерфейс ChatGPT.
Третя категорія — стабільність і помилки. Якщо за типових сценаріїв App регулярно показує «Error talking to app» або внутрішні 500‑ки, рецензія може зупинитися доти, доки ви не доведете, що це поодинокі збої, а не норма. Тут від вас чекають не лише виправлення багів, а й мінімальної спостережуваності: логів, health‑чеків, розумних таймаутів.
Четверта категорія — чесність лістингу та маркетингових обіцянок. Якщо в описі ви обіцяєте більше, ніж реально вмієте, рецензенти зазвичай швидко це помічають — особливо якщо ви гарантуєте результат у чутливих доменах. Виправлення в такій ситуації складається з двох кроків: або зменшуєте обіцянки, або нарощуєте реалізацію (найчастіше — перше).
Як правильно реагувати на зауваження? Головне правило — ставитися до рецензії як до партнерства, а не як до «злих модераторів». У відповіді корисно:
- Чітко визнати проблему: «Так, у поточній версії App робить X, а в описі написано Y».
- Описати, що ви вже змінили: «Ми скоригували лістинг і оновили Privacy Policy, уточнивши, що…».
- За можливості додати короткий тестовий сценарій, у якому рецензент побачить виправлення.
Якщо ви не до кінця розумієте, чому надійшло зауваження, краще поставити уточнювальне запитання, а не намагатися вгадати. Наприклад: «Чи правильно ми розуміємо, що основна проблема в тому, що App автоматично розгортається у fullscreen без запиту користувача?».
6. Внутрішній чек‑лист перед надсиланням на рецензію
Щоб скоротити кількість ітерацій, корисно завести власний «pre‑flight чек‑лист» за мотивами модулів 7, 15–17. Це не список «для галочки», а цілком практична річ, яку ви справді проходите перед кожним поданням.
Технічно ви можете навіть «зашити» цей чек‑лист у репозиторій як невеликий JSON/TS‑модуль і проганяти його в README або в пайплайні.
Найпростіший варіант на TypeScript може виглядати так:
// tools/review-checklist.ts
export interface ChecklistItem {
id: string;
description: string;
done: boolean;
}
export const reviewChecklist: ChecklistItem[] = [
{
id: "ux-inline-first",
description: "Основні сценарії App працюють в inline-режимі, fullscreen лише там, де це справді виправдано.",
done: false,
},
{
id: "privacy-links",
description: "Посилання на Privacy Policy, Terms, Support валідні та відкриваються без авторизації.",
done: false,
},
{
id: "permissions-minimal",
description: "Запитано лише мінімально необхідні дозволи; кожен із них описаний у лістингу.",
done: false,
},
];
А у власних внутрішніх інструментах або просто в консолі ви можете виводити цей список і позначати прогрес. Це, звісно, не обовʼязкова автоматизація, але програмісти традиційно краще дружать із кодом, ніж із Google Docs. Тож чому б не використати звичний інструмент.
7. Ітерації та версіонування: життя після першої публікації
Сюрприз номер два: навіть після того, як ваш App пройшов рецензію й став доступним користувачам, процес не закінчується. Будь‑яке суттєве оновлення може знову запустити перевірку — особливо якщо ви змінюєте дозволи, додаєте нові чутливі сценарії або радикально переробляєте UX.
Тому варто ставитися до ChatGPT App як до живого продукту з нормальним release‑процесом, а не як до «останнього пострілу».
Зазвичай розумний мінімум такий: у вас є версія в коді (semver), журнал змін (changelog) і розуміння, які релізи тягнуть за собою потребу повторної рецензії, а які — ні. Наприклад, виправлення друкарських помилок в UI, що не зачіпає поведінки App і дозволів, може пройти «тихо». А перехід від «лише рекомендації» до «повноцінного checkout з оплатою» точно потребуватиме нової уваги.
У коді це може виглядати як проста константа та обʼєкт зі змінами:
// config/app-version.ts
export const appVersion = "1.1.0";
export const appChangelog = {
"1.1.0": [
"Додано sandbox-checkout для тестових користувачів",
"Уточнено опис дозволів у лістингу",
],
"1.0.0": ["Перша публічна версія GiftGenius без оплати"],
};
І так, чудово, якщо ви синхронізуєте ці нотатки з тим, що пишете в реліз‑нотах Store. Тоді і рецензентам, і користувачам легше розуміти, що саме змінилося.
8. Комунікація з платформою: як не посваритися з рецензентами
Мабуть, одна з найнедооцінених навичок — нормально спілкуватися з рецензентами. Зазвичай зворотний звʼязок приходить у вигляді набору тез: що не так, на які пункти політик ви натрапили, які частини UX викликають запитання. Хороша відповідь — це не «Та ви нічого не розумієте», а спокійне й конкретне повідомлення.
Варто тримати в голові кілька простих принципів.
По‑перше, ясність. Не пишіть кілометрових есе про те, як влаштована внутрішня архітектура вашого MCP‑сервера й чому вона така прекрасна. Рецензента цікавить насамперед користувацький досвід і відповідність політикам. Достатньо коротко описати, що ви змінили й як це тепер можна перевірити.
По‑друге, прозорість. Якщо проблема складніша, ніж «ми виправили текст», і потребує суттєвих переробок, чесніше написати: «Це зауваження зачіпає ключову частину нашого checkout‑флоу, нам знадобиться 1–2 тижні на коректне виправлення. Ми надішлемо оновлену версію, щойно вона буде готова».
По‑третє, памʼять. Зауваження рецензії варто зберігати не лише в пошті чи у внутрішньому трекері, а й у вигляді короткого «рішення» в документації: що саме було не можна і чому. Це допомагає новим розробникам і продакту не наступати на ті самі граблі. Тут стане в пригоді проста внутрішня нотатка в документації або навіть README‑секція на кшталт «Store Review Decisions».
9. Звʼязок з архітектурою та попередніми модулями
Корисно дивитися на процес рецензії як на «інтегральну перевірку» всього, над чим ви працювали в попередніх модулях.
Без модулів із безпеки та дозволів (7, 15) у вас, найімовірніше, виникатимуть запитання щодо доступів, роботи з PII, OAuth і destructive actions.
Без модулів зі стабільності та спостережуваності (16, 17) ви не зможете виразно пояснити, чому App іноді падає, а іноді ні, і як ви за цим стежите. Метрики та SLO перетворюються з теорії на аргументи: «ми бачимо p95 < 2 с для основного інструмента і error rate < 1 % за останні N днів».
Без UX‑модулів (8, 11) App може просто «ламати» чат: fullscreen там, де він не потрібен, незрозумілі переходи між режимами, відсутність текстового резюме. Рецензенти помічають такі речі швидше за вас, бо тестують багато різних App і добре відчувають, коли хтось «перегинає палицю».
І нарешті, без сьогоднішнього розуміння процесу рецензії ви ризикуєте застрягти на стадії «ми надіслали, нам повернули, ми образилися». Натомість правильніше сприймати це як ще один цикл ітерацій, дуже схожий на вашу внутрішню регресію, тільки з додатковим зацікавленим учасником — платформою.
У підсумку, якщо у вас є адекватний чек‑лист, тестові акаунти та sandbox‑режим, базова спостережуваність і нормальна комунікація з рецензентами, процес рецензії перестає бути лотереєю. Це просто ще один ітеративний цикл навколо вашого ChatGPT App — такий самий природний, як регресія перед релізом або код‑ревʼю всередині команди.
10. Типові помилки під час проходження рецензії
Помилка № 1: Надіслати App «як є» без внутрішнього чек‑листа.
Багато команд натискають «Submit» одразу після того, як App «запрацював» у Dev Mode. У результаті на рецензії спливають базові речі: биті посилання на Privacy/Terms, неробочі сценарії, відсутність тестових акаунтів. Це лікується простим внутрішнім чек‑листом, який ви справді проходите перед кожним поданням (валідні посилання, мінімальні дозволи, працездатні ключові сценарії). Приклад такого чек‑листа ми щойно розібрали в розділі «Внутрішній чек‑лист перед надсиланням на рецензію».
Помилка № 2: Ігнорувати тестові акаунти та sandbox‑режими.
Надсилати на рецензію App, який вимагає від рецензента реальної банківської картки, — погана ідея. Так само погано, якщо checkout теоретично є, але рецензент узагалі не може його протестувати. Потрібно заздалегідь продумати тестові організації/користувачів у вашій системі та sandbox‑режим платіжного провайдера, привʼязаний до REVIEW_MODE або аналогічного прапорця.
Помилка № 3: Намагатися «виторгувати» винятки замість того, щоб виправити проблему.
Іноді розробники починають сперечатися з рецензентом: «але ж у конкурентів так само» або «це обмеження платформи, ми тут ні до чого». Такий стиль рідко допомагає. Значно ефективніше переформульовувати сценарій, спрощувати UX, зменшувати дозволи та правити лістинг так, щоб він чесно відображав поведінку App.
Помилка № 4: Не документувати зауваження та рішення.
Якщо ви отримали коментар від рецензії й просто «виправили баг у коді», не записавши, що саме було не можна, за пів року хтось у команді знову зробить те саме. Краще вести невеликий реєстр рішень рецензії: «Не можна автоматично розгортати fullscreen без явної дії користувача», «не можна зберігати повні тексти чатів довше N днів без явного зазначення в Policy» тощо.
Помилка № 5: «Великі релізи» без поетапної стратегії.
Намагатися за один реліз додати і оплату, і нові дозволи, і новий UX, і перероблений бекенд — чудовий рецепт для довгих ітерацій рецензії. Набагато спокійніше рухатися невеликими кроками: спочатку рекомендації без оплати, потім — sandbox‑checkout, потім — повноцінний платіжний флоу. Так ви і ризики знижуєте, і приводів для запитань на рецензії стає менше.
Помилка № 6: Спиратися на перевірку Store замість власної QA та спостережуваності.
Іноді команда підсвідомо чекає, що рецензенти «протестують за них». У результаті рецензія перетворюється на безкоштовний QA, але затягує запуск на тижні. Значно здоровіше ставитися до рецензії як до фінальної sanity‑перевірки вже досить зрілого продукту, у якого є свої тести, логи, метрики та зрозумілі сценарії.
ПЕРЕЙДІТЬ В ПОВНУ ВЕРСІЮ