Приклади нотаток до релізу в App Store: як написати текст «Що нового», який пояснює користувачам зміни (2026)

Хороші нотатки до релізу в App Store відповідають на одне питання: що зміниться для мене після оновлення? Усі наведені нижче приклади нотаток до релізу App Store побудовано за одним шаблоном. Почніть зі зміни, яку користувач помітить, конкретно назвіть кожне виправлення й пропустіть усе, чого він не бачить. Власні рекомендації Apple щодо поля What's New in This Version кажуть те саме. Apple просить описати нові функції, покращення інтерфейсу чи виправлення помилок і радить повідомляти користувачам «конкретику змін, покращень або виправлень у версії».

Які правила для нотаток до релізу діють в App Store Connect і Google Play?

Поле Apple «Що нового» вміщує 4000 символів і обов'язкове для кожної версії після першої. Google Play дозволяє 500 символів Unicode на мову й забороняє рекламний вміст.

Станом на жовтень 2026 року Довідка Play Console зазначає: «Не використовуйте нотатки до релізу в рекламних цілях або для заклику користувачів до дій». В Apple маркетинговий текст натомість розміщуйте в полі Promotional Text. Воно вміщує 170 символів, відображається над описом, і Apple дозволяє оновлювати його без подання нової версії.

Як виглядають хороші нотатки до релізу в App Store?

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

Якщо виправлення надто технічне, щоб пояснити його одним реченням, користувачі, найімовірніше, його не помітять, тож його можна винести в один рядок «покращення стабільності» наприкінці. Правило 2.3.12 дозволяє це для дрібних виправлень, але не для реальних змін функцій.

Чи є шаблон нотаток до релізу, який можна використовувати повторно?

Так. Шаблон для повторного використання містить заголовок, а потім розділи New («Нове»), Improved («Покращено») та Fixed («Виправлено»). Зберігайте його в репозиторії поруч зі списком змін (changelog) і заповнюйте, коли створюєте релізну гілку, а не після завантаження збірки.

