Listing i promocja: treści, lokalizacja, release notes

1. Listing jako część produktu, a nie „formularz do odhaczenia”

Programista, który po raz pierwszy trafia do Store, często postrzega listing jako „kolejny długi formularz, który trzeba czymś wypełnić”. To trochę jak pisanie README w repozytorium o trzeciej w nocy: „później przepiszę porządnie”. Spoiler: zazwyczaj nikt już tego nie przepisuje.

Dla ChatGPT App listing — to pierwsze, a czasem i jedyne, co zobaczy użytkownik, zanim kliknie „Try” albo przewinie dalej. Nazwa, podtytuł, krótki opis, lista scenariuszy, ikona — wszystko to działa jak mini‑landing.

Poza tym listing wpływa nie tylko na ludzi, ale i na sam ChatGPT. Metadane (nazwa, kategorie, opis) uczestniczą w mechanizmach odkrywania. Gdy model wybiera, którą App zaproponować użytkownikowi dla konkretnego zapytania, opiera się m.in. na tekstach, które tutaj wpiszesz.

Oficjalne wytyczne wymagają, by nazwa i opis App były jasne, precyzyjne i nie wprowadzały w błąd co do funkcjonalności. Żadnego „jesteśmy magiczną SI, która robi wszystko” ani „oficjalny klient X”, jeśli to nie odpowiada rzeczywistości.

Na tym etapie robisz trzy rzeczy jednocześnie:

1. Wyjaśniasz człowiekowi, po co w ogóle istnieje twoja App.
2. Dajesz wskazówki algorytmom Store i ChatGPT, w jakich sytuacjach App warto proponować.
3. Budujesz podstawę zaufania: obiecujesz dokładnie to, co realnie robisz — bez magii i dark patterns.

2. Szkielet listingu ChatGPT App

Konkretne UI Store mogą zmieniać pola i wygląd, ale logiczny szkielet prawie zawsze jest ten sam. Z tego, co dziś typowo potrzebne dla ChatGPT App z widżetem UI:

Przypomnę z początku wykładu: wytyczne wymagają, by nazwy i opisy były jasne i uczciwe, bez udawania „oficjalnego klienta czegokolwiek”. W powyższej tabeli jest to rozłożone na konkretne pola listingu.

To wszystko wygląda trochę biurokratycznie, dopóki nie wyobrazisz sobie siebie na miejscu użytkownika. Otwierasz Store, widzisz mnóstwo kart, masz pięć sekund uwagi. Patrząc na GiftGenius, chcesz od razu zrozumieć:

• czy ta App w ogóle dotyczy moich zadań?
• czy jest bezpieczna i nie zrobi nic dziwnego z moimi danymi?
• czy różni się od zwykłej rozmowy z ChatGPT?

Odpowiedzi na te pytania powinien dawać twój listing.

3. Nazwa i podtytuł: jak nie strzelić sobie w stopę

Kryteria dobrej nazwy

Nazwa App pełni kilka ról jednocześnie: wypowiada się ją w rozmowie („włącz GiftGenius”), wpisuje w wyszukiwarkę, widzi na liście. Idealna nazwa:

• jest krótka i zapadająca w pamięć;
• oddaje główny pomysł (GiftGenius → „coś o prezentach i ‘inteligencji’”);
• nie narusza cudzych znaków towarowych;
• nie obiecuje niemożliwego i nie udaje oficjalnego klienta czyjejś platformy.

Te same wytyczne OpenAI, o których mówiliśmy na początku, wprost zakazują mylących nazw, w tym aluzji do oficjalności, której nie posiadasz.

Zobaczmy przykłady dla naszego GiftGenius.

W ramach kursu nadal używamy GiftGenius jako głównej nazwy. Jeśli tworzysz własną App, nie bój się lekkiego brandingu: „TripTailor”, „StockScout”, „LegalChecklist” itp.

Podtytuł: jedno zdanie, które decyduje o wszystkim

Podtytuł to twój „one‑liner”. Widać go w wynikach Store i na stronie App. Oficjalne wytyczne radzą, aby takie teksty jasno i uczciwie wyjaśniały przeznaczenie App.

Słaby wariant:

"Idealny asystent SI do dowolnych zadań!"

Dobry wariant:

"Pomaga w 30 sekund dobrać prezent do zainteresowań osoby — bezpośrednio na czacie."

Dobry podtytuł:

