Підготуйте застосунок до магазинів з агентом програмування

Перш ніж почати

Вам потрібні Claude Code і акаунт AppFoyer. Безкоштовного тарифу досить: створіть акаунт. Ключ створювати не треба — під час першого підключення агент попросить вас схвалити його в браузері.

Агента програмування немає взагалі? Шість полів у браузері дадуть ті самі п’ять сторінок без плагіна.

Не користуєтеся Claude Code? Плагіну він потрібен, а сторінкам політики конфіденційності та умов — ні: у їхніх редакторах у дашборді є промпт, заповнений даними вашого застосунку, який ви запускаєте в будь-якому асистенті й вставляєте відповідь назад. Повністю його наведено в посібнику про політику конфіденційності і посібнику про умови.

Встановлення

claude
/plugin marketplace add appfoyer/claude-plugin
/plugin install appfoyer@appfoyer

Щоб почати, акаунт не потрібен: агент читає збірку, показує, що знайшов, і ставить запитання на вашому комп’ютері, а підключитися просить лише тоді, коли є що зберегти. Коли він уперше звертається до AppFoyer, у браузері відкривається сторінка схвалення: увійдіть або створіть безкоштовний акаунт, перевірте назву й адресу, на яку повернеться браузер, і схваліть. Claude Code зберігає підключення й сам його поновлює; нічого не копіюється, нічого не зберігається у вашій оболонці. Якщо браузер не відкрився, виконайте /mcp, оберіть appfoyer і виберіть Authenticate. У настільному застосунку Claude Code підключіться один раз так само з термінала, а потім почніть там новий сеанс: сеанс, що вже був запущений, нового підключення не бачить. Відключіть його на сторінці Agent у дашборді — і наступний виклик одразу завершиться помилкою. Claude Code сам не оновлює сторонній маркетплейс: у /plugin → Marketplaces → appfoyer виберіть Enable auto-update, щоб отримувати нові версії.

На цьому комп’ютері немає браузера — віддалений сервер, контейнер, запуск зі скрипта? Тоді використайте API-ключ: створіть його в Agent → API key — for CI and headless use, установіть плагін, як описано вище, заради робочого процесу, і додайте сервер ще раз із ключем у заголовку:

export APPFOYER_API_KEY=cpk_…
claude mcp add --transport http appfoyer-key https://app.appfoyer.com/mcp --header "Authorization: Bearer $APPFOYER_API_KEY"

Плагін читає ключ лише з цієї змінної середовища — скіл його ніколи не бачить, і передається він лише в заголовку Authorization, який заповнює Claude Code.

Інший MCP-клієнт — claude.ai, Claude Desktop, Cursor, VS Code — може підключитися до https://app.appfoyer.com/mcp так само, через ту саму сторінку схвалення. Він отримає інструменти; покроковий робочий процес, який читає файли збірки, постачається з плагіном Claude Code.

Що сказати

Запускайте це в репозиторії вашого застосунку, а не в порожньому каталозі:

Приклади

Кажіть своїми словами; ось випадки, з якими працює скіл.

Один застосунок, перший запуск

> Make this app store-ready

• Перелічує, що знайшов у файлах збірки, — SDK, дозволи, bundle id — кожне з файлом і рядком.
• Питає лише те, чого не зміг знайти: назву компанії, email підтримки, юрисдикцію, посилання на магазини. Щонайбільше два раунди.
• Створює застосунок, завантажує значок із репозиторію й складає чернетки всіх п’яти сторінок.
• Завершує посиланням для перевірки. Ніщо не стає публічним, доки ви не опублікуєте там.

Повторний запуск після зміни

> Make this app store-ready

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

Кілька flavor, названих у запиті

> Make com.acme.weather.free and com.acme.weather.pro store-ready

• Створює два застосунки й нічого не питає про вибір.
• Читає власну папку, назву й залежності кожного flavor. Рекламний SDK, який використовує лише безкоштовний flavor, не потрапляє в політику конфіденційності pro-flavor.
• Повертає посилання для перевірки й таблицю URL для консолей для кожного flavor.

Кілька flavor, не названих у запиті

> Make this app store-ready

• Перелічує flavor з їхніми application id, усі заздалегідь вибрані, і ви обираєте, які з них отримають сайт.
• Типи збірок на кшталт debug і staging показуються як виключені, а не пропонуються.

Виміри бренд × середовище

> Make every brand store-ready

• Перелічує комбінації (brandAProd, brandBProd), а не окремі flavor.
• Пропонує лише продакшн-середовище. dev і qa ніколи не потрапляють у магазин.
• Читає назву застосунку з Gradle (resValue, manifestPlaceholders) або з перенесених source sets, коли збірка зберігає її там.
• Якщо не може визначити, чи вимір — це середовища чи бренди, — питає.

Власна адреса (Pro та Advanced)

> Make this app store-ready

