Что можно изменить без новой версии приложения: Apple против Google
Прежде чем трогать листинг в сторе, стоит ответить на один вопрос: обойдётся ли эта правка в полноценную отправку на проверку, или её можно выпустить незаметно? Ошибёшься — и либо застрянешь в очереди на проверку, которую не планировал, либо решишь, что изменение уже опубликовано, хотя оно ещё ждёт одобрения. Два стора отвечают на этот вопрос противоположно, и именно в этом причина, почему поддерживать листинги в обоих синхронными так утомительно.
Вот честная версия по каждому полю — сначала матрица, затем логика правил каждого стора, чтобы предсказывать случаи, которые эта таблица не описывает напрямую.
Матрица
Каждое распространённое поле листинга и требования каждого стора при его изменении. «Новая версия / релиз» означает, что стор считает правку частью отправки, которую нужно отправить на проверку; «проверяется» означает, что перед публикацией срабатывает ручная или автоматическая проверка.
| Иконка приложения | Основная иконка встроена в бинарник — для её смены нужна новая сборка. Проверяется вместе с этой сборкой. | Иконка стора — это ресурс листинга. Новый релиз не нужен. Проверяется. |
Бросаются в глаза две вещи. Apple почти всё пропускает через версию. Google даёт всему листингу двигаться самостоятельно. Ни один стор не пропускает проверку важных элементов — слово «проверяется» встречается почти в каждой ячейке. Так что настоящий вопрос редко звучит как «пройдёт ли это проверку», а скорее «тянет ли эта правка за собой отправку на проверку».
Apple: новая версия — не то же самое, что новая сборка
Именно здесь люди чаще всего путаются. В App Store изменение скриншотов, названия, подзаголовка, поля ключевых слов или описания создаёт новую версию листинга. Кажется, что это должно вернуть тебя в Xcode. Но нет. Apple автоматически переносит текущие метаданные в новую версию, и правка только метаданных не требует нового кода приложения — к версии просто прикрепляется сборка (App Store Connect всё равно её требует), а поведение приложения не меняется. Ты редактируешь очередь полей, отправляешь, и один цикл проверки покрывает их все.
Так что «нового кода нет, но проверка всё равно есть» — точная формулировка. Компиляции и новых функций нет, но правка всё равно попадает в App Review и ждёт своей очереди перед публикацией. Собирай изменения в пакет: раз одна версия может содержать сразу новые скриншоты, переписанное описание, свежий подзаголовок и обновлённые ключевые слова, нет смысла тратить отдельный цикл проверки на каждое из них.
Иконка приложения — исключение, которое действительно требует сборки. Основная иконка запечена в бинарник и берётся из него, так что по-настоящему новая иконка означает новую сборку. То же самое с альтернативными иконками — они должны быть встроены в приложение, чтобы работать, так что добавление новой — это сборка, а не правка листинга.
Две лазейки Apple
Промо-текст. Это единственное поле, которое можно менять без версии и без проверки. Это 170 символов над описанием, и оно обновляется в любой момент — удобно для распродажи, заметки о запуске или срочной формулировки. Оно не влияет на позиции в поиске и не входит ни в одну отправку — именно поэтому это самая быстрая правка в сторе. Если что-то нужно опубликовать сегодня же, это то самое поле.
Product Page Optimization. PPO позволяет тестировать до трёх вариантов скриншотов, превью приложения и иконки на живой странице продукта — без выпуска новой версии приложения. Это ближе всего Apple подходит к изменению визуала вне обычной отправки. Есть две оговорки: метаданные варианта всё равно должны быть одобрены перед началом теста (то есть проверка есть, мгновенности нет), и любая иконка для теста уже должна быть частью текущего бинарника приложения. PPO меняет то, что видят посетители — но не пропускает проверку.
Google Play: публикация листинга без релиза
Play работает наоборот. Листинг в сторе — название, короткое описание, полное описание, скриншоты, графика функций, иконка, промо-видео — редактируется и публикуется самостоятельно, без привязки к новому релизу приложения. Ты вносишь правки, и они появляются в обзоре публикации как изменения, готовые к отправке на проверку. Ты их отправляешь, они проходят проверку Google и публикуются независимо от какой-либо сборки.
Есть пара нюансов, которые важно не упустить. Изменения всё равно проверяются — проверка Play работает и на правках листинга, а такие элементы, как название приложения и иконка, проверяются, так что это не мгновенная тихая замена. И листинг не может существовать сам по себе без выпущенного приложения: Play требует, чтобы приложение уже имело релиз, прежде чем появится публичный листинг для редактирования. Нельзя опубликовать отдельную страницу стора для того, что никогда не выходило. Управляемая публикация добавляет ещё один нюанс — если она включена, одобренные изменения ждут, пока ты сам их не опубликуешь, и это не задержка, а функция, если знать о ней заранее.
Асимметрия — и почему она отнимает время
Если выстроить обе модели рядом, разница становится очевидной. Apple привязывает почти каждую текстовую и графическую правку к версии и проверке, а промо-текст и PPO — единственные обходные пути. Google полностью отделяет листинг от релиза, проверяет правки и публикует их по своему расписанию, пока приложение уже существует.
Эта асимметрия незаметно дорого обходится, если ведёшь оба стора. Одно и то же обновление скриншотов — это отправка новой версии в одном сторе и самостоятельное обновление листинга в другом. Переписанное описание — это проверяемая версия в Apple и проверяемое изменение листинга в Google. Контент одинаков, механика — нет, так что действие, которое в Play выполняется в один шаг, в App Store требует другого шага — и легко выпустить одно, забыв про второе, или решить, что что-то уже опубликовано в Apple, хотя оно всё ещё на проверке.
Где здесь место Mokbi
Эта межплатформенная асимметрия и есть причина, по которой инструмент публикации оправдывает себя. Mokbi начинался как редактор скриншотов, но листинг — это текст и изображения вместе, поэтому он проектирует набор скриншотов и составляет текст листинга сразу для обоих сторов в одном месте: название, подзаголовок, поле ключевых слов и описание для App Store; название, короткое и полное описание для Play. Ты получаешь именно те поля, которые индексирует каждый стор, оформленные под этот стор, а не один блок текста, который вставляешь дважды.
Затем он переводит весь листинг — скриншоты и текст — на 50 языков, так что изменение, сделанное один раз, попадает в нужное поле на каждом рынке, а не остаётся на английском в листинге, который во всём остальном уже локализован. И он публикует: Mokbi отправляет готовый листинг напрямую в Google Play через Play Developer API и готовит его в App Store Connect к отправке — финальный Submit и проверку на своей стороне Apple всё равно требует, это правило Apple и как раз та межплатформенная асимметрия, о которой весь этот пост. Именно с этой последней проверки и начинается отсчёт времени, о котором шла речь выше.