• mówi, jaki rezultat otrzyma użytkownik;
• sugeruje kontekst (u nas — „bezpośrednio na czacie”);
• nie schodzi w szczegóły techniczne („analizuje wektory embedding” nikogo nie interesuje).

Dla praktyki warto napisać 5–7 wariantów i przeczytać je oczami osoby nietechnicznej. Jeśli sam się zacinasz, czytając tekst na głos — przepisz go.

4. Opis: krótki i długi, przed/po

Krótki opis

Krótki opis zwykle składa się z paru zdań i jest pokazywany obok podtytułu. Często to twoja ostatnia szansa, by przyciągnąć użytkownika, któremu nie chce się otwierać szczegółów.

Struktura:

1. Pierwsze zdanie — co robi App.
2. Drugie — czym różni się od zwykłego ChatGPT lub innych App.

Przykład „przed” dla GiftGenius:

"App do doboru prezentów. Używa MCP i złożonego backendu, aby zapewniać najlepsze wyniki."

Problemy:

• zbędne szczegóły techniczne;
• nie wiadomo, dlaczego jesteś lepszy niż sam ChatGPT;
• nie opisano scenariusza użytkownika.

Przepiszmy:

"GiftGenius pomaga dobrać prezent do zainteresowań osoby, budżetu i okazji. Odpowiadasz na kilka pytań na czacie, a App pokazuje konkretne pomysły z linkami."

Tutaj odnosimy się do realnego doświadczenia użytkownika: „odpowiadam na pytania → widzę pomysły”. Taki tekst jednocześnie pomaga ChatGPT lepiej zrozumieć twoje typowe scenariusze.

Długi opis

Długi opis czytają już zmotywowani ludzie, ale nawet oni nie chcą zanurzać się w traktat techniczny. Dobry szablon:

1. Kto jest grupą docelową (np. „ludzie, którzy nienawidzą wybierać prezentów na ostatnią chwilę”).
2. Jakie zadania rozwiązuje App (2–3 główne scenariusze).
3. Czym App jest wygodniejsza niż po prostu zapytać ChatGPT bez App.
4. Co z danymi i bezpieczeństwem — bardzo krótko, z odesłaniem do Polityki.
5. Języki/regiony, jeśli są ograniczenia.

Przykładowy szablon dla GiftGenius:

GiftGenius — dla tych, którzy za każdym razem przypominają sobie o prezencie w ostatniej chwili. 
App pyta, dla kogo wybierasz prezent, jaki masz budżet i z jakiej okazji, a następnie pokazuje gotową listę pomysłów z opisami i linkami.

W przeciwieństwie do zwykłej rozmowy z ChatGPT, GiftGenius korzysta z twojego katalogu towarów i aktualnych cen, a także pamięta historię doborów w ramach rozmowy.

App nie przechowuje twojej korespondencji dłużej niż to potrzebne do doboru rekomendacji. Więcej — w naszej Polityce prywatności.

Najważniejsze — nie zamieniaj opisu w śmietnik terminów architektonicznych. Pod maską są MCP, Agents, cache, feature flagi, ale użytkownika interesuje scenariusz: szybciej, prościej, pewniej.

5. Zrzuty ekranu, wideo, ikona i warstwa wizualna

Z tekstami listingu już po sprawie. Dalej — to, co użytkownik widzi, a nie czyta: ikona, ewentualne zrzuty ekranu i krótkie wideo.

Gdzie widać wizual dla ChatGPT App

Na moment lat 2025–2026 interfejsy ChatGPT Store dla zwykłych GPTs nie pokazują typowej „karuzeli zrzutów ekranu” jak w mobilnych sklepach: widać głównie ikonę, nazwę, autora i prompty startowe.

Dla ChatGPT Apps z widżetami UI sytuacja jest podobna: główna „witryna” znajduje się wewnątrz samego ChatGPT (pierwsze uruchomienie App, widżet inline itp.). Zewnętrzne zrzuty ekranu, wideo i szerokie opracowanie wizualne najczęściej żyją:

• na osobnym landing page App;
• w postach i zapowiedziach („jak zrobiliśmy GiftGenius”);
• na platformach typu Product Hunt, GitHub README itp.

Dlatego gdy mówimy o „zrzutach i wideo do listingu”, w praktyce chodzi o zewnętrzne zasoby, dokąd będziesz kierować ludzi ze Store, dokumentacji lub social mediów.

Ikona App

