Przygotuj aplikację do sklepu z agenta kodującego

Zanim zaczniesz

Potrzebujesz Claude Code i konta AppFoyer. Wystarczy plan darmowy: załóż konto. Nie trzeba tworzyć żadnego klucza — przy pierwszym połączeniu agent poprosi Cię o zatwierdzenie w przeglądarce.

W ogóle nie masz agenta kodującego? Sześć pól w przeglądarce daje te same pięć stron bez wtyczki.

Nie używasz Claude Code? Wtyczka go wymaga, ale strony polityki prywatności i regulaminu już nie: ich edytory w panelu mają prompt uzupełniony danymi Twojej aplikacji, który uruchamiasz w dowolnym asystencie i wklejasz odpowiedź — w całości wydrukowany w poradniku o polityce prywatności i poradniku o regulaminie.

Instalacja

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

Na start nie potrzebujesz konta: agent czyta Twój build, pokazuje, co znalazł, i zadaje pytania na Twoim komputerze, a o połączenie prosi dopiero wtedy, gdy jest coś do zapisania. Przy pierwszym wywołaniu AppFoyer Twoja przeglądarka otwiera stronę zatwierdzenia: zaloguj się lub załóż darmowe konto, sprawdź nazwę i adres, na który wróci przeglądarka, i zatwierdź. Claude Code przechowuje połączenie i samo je odnawia; nic nie jest kopiowane, nic nie jest zapisywane w Twojej powłoce. Jeśli przeglądarka się nie otworzy, uruchom /mcp, wybierz appfoyer i kliknij Authenticate. W aplikacji desktopowej Claude Code połącz się raz w ten sposób z terminala, a potem rozpocznij tam nową sesję: sesja, która już działała, nie widzi nowego połączenia. Rozłącz je na stronie Agent w panelu, a następne wywołanie od razu się nie powiedzie. Claude Code nie odświeża samo marketplace’u innej firmy: w /plugin → Marketplaces → appfoyer wybierz Enable auto-update, żeby dostawać nowe wersje.

Na tej maszynie nie ma przeglądarki — zdalny serwer, kontener, uruchomienie ze skryptu? Użyj zamiast tego klucza API: utwórz go w Agent → API key — for CI and headless use, zainstaluj wtyczkę jak wyżej, żeby mieć cały przepływ pracy, i dodaj serwer jeszcze raz z kluczem w nagłówku:

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

Wtyczka odczytuje klucz wyłącznie z tej zmiennej środowiskowej — skill nigdy go nie widzi, a klucz trafia tylko do nagłówka Authorization, który wypełnia Claude Code.

Inny klient MCP — claude.ai, Claude Desktop, Cursor, VS Code — może połączyć się z https://app.appfoyer.com/mcp w ten sam sposób, przez tę samą stronę zatwierdzenia. Dostaje narzędzia; przepływ pracy krok po kroku, który czyta Twoje pliki builda, jest dostarczany z wtyczką Claude Code.

Co powiedzieć

Uruchamiaj to w repozytorium aplikacji, a nie w pustym katalogu:

Przykłady

Mów własnymi słowami; to są przypadki, które obsługuje skill.

Jedna aplikacja, pierwsze uruchomienie

> Make this app store-ready

• Wymienia, co znalazł w plikach builda — SDK, uprawnienia, bundle id — każde z plikiem i wierszem.
• Pyta tylko o to, czego nie mógł znaleźć: nazwę firmy, e-mail wsparcia, jurysdykcję, linki do sklepów. Najwyżej w dwóch rundach.
• Tworzy aplikację, przesyła ikonę z repozytorium i przygotowuje wersje robocze wszystkich pięciu stron.
• Kończy linkiem do przeglądu. Nic nie jest publiczne, dopóki tam nie opublikujesz.

Uruchom ponownie po zmianie

> Make this app store-ready