[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.

Для Google Play скоротіть ті самі нотатки до заголовка й двох-трьох головних пунктів, щоб вони вмістилися в 500 символів. Розміщуйте теги кожної мови на окремих рядках, наприклад <en-US> і </en-US>. Приберіть заключний рядок у Play, бо він просить користувача щось зробити.

Як перетворити змерджені pull request'и на нотатки до релізу?

Щоб перетворити змерджені pull request'и на нотатки до релізу, відфільтруйте зміни, яких користувачі не бачать, а кожну решту перепишіть як симптом або результат. Виконуйте ці кроки для кожного релізу.

1. Експортуйте назви змерджених pull request'ів від останнього тегу, потім видаліть усе, чого користувачі не бачать: рефакторинг, оновлення залежностей і зміни CI.
2. Перепишіть кожен пункт, що залишився, як симптом або результат. «Fix nil coordinator» перетворюється на «Виправлено порожній екран після входу через Apple».
3. Упорядкуйте пункти за кількістю користувачів, яких вони стосуються, а не за обсягом інженерної роботи.
4. В App Store Connect створіть нову версію, потім очистіть скопійований текст «Що нового», перш ніж вставляти нові нотатки, бо метадані попередньої версії переносяться.
5. Вставте нотатки в кожну локалізацію, яку ви підтримуєте, — перекладені або принаймні перевірені кожною мовою, — щоб користувачі в інших локалях не бачили нотаток минулої версії.
6. Для Play вставте скорочену версію всередину мовних тегів і переконайтеся, що кожна мова вкладається в 500 символів.
7. Прочитайте нотатки вголос один раз. Якщо речення потребує пояснень розробника, перепишіть його.

Що писати в нотатках до релізу для хотфіксу?

Нотатки до хотфіксу мають назвати зламану версію, описати симптом, який тепер виправлено, і пояснити постраждалим користувачам, що станеться після оновлення. Apple не дозволяє повернутися до попередньої версії в App Store, тож виправлення завжди виходить як нова версія.

Приклад: «Виправлено проблему у версії 3.4.0, через яку в деяких користувачів перестали спрацьовувати нагадування. Нагадування, налаштовані до оновлення, відновляться автоматично». Постраждалі користувачі розуміють, що треба оновитися, а решта бачить, що виправлення їх не стосується. Не звинувачуйте операційну систему й не обіцяйте дат майбутніх виправлень. Якщо ви випускаєте оновлення через поетапний реліз, призупинення розгортання обмежує кількість користувачів, які отримають зламану збірку, поки виправлення проходить перевірку. Якщо хотфікс змінює поведінку функції, ще раз пройдіться чек-листом подання в App Store, щоб нотатки, скриншоти й нотатки для перевірки збігалися.

Чи може App Review відхилити оновлення через нотатки до релізу?

Так. Нотатки до релізу — це метадані, і App Review Guidelines регулюють їх напряму. Правило 2.3.12 каже: «Застосунки мають чітко описувати нові функції та зміни продукту у своєму тексті „What's New“».

Загальні формулювання дозволені для «простих виправлень помилок, оновлень безпеки та покращень продуктивності», але «суттєвіші зміни мають бути перелічені в нотатках». Правило 2.3.10 забороняє назви чи зображення інших мобільних платформ у метаданих, зокрема в «Що нового». Не описуйте функції, приховані за прапорцями (feature flags), чи будь-що, чого немає в поданій збірці. Правило 2.3.1(a) окремо вимагає, щоб нові функції були «конкретно описані в розділі Notes for Review», тож кроки для рецензента й демо-акаунт розміщуйте там, а не в публічних нотатках. Якщо ви все ж отримали запитання щодо метаданих, наш посібник із виправлення відхилень App Store пояснює, як відповісти.

З якими проблемами нотаток до релізу стикалися інші розробники?

Публічно описані випадки показують два типи збоїв: відхилені завантаження через перевищення ліміту довжини в магазині та відхилення під час перевірки, інструкції до яких включають текст «Що нового».

• Ліміт довжини Play у CI. У GitHub issue в шаблоні розгортання Flutter описано, як згенерований ШІ список змін зламав завантаження у внутрішнє тестування Google Play через fastlane з помилкою: «The release created has notes in language ko-KR with length 612, which is too long (max: 500).» Мейнтейнери додали скрипт, який обрізає нотатки перед завантаженням: 480 символів для Play і 3800 байтів для TestFlight, який вимірює ліміт у байтах.
• Виправлення за 2.3.10, що включає «Що нового». Розробник на Apple Developer Forums опублікував відхилення за правилом 2.3.10, спричинене рядками стану не з iOS на скриншотах. У наступних кроках Apple було сказано «видалити всі випадки цієї інформації із застосунку та його метаданих, зокрема з опису застосунку, промотексту, інформації What's New, превʼю та скриншотів». У відповідях радили переробити скриншоти й перевірити кожне поле метаданих, включно з нотатками до релізу.

Висновок: ліміт довжини — механічний і гучно спрацьовує під час завантаження, а правила перевірки стосуються змісту й поширюються на кожне поле метаданих. Автоматизуйте перевірку кількості символів і читайте «Що нового» так само уважно, як переглядаєте скриншоти.

Що перевірити перед поданням нотаток до релізу?

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

• Заголовок називає зміну, яку помітить більшість користувачів.
• Кожну суттєву функцію чи зміну продукту перелічено, як вимагає правило 2.3.12.
• Кожне виправлення описує симптом, який бачив користувач, а не внутрішній код.
• Жодних функцій за прапорцями, обіцянок на майбутнє, внутрішніх номерів тікетів чи назв інших платформ.
• Текст «Що нового» попередньої версії очищено й замінено в кожній локалізації.
• Нотатки для Play коротші за 500 символів на мову, обгорнуті в правильні мовні теги, без реклами й закликів до дії.
• Маркетингові повідомлення перенесено в Promotional Text в Apple.
• Якщо у вас також є тестувальники Android, ті самі нотатки звірено з вашим планом закритого тестування.

Якщо хочете, щоб хтось іще раз переглянув метадані вашого оновлення перед поданням, напишіть на yagyeshsrbobde@gmail.com, додавши чернетку нотаток і список змін у збірці, або перегляньте наші послуги.