Przykłady informacji o wydaniu w App Store: tekst „Co nowego”, który mówi, co się zmieniło (2026)

Dobre informacje o wydaniu w App Store odpowiadają na jedno pytanie: co zmienia się dla mnie po aktualizacji? Wszystkie poniższe przykłady informacji o wydaniu w App Store działają według jednego wzorca. Zacznij od zmiany, którą użytkownik zauważy, nazwij konkretnie każdą poprawkę i pomiń wszystko, czego nie widać. Własne wskazówki Apple dla pola What's New in This Version mówią to samo. Apple prosi o opis nowych funkcji, ulepszeń interfejsu lub poprawek błędów i zaleca przekazanie użytkownikom „szczegółów zmian, ulepszeń lub poprawek w tej wersji”.

Jakie zasady dotyczą informacji o wydaniu w App Store Connect i Google Play?

Pole „What's New” u Apple mieści 4000 znaków i jest wymagane w każdej wersji po pierwszej. Google Play pozwala na 500 znaków Unicode na język i zakazuje treści promocyjnych.

Według stanu na październik 2026 Pomoc Play Console mówi: „Nie używaj informacji o wersji do celów promocyjnych ani do zachęcania użytkowników do działań”. U Apple treści marketingowe umieszczaj zamiast tego w polu Promotional Text. To pole mieści 170 znaków, wyświetla się nad opisem, a Apple pozwala je aktualizować bez przesyłania nowej wersji.

Jak wyglądają dobre informacje o wydaniu w App Store?

Dobre informacje o wydaniu nazywają sytuację, w której był użytkownik, i efekt, jaki teraz uzyskuje. Poniższe przykłady pochodzą z fikcyjnej aplikacji do śledzenia nawyków. Wersje ogólnikowe to typ informacji pisanych w ostatniej chwili.

Jeśli poprawka jest zbyt techniczna, by wyjaśnić ją jednym zdaniem, użytkownicy prawdopodobnie jej nie zauważą, więc może trafić do jednej linijki o „poprawie stabilności” na końcu. Wytyczna 2.3.12 pozwala na to przy drobnych poprawkach, ale nie przy prawdziwych zmianach funkcji.

Czy jest szablon informacji o wydaniu, którego mogę używać wielokrotnie?

Tak. Szablon wielokrotnego użytku ma nagłówek oraz sekcje Nowe, Ulepszone i Naprawione. Trzymaj go w repozytorium obok changeloga i wypełniaj w momencie tworzenia gałęzi wydania, a nie po przesłaniu buildu.

[One-line headline: the change most users will notice]

New
- [Feature]: [what you can now do], [where to find it]

Improved
- [Screen or flow]: [what feels different]

Fixed
- [Symptom the user saw] when [situation]

Thanks for the reports. Reply via Settings > Help if anything looks off.

Dla Google Play skróć te same informacje do nagłówka i dwóch–trzech najważniejszych punktów, aby zmieściły się w 500 znakach. Tagi każdego języka umieść w osobnych wierszach, np. <en-US> i </en-US>. W Play usuń zdanie zamykające, bo prosi ono użytkownika o wykonanie działania.

Jak zamienić scalone pull requesty w informacje o wydaniu?

Aby zamienić scalone pull requesty w informacje o wydaniu, odfiltruj zmiany niewidoczne dla użytkowników, a każdą pozostałą przepisz jako objaw lub efekt. Wykonuj te kroki przy każdym wydaniu.

1. Wyeksportuj tytuły scalonych pull requestów od ostatniego tagu, a następnie usuń wszystko, czego użytkownicy nie widzą, np. refaktoryzacje, podbicia zależności i zmiany w CI.
2. Przepisz każdy pozostały punkt jako objaw lub efekt. „Fix nil coordinator” zmienia się w „Naprawiono pusty ekran po zalogowaniu przez Apple”.
3. Uporządkuj punkty według liczby użytkowników, których dotyczą, a nie według nakładu pracy inżynierskiej.
4. W App Store Connect utwórz nową wersję, a potem wyczyść skopiowany tekst „What's New”, zanim wkleisz nowe informacje, ponieważ metadane poprzedniej wersji są przenoszone.
5. Wklej informacje do każdej obsługiwanej lokalizacji – przetłumaczone lub przynajmniej sprawdzone w każdym języku – aby użytkownicy w innych lokalizacjach nie widzieli informacji z ostatniej wersji.
6. W Play wklej skróconą wersję między tagi języka i upewnij się, że każdy język mieści się w 500 znakach.
7. Przeczytaj informacje raz na głos. Jeśli jakieś zdanie wymaga wyjaśnienia przez programistę, przepisz je.

Co powinny zawierać informacje o wydaniu przy hotfiksie?

Informacje o wydaniu hotfiksa powinny wskazać wadliwą wersję, opisać objaw, który został naprawiony, i powiedzieć dotkniętym użytkownikom, co stanie się po aktualizacji. Apple nie pozwala cofnąć się do poprzedniej wersji w App Store, więc poprawka zawsze trafia do użytkowników jako nowa wersja.