• Znajduje istniejącą aplikację po jej application id i porównuje nowe fakty z zapisanymi.
• Ponownie przygotowuje tylko te strony, których dotyczy zmiana, np. politykę prywatności po dodaniu nowego SDK analityki.
• Nie rusza ikony ani adresu, chyba że o to poprosisz.

Kilka flavorów, wymienionych w prompcie

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

• Tworzy dwie aplikacje i o nic nie pyta w sprawie wyboru.
• Czyta własny folder, nazwę i zależności każdego flavora. SDK reklamowe używane tylko przez flavor free nie trafia do polityki prywatności flavora pro.
• Zwraca link do przeglądu i tabelę adresów URL do konsoli dla każdego flavora.

Kilka flavorów, niewymienionych

> Make this app store-ready

• Wymienia flavory z ich application id, wszystkie wstępnie zaznaczone, a Ty wybierasz, które dostaną stronę.
• Typy buildów, takie jak debug i staging, są wymienione jako wykluczone, a nie proponowane.

Wymiary marka × środowisko

> Make every brand store-ready

• Wymienia kombinacje (brandAProd, brandBProd), a nie pojedyncze flavory.
• Proponuje tylko środowisko produkcyjne. dev i qa nigdy nie trafiają do sklepu.
• Odczytuje nazwę aplikacji z Gradle (resValue, manifestPlaceholders) lub z przeniesionych source setów, jeśli build ją tam umieszcza.
• Jeśli nie potrafi stwierdzić, czy wymiar to środowiska czy marki, pyta.

Własny adres (Pro i Advanced)

> Make this app store-ready

• Tworzy adres z angielskiej nazwy aplikacji, na przykład weather-now.
• Jeśli jest zajęty lub zbyt podobny do nazwy marki, próbuje kolejnego — weather-now-app, acme-weather — najwyżej pięć razy, a potem pyta Ciebie.
• W planie darmowym zostawia adres app-… i informuje, że własny adres jest dostępny w Pro.
• Adres app-… nadal serwuje tę samą stronę.

Zmiana adresu, którego już używasz

> Change the address to weather-radar

• Najpierw pyta. Stary własny adres zostaje natychmiast zwolniony, a strona aplikacji w sklepie, która nadal go podaje, przestaje działać.
• Zmienia go dopiero, gdy się zgodzisz.

Aktualizacja ikony

> Update the app icon

• Znajduje ikonę launchera: ikonę Play 512, największy obraz mipmap lub obraz marketingowy AppIcon z iOS — najpierw własną ikonę flavora.
• Jeśli ma ponad 512 KB, zmniejsza kopię w folderze tymczasowym. Twoje repozytorium pozostaje nietknięte.
• Informuje, który plik przesłał. W opublikowanej aplikacji nowa ikona jest widoczna od razu.

Aplikacja z reklamami

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

• Zapisuje app-ads.txt z podanych przez Ciebie wierszy. Identyfikatora wydawcy nie ma w Twoim kodzie, więc nigdy go nie zgaduje.
• Przypomina, żeby ustawić stronę jako witrynę dewelopera na stronie aplikacji w sklepie.
• AdMob zweryfikował pliki app-ads.txt pod naszymi adresami; daj mu do 24 godzin na ich pobranie.

Utrzymuj strony w zgodzie z buildem

> Add the AppFoyer drift check

• Każde uruchomienie „make this app store-ready” zapisuje appfoyer.json w katalogu głównym repozytorium: SDK, typy danych i uprawnienia, na podstawie których powstały strony. Zapisuje go ten sam skaner, którego używa kontrola, nigdy ręcznie.
• Ten prompt pokazuje workflow GitHub dla darmowego appfoyer/check-action i zapisuje .github/workflows/appfoyer.yml, gdy się zgodzisz. Nigdy nie nadpisuje istniejącego.
• Od tej chwili każdy pull request wymienia, co dodał lub usunął od napisania stron, z plikiem i wierszem. Ponowne uruchomienie wtyczki aktualizuje wersje robocze i appfoyer.json.
• Nic nie jest commitowane za Ciebie. Szczegóły i konfigurację dla innych systemów CI znajdziesz w poradniku o utrzymywaniu polityki prywatności w zgodzie z buildem.

