Примеры описаний обновлений App Store: как написать «Что нового», чтобы было ясно, что изменилось (2026)

Хорошее описание обновления в 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 гласит: «Приложения должны чётко описывать новые функции и изменения продукта в тексте „Что нового“».

Общие формулировки допустимы для «простых исправлений ошибок, обновлений безопасности и улучшений производительности», но «более существенные изменения должны быть перечислены в заметках». Правило 2.3.10 запрещает названия или изображения других мобильных платформ в метаданных, включая «Что нового». Не описывайте функции, скрытые за флагами, или что-либо, чего нет в отправленной сборке. Правило 2.3.1(a) отдельно требует, чтобы новые функции были «конкретно описаны в разделе Notes for Review», поэтому шаги для проверяющего и демо-аккаунт указывайте там, а не в публичных заметках. Если вам всё же задали вопрос о метаданных, наше руководство по исправлению отклонений App Store объясняет, как ответить.

С какими проблемами в описаниях обновлений сталкивались другие разработчики?

Публично описанные случаи показывают два типа сбоев: загрузки, отклонённые из-за превышения лимита длины магазина, и отклонения при проверке, в инструкциях к которым упоминается текст «Что нового».

• Лимит длины Play в CI. В issue на GitHub в шаблоне деплоя Flutter описан changelog, сгенерированный ИИ, который сломал загрузку во внутреннее тестирование 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 было сказано «удалить все упоминания этой информации из приложения и его метаданных, включая описание приложения, рекламный текст, информацию „Что нового“, превью и скриншоты». В ответах советовали переснять скриншоты и проверить каждое поле метаданных, включая описание обновления.

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

Что проверить перед отправкой описания обновления?

Перед отправкой убедитесь, что заметки описывают только то, что есть в сборке, укладываются в лимиты каждого магазина и заменяют текст прошлой версии на всех языках.

• Заголовок называет изменение, которое заметит большинство пользователей.
• Перечислены все существенные функции и изменения продукта, как требует правило 2.3.12.
• Каждое исправление описывает симптом, который видел пользователь, а не внутренний код.
• Никаких функций за флагами, обещаний на будущее, внутренних номеров задач и названий других платформ.
• Текст «Что нового» предыдущей версии очищен и заменён во всех локализациях.
• Заметки для Play — меньше 500 символов на язык, в правильных языковых тегах, без рекламы и призывов к действию.
• Маркетинговые сообщения перенесены в Promotional Text у Apple.
• Если вы также работаете с тестировщиками Android, те же заметки сверены с вашим планом закрытого тестирования.

Если хотите, чтобы кто-то ещё посмотрел метаданные вашего обновления перед отправкой, напишите на yagyeshsrbobde@gmail.com, приложив черновик заметок и список изменений в сборке, или ознакомьтесь с нашими услугами.