Przykład: „Naprawiono problem w wersji 3.4.0, przez który u części użytkowników przestały działać przypomnienia. Przypomnienia ustawione przed aktualizacją wznowią się automatycznie”. Użytkownicy, których to dotyczyło, wiedzą, że warto zaktualizować, a pozostali widzą, że poprawka ich nie dotyczy. Nie zrzucaj winy na system operacyjny i nie obiecuj terminów przyszłych poprawek. Jeśli wydajesz aktualizacje z wdrażaniem etapowym, wstrzymanie wdrożenia ogranicza liczbę użytkowników, którzy dostaną wadliwy build, dopóki poprawka jest w weryfikacji. Jeśli hotfiks zmienia działanie funkcji, przejdź ponownie przez listę kontrolną przesyłania do App Store, aby informacje, zrzuty ekranu i notatki dla recenzenta były spójne.

Czy App Review może odrzucić aktualizację z powodu informacji o wydaniu?

Tak. Informacje o wydaniu to metadane, a Wytyczne App Review odnoszą się do nich bezpośrednio. Wytyczna 2.3.12 mówi: „Aplikacje muszą jasno opisywać nowe funkcje i zmiany w produkcie w tekście »What's New«”.

Ogólne sformułowania są dozwolone przy „prostych poprawkach błędów, aktualizacjach bezpieczeństwa i ulepszeniach wydajności”, ale „bardziej istotne zmiany muszą być wymienione w informacjach”. Wytyczna 2.3.10 zakazuje nazw i grafik innych platform mobilnych w metadanych, w tym w „What's New”. Nie opisuj funkcji ukrytych za flagami ani niczego, czego nie ma w przesłanym buildzie. Wytyczna 2.3.1(a) osobno wymaga, aby nowe funkcje były „konkretnie opisane w sekcji Notes for Review”, więc kroki dla recenzenta i konto demo umieszczaj tam, a nie w publicznych informacjach. Jeśli dostaniesz pytanie dotyczące metadanych, nasz poradnik o naprawianiu odrzuceń w App Store wyjaśnia, jak odpowiedzieć.

Na jakie problemy z informacjami o wydaniu natrafili inni deweloperzy?

Publicznie zgłoszone przypadki pokazują dwa typy błędów: przesyłki odrzucone za przekroczenie limitu długości w sklepie oraz odrzucenia w weryfikacji, w których instrukcje porządkowe obejmują tekst „What's New”.

• Limit długości Play w CI. Zgłoszenie na GitHubie w szablonie wdrożeniowym Fluttera opisuje changelog wygenerowany przez AI, który zepsuł przesyłanie wersji do testów wewnętrznych w Google Play przez fastlane z komunikatem: "The release created has notes in language ko-KR with length 612, which is too long (max: 500)." Opiekunowie dodali skrypt przycinający informacje przed przesłaniem: do 480 znaków dla Play i 3800 bajtów dla TestFlight, który mierzy swój limit w bajtach.
• Porządki w ramach 2.3.10 obejmujące „What's New”. Deweloper na Apple Developer Forums opublikował odrzucenie na podstawie wytycznej 2.3.10, wywołane paskami stanu innymi niż iOS na zrzutach ekranu. Kolejne kroki od Apple nakazywały „usunąć wszystkie wystąpienia tych informacji z aplikacji i jej metadanych, w tym z opisu aplikacji, tekstu promocyjnego, informacji »What's New«, podglądów i zrzutów ekranu”. W odpowiedziach doradzano ponowne wykonanie zrzutów ekranu i sprawdzenie każdego pola metadanych, łącznie z informacjami o wydaniu.

Wniosek: limit długości jest mechaniczny i głośno zawodzi przy przesyłaniu, a zasady weryfikacji dotyczą treści i obejmują każde pole metadanych. Zautomatyzuj sprawdzanie liczby znaków i czytaj „What's New” z taką samą uwagą jak zrzuty ekranu.

Co sprawdzić przed przesłaniem informacji o wydaniu?

Przed przesłaniem sprawdź, czy informacje opisują tylko to, co jest w buildzie, mieszczą się w limitach każdego sklepu i zastępują tekst z ostatniej wersji w każdym języku.

• Nagłówek nazywa zmianę, którą zauważy większość użytkowników.
• Każda istotna funkcja lub zmiana w produkcie jest wymieniona, zgodnie z wymogiem wytycznej 2.3.12.
• Każda poprawka opisuje objaw, który widział użytkownik, a nie wewnętrzny kod.
• Żadnych funkcji za flagami, obietnic na przyszłość, wewnętrznych numerów zgłoszeń ani nazw innych platform.
• Tekst „What's New” z poprzedniej wersji wyczyszczony i zastąpiony w każdej lokalizacji.
• Informacje w Play mają mniej niż 500 znaków na język, są ujęte w poprawne tagi języka i nie zawierają promocji ani wezwań do działania.
• Komunikaty marketingowe przeniesione do Promotional Text u Apple.
• Jeśli prowadzisz też testy z testerami Androida, te same informacje zostały sprawdzone pod kątem Twojego planu testów zamkniętych.

Jeśli chcesz, aby ktoś jeszcze rzucił okiem na metadane aktualizacji przed przesłaniem, napisz na yagyeshsrbobde@gmail.com, dołączając szkic informacji i listę zmian w buildzie, albo zobacz nasze usługi.