Sprawdzenie bez zmieniania czegokolwiek

> Is this app store-ready?

• Uruchamia listę kontrolną dla każdej pasującej aplikacji i zgłasza, czego brakuje. Niczego nie zapisuje.
• Flavor, który nie ma jeszcze aplikacji, jest zgłaszany jako brakujący.

Dodanie linków do aplikacji

> Wire the store-ready links into the app

• Wymaga opublikowanych stron.
• Proponuje diff z linkami do polityki prywatności i wsparcia na ekranie ustawień lub w zasobach tekstowych. Stosuje go tylko po Twojej zgodzie i nigdy nie commituje.

Co opuszcza Twój komputer

Tylko wywnioskowane fakty:

• nazwa aplikacji, platforma oraz bundle id lub application id;
• nazwy SDK i uprawnień znalezionych w Twoich plikach builda;
• potwierdzone przez Ciebie odpowiedzi — nazwa firmy, e-mail wsparcia, jurysdykcja, adresy URL sklepów;
• tekst stron przygotowany przez agenta, zapisany na Twoim koncie jako wersja robocza;
• własna ikona aplikacji, wysłana raz przez jednorazowy link do przesyłania.

Żaden inny plik, nigdy kod źródłowy, nigdy sekrety ani klucze znalezione w repozytorium. To, co wysyła agent, i tak musi znaleźć się w polityce prywatności.

Jeden plik jest zapisywany w Twoim repozytorium i tam pozostaje: appfoyer.json, zapis tego, na podstawie czego powstały strony, tworzony przez skaner dołączony do wtyczki. Nie jest nigdzie wysyłany. Agent nigdy go nie commituje, ani niczego innego — robisz to Ty.

Czego agent nie może zrobić

Niezależnie od tego, czy łączy się przez przeglądarkę, czy kluczem API, wtyczka ma poświadczenie agenta — więc publikowanie jest dla niej w ogóle niedostępne. Wymusza to serwer, a nie uprzejma prośba skierowana do agenta:

• Nie ma narzędzia do publikowania. Agent zapisuje wersje robocze; Twoje opublikowane strony się nie zmieniają.
• Dwie rzeczy nie mają wersji roboczej: ikona i własny adres. W opublikowanej aplikacji zmieniają opublikowaną stronę od razu, a agent informuje, kiedy je ustawił. Nie może zastąpić własnego adresu, którego już używasz, bez Twojej zgody.
• Ścieżka REST, która publikuje stronę, odrzuca poświadczenia agenta bez wyjątku — tylko sesja.
• Każda strona nadal przechodzi przy publikacji tę samą kontrolę treści co edycja wpisana ręcznie.
• Każde wywołanie agenta jest zapisywane w dzienniku audytu konta wraz z połączeniem lub kluczem, który je wykonał.

W najgorszym razie przejęte połączenie lub klucz oznacza więc wersje robocze do odrzucenia, złą ikonę lub nowy adres — a nie stronę opublikowaną w Twoim imieniu.

Narzędzia, które dostaje

Wtyczka łączy się z punktem końcowym MCP, który udostępnia dokładnie te narzędzia:

Gdy coś pójdzie nie tak

Jedna rzecz, której to nie zmienia

Wersje robocze to szablony uzupełnione na podstawie Twojego kodu, a nie porada prawna. To, że agent pisze je szybko, nie czyni ich prawdziwymi — przeczytaj, co napisał, zanim opublikujesz, zwłaszcza listę tego, co zbiera Twoja aplikacja. To Ciebie sklep uznaje za odpowiedzialnego.

Pytania: support@appfoyer.com.