Ikona to drobiazg — dopóki nie zobaczysz jej na liście dziesiątek aplikacji. Podstawowe zasady:

• prosta forma, czytelna w małym okręgu (128×128);
• minimum tekstu, najlepiej bez tekstu;
• dobry kontrast z tłem;
• wizualny związek z tematem App (prezent, koszyk, analiza wykresów itp.).

Dla GiftGenius logiczny wariant — oszczędne pudełko‑prezent na kontrastowym tle, bez napisu „GG” drobną czcionką.

Zrzuty ekranu: co dokładnie pokazać

Gdy robisz landing albo artykuł o App, potrzebujesz zrzutów pokazujących:

• główny scenariusz: użytkownik zadał pytanie → pojawił się widżet z rekomendacjami;
• „efektowny moment”: filtrowanie, wybór wariantu, ewentualnie — integracja Instant Checkout (jeśli jest);
• minimum zbędnych szczegółów: usuwamy PII, konta testowe zamiast prawdziwych klientów, czysty interfejs.

Dobry praktyczny zabieg — złożyć osobny „katalog demo” z fikcyjnymi produktami i schludnymi nazwami, aby nie ujawniać wewnętrznych identyfikatorów i cudzych marek.

Krótkie wideo

Krótki pokaz trwający 30–60 sekund można nagrać zwykłym narzędziem do nagrywania ekranu: otworzyć ChatGPT, wpisać typowe zapytanie, pokazać, jak App się pojawia i jak z nią wchodzi się w interakcję. W istocie odtwarzasz jeden ze swoich golden prompts z modułu o UX.

Scenariusz dla GiftGenius:

1. Użytkownik pisze: „Potrzebny prezent dla kolegi‑programisty, budżet $50”.
2. ChatGPT proponuje GiftGenius.
3. Pojawia się widżet z pytaniami doprecyzowującymi, a następnie — lista wariantów.

Takie wideo to świetny materiał zarówno na landing, jak i na post w social mediach.

6. Lokalizacja listingu: strategie i pułapki

Od wizualu — do języków. Nawet jeśli UI i dane są już świetnie zlokalizowane (czym zajmowaliśmy się w module 9), listing żyje własnym życiem i tu są pułapki.

Dlaczego to nie jest takie proste

Twoja App może doskonale lokalizować UI i dane, używać openai/locale, _meta["openai/userLocation"] i innych trików z modułu 9. Ale listing żyje swoim życiem.

Na lata 2025–2026 ChatGPT Store nie przełącza automatycznie nazwy i opisu App w zależności od języka interfejsu użytkownika. Nie masz więc „wbudowanego” mechanizmu wielojęzycznych metadanych: Store pokazuje jeden zestaw tekstów.

Wynikają z tego trzy popularne strategie.

Strategia 1: Universal English

Najprostszy i najpowszechniejszy wariant — cały opis i nazwa po angielsku. W tekście można wprost wskazać, jakie języki wspiera App:

"Supports English, Spanish, Russian."

Plusy: jeden listing, prostota utrzymania, zrozumiały dla większości audytorium technicznego. Minus oczywisty: gorsza konwersja wśród użytkowników, którzy niekomfortowo czytają po angielsku.

Strategia 2: Nazwa hybrydowa

To próba siedzenia na dwóch stołkach: „GiftGenius | Prezenty”. Taka nazwa jest czytelna i dla anglo‑, i dla rosyjskojęzycznych użytkowników.

Plus: więcej osób intuicyjnie rozumie, o czym jest App. Minus: wygląda „hałaśliwie”, może psuć ogólny styl Store i nie rozwiązuje problemu długiego opisu — i tak trzeba wybrać jeden język.

Strategia 3: Oddzielne App na języki

Wariant dla większych projektów: stworzyć, powiedzmy, „GiftGenius (RU)” i „GiftGenius (Global)” jako różne App ze wspólnym backendem MCP.

Plusy:

• można kompletnie dostosować opis, prompty startowe, a nawet flow do lokalnego rynku;
• lepsze „SEO” w Store: użytkownik piszący po rosyjsku zobaczy zrozumiałą nazwę i opis.

Minusy:

• statystyki użycia i opinie rozpraszają się po kilku App;
• więcej pracy z utrzymaniem: wydania, listingi, przeglądy dla każdej wersji.

Praktyczna rada

Dla aplikacji edukacyjnych/proof‑of‑concept zwykle wystarczy Universal English, zwłaszcza jeśli główna publiczność to deweloperzy. W prawdziwym produkcie rozsądny kompromis — zacząć od jednego–dwóch języków i zrobić dobre tłumaczenia, zamiast startować od razu w dziesięciu z maszynową „sałatką słowną”.

Powiązanie z modułem o lokalizacji jest takie: UI i dane już umiesz lokalizować elastycznie. Teraz trzeba, by teksty listingu nie przeczyły temu, co realnie zobaczy użytkownik. Nie pisz „obsługuje tylko angielski”, jeśli App bez problemu działa po hiszpańsku.

7. Release notes: po co są i jak pisać bez „wszystko poprawiliśmy”

Listing to moment pierwszego spotkania. Dalej App będzie się rozwijać i trzeba o tym jakoś opowiadać użytkownikom — tu wchodzą release notes.

Czym są release notes w kontekście ChatGPT App

Release notes to krótkie opisy zmian w nowej wersji App: co dodano, co poprawiono, co przyspieszono. W klasycznych sklepach jest do tego oddzielna zakładka „Version history”. W obecnym ChatGPT Store takiej zakładki może nie być, więc release notes żyją:

• w opisie nowej wersji w konsoli Store;
• na twojej stronie/blogu/repozytorium;
• wewnątrz samej App, jeśli pozwalasz użytkownikowi zapytać „co nowego”.

Format jest zwykle prosty: nazwa wersji, data i lista kluczowych zmian.

Po co w ogóle na to tracić czas

Po pierwsze, użytkownik widzi, że App żyje: ktoś do niej wraca, ulepsza ją, naprawia błędy. To zwiększa zaufanie do twojego kodu i biznesu.

Po drugie, masz własną chronologię: wygodnie sprawdzić, kiedy dodano konkretną funkcję, odwołać się do tego w supporcie albo sprzedawać „aktualizacje” wewnątrz firmy.

Po trzecie, release notes to gotowy materiał do mini‑promocji: wiadomość w newsletterze, post w social mediach, krótkie wideo.

Jak pisać: sprzedajemy korzyść, a nie wewnętrzne terminy

Doświadczenia z mobilnych sklepów i rekomendacje autorów produktowych sprowadzają się do prostej myśli: opisuj zmiany z perspektywy korzyści dla użytkownika, a nie wewnętrznych bytów, które zmieniłeś.

Słabo:

"v1.1 — refaktoryzacja algorytmu doboru, ulepszony scoring, naprawione bugi."

Lepiej:

"v1.1 — prezenty dobierają się trafniej dla osób z rzadkimi hobby. 
GiftGenius lepiej rozumie teraz zainteresowania, jeśli wspominasz o grach planszowych, craftcie lub muzyce. 
Naprawiliśmy też rzadki błąd, przez który lista rekomendacji czasem się czyściła."

Nawet poprawka błędu jest tu sformułowana jako poprawa niezawodności dla użytkownika.

Przykłady dla GiftGenius

Pierwsze wydanie:

v1.0 — start GiftGenius
- Pierwsze dobory prezentów po imieniu, zainteresowaniach i budżecie.
- Wsparcie USD/EUR.
- Lokalizacja interfejsu: EN, RU.

Drugie wydanie:

v1.1 — prezenty po zdjęciu i filtry po typie
- Dodaliśmy eksperymentalne narzędzie: możesz wgrać zdjęcie biurka danej osoby, a GiftGenius zaproponuje pomysły w temacie.
- Nowy filtr "tylko cyfrowe prezenty" — wygodne, jeśli osoba mieszka w innym mieście.
- Przyspieszyliśmy wyszukiwanie w katalogu, lista rekomendacji otwiera się szybciej.

Taki format łatwo zamienić i w tekst w Store, i w krótki post „co nowego w GiftGenius”.

8. Mini plan promocji: jak sprawić wrażenie, że trochę jesteś marketingowcem

Nawet idealny listing i schludne release notes nie przyprowadzą użytkowników same z siebie. Potrzebny jest choćby minimalny plan promocji, który da się zrealizować siłami dewelopera.

Pełnoprawny marketing to osobny kurs, ale bez choćby minimalnej promocji nawet najlepsza App w Store będzie się kurzyć. Potrzebujemy minimalnego zestawu działań, które realnie zrobisz jako deweloper.

Wewnętrzna „promocja” w ekosystemie ChatGPT