• Складає адресу з англійської назви застосунку, наприклад weather-now.
• Якщо її зайнято або вона надто схожа на назву бренду, пробує наступну — weather-now-app, acme-weather — щонайбільше п’ять разів, а потім питає вас.
• На безкоштовному тарифі лишає адресу app-… і повідомляє, що власна адреса доступна з Pro.
• Адреса app-… і далі віддає той самий сайт.

Зміна адреси, якою ви вже користуєтеся

> Change the address to weather-radar

• Спершу питає. Стара власна адреса звільняється одразу, і сторінка в магазині, де вона досі вказана, перестає працювати.
• Змінює її лише після вашої згоди.

Оновлення значка

> Update the app icon

• Знаходить значок запуску: значок Play 512, найбільше зображення mipmap або маркетингове зображення iOS AppIcon — спершу власний значок flavor.
• Якщо він більший за 512 KB, зменшує копію в тимчасовій папці. Ваш репозиторій не змінюється.
• Повідомляє, який файл завантажив. На опублікованому застосунку новий значок з’являється одразу.

Застосунок із рекламою

> Make this app store-ready. AdMob publisher id pub-0000000000000000

• Записує app-ads.txt із рядків, які ви надали. Ідентифікатора видавця немає у вашому коді, тож він його ніколи не вгадує.
• Нагадує вказати сайт як вебсайт розробника на сторінці в магазині.
• AdMob перевірив файли app-ads.txt на наших адресах; дайте йому до 24 годин на сканування.

Тримати сторінки синхронізованими зі збіркою

> Add the AppFoyer drift check

• Кожен запуск “make this app store-ready” записує appfoyer.json у корінь репозиторію: SDK, типи даних і дозволи, на основі яких написано сторінки. Його записує той самий сканер, що виконує перевірку, і ніколи — вручну.
• Цей запит показує робочий процес GitHub для безкоштовного appfoyer/check-action і записує .github/workflows/appfoyer.yml, коли ви погоджуєтеся. Наявний файл він ніколи не перезаписує.
• Відтоді кожен pull request показує, що він додав або прибрав відтоді, як було написано сторінки, — із файлом і рядком. Повторний запуск плагіна оновлює чернетки й appfoyer.json.
• Нічого не комітиться за вас. У посібнику про синхронізацію політики конфіденційності є подробиці й налаштування для інших CI-систем.

Перевірити, нічого не змінюючи

> Is this app store-ready?

• Проходить чекліст для кожного відповідного застосунку й повідомляє, чого бракує. Нічого не записує.
• Flavor, для якого ще немає застосунку, позначається як відсутній.

Додати посилання в застосунок

> Wire the store-ready links into the app

• Потрібні опубліковані сторінки.
• Пропонує diff для посилань на політику конфіденційності й підтримку на екрані налаштувань чи в рядках застосунку. Застосовує його лише після вашої згоди й ніколи не комітить.

Що залишає ваш комп’ютер

Лише виведені факти:

• назва застосунку, платформа та bundle id або application id;
• назви SDK і дозволів, знайдених у файлах збірки;
• відповіді, які ви підтверджуєте, — назва компанії, email підтримки, юрисдикція, URL магазинів;
• текст сторінок, складений агентом, який зберігається у вашому акаунті як чернетка;
• власний значок застосунку, надісланий один раз через одноразове посилання для завантаження.

Жодних інших файлів, ніколи — вихідного коду, ніколи — секретів чи ключів, знайдених у репозиторії. Те, що надсилає агент, — це те, що політика конфіденційності й так має зазначати.

Один файл записується у ваш репозиторій і там лишається: appfoyer.json — запис того, на основі чого написано сторінки, створений сканером, що входить до плагіна. Він нікуди не надсилається. Агент ніколи не комітить ні його, ні щось інше — це робите ви.

Чого агент не може

Хоч через браузер, хоч з API-ключем — плагін має облікові дані агента, тож публікація йому недоступна взагалі. Це забезпечує сервер, а не ввічливе прохання до агента:

• Інструмента для публікації немає. Агент пише чернетки; ваші опубліковані сторінки не змінюються.
• Дві речі не мають чернетки: значок і власна адреса. На опублікованому застосунку вони одразу змінюють живий сайт, і агент повідомляє, коли їх установив. Замінити власну адресу, якою ви вже користуєтеся, без вашої згоди він не може.
• REST-маршрут, що публікує сторінку, повністю відхиляє облікові дані агента — лише сеанс.
• Кожна сторінка під час публікації проходить ту саму перевірку вмісту, що й редагування вручну.
• Кожен виклик агента записується в журнал аудиту акаунта разом із підключенням чи ключем, що його зробили.

Тож найгірше, що може статися зі скомпрометованим підключенням чи ключем, — чернетки, які доведеться відкинути, неправильний значок або нова адреса, а не сторінка, опублікована від вашого імені.

Інструменти, які він отримує

Плагін підключається до MCP-ендпоінта, що надає саме ці інструменти:

Коли щось іде не так

Чого це не змінює

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

Запитання: support@appfoyer.com.