Po pierwsze i najważniejsze: dobrze napisany listing już sam w sobie jest częścią promocji. Metadane i opisy pomagają ChatGPT proponować twoją App w relewantnych dialogach, a wyszukiwanie w Store — znajdować ją po słowach kluczowych.

Stąd wynikają praktyczne kroki:

• wspominać typowe scenariusze w opisie (zakup prezentów, przygotowanie raportów itp.);
• nie zasypywać listingu żargonem technicznym — użytkownika to tylko odstrasza;
• unikać zbyt szerokich deklaracji „dla wszystkiego i wszystkich”, by nie rozmywać „SEO”.

Zewnętrzna promocja: landing, social media, społeczność

Badania i praktyka sugerują prosty minimalny plan promocji dla ChatGPT Apps:

1. Stworzyć krótkie wideo‑preview (30–60 sekund) pokazujące kluczowy scenariusz.
2. Napisać notkę/artykuł na blogu: „Jak zrobiliśmy GiftGenius” — z kilkoma zrzutami i opisem architektury na wysokim poziomie.
3. Zrobić 1–2 posty w social mediach (Twitter/X, LinkedIn, Telegram) z linkiem do App lub landingu.
4. Poprosić 5–10 znajomych kolegów/przyjaciół o wypróbowanie App i szczery feedback.

Ważne, by nie stać się spamerem: żadnego masowego „oznaczę wszystkich w tweecie” i „napiszę na wszystkie czaty”. Dobra zasada — każdy post wnosi realną wartość (demo, wyjaśnienie architektury, analiza ciekawego przypadku).

Gdzie publikować release notes

Jak już omawialiśmy, w Store może nie być osobnej historii wersji. Zatem release notes rozsądnie dublować:

• na stronie App w Store (jeśli da się tam dodać tekst o nowej wersji);
• na własnej stronie (sekcja Changelog);
• w README repozytorium (jeśli App jest open‑source lub częściowo otwarta);
• w newsletterze lub kanale dla zainteresowanych użytkowników.

Wygodnie używać tej samej „surowej” struktury, zadanej w kodzie lub konfigu, a potem po prostu renderować ją w różnych kanałach.

Najprostszy przykład w TypeScript:

// shared/releaseNotes.ts
export const releaseNotes = [
  {
    version: "1.0.0",
    date: "2025-02-01",
    changes: [
      "Pierwsze publiczne wydanie GiftGenius",
      "Dobór prezentów po zainteresowaniach i budżecie",
    ],
  },
  {
    version: "1.1.0",
    date: "2025-03-10",
    changes: [
      "Nowy filtr «tylko cyfrowe prezenty»",
      "Przyspieszone wyszukiwanie w katalogu",
    ],
  },
];

Tę tablicę można wykorzystać i w widżecie (odpowiedź na „co nowego?”), i do generacji strony Changelog na twojej stronie.

9. Spójny obraz: listing GiftGenius jako przykład

Aby połączyć wszystko w całość, naszkicujmy „roboczy” listing dla naszej edukacyjnej App.

Wersja tekstowa

Nazwa:
GiftGenius

Podtytuł:
Dobiera prezenty w 30 sekund według zainteresowań i budżetu — bezpośrednio na czacie.

Krótki opis:
GiftGenius zadaje kilka pytań o osobę, budżet i okazję, a następnie pokazuje gotową listę pomysłów z opisami i linkami. Idealne, gdy do święta został już tylko jeden wieczór.

Długi opis (wersja skrócona):

GiftGenius pomaga tym, którzy mają dość łamania sobie głowy nad prezentami na ostatnią chwilę. 
App pyta, dla kogo wybierasz prezent, czym ta osoba się interesuje i jaki masz budżet, 
a następnie pokazuje konkretne pomysły z krótkim opisem i linkiem, gdzie je kupić.

GiftGenius uwzględnia twój katalog produktów i aktualne ceny, dlatego rekomendacje są bliższe realnemu światu 
niż ogólna rada na czacie.

App obsługuje interfejs po angielsku i rosyjsku. 
Nie używamy twoich danych do trenowania zewnętrznych modeli i przechowujemy historię doborów tylko w granicach jednej sesji. 
Więcej — w naszej Polityce prywatności.

Prompty startowe:

• „Help me find a birthday gift for a colleague who loves board games, budget $40.”
• „Dobierz prezent dla mamy, która interesuje się ogrodnictwem, do 3000 ₽.”
• „Suggest digital-only gifts for a friend who lives abroad, budget €50.”

Ikona: minimalistyczne pudełko‑prezent w firmowych kolorach.

Języki: EN, RU (w opisie jest to wyraźnie wskazane, a UI już potrafi przełączać się na podstawie openai/locale).

Linki:
Privacy Policy, Terms of Use, Support page — wszystko to zrobiliśmy na poprzednim wykładzie.

Schemat: ścieżka użytkownika od listingu do użycia

Dla jasności — mały diagram:

flowchart TD
    A[Listing GiftGenius w Store] --> B[Użytkownik czyta
nazwę i opis]
    B --> C{Czy rozumie
wartość aplikacji?}
    C -- Tak --> D[Klika Try / podłącza App]
    C -- Nie --> E[Przewija dalej]
    D --> F[Pierwsza rozmowa z ChatGPT]
    F --> G[Model proponuje GiftGenius
na podstawie kontekstu zapytania]
    G --> H[Pojawia się widżet
i scenariusz doboru prezentów]

Dobry listing zwiększa prawdopodobieństwo, że użytkownik pójdzie gałęzią „Tak” i na kroku G będzie już mniej więcej wiedział, czego oczekiwać od App.

10. Typowe błędy przy listingu i promocji

Błąd nr 1: nazwa i podtytuł obiecują magię, której nie ma.
Napisać „Ultimate AI that does everything” jest kusząco, ale uderza na dwa fronty. Użytkownik oczekuje uniwersalnego super‑asystenta, a dostaje wyspecjalizowane narzędzie. Moderacja Store może zapytać: czy takie deklaracje odpowiadają realnemu zachowaniu i polityce. Wytyczne wprost wymagają jasnych i precyzyjnych sformułowań bez przesady.

Błąd nr 2: opis zawalony detalami technicznymi.
„Używa MCP, Agents SDK, cache na warstwie edge” — świetne na prelekcję na meetupie, ale kompletnie bezużyteczne w listingu. Użytkownika interesują scenariusze i wynik: szybciej, prościej, pewniej. Szczegóły techniczne zostaw na wpis na blogu „jak to zrobiliśmy”.

Błąd nr 3: ignorowanie lokalizacji listingu.
App świetnie lokalizuje UI i dane, ale listing został na kiepskim tłumaczeniu maszynowym albo wyłącznie po angielsku dla rynku, gdzie większość użytkowników nie czyta po angielsku. W efekcie tracisz konwersję jeszcze przed pierwszym uruchomieniem App. Lepiej jeden–dwa języki z jakościowym tekstem niż dziesięć z bełkotem.

Błąd nr 4: ikona i wizual zrobione na ostatnią chwilę „na kolanie”.
Zbyt drobne detale, tekstu nie da się przeczytać w małym kółku, albo szara ikona ginąca wśród innych. Użytkownik zwyczajnie nie zapamiętuje, że to była twoja App. Poświęć parę godzin na porządną ikonę i czytelne zrzuty: będziesz ich używać jeszcze długo w artykułach, slajdach i social mediach.

Błąd nr 5: release notes w stylu „bug fixes and improvements”.
Tak, wszyscy tak piszą, ale ty możesz lepiej. Jeśli ty sam za miesiąc nie zrozumiesz, co zmieniło się w wersji 1.3, użytkownik tym bardziej nie zrozumie. Opisuj zmiany z perspektywy korzyści: co przyspieszyło, co stało się bardziej niezawodne, jakie nowe scenariusze się pojawiły. Krótko, ale konkretnie.

Błąd nr 6: brak zewnętrznej zapowiedzi.
App już jest w Store, ale nikomu o tym nie powiedziałeś. Ani postu, ani krótkiego wideo, ani wpisu na blogu. W efekcie twoją App widzą tylko przypadkowi użytkownicy w wynikach Store. Nawet minimalna zapowiedź dla kolegów, obserwujących czy społeczności daje pierwsze instalacje i feedback, na którym możesz się poprawiać.

Błąd nr 7: niespójność listingu i realnego zachowania App.
W listingu napisano, że App nie przechowuje danych, ale logika retencji jest ustawiona inaczej. Albo obiecano język rosyjski, a w praktyce jest dopiero w becie i się psuje. To nie tylko psuje opinie, ale może też stać się podstawą roszczeń ze strony Store. Teksty listingu powinny podążać za architekturą i ustawieniami bezpieczeństwa, o których mówiliśmy w poprzednich modułach, a nie żyć własnym życiem.