Почему обновления — это часть продвижения, а не рутина

Алгоритмы App Store и Google Play учитывают «свежесть» приложения. Продукт, который не обновлялся полгода, постепенно теряет позиции в поиске стора, а на устройствах с новыми версиями iOS и Android начинает работать нестабильно. Регулярный релиз раз в 4–6 недель — это сигнал алгоритму, что приложение живо, и одновременно повод напомнить о себе пользователям через раздел «Что нового».

Есть и обратная сторона: неудачное обновление способно за сутки обрушить рейтинг, который выстраивался месяцами. Один релиз с критическим багом — и страница приложения наполняется отзывами с одной звездой. Поэтому процесс обновления мы рассматриваем как часть общей стратегии продвижения мобильного приложения: версионирование, поэтапный раскат и грамотные тексты релизов работают на удержание аудитории не меньше, чем реклама.

Версионирование: как нумеровать релизы правильно

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

Семантическое версионирование (X.Y.Z)

Для пользовательской версии мы используем схему «мажор.минор.патч»:

• Мажор (2.0.0) — редизайн, новая бизнес-логика, изменения, которые пользователь заметит сразу;
• Минор (2.3.0) — новая функция: онлайн-оплата, тёмная тема, новый раздел;
• Патч (2.3.1) — исправления багов и мелкие улучшения без новых функций.

Такая схема дисциплинирует команду и помогает поддержке: когда пользователь пишет «у меня версия 2.3.1», сразу понятно, какой набор функций у него на руках.

Номер сборки: versionCode и CFBundleVersion

В Google Play за уникальность релиза отвечает versionCode — целое число, которое обязано расти с каждой загрузкой. В App Store ту же роль играет CFBundleVersion (build number). Стор отклонит сборку с уже использованным номером, поэтому удобно автоматизировать инкремент в CI/CD — это исключает человеческую ошибку, из-за которой релиз «застревает» на этапе загрузки.

Важный нюанс Google Play: откатить versionCode назад невозможно. Если вы загрузили сборку с номером 100 даже в закрытое тестирование, следующая публичная версия должна иметь номер выше.

Чеклист перед загрузкой обновления

Перед каждым релизом мы проходим короткий, но обязательный список:

• Доступы к консолям. Проверьте, что сертификаты iOS не истекли, а у команды есть права на публикацию. Если аккаунты оформлялись давно или сторонним подрядчиком, разберитесь с этим заранее — как устроены аккаунты разработчика Apple и Google, мы разобрали отдельно;
• Регрессионное тестирование. Минимум — критические сценарии: регистрация, оплата, push-уведомления, основной пользовательский путь;
• Скриншоты и метаданные. Если интерфейс изменился, старые скриншоты в сторе вводят пользователей в заблуждение и снижают конверсию страницы;
• Возрастной рейтинг. Добавили чат, пользовательский контент или ссылки на соцсети — заново пройдите анкету, иначе возможен реджект. Подробности — в статье про возрастной рейтинг приложения;
• Минимальные версии ОС и SDK. Google Play ежегодно поднимает требования к target API — релиз на устаревшем SDK просто не пройдёт;
• Миграции данных. Обновление не должно стирать локальные данные пользователя: проверьте сценарий «обновился со старой версии», а не только чистую установку.

Поэтапный раскат: страховка от провального релиза

Поэтапный раскат (staged rollout) — главный инструмент управления риском. Смысл простой: обновление получает не вся аудитория сразу, а небольшой процент. Если в течение 24–48 часов метрики стабильны, охват расширяется.

Google Play: ручное управление процентом

В Google Play Console вы сами задаёте долю аудитории — мы обычно начинаем с 5–10%. Дальше следим за разделом Android Vitals: доля крэшей и ANR не должна расти относительно прошлой версии. Если всё чисто — поднимаем до 25%, 50% и 100%. Если появился критический баг, раскат можно остановить кнопкой Halt: те, кто уже обновился, останутся на новой версии, но остальные её не получат, и вы спокойно готовите исправление.

App Store: семидневный phased release

У Apple механика автоматическая. Включённый phased release раскатывает обновление за 7 дней по нарастающей: 1% → 2% → 5% → 10% → 20% → 50% → 100% пользователей с автообновлением. Процесс можно поставить на паузу (суммарно до 30 дней) или досрочно выкатить на всех. Важно помнить: пользователь, который сам зайдёт на страницу приложения, сможет обновиться вручную в любой день — phased release управляет только автообновлениями.

Что мониторить во время раската

• crash-free rate в Crashlytics или Sentry — падение ниже 99% на старте раската означает проблему;
• ключевые продуктовые события: оплаты, регистрации, заказы — баг не всегда проявляется крэшем;
• свежие отзывы в обоих сторах — пользователи сообщают о проблемах быстрее любых дашбордов;
• нагрузку на бэкенд: новая версия может изменить частоту запросов к API.

Текст «Что нового»: описание обновления, которое читают

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

Принципы, которых мы придерживаемся:

• Конкретика вместо шаблона. «Исправили ошибки и улучшили стабильность» — текст, который не говорит ничего. Лучше: «Исправили ошибку, из-за которой не приходило уведомление о статусе заказа»;
• Главное — в первых двух строках. На странице стора текст обрезается, и большинство не нажимает «ещё»;
• Язык пользы, а не задач разработки. Не «обновили библиотеку платежей», а «оплата картой стала проходить быстрее»;
• Локализация. Для рынка Казахстана готовим текст на русском и казахском, для зарубежных версий — на английском. Несовпадение языка релиз-ноута и аудитории заметно бьёт по доверию;
• Ключевые слова — аккуратно. В Google Play текст «Что нового» индексируется, поэтому уместное упоминание функций помогает видимости. Но это не место для спама ключами.

Сроки модерации и стоимость обновлений в Казахстане

Модерация Apple в 2026 году занимает в среднем 24–48 часов, у Google — от пары часов до 1–3 дней; первые релизы и приложения с платежами проверяются дольше. Закладывайте запас: релиз «к акции в пятницу» нужно отправлять на ревью минимум во вторник.

Ориентиры по стоимости работ для рынка Казахстана:

Вилки зависят от стека (нативный код дороже кроссплатформы в поддержке двух платформ), объёма тестирования и наличия CI/CD. Если приложение разрабатывали мы, инфраструктура релизов настраивается ещё на этапе разработки мобильного приложения — тогда каждое обновление выходит быстрее и дешевле.

Типичные ошибки при обновлении

• Релиз сразу на 100% аудитории. Любой пропущенный баг мгновенно затрагивает всех — и рейтинг падает раньше, чем вы успеете собрать hotfix;
• Релиз в пятницу вечером. Если проблема всплывёт в выходные, чинить её будет некому, а модерация исправления займёт ещё сутки;
• Принудительное обновление без необходимости. Жёсткий force update оправдан только при критических уязвимостях или несовместимости с API — в остальных случаях он раздражает;
• Игнорирование старых версий. Часть аудитории живёт на версии годичной давности: ломая обратную совместимость API, вы ломаете приложение у этих людей;
• Молчание в ответ на отзывы после релиза. Ответ разработчика на негатив о новой версии часто превращает одну звезду в четыре — пользователи правят оценки чаще, чем принято думать.

Частые вопросы

Как часто нужно обновлять приложение?

Оптимальный ритм — раз в 4–6 недель. Это поддерживает позиции в поиске сторов, позволяет вовремя закрывать уязвимости и адаптироваться к новым версиям iOS и Android. Реже допустимо для простых приложений, но пауза больше 4–6 месяцев уже воспринимается алгоритмами и пользователями как признак заброшенного продукта.

Можно ли откатить обновление, если что-то сломалось?

Прямого отката нет ни в одном сторе. В Google Play можно остановить поэтапный раскат, в App Store — поставить phased release на паузу, но пользователи с новой версией останутся на ней. Единственное решение — срочно выпустить исправляющую сборку. Именно поэтому раскат на малый процент аудитории обязателен.

Нужно ли заново проходить модерацию при каждом обновлении?

Да, каждая сборка проходит ревью. У Apple это обычно 24–48 часов, у Google — от нескольких часов до трёх дней. Метаданные (описание, скриншоты, текст «Что нового») тоже проверяются. Если обновление добавляет новые типы контента или функций, может потребоваться обновить анкету возрастного рейтинга и раздел о конфиденциальности данных.

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

Внимательно прочитать причину реджекта: в 2026 году чаще всего это устаревший target SDK в Google Play, проблемы с описанием сбора данных и нарушения правил платежей. Исправьте конкретное замечание и отправьте сборку повторно — повторное ревью обычно проходит быстрее. Спорные решения Apple можно оспорить через Resolution Center.

Сколько стоит поддержка приложения в Казахстане?

Регулярная поддержка с плановыми релизами, мониторингом крэшей и работой с отзывами стоит от 150 000 до 450 000 ₸ в месяц в зависимости от сложности продукта. Разовый hotfix — от 60 000 ₸. Applications.kz берёт на поддержку и приложения, разработанные другими командами: проводим аудит и готовим смету за 24 часа — +7 (707) 928-13-15.

Сообщение Как обновлять приложение в App Store и Google Play: версионирование, поэтапный раскат, «Что нового» появились сначала на Applications.kz.

Личный аккаунт или аккаунт организации: что выбрать

И Apple, и Google делят аккаунты на два типа: индивидуальный (физическое лицо) и аккаунт организации. Выбор определяет, какое имя увидят пользователи в сторе: у физлица это ФИО, у организации — юридическое название. Для коммерческого продукта почти всегда правильнее аккаунт организации: он выглядит доверительнее, позволяет раздавать доступы команде по ролям и не привязан к одному человеку.

Важный нюанс для Казахстана: Apple не считает ИП организацией. Индивидуальный предприниматель регистрируется как Individual, и в App Store будет видно его имя, а не бренд. Если название бренда на странице приложения критично — оформляйте ТОО до подачи заявки. Google к ИП лояльнее, но аккаунт организации и там требует подтверждения регистрации юрлица.

Apple Developer Program: цена, сроки, порядок действий

Членство стоит 99 $ в год — по курсу 2026 года это примерно 52 000–54 000 ₸. Оплата ежегодная: если подписку не продлить, приложения снимаются с публикации, поэтому ставьте напоминание за месяц до даты списания. Процедура для ТОО выглядит так:

1. Создайте Apple ID на корпоративную почту и включите двухфакторную аутентификацию — без неё заявку не примут.
2. Получите номер D-U-N-S (бесплатно, подробнее ниже).
3. Подайте заявку на developer.apple.com: юридическое название латиницей, адрес, сайт, рабочий телефон.
4. Дождитесь верификационного звонка Apple — обычно в течение 1–2 недель; разговор возможен на русском или английском.
5. Оплатите членство картой с поддержкой международных платежей.

Отдельная Apple Developer Enterprise Program за 299 $ в год (около 160 000 ₸) предназначена только для внутренних корпоративных приложений без публикации в App Store. Apple одобряет такие заявки неохотно и долго, поэтому для 95 % компаний она избыточна.

Номер D-U-N-S: главный блокер по срокам

D-U-N-S — международный идентификатор компании в базе Dun & Bradstreet. Apple требует его от всех организаций без исключений. Получить номер можно бесплатно через форму на сайте Apple, но обработка занимает до 30 дней — это самый длинный этап всей регистрации, закладывайте его в план релиза заранее.

Главное правило: название и адрес в заявке на D-U-N-S должны буква в букву совпадать с тем, что вы потом укажете в Apple Developer. Расхождение в транслитерации — «TOO» против «LLP», разные написания одной и той же улицы Алматы латиницей — типовая причина отказа и недель переписки с поддержкой.

Заявку на участие в программе должен подавать человек с правом подписи — директор или сотрудник с подтверждёнными полномочиями: Apple вправе запросить письмо-подтверждение. Регистрировать аккаунт «на фрилансера» — плохая практика: при конфликте с подрядчиком компания рискует потерять доступ к собственному приложению вместе с базой пользователей.

Google Play Console: цена и порядок регистрации

Регистрация в Google Play Console стоит 25 $ единоразово — около 13 500 ₸. Продлевать ничего не нужно. Порядок такой:

1. Создайте Google-аккаунт на корпоративном домене — не на личном Gmail сотрудника.
2. Выберите тип «Организация» и укажите данные ТОО, а также контакты, которые будут видны пользователям: e-mail, телефон, адрес.
3. Пройдите верификацию организации: Google запрашивает документ о регистрации юрлица и номер D-U-N-S — требование действует для организаций с 2023 года.
4. Оплатите сбор картой Visa или Mastercard.
5. Подтвердите личность владельца аккаунта — удостоверение личности РК подходит, фото должно быть чётким и без обрезанных краёв.

Для личных аккаунтов, созданных после ноября 2023 года, действует жёсткое условие: перед публикацией приложение обязано пройти закрытое тестирование минимум с 12 тестировщиками в течение 14 дней. Аккаунтов организаций это не касается — ещё один аргумент регистрироваться как юрлицо и не терять две недели на старте.

Сколько стоит выход в сторы: сводная таблица

Итого прямые платежи сторам для ТОО в первый год — примерно 66 000–68 000 ₸, со второго года — только продление Apple. На фоне бюджета самой разработки это копейки, но именно бюрократия вокруг аккаунтов чаще всего сдвигает дату релиза.

Документы для компаний из Казахстана

Для ТОО подготовьте заранее:

• справку о государственной регистрации юрлица (БИН) — Google может запросить скан;
• номер D-U-N-S с актуальными данными;
• данные директора и при необходимости подтверждение полномочий подающего заявку;
• работающий сайт компании и почту на собственном домене;
• корпоративную карту Visa/Mastercard с включёнными международными платежами.

Для ИП: талон о регистрации предпринимателя и удостоверение личности; в Apple такой аккаунт всё равно оформляется как Individual. Физлицу достаточно удостоверения или паспорта и карты — но помните про ограничение Google на закрытое тестирование для новых личных аккаунтов.

Частые проблемы KZ-компаний и как их обойти

1. Платёж не проходит. Самая массовая проблема: на карте отключены международные операции, стоит низкий лимит или банк режет рекуррентное списание Apple. Решение — заранее включить международные платежи, поднять лимит и держать на карте запас с учётом курсовой конвертации.
2. Данные D-U-N-S не совпадают с заявкой. Любое расхождение в написании названия или адреса блокирует enrollment. Сначала проверьте, что числится в базе Dun & Bradstreet, и копируйте оттуда символ в символ.
3. Apple не дозвонилась. Звонок приходит с иностранного номера в дневное время по Калифорнии — то есть ночью или ранним утром по Алматы. Укажите номер сотрудника, который реально берёт трубку с незнакомых номеров, и проверяйте почту: иногда Apple вместо звонка присылает письмо.
4. Бесплатная почта и отсутствие сайта. Заявка организации с адресом на gmail.com и без работающего сайта — почти гарантированный запрос дополнительных документов. Минимальный лендинг на собственном домене снимает вопрос.
5. Аккаунт оформлен на подрядчика. Студия публикует приложение со своего аккаунта, сотрудничество заканчивается — и перенос приложения превращается в отдельный проект с потерей отзывов в Google Play. Аккаунты всегда оформляйте на свою компанию, подрядчику выдавайте роль с ограниченными правами.
6. Платные приложения и выплаты. Для приёма денег нужны банковские реквизиты с SWIFT и заполненные налоговые формы США (W-8BEN-E для ТОО). Ошибки в форме задерживают выплаты на месяцы — заполняйте её вместе с бухгалтером.

Что дальше: публикация и продвижение

Готовый аккаунт — только пропуск в магазин. Дальше идут сборка, сертификаты, метаданные и модерация: пошаговый процесс мы разобрали в инструкции как опубликовать приложение в App Store. На этапе заполнения карточки оба стора потребуют пройти анкету контента — заранее изучите, как работает возрастной рейтинг приложения: ошибка в анкете ведёт к отклонению или неправильной видимости в каталоге.

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

Applications.kz занимается мобильной разработкой с 2007 года: за это время команда выпустила 300+ проектов для рынков Казахстана, ОАЭ и Таиланда — и оформление аккаунтов разработчика мы берём на себя в рамках разработки мобильных приложений под ключ: от D-U-N-S до первой версии в сторах. Позвоните +7 (707) 928-13-15 — посчитаем смету за 24 часа.

Частые вопросы

Можно ли опубликовать приложение через аккаунт студии, не оформляя свой?

Технически да, и для быстрого MVP это допустимо. Но приложение, отзывы и подписчики юридически принадлежат владельцу аккаунта. При смене подрядчика перенос в Apple проходит относительно безболезненно, а в Google Play вы потеряете историю отзывов. Для долгосрочного продукта оформляйте собственный аккаунт сразу — это 66 000–68 000 ₸ и пара недель.

Сколько ждать D-U-N-S и можно ли ускорить?

Через бесплатную форму Apple номер приходит в срок от нескольких дней до 30. Платное «ускорение» через посредников для Казахстана работает нестабильно и не гарантирует совпадения данных. Практичнее подать заявку в самом начале проекта, параллельно с разработкой, — тогда к моменту релиза номер уже будет на руках.

Принимают ли Apple и Google карты казахстанских банков?

Да, оба стора принимают казахстанские Visa и Mastercard. Проблемы возникают не из-за страны, а из-за настроек: отключённые международные платежи, лимиты на онлайн-операции, сбои 3-D Secure. Перед оплатой включите международные транзакции в приложении банка и убедитесь, что на карте есть запас сверх суммы — списание идёт в долларах с конвертацией по курсу банка.

Нужно ли каждый год платить за Google Play?

Нет. Сбор Google Play Console — разовый, 25 $ при регистрации. Ежегодное продление есть только у Apple: 99 $ каждый год. Если пропустить оплату, Apple сначала шлёт напоминания, затем снимает приложения с публикации; восстановление возможно, но это простой и потеря позиций в поиске стора.

Может ли казахстанское ИП продавать платные приложения и подписки?

Да, Казахстан входит в список стран, где доступны платные приложения и выплаты разработчикам в обоих сторах. ИП понадобятся валютные реквизиты с SWIFT и корректно заполненные налоговые формы США. Учтите, что в App Store такой аккаунт оформляется на физлицо-предпринимателя, и в карточке будет отображаться имя, а не торговая марка.

Сообщение Аккаунт разработчика Apple и Google: как оформить компании из Казахстана появились сначала на Applications.kz.

Что такое возрастной рейтинг и почему сторы относятся к нему строго

Возрастной рейтинг — это формальная оценка того, с какого возраста контент приложения считается допустимым. В отличие от кино, где рейтинг присваивает комиссия, в мобильных сторах работает декларативная модель: разработчик отвечает на вопросы анкеты, а алгоритм стора выводит итоговую метку. Ответственность при этом полностью лежит на разработчике — занижение трактуется как введение пользователей в заблуждение.

Сторы перепроверяют декларации тремя способами: ручной модерацией при ревью, автоматическим сканированием скриншотов, описаний и пуш-уведомлений, а также жалобами пользователей. Расхождение между анкетой и реальным контентом — одна из частых причин отклонения сборки, а при повторных нарушениях — удаления приложения и санкций для аккаунта разработчика.

Как определяется рейтинг в App Store

Анкета заполняется в App Store Connect на уровне приложения и действует для всех его версий. Apple спрашивает о наличии и частоте («нет», «редко», «часто») примерно двадцати типов контента: мультяшное и реалистичное насилие, ненормативная лексика, темы для взрослых, упоминания алкоголя, табака и наркотиков, симулированные азартные игры, медицинская информация, материалы ужасов.

Отдельные пункты работают как переключатели и поднимают рейтинг автоматически, независимо от остальных ответов:

• неограниченный доступ к интернету (встроенный браузер) — минимум 16+;
• азартные игры на реальные деньги — сразу 18+;
• пользовательский контент без премодерации и инструментов жалоб — повышение рейтинга плюс риск отклонения по гайдлайну 1.2;
• частые или интенсивные «зрелые» темы — 18+ без вариантов.

Новая шкала Apple: 4+, 9+, 13+, 16+, 18+

В 2025 году Apple расширила шкалу: вместо привычных 12+ и 17+ появились градации 13+, 16+ и 18+. Рейтинги существующих приложений были пересчитаны автоматически по старым ответам анкеты, поэтому приложениям, опубликованным до реформы, стоит перепроверить итоговую метку — автоматический пересчёт нередко завышает её. Подробный порядок подготовки сборки и метаданных мы разобрали в материале о том, как опубликовать приложение в App Store.

Как определяется рейтинг в Google Play

Google Play использует международную систему IARC. В Play Console разработчик один раз проходит опросник — категория приложения, наличие насилия, секса, лексики, наркотиков, азартных механик, обмена данными между пользователями, покупок и геолокации. На выходе IARC выдаёт сразу пакет рейтингов под разные регионы: PEGI для Европы, ESRB для США и Канады, USK для Германии, ClassInd для Бразилии и универсальную шкалу IARC 3+/7+/12+/16+/18+ для остальных стран, включая Казахстан.

Важные особенности именно Google Play:

• анкета привязана к функциональности: добавили чат, стримы или шеринг геопозиции — опросник нужно пройти заново до релиза;
• Google периодически требует повторную сертификацию рейтинга; просроченная анкета блокирует публикацию обновлений;
• неверные ответы квалифицируются как Misrepresentation — это прямое основание для удаления приложения и страйка аккаунту.

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

Сравнение шкал App Store и Google Play

Одно и то же приложение почти всегда получает разные метки в двух сторах — это нормально, шкалы не совпадают. Ориентир для планирования:

Таблица — ориентир, а не гарантия: итог зависит от сочетания ответов. Например, безобидный мессенджер с открытой регистрацией и обменом фото легко уходит в 13+/12+ только из-за пользовательского контента.

На что влияет возрастной рейтинг

Рейтинг — не формальность для галочки, а параметр, который напрямую двигает экономику продукта.

• Охват аудитории. Приложения 18+ скрываются у пользователей с включёнными семейными ограничениями, а в ряде стран не показываются в поиске стора по умолчанию. Подростковая аудитория с активным Screen Time или Family Link физически не сможет установить приложение выше разрешённой планки.
• Реклама и монетизация. AdMob и другие сети режут форматы для детских рейтингов: персонализированная реклама запрещена (требования COPPA и GDPR-K), eCPM падает. Для рейтинга 18+ часть рекламодателей недоступна по их собственным brand-safety политикам.
• Детские программы сторов. Попасть в категорию «Дети» в App Store или в программу Families в Google Play можно только с низким рейтингом и жёстко ограниченным набором SDK — это отдельный аудит трекинга и аналитики.
• Фичеринг и продвижение. Редакции сторов почти не выносят 18+ в подборки. Стратегию вывода в топ с учётом рейтинговых ограничений мы описали в гайде по продвижению мобильных приложений.
• Скорость модерации. Высокие рейтинги и «пограничный» контент проверяются дольше и чаще уходят на ручное ревью.

Типичные ошибки и чем грозит занижение

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

1. Занижение ради охвата. Соблазн поставить 4+ вместо честных 13+ заканчивается отклонением на ревью, а если модерация пропустила — удалением после первой жалобы.
2. Забытый пользовательский контент. Комментарии, аватарки, чат поддержки с обменом фото — всё это UGC, который обязан быть отражён в анкете.
3. Встроенный браузер. WebView с произвольными ссылками автоматически тянет рейтинг вверх; если браузер не нужен — уберите его до сабмита.
4. Несинхронные обновления. Добавили дейтинг-механику или лотерею, а анкету не обновили — для Google это Misrepresentation, для Apple — нарушение гайдлайнов.
5. Маркетинг противоречит рейтингу. Скриншоты и тексты со «взрослыми» намёками при детском рейтинге — отдельная причина реджекта, даже если само приложение чистое.

Цена ошибки — не только время. Удалённое приложение теряет позиции в выдаче, а повторная публикация стартует почти с нуля: история установок и отзывов в ранжировании весит много.

Помощь с рейтингом и публикацией: цены в Казахстане

Applications.kz сопровождает публикации в App Store и Google Play с 2007 года — за это время мы выпустили 300+ проектов на рынках Казахстана, ОАЭ и Таиланда и знаем, какие формулировки анкеты вызывают вопросы у модерации. Ориентировочные цены на 2026 год:

• аудит анкеты возрастного рейтинга, privacy-меток и метаданных перед сабмитом — от 60 000 ₸;
• публикация в одном сторе под ключ (аккаунт, сборка, анкеты, ответы модерации) — от 120 000 ₸;
• публикация в App Store и Google Play пакетом — от 180 000 ₸;
• разбор отклонения по рейтингу и повторный сабмит — от 90 000 ₸;
• разработка мобильного приложения под ключ с публикацией — от 3 500 000 ₸.

Если сомневаетесь, какой рейтинг получит ваш продукт и как он скажется на охвате — напишите нам: +7 (707) 928-13-15. Директор студии Иван Калита лично курирует сложные публикации. Смету и прогноз по рейтингу подготовим за 24 часа.

Частые вопросы

Можно ли изменить возрастной рейтинг после публикации?

Да, в любой момент: в App Store Connect правится анкета приложения, в Play Console заново проходится опросник IARC. Изменение вступает в силу с ближайшим ревью. Учтите, что повышение рейтинга может «отрезать» часть текущей аудитории с семейными ограничениями, поэтому планируйте его вместе с релизом, а не задним числом после жалоб.

Почему у одного приложения разные рейтинги в App Store и Google Play?

Шкалы не совпадают: Apple использует собственные градации 4+/9+/13+/16+/18+, а Google опирается на региональные системы через IARC. Один и тот же ответ — например, «редкая ненормативная лексика» — конвертируется в разные метки. Это не ошибка и не повод подгонять анкеты: модерация каждого стора сверяет ответы со своими правилами.

Что будет, если занизить рейтинг?

Минимум — отклонение сборки с требованием исправить анкету. Если занижение вскрылось после релиза, Apple может снять приложение с публикации, а Google расценивает это как Misrepresentation: удаление плюс страйк аккаунту. Три страйка — бан аккаунта разработчика со всеми приложениями. Восстановление позиций после удаления занимает месяцы.

Рейтинг 18+ сильно бьёт по скачиваниям?

Заметно: приложение исчезает из выдачи у пользователей с родительским контролем, теряет шансы на фичеринг и часть рекламного инвентаря. Но если продукт объективно взрослый — дейтинг, беттинг, финансовые спекуляции, — честный 18+ безопаснее: занижение приведёт к удалению, что дороже любых потерь охвата.

Нужно ли обновлять анкету при каждом релизе?

Нет, только когда меняется контент или функциональность: добавили чат, UGC, встроенный браузер, рекламу, азартные механики. Исключение — Google Play периодически сам требует повторную сертификацию IARC; игнорировать письмо нельзя, иначе блокируются обновления. Мы включаем проверку анкеты в чек-лист каждого релиза наших клиентов.

Сообщение Возрастной рейтинг приложения: как определяется и на что влияет появились сначала на Applications.kz.

Что нового в требованиях Apple в 2026 году

Apple пересматривает правила каждый год, и команда Applications.kz отслеживает каждое обновление: с 2007 года мы выпустили более 300 проектов для рынков Казахстана, ОАЭ и Таиланда, и значительная часть из них проходила ревью Apple не один раз. Вот что изменилось к 2026 году:

• Актуальный SDK обязателен. Новые приложения и обновления должны собираться в Xcode 26 на базе iOS 26 SDK. Сабмит из устаревшей среды отклоняется автоматически — ещё до того, как билд увидит живой рецензент.
• Обновлённая шкала возрастных рейтингов. Apple расширила систему до пяти ступеней: 4+, 9+, 13+, 16+ и 18+. Анкету рейтинга нужно заполнить заново, а расхождение между заявленным возрастом и реальным контентом стало самостоятельным основанием для отклонения.
• Декларация передачи данных сторонним ИИ. Если приложение отправляет персональные данные во внешние AI-модели — например, в API генеративных сетей для обработки фото или текста, — пользователь обязан дать явное согласие. Это требование обновлённого пункта 5.1.2(i).
• Контроль встроенных мини-приложений. Пункт 4.7 теперь детально регулирует HTML5-игры, чат-ботов и плагины внутри приложений: им запрещено обходить системные разрешения, собирать данные без согласия и принимать оплату мимо In-App Purchase.

Как устроены App Review Guidelines: пять разделов

Свод правил Apple состоит из пяти больших блоков, и рецензент проверяет приложение по каждому из них:

1. Safety (Безопасность) — контент без вреда пользователю: модерация UGC, защита детей, корректная работа с медицинскими данными.
2. Performance (Производительность) — приложение запускается, не падает, не содержит заглушек «coming soon» и битых ссылок. Сюда же относится требование передавать рецензенту работающий демо-доступ.
3. Business (Бизнес) — монетизация по правилам: цифровые товары и подписки только через In-App Purchase, без скрытых платежей и накрутки.
4. Design (Дизайн) — приложение должно давать самостоятельную ценность, а не дублировать сайт в WebView. Минимальная функциональность — одна из самых частых претензий к «приложениям-обёрткам».
5. Legal (Право) — приватность, лицензии, соответствие законам стран, где приложение распространяется, включая требования к хранению персональных данных.

Важно понимать: рецензент не обязан объяснять, как исправить проблему. Он указывает номер нарушенного пункта — расшифровать формулировку и найти реальную причину должна команда разработки. Если ответ Apple поставил вас в тупик, разберите ситуацию по нашему материалу что делать, если приложение отклонили в App Store.

Privacy — главный фокус проверки

За последние три года приватность превратилась из формальности в центральный блок ревью. Apple проверяет три уровня.

Privacy Manifest и Required Reason API

Файл PrivacyInfo.xcprivacy обязателен для приложения и для каждого стороннего SDK из списка Apple. В манифесте декларируется, какие данные собираются, зачем и используются ли они для трекинга. Отдельно описываются причины обращения к «чувствительным» API — например, к UserDefaults или системным таймстампам. Если подключённая аналитика или рекламный SDK не имеет манифеста, билд не пройдёт даже автоматическую валидацию при загрузке в App Store Connect.

Privacy-метки в карточке приложения

Раздел App Privacy («этикетка приватности») заполняется в App Store Connect и должен совпадать с фактическим поведением приложения. Расхождение — например, метка «данные не собираются» при подключённой Firebase Analytics — трактуется как обман пользователя. Метки должны соответствовать и политике конфиденциальности: как правильно составить этот документ, мы разобрали в статье о privacy policy для приложения.

App Tracking Transparency и удаление аккаунта

Любой трекинг пользователя между приложениями и сайтами требует системного диалога ATT — и приложение обязано корректно работать при отказе. Второе жёсткое правило: если в приложении есть регистрация, внутри обязана быть функция полного удаления аккаунта, а не просто «деактивации». Ссылки на сайт с многоступенчатой процедурой Apple не принимает.

Топ-7 причин реджектов в 2026 году

По нашему опыту публикаций, подавляющее большинство отклонений укладывается в короткий список:

• Guideline 2.1 — App Completeness. Краши, незаполненные экраны, отсутствие демо-логина для рецензента. Самая массовая причина: Apple физически не может проверить функции за авторизацией без тестового аккаунта.
• Guideline 2.3 — Accurate Metadata. Скриншоты не соответствуют интерфейсу, в описании обещаны функции, которых нет, упоминаются чужие бренды.
• Guideline 4.3 — Spam / шаблонность. Приложение слишком похоже на десятки других на том же шаблоне. Боль конструкторов и «клонов под ключ за неделю».
• Guideline 5.1.1 — Data Collection. Запрос данных без обоснования: например, обязательный номер телефона там, где он не нужен для работы функций.
• Guideline 3.1.1 — обход In-App Purchase. Ссылки на внешнюю оплату цифрового контента без разрешённого исключения.
• Guideline 4.8 — Sign in with Apple. Если есть вход через Google или Facebook, должен быть и вход через Apple (или другой сервис с равной защитой приватности).
• Guideline 4.2 — Minimum Functionality. WebView-обёртка сайта без нативной ценности: офлайн-режима, push-уведомлений, интеграции с системой.

Каждую из этих причин можно закрыть до сабмита — дешевле потратить два дня на внутренний аудит, чем терять одну-две недели на цикл «реджект — исправление — повторное ревью».

Сколько стоит соответствие требованиям Apple в Казахстане

Ориентировочные затраты для компании из Казахстана в 2026 году:

Главная статья экономии — закладывать требования Apple на этапе проектирования, а не дорабатывать готовый продукт. Когда мы берём разработку мобильного приложения под ключ, соответствие Guidelines входит в обязательный объём работ: от Privacy Manifest до сценария ревью с демо-доступом.

Чек-лист перед отправкой на ревью

Минимальный список, который мы прогоняем перед каждым сабмитом:

• Билд собран в актуальном Xcode на свежем iOS SDK, протестирован на реальных устройствах, включая старые модели из поддерживаемого диапазона.
• Privacy Manifest заполнен для приложения и всех сторонних SDK, privacy-метки в App Store Connect совпадают с фактическим сбором данных.
• В App Review Information указан рабочий демо-аккаунт и примечания для рецензента: что проверять, какие данные тестовые.
• Есть удаление аккаунта внутри приложения, Sign in with Apple при сторонних логинах, диалог ATT при трекинге.
• Скриншоты сняты с финальной версии, описание без упоминания Android и чужих торговых марок, возрастной рейтинг пересчитан по новой анкете.
• Все платежи за цифровой контент идут через In-App Purchase; физические товары и услуги — через сторонний эквайринг, это разрешено.

Прохождение ревью — это не финиш, а старт: дальше карточку приложения нужно выводить в топ поисковой выдачи App Store. Как устроена эта работа — от ASO до платного трафика — мы подробно описали в руководстве по продвижению мобильных приложений.

Частые вопросы

Сколько длится проверка приложения Apple в 2026 году?

Около 90% сабмитов Apple проверяет в течение 24–48 часов — это официальная статистика App Review. Первая публикация нового приложения обычно идёт дольше повторных обновлений. Если приложение отклонили, после исправлений оно встаёт в общую очередь заново, поэтому цикл с двумя реджектами легко растягивается на одну-две недели.

Можно ли публиковать приложение в App Store из Казахстана?

Да, без ограничений. Индивидуальный аккаунт регистрируется на физическое лицо с Apple ID и оплатой $99 в год (~55 000 ₸). Для аккаунта организации (имя компании вместо имени разработчика на странице приложения) понадобится D-U-N-S номер — казахстанские ТОО получают его бесплатно за одну-две недели через сайт Dun & Bradstreet.

Что чаще всего становится причиной реджекта?

Лидируют пункты 2.1 (краши, незавершённость, отсутствие демо-доступа для рецензента), 2.3 (метаданные не соответствуют приложению) и 5.1.1 (избыточный сбор данных, нет удаления аккаунта). Большинство таких отклонений предотвращается внутренним аудитом до сабмита: проверка занимает два-три дня и стоит на порядок дешевле потерянных недель релиза.

Обязателен ли Privacy Manifest, если приложение не собирает данные?

Да. Даже если ваше приложение ничего не отправляет на сервер, манифест нужен для деклараций обращения к Required Reason API — а к ним относятся вполне бытовые вещи вроде UserDefaults. Кроме того, манифесты обязаны иметь сторонние SDK из списка Apple: без них билд не пройдёт автоматическую валидацию при загрузке.

Поможет ли Applications.kz пройти ревью, если приложение писала другая команда?

Да, мы регулярно берём на аудит и публикацию чужие проекты. Проверяем приложение по всем разделам Guidelines, приводим в порядок Privacy Manifest, метки приватности и карточку App Store, готовим ответы рецензенту. Свяжитесь с нами по телефону +7 (707) 928-13-15 — смету и план работ подготовим за 24 часа.

Сообщение Требования Apple к приложениям в 2026 году: гайд по App Review, privacy и реджектам появились сначала на Applications.kz.

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

Как устроена проверка и почему отклонение — это нормально

Каждая сборка перед публикацией проходит ручную и автоматическую проверку командой App Review на соответствие App Store Review Guidelines — документу примерно из 150 пунктов, который Apple обновляет несколько раз в год. Ревьюер реально запускает приложение, проходит регистрацию, кликает по экранам и сверяет увиденное с описанием и скриншотами.

Отклонение с первой попытки — рядовая ситуация даже для опытных команд: формулировки гайдлайнов размытые, трактовка зависит от конкретного ревьюера, а требования к приватности и платежам ужесточаются ежегодно. Важно другое: в ответе Apple всегда указан номер пункта (например, Guideline 2.1 или 5.1.1) и, как правило, скриншот проблемного места. Это и есть отправная точка для исправления.

Шесть самых частых реджектов и как их закрыть

Guideline 2.1 — App Completeness: краши и нерабочие функции

Самая массовая причина. Приложение падает при запуске на устройстве ревьюера, бэкенд недоступен из США, кнопки ведут в никуда, контент-разделы пустые. Частный случай — ревьюер не смог войти, потому что регистрация требует казахстанский номер телефона с SMS.

Что делать: воспроизвести проблему на чистом устройстве (не на симуляторе), проверить доступность API из-за рубежа, обязательно приложить работающий демо-аккаунт в поле App Review Information. Если вход завязан на SMS — добавьте тестовый номер с фиксированным кодом подтверждения.

Guideline 4.3 — Spam: «ещё одно такое же приложение»

Apple отклоняет приложения, которые считает клоном существующих: шаблонные сборки, переименованные копии чужого кода, второй экземпляр своего же продукта под другим брендом. Под удар часто попадают конструкторы и white-label-решения.

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

Guideline 5.1.1 — приватность: сбор данных без объяснений

Запрос доступа к камере или геолокации без понятного текста причины, регистрация там, где она не нужна, отсутствие или недоступность политики конфиденциальности, расхождение между Privacy Nutrition Labels и реальным поведением приложения. С 2024 года добавилось требование Privacy Manifest для используемых SDK.

Что делать: прописать человеческие тексты в Info.plist для каждого разрешения, сделать регистрацию опциональной, где это возможно, и опубликовать корректную политику по постоянному URL. Как составить документ, который пройдёт проверку, мы разобрали в статье о privacy policy для приложения.

Guideline 2.3 — метаданные: скриншоты и описание врут

Скриншоты показывают функции, которых нет в сборке, описание обещает «лучшее приложение №1», в ключевых словах — названия конкурентов, в превью — устройство Android. Сюда же относится упоминание других платформ в описании.

Что делать: метаданные можно поправить без пересборки прямо в App Store Connect — это самый быстрый тип реджекта. Скриншоты должны быть сняты из реального приложения, описание — отражать фактический функционал текущей версии.

Guideline 3.1.1 — платежи в обход Apple

Цифровой контент (подписки, премиум-функции, виртуальная валюта) продаётся через Kaspi, карту или внешнюю ссылку вместо In-App Purchase. Apple отклоняет такие сборки последовательно и жёстко. Физические товары и услуги «в реальном мире» — доставка еды, бронирования, такси — наоборот, обязаны принимать оплату вне IAP.

Что делать: честно определить тип продукта. Цифровое — только через StoreKit с комиссией Apple; физическое — любой эквайринг. Гибридные случаи (например, онлайн-курсы с офлайн-занятиями) стоит описать ревьюеру в примечаниях заранее.

Guideline 4.2 — Minimum Functionality: сайт в обёртке

WebView вокруг мобильной версии сайта без нативных функций Apple публиковать отказывается: по логике компании такому продукту достаточно браузера. Что делать: добавить то, чего нет у сайта — push-уведомления, офлайн-режим, виджеты, Face ID, нативную навигацию. Если бюджет позволяет, кроссплатформенная разработка на Flutter решает проблему радикально и при этом дешевле двух нативных команд.

Пошаговый план после отклонения

1. Прочитайте сообщение целиком. Зафиксируйте номера гайдлайнов, скриншоты и формулировки — Apple почти всегда указывает конкретное место в приложении.
2. Воспроизведите проблему. На физическом устройстве, со свежей установкой, в идеале через VPN с американским IP — окружение ревьюера отличается от вашего.
3. Уточните, если непонятно. В Resolution Center можно задать вопрос ревьюеру до внесения правок. Вежливый конкретный вопрос экономит итерацию.
4. Исправьте и опишите правки. При повторной отправке в Notes напишите, что именно изменено по каждому пункту. Сборки с пояснениями проходят заметно быстрее.
5. Не согласны — подавайте апелляцию. Через App Review Board: аргументированно, со ссылками на пункты гайдлайнов и примеры аналогичных одобренных приложений. Апелляции реально работают, особенно по спорным трактовкам 4.3.

Чего делать не стоит: пересабмитить без изменений, спорить эмоционально, пытаться «протащить» скрытый функционал — за умышленный обман Apple может заблокировать аккаунт разработчика целиком.

Сколько стоит исправление реджекта в Казахстане

Бюджет зависит от типа претензии: правка метаданных — часы работы, а доработка веб-обёртки до нативного уровня — недели. Ориентиры по рынку Казахстана на 2026 год:

Для сравнения: членство в Apple Developer Program стоит 99 $ в год (около 53 000 ₸), а каждая неделя простоя из-за цепочки реджектов — это сдвиг запуска, маркетинга и выручки.

Как застраховаться от реджекта до отправки

Дешевле всего реджект, которого не было. Наш предсабмит-чеклист, выработанный на десятках публикаций:

• Прогнать релиз-кандидат через внешнее бета-тестирование в TestFlight — внешние сборки проходят упрощённое ревью и подсвечивают проблемы до основного;
• Подготовить демо-аккаунт с заполненными данными и описать ревьюеру неочевидные сценарии в App Review Information;
• Сверить Privacy Labels, Privacy Manifest и реальные запросы разрешений между собой;
• Проверить доступность бэкенда и платёжных сценариев из-за пределов Казахстана;
• Убедиться, что скриншоты сняты из финальной сборки, а в описании нет упоминаний Android и пустых обещаний;
• Перечитать разделы 2, 3, 4 и 5 гайдлайнов применительно к своей нише — для финтеха, медицины и азартных механик есть отдельные требования.

Публикация — не финал, а старт: дальше идут работа с рейтингом, ключевыми словами и конверсией страницы. Этому посвящён наш большой материал о продвижении мобильных приложений.

Чем поможет Applications.kz

Мы публикуем приложения в App Store с эпохи iOS 2 — студия работает с 2007 года, за плечами 300+ проектов для рынков Казахстана, ОАЭ и Таиланда. Реджекты по 2.1, 4.3 и 3.1.1 для нас — рутинные задачи с отработанными сценариями: от точечной переписки с App Review до полной разработки мобильного приложения, которое проходит проверку с первого раза.

Пришлите текст отклонения из Resolution Center на WhatsApp +7 (707) 928-13-15 — разберём причину, предложим план исправления и подготовим смету за 24 часа.

Частые вопросы

Сколько времени занимает повторная проверка после исправления?

Обычно 24–48 часов, как и первичное ревью. Если правки касались только метаданных, бывает быстрее. Затяжные сроки (от недели) встречаются после нескольких подряд отклонений одной сборки или в пиковые периоды — перед новогодними праздниками Apple традиционно перегружена. Срочный релиз можно запросить через Expedited Review, но злоупотреблять этим нельзя.

Реджект влияет на аккаунт разработчика или будущие сабмиты?

Обычные отклонения — нет: это рабочий процесс, через который проходят почти все. Опасны умышленные нарушения — скрытый функционал, подмена контента после ревью, накрутка отзывов, повторные клоны после реджекта по 4.3. За них Apple может удалить приложение из стора и заблокировать аккаунт по пункту о честности разработчика без права восстановления.

Можно ли узнать причину подробнее, если формулировка Apple непонятна?

Да. В Resolution Center задайте ревьюеру прямой вопрос: какой экран вызвал претензию, какого изменения будет достаточно. Отвечают в течение одного-двух дней, часто со скриншотами. Для сложных случаев у Apple есть телефонная консультация App Review — её можно запросить там же. Это бесплатно и нередко быстрее, чем гадать и пересабмитить вслепую.

Приложение отклонили уже после публикации обновления — так бывает?

Да, каждый апдейт проходит ревью заново, и новая версия может получить реджект по пункту, который раньше пропускали — гайдлайны ужесточаются. Опубликованная версия при этом остаётся в сторе и продолжает работать. Исключение — грубые нарушения: тогда Apple может снять приложение с публикации до устранения проблемы.

Стоит ли сразу заказывать исправление студии или попробовать самим?

Реджекты по метаданным (2.3) и текстам разрешений закрываются своими силами за день. Звать подрядчика разумно, когда претензия архитектурная: переход на In-App Purchase, доработка веб-обёртки, спор по 4.3 — здесь цена ошибки выше, а каждая неудачная итерация добавляет неделю к запуску. Аудит сборки перед сабмитом обходится от 200 000 ₸ и обычно дешевле двух лишних кругов ревью.

Сообщение Отклонили приложение в App Store: что делать появились сначала на Applications.kz.

Команда Applications.kz с 2007 года вывела в App Store и Google Play более 300 проектов для рынков Казахстана, ОАЭ и Таиланда. Заметная доля отказов модерации, с которыми к нам приходят за помощью, связана не с кодом, а с приватностью: ссылка на политику не открывается, декларация данных не совпадает с реальным поведением SDK, нет кнопки удаления аккаунта. Разберём, как составить документ, который пройдёт ревью с первого раза и не создаст юридических рисков.

Почему без Privacy Policy приложение не опубликуют

С 2018 года Apple требует ссылку на политику конфиденциальности для каждого приложения в App Store Connect — даже если оно формально «ничего не собирает». Требование распространяется и на этап внешнего бета-тестирования в TestFlight: без URL политики внешнюю группу тестировщиков просто не отправить на ревью. Google Play действует так же: ссылка указывается в Play Console и обязана дублироваться внутри приложения.

Модераторы проверяют не только наличие ссылки. Документ должен:

• открываться без авторизации, с любого устройства, не вести на PDF в облачном диске;
• быть размещён на домене, который вы контролируете (не на бесплатном генераторе, который завтра закроется);
• соответствовать тому, что приложение реально делает с данными — включая сторонние SDK аналитики, рекламы и крэш-репортов;
• совпадать с декларациями App Privacy (Apple) и Data Safety (Google).

Несоответствие любого из пунктов — это отклонение по guideline 5.1.1 у Apple или предупреждение с дедлайном на исправление у Google, вплоть до удаления приложения из каталога.

Что обязательно должно быть в политике конфиденциальности

Универсального шаблона «на все случаи» не существует, но структура рабочего документа стабильна. Минимальный состав разделов:

1. Оператор данных — юридическое лицо или ИП с реквизитами и контактом для запросов по персональным данным.
2. Перечень собираемых данных — по категориям: идентификаторы (e-mail, телефон), данные устройства, геолокация, платёжные данные, контент пользователя, диагностика.
3. Цели обработки — для каждой категории отдельно: авторизация, доставка push-уведомлений, аналитика, маркетинг.
4. Правовое основание — согласие, исполнение договора, законное требование.
5. Сторонние получатели — все SDK и сервисы: Firebase, AppMetrica, рекламные сети, платёжные шлюзы, с указанием, какие данные им уходят.
6. Сроки хранения и география серверов — где физически лежат данные и когда удаляются.
7. Права пользователя — доступ, исправление, удаление, отзыв согласия, и конкретный механизм реализации (форма, e-mail, кнопка в приложении).
8. Данные несовершеннолетних — собираете или нет, и как проверяете возраст.
9. Порядок изменений — как пользователи узнают о новой редакции.

Отдельный пункт, который чаще всего забывают: процедура удаления аккаунта. С июня 2022 года Apple отклоняет приложения с регистрацией, в которых нет инициируемого пользователем удаления аккаунта прямо из интерфейса. Политика должна описывать этот механизм, а приложение — содержать его.

Закон РК «О персональных данных и их защите»: что учесть

Базовый документ для казахстанского рынка — Закон РК от 21 мая 2013 года № 94-V. Если ваше приложение обрабатывает данные граждан Казахстана, ключевые требования такие.

Согласие на сбор и обработку

Согласие должно быть осознанным и подтверждённым действием пользователя: чекбокс при регистрации со ссылкой на политику, а не строчка мелким шрифтом «продолжая, вы соглашаетесь». Пользователь вправе отозвать согласие — в политике опишите, как именно это сделать и что произойдёт с данными после отзыва.

Локализация баз данных

Закон требует, чтобы база, содержащая персональные данные казахстанцев, хранилась на территории республики. На практике это означает: если бэкенд развёрнут на зарубежном облаке, для персональных данных пользователей из РК нужен сервер или реплика в казахстанском дата-центре. Этот момент стоит закладывать в архитектуру на старте — при разработке мобильных приложений мы проектируем хранение данных с учётом локализации ещё до первого спринта, потому что переезд готовой базы обходится заметно дороже.

Ответственность

Нарушения в сфере персональных данных караются по КоАП РК: для юридических лиц штрафы исчисляются сотнями МРП, а при утечках добавляются репутационные потери и предписания регулятора — уполномоченного органа в сфере защиты персональных данных при МЦРИАП. Для приложений банковской, медицинской и государственной тематики проверки строже.

GDPR: когда европейский регламент касается приложения из Казахстана

GDPR действует экстерриториально: он применяется, если вы предлагаете товары или услуги пользователям в ЕС либо отслеживаете их поведение — независимо от того, где зарегистрирована компания. Признаки, по которым регулятор определит «таргетинг на ЕС»: версии приложения на европейских языках, цены в евро, доставка в страны союза, маркетинг на европейскую аудиторию. Само по себе наличие приложения в европейском сторе ещё не означает применимость GDPR, но как только появляются устойчивые пользователи из ЕС — риски становятся реальными.

Что добавляет GDPR к требованиям казахстанского закона:

• шесть правовых оснований обработки — и для каждой операции нужно выбрать одно конкретное;
• расширенные права субъекта: переносимость данных, возражение против профилирования, «право быть забытым» в жёсткие сроки (до 30 дней на ответ);
• уведомление надзорного органа об утечке в течение 72 часов;
• privacy by design — настройки приватности по умолчанию должны быть максимально щадящими;
• штрафы до 20 млн евро или 4% мирового оборота.

Практичный подход для приложения, которое выходит на несколько рынков: одна политика, написанная по самому строгому стандарту (GDPR), с разделами-дополнениями для юрисдикций — РК, ОАЭ, Таиланд (там действует собственный закон PDPA). Так документ не придётся переписывать при выходе в новый стор-регион.

Требования Apple и Google в 2026 году: сравнение

Частые причины отказа модерации

• ссылка на политику возвращает 404 или редиректит на главную сайта;
• privacy labels заявляют «данные не собираются», а в сборке стоит Firebase Analytics или рекламный SDK;
• в Privacy Manifest не задекларированы required reason API (например, доступ к UserDefaults);
• политика есть только на английском, а приложение локализовано на русский и казахский — формально это не нарушение, но возражения пользователей и регулятора РК вероятны;
• после добавления нового SDK декларации не обновили. Сверка политики и privacy-деклараций должна входить в чек-лист при каждом обновлении приложения в сторах — рассинхронизация копится незаметно и всплывает в самый неудобный момент.

Сколько стоит подготовка Privacy Policy в Казахстане

Ориентиры по рынку на 2026 год — вилки зависят от количества интеграций, юрисдикций и наличия чувствительных данных (платежи, медицина, геолокация):

Экономика простая: один отказ модерации сдвигает релиз на дни, а предписание регулятора или блокировка приложения стоят несоизмеримо дороже аккуратно составленного документа. Корректные privacy labels к тому же работают на конверсию страницы приложения — пользователи всё чаще смотрят на блок «Конфиденциальность» перед установкой, и это уже фактор продвижения приложения, а не только комплаенса.

Applications.kz готовит privacy-пакет как часть выпуска приложения: мы знаем, какие данные реально собирает каждый SDK в вашей сборке, поэтому декларации совпадают с фактическим поведением кода. Напишите нам на +7 (707) 928-13-15 — посчитаем смету за 24 часа.

Частые вопросы

Можно ли использовать бесплатный онлайн-генератор политики?

Для прохождения модерации — иногда да, для юридической защиты — нет. Генераторы не знают про закон РК № 94-V, локализацию баз данных и ваш реальный набор SDK. Типичный сценарий: сгенерированный текст заявляет одно, приложение делает другое, и при первой жалобе пользователя или проверке регулятора расхождение оборачивается против вас. Для коммерческого продукта документ должен писаться под конкретную архитектуру.

Нужна ли политика, если приложение вообще не собирает данные?

Да. Apple и Google требуют ссылку на политику для каждого приложения без исключений. К тому же «не собирает» почти всегда иллюзия: крэш-репорты, идентификаторы устройства, IP-адреса в логах сервера — это уже обработка данных. Честная политика в таком случае получается короткой, но она обязана существовать и быть доступной по постоянному URL.

На каком языке писать политику для приложения в Казахстане?

Минимум — русский; для аудитории РК сильная практика — русский плюс казахский, для модерации сторов и зарубежных рынков добавляется английская версия. Версии должны быть синхронны по содержанию: расхождения между переводами создают юридическую неопределённость. В приложении и сторе указывайте ссылку на страницу с переключателем языков.

Где разместить политику, если у приложения нет сайта?

Достаточно одной статической страницы на собственном домене — её можно развернуть за день. Размещать документ на бесплатных конструкторах или в облачных документах не стоит: ссылка должна быть стабильной годами, открываться без авторизации и не зависеть от стороннего сервиса. Домен и страница политики — часть инфраструктуры релиза, как сертификаты и аккаунты разработчика.

Что будет, если политика не совпадает с реальным поведением приложения?

Три уровня последствий. Сторы: отклонение при ревью или удаление из каталога после жалобы. Регулятор РК: предписание и штраф по КоАП за обработку данных без надлежащего основания. GDPR-юрисдикции: расследование с потенциальными многомиллионными штрафами. Поэтому при каждом добавлении SDK или новой фичи со сбором данных политику и декларации сторов нужно актуализировать одновременно с релизом.

Сообщение Privacy Policy для мобильного приложения: что обязательно, GDPR и закон Казахстана появились сначала на Applications.kz.

Что такое TestFlight и почему без него рискованно релизить

TestFlight — официальный сервис Apple для распространения предрелизных сборок. Он встроен в App Store Connect, бесплатен и решает главную проблему этапа перед публикацией: как дать приложение живым людям на их собственные iPhone, не выкладывая его в стор. Тестировщик ставит приложение TestFlight из App Store, принимает приглашение по e-mail или публичной ссылке — и получает вашу сборку со всеми обновлениями.

Каждая сборка живёт в TestFlight 90 дней, поддерживаются iOS, iPadOS, watchOS, tvOS и visionOS. Внутри доступны автоматический сбор крашей, скриншоты с комментариями от тестировщиков и заметки «что проверить» для каждого билда. По опыту Applications.kz — а мы с 2007 года выпустили более 300 проектов для Казахстана, ОАЭ и Таиланда — приложения, прошедшие полноценный бета-цикл, проходят модерацию App Store с первой попытки заметно чаще: основные причины отклонений (краши, нерабочие сценарии, битые ссылки) отлавливаются ещё до отправки.

Единственное обязательное условие — действующий аккаунт Apple Developer Program. Если вы его ещё не оформили, начните с инструкции по регистрации аккаунтов разработчика Apple и Google: без него ни загрузить сборку, ни пригласить тестировщиков не получится.

Внутреннее и внешнее тестирование: в чём разница

TestFlight делит тестировщиков на два круга, и путать их не стоит — у них разные лимиты, скорость и назначение.

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

Пошаговый план: как организовать бета-тест до релиза

Шаг 1. Подготовьте и загрузите сборку

Соберите архив в Xcode или через fastlane, присвойте корректные версию и номер билда, загрузите в App Store Connect. Сразу заполните ответы по экспортному шифрованию (ключ ITSAppUsesNonExemptEncryption в Info.plist избавит от ручного вопроса при каждой загрузке) и напишите заметку «Что тестировать» — конкретный список экранов и сценариев, а не «посмотрите приложение».

Шаг 2. Прогоните внутренний круг

Добавьте команду и заказчика внутренними тестировщиками. Цель этого этапа — за 1–2 дня убедиться, что сборка вообще пригодна к показу: авторизация работает, оплата проходит в sandbox, push-уведомления доставляются, основные экраны не падают. Выносить на внешних людей билд, который падает на онбординге, — пустая трата их лояльности.

Шаг 3. Соберите внешнюю группу

Для большинства продуктов на старте достаточно 30–100 внешних тестировщиков. Где их брать: будущие клиенты и партнёры заказчика, профильные чаты и сообщества, подписчики соцсетей бренда, сотрудники компании вне проектной команды. Публичная ссылка TestFlight упрощает набор: один URL можно разместить в Telegram-канале или лендинге, ограничив число участников и при необходимости включив критерии по устройствам и версии iOS.

Шаг 4. Пройдите Beta App Review

Первая сборка для внешних тестировщиков проходит облегчённую проверку Apple — обычно в пределах суток. Требования мягче, чем при релизном ревью, но базовые правила действуют: приложение не должно крашиться, ссылки на политику конфиденциальности обязаны работать, тестовые доступы для проверяющих нужно приложить. Последующие билды той же версии чаще всего попадают к тестировщикам без повторной проверки.

Шаг 5. Итерируйте до критериев готовности

Выпускайте новые билды по мере исправлений — тестировщики получают их автоматически. Зафиксируйте критерии выхода из беты заранее: например, crash-free rate выше 99,5%, все приоритетные сценарии пройдены минимум на пяти моделях iPhone, нет открытых блокирующих дефектов. Без формальных критериев бета затягивается на месяцы, а ценность каждой новой недели падает.

Как собирать обратную связь, чтобы она была полезной

Встроенные механизмы TestFlight закрывают базу: тестировщик делает скриншот, рисует пометки и отправляет комментарий прямо из приложения, а краши с согласия пользователя улетают в App Store Connect вместе с контекстом. Но для серьёзного бета-теста этого мало.

• Подключите Crashlytics или аналог. Краш-репорты TestFlight приходят только от тех, кто разрешил их отправку; внешняя аналитика даёт полную картину стабильности.
• Дайте тестировщикам сценарии. Чек-лист из 10–15 конкретных задач («зарегистрируйтесь, добавьте товар, оформите заказ с оплатой картой») даёт в разы больше дефектов, чем свободное блуждание по приложению.
• Сделайте единую точку сбора. Форма или отдельный чат, куда падают все отчёты, плюс ответственный, который превращает их в задачи в трекере. Фидбек, который никто не разбирает, — это не тестирование, а имитация.
• Замеряйте поведение, а не только баги. Где пользователи бросают онбординг, какие функции игнорируют — эти данные из беты экономят месяцы после релиза.

Учтите и долгосрочный эффект: процессы, которые вы выстроите на бете, понадобятся постоянно — каждое обновление приложения в сторах стоит прогонять через тот же TestFlight-цикл, просто короче.

А что с Android: бета-инструменты Google Play

Если приложение кроссплатформенное, бета-тест стоит запускать параллельно. В Google Play Console три уровня: внутреннее тестирование (до 100 человек, сборка доступна за минуты), закрытое тестирование по спискам e-mail или Google-группам и открытое тестирование, доступное всем из карточки в сторе. Важный нюанс 2026 года: новым личным аккаунтам разработчика Google требует провести закрытое тестирование минимум с 12 тестировщиками в течение 14 дней, прежде чем откроет доступ к продакшн-релизу — закладывайте это в сроки. Для компаний-разработчиков с организационным аккаунтом таких ограничений нет, что ещё один аргумент публиковаться через аккаунт студии или юрлица.

Сколько стоит организовать бета-тестирование в Казахстане

Сам TestFlight бесплатен — платите вы за инфраструктуру аккаунтов и работу специалистов. Ориентиры по рынку Казахстана на 2026 год:

Если приложение разрабатывает наша студия под ключ, бета-этап уже включён в процесс: мы собираем билды, ведём TestFlight, готовим сценарии и доводим продукт до релизных критериев — отдельно докупать это не нужно.

Типичные ошибки, которые обнуляют пользу беты

• Тестируют только свои. Команда знает, куда нажимать, и не видит проблем новичка. Без внешнего круга бета не отвечает на главный вопрос — поймёт ли продукт незнакомый человек.
• Нет заметок «что тестировать». Пустое поле — и тестировщики открывают приложение один раз из вежливости.
• Игнорируют краши «у одного пользователя». Один воспроизводимый краш в бете — это сотни после релиза и единица в оценке стора.
• Забывают про платежи и пуши. Sandbox-покупки и доставку уведомлений нужно проверять именно на бете — на симуляторе и внутренних стендах они ведут себя иначе.
• Не используют бету для маркетинга. Лояльные бета-тестировщики — первые оценки, отзывы и сарафан после релиза. Как конвертировать их в установки, разбираем в гайде по продвижению мобильных приложений.

Частые вопросы

Сколько длится проверка Beta App Review?

Обычно до 24 часов, иногда несколько часов. Проверяется только первая сборка версии, отправляемая внешним тестировщикам; последующие билды той же версии, как правило, доходят до группы автоматически. Внутренние тестировщики получают сборки вообще без ревью — сразу после обработки загрузки, что занимает 10–30 минут.

Попадают ли отзывы бета-тестировщиков в App Store?

Нет. Фидбек из TestFlight виден только команде в App Store Connect: ни оценки, ни комментарии, ни краш-отчёты не публикуются. Это безопасная среда — даже сырая сборка не испортит будущий рейтинг приложения. Публичные отзывы появляются только после релиза в сторе.

Сколько времени закладывать на бета-тест?

Для типового продукта — 2–4 недели: неделя на внутренний круг и стабилизацию, одна-две недели активного внешнего тестирования, остаток на исправления и контрольный прогон. Сложные продукты с платежами, интеграциями и большой аудиторией тестируют 4–8 недель. Дольше двух месяцев бету тянуть не стоит — сборки устаревают, интерес группы гаснет.

Что будет, когда сборка «протухнет» через 90 дней?

Тестировщики не смогут открыть приложение, пока вы не загрузите новый билд. На практике до этого редко доходит: при живом процессе сборки выходят каждые одну-две недели. Если бета-пауза затянулась, просто соберите и загрузите свежий билд — группа и настройки сохранятся.

Можно ли показать приложение заказчику без TestFlight?

Технически да — через ad-hoc-дистрибуцию по UDID устройств, но это неудобно: каждое устройство нужно регистрировать вручную, а обновления рассылать файлами. TestFlight решает то же самое в два клика, с автообновлениями и сбором крашей, поэтому в реальных проектах ad-hoc почти не используют.

Автор — команда Applications.kz. Планируете релиз и хотите выстроить бета-тест правильно? Позвоните +7 (707) 928-13-15 — посчитаем смету за 24 часа.

Сообщение TestFlight и бета-тестирование: как проверить приложение до релиза появились сначала на Applications.kz.

Команда Applications.kz публикует iOS-приложения с 2007 года: более 300 проектов для рынков Казахстана, ОАЭ и Таиланда. Ниже — процесс публикации образца 2026 года с нюансами, важными именно для казахстанских компаний: регистрация на ТОО, оплата из KZ, типичные причины отклонения.

Шаг 1. Аккаунт Apple Developer Program

Без членства в Apple Developer Program публикация невозможна — это самый бюрократический этап. Стоимость — 99 $ в год (примерно 53 000–56 000 ₸ по курсу 2026 года); карты казахстанских банков с USD-транзакциями проходят без проблем.

Тип аккаунта влияет на то, что увидит пользователь в сторе:

• Individual — на физическое лицо. Регистрация за 1–2 дня, но в App Store продавцом будет указано ваше имя и фамилия. Для бизнеса это выглядит несолидно и мешает доверию.
• Organization — на компанию (ТОО или ИП с подтверждённым юрстатусом). В сторе отображается название компании, доступны корпоративные роли в App Store Connect. Требуется номер D-U-N-S — бесплатный идентификатор от Dun & Bradstreet. Казахстанские ТОО получают его за 5–14 дней, и это самое узкое место по срокам: закладывайте его в план заранее.

После оплаты Apple проверяет данные — иногда звонит на указанный номер или запрашивает документы. Для Organization-аккаунта понадобится человек с правом подписи (Legal Entity contact) и рабочий e-mail на домене компании: заявки с бесплатных почтовых ящиков проверяются дольше.

Шаг 2. Подготовка сборки: подписи, Xcode, TestFlight

Когда аккаунт активен, приложение нужно собрать и подписать. Если коротко, цепочка такая:

1. Bundle ID — уникальный идентификатор вида kz.company.appname, регистрируется в разделе Certificates, Identifiers & Profiles. Изменить его после публикации нельзя.
2. Сертификат дистрибуции и provisioning profile — Xcode 16+ создаёт их автоматически при включённом Automatically manage signing. Ручная настройка нужна только при CI/CD-сборках (fastlane, Xcode Cloud).
3. Архив и загрузка — Product → Archive, затем Distribute App → App Store Connect. Сборка проходит автоматическую валидацию: Apple проверяет SDK (в 2026 году обязателен iOS 18 SDK и новее), Privacy Manifest у сторонних библиотек, иконки и entitlements.
4. TestFlight — внутреннее тестирование до 100 человек доступно сразу после обработки сборки, внешнее (до 10 000 тестеров) требует упрощённого beta-ревью за 1–2 дня. Мы не отправляем в продакшен проекты без круга TestFlight: большинство отклонений ловится именно здесь.

Если приложения у вас ещё нет и вы только оцениваете проект — посмотрите, как устроена разработка мобильных приложений под ключ в Applications.kz: публикация в сторах входит в каждый наш контракт отдельным этапом с гарантией прохождения ревью.

Шаг 3. Листинг в App Store Connect

Листинг — это витрина приложения. Apple жёстко лимитирует каждое поле, и эти лимиты стоит использовать полностью, потому что от них зависит поисковая видимость внутри стора.

Текстовые поля и их лимиты

• Название — 30 символов. Самое весомое поле для поиска: бренд + один ключевой запрос.
• Подзаголовок — 30 символов, второе по весу поле.
• Keywords — 100 символов через запятую, не видны пользователю. Не дублируйте слова из названия — это сжигает лимит впустую.
• Описание — до 4000 символов. На ранжирование почти не влияет, но конвертирует просмотр в установку: первые три строки видны без раскрытия.
• Промо-текст — 170 символов, единственное поле, которое можно менять без выпуска новой версии.

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

Скриншоты и графика

В 2026 году обязательны скриншоты двух размеров: iPhone 6.9″ (1320×2868) и — при поддержке iPad — iPad 13″ (2064×2752); остальные диагонали Apple масштабирует сама. Допустимо до 10 скриншотов и 3 видео-превью по 15–30 секунд. Первые два скриншота решают всё: их видно в поисковой выдаче стора ещё до перехода на страницу.

Приватность и юридические поля

Без этих пунктов кнопка «Submit» останется неактивной: privacy-метки (какие данные собирает приложение и зачем), ссылка на политику конфиденциальности на действующем домене, возрастной рейтинг по анкете Apple и контакт поддержки. Если в приложении есть вход — обязательна функция удаления аккаунта прямо из интерфейса: это требование Apple проверяет вручную.

Шаг 4. Ревью: как проходит модерация Apple

После заполнения листинга вы прикрепляете сборку к версии и нажимаете Submit for Review. Дальше происходит следующее:

• Сроки. Около 90 % приложений Apple проверяет за 24–48 часов. Первая публикация нового аккаунта иногда идёт дольше — до 3–5 дней, модератор может задать вопросы прямо в App Store Connect.
• Демо-доступ. Если в приложении есть авторизация, в поле App Review Information обязательно укажите рабочий тестовый логин и пароль. Отсутствие демо-доступа — причина отклонения номер один по Guideline 2.1.
• Notes для ревьюера. Короткая записка на английском: что делает приложение, как проверить ключевые сценарии, почему запрашиваются разрешения (геолокация, камера, push). Две минуты работы экономят сутки переписки.
• Expedited review. Если релиз горит (критический баг в проде, привязка к дате запуска), можно запросить ускоренное ревью через специальную форму — Apple одобряет такие запросы, если не злоупотреблять.

Отклонение — не катастрофа: вы получаете конкретный пункт гайдлайнов и переписку с ревьюером в Resolution Center, исправляете и отправляете заново. Что именно Apple ужесточила в этом году — от Privacy Manifest до правил для приложений с ИИ-генерацией — мы собрали в обзоре требований Apple к приложениям в 2026 году.

Сроки и бюджет публикации: цифры для Казахстана

Реалистичная смета на публикацию в 2026 году, если само приложение уже разработано:

Итого публикация силами подрядчика обходится в 200 000–450 000 ₸ в зависимости от числа локалей и сложности графики. Самостоятельно — только 55 000 ₸ за аккаунт, но впервые это 30–60 часов на разбор требований.

Пять причин отклонения, которые мы видим чаще всего

1. Guideline 2.1 — App Completeness. Краши при проверке, нерабочие кнопки, заглушки «Coming soon». Лечится обязательным прогоном через TestFlight на реальных устройствах.
2. Guideline 4.2 — Minimum Functionality. Приложение-обёртка над мобильным сайтом без нативной ценности. Apple отклоняет WebView-обёртки стабильно и без сожалений.
3. Guideline 5.1.1 — Privacy. Запрос разрешений без объяснения цели, сбор данных, не указанный в privacy-метках, отсутствие удаления аккаунта.
4. Guideline 3.1.1 — Payments. Цифровой контент продаётся в обход In-App Purchase. Для физических товаров и услуг (доставка, бронирование) внешние платёжные шлюзы, включая Kaspi-сценарии, разрешены — путаница в этом пункте у казахстанских проектов встречается постоянно.
5. Битые метаданные. Скриншоты с чужих устройств, упоминание Android в описании, неработающая ссылка на политику конфиденциальности.

Каждый пункт проверяется до сабмита за 15 минут по чек-листу — поэтому подготовленные заявки проходят с первого раза, а «сырые» зависают на недели переписки.

App Store и Google Play: публиковаться параллельно?

Если приложение кроссплатформенное, запускайте обе площадки одной волной: трафик из рекламы приходит с разных устройств, и пустая страница в одном из сторов — потерянные установки. Процессы различаются: у Google разовая оплата 25 $ вместо подписки, обязательное закрытое тестирование для новых разработчиков и иной механизм ревью. Разбор второй площадки — в статье как опубликовать приложение в Google Play.

Планируете запуск и хотите пройти ревью с первой попытки? Applications.kz берёт публикацию под ключ: аккаунт, сборка, листинг, переписка с Apple. Звоните +7 (707) 928-13-15 — директор студии Иван Калита и команда подготовят смету за 24 часа.

Частые вопросы

Сколько стоит опубликовать приложение в App Store в Казахстане?

Обязательный платёж один — Apple Developer Program, 99 $ в год (около 55 000 ₸). Всё остальное опционально: публикация под ключ силами студии стоит от 200 000 ₸, включая подготовку листинга, скриншоты, сборку и сопровождение ревью. Комиссию 15–30 % Apple берёт только с продаж цифрового контента внутри приложения.

Можно ли опубликовать приложение на ТОО из Казахстана?

Да, без ограничений. Понадобится Organization-аккаунт: действующее ТОО или ИП, номер D-U-N-S (выдаётся бесплатно за 5–14 дней), корпоративная почта и сотрудник с правом подписи. В App Store продавцом будет указано юридическое название компании, что повышает доверие пользователей по сравнению с аккаунтом на физлицо.

Сколько длится ревью Apple?

В 2026 году около 90 % сборок проверяются за 24–48 часов. Первая публикация нового аккаунта может занять 3–5 дней. При отклонении вы получаете конкретный пункт гайдлайнов и чат с ревьюером; повторная проверка после исправлений обычно проходит быстрее первой. Для срочных случаев существует expedited review по запросу.

Что подготовить до сабмита, чтобы пройти ревью с первого раза?

Минимальный чек-лист: тестовый логин-пароль для ревьюера, рабочая ссылка на политику конфиденциальности, заполненные privacy-метки, функция удаления аккаунта (если есть регистрация), скриншоты актуальных размеров без упоминания Android и прогон сборки через TestFlight на реальных устройствах. Эти шесть пунктов закрывают большинство типовых отклонений.

Можно ли менять страницу приложения после публикации?

Частично. Промо-текст (170 символов) и цену можно менять в любой момент. Название, подзаголовок, ключевые слова, описание и скриншоты обновляются только вместе с новой версией приложения, которая снова проходит ревью. Поэтому листинг стоит продумывать до релиза, а обновления метаданных привязывать к плановым версиям раз в 4–6 недель.

Сообщение Как опубликовать приложение в App Store: пошаговая инструкция 2026 появились сначала на Applications.kz.

Команда Applications.kz выпускает Android-приложения для клиентов из Казахстана, ОАЭ и Таиланда с 2007 года — за это время через наши руки прошло более 300 проектов. Ниже — рабочий порядок публикации с актуальными требованиями Google на 2026 год и пояснениями, на чём чаще всего «застревают» новички.

Шаг 1. Аккаунт разработчика Google Play

Без аккаунта разработчика ничего не выйдет — это вход в Google Play Console, панель управления всеми вашими приложениями. Регистрация открывается на странице play.google.com/console, оплата взноса 25 $ проходит банковской картой, в том числе казахстанской. Взнос разовый: в отличие от Apple, Google не берёт ежегодную плату.

Личный аккаунт или аккаунт организации

На старте Google спрашивает тип аккаунта, и это решение важнее, чем кажется:

• Личный аккаунт — быстрее открыть, но Google публично показывает в сторе ваше имя и обязывает пройти этап закрытого тестирования с реальными тестировщиками до выхода в продакшн.
• Аккаунт организации — требует номер D-U-N-S (бесплатный идентификатор Dun & Bradstreet, оформление занимает до 30 дней), зато избавляет от обязательного закрытого тестирования и выглядит солиднее в карточке приложения.

Для бизнеса в Казахстане мы почти всегда рекомендуем аккаунт организации: ТОО или ИП получает D-U-N-S без проблем, а публикация от юрлица упрощает дальнейшую работу с платежами и передачу прав.

Верификация: что попросит Google

После оплаты взноса Google проверяет, что вы — реальный человек или компания. Понадобятся документ, удостоверяющий личность (для личного аккаунта), регистрационные данные и сайт компании (для организации), подтверждение адреса, телефона и адреса электронной почты. Имя и адрес указывайте латиницей и ровно так, как в документах: расхождение в одну букву — типовая причина отказа в верификации. Без завершённой верификации публикация заблокирована.

Шаг 2. Технические требования к сборке в 2026 году

Google Play принимает только формат Android App Bundle (AAB) — классический APK для новых приложений не подходит. Перед загрузкой проверьте сборку по списку:

• Target API level. Новые приложения обязаны таргетировать актуальную версию Android (API 35 и выше). Сборка под устаревший API отклоняется автоматически, ещё до модерации.
• Подпись через Play App Signing. Ключ подписи хранится у Google, вы загружаете upload-ключ. Потерянный собственный keystore — невосполнимая проблема, поэтому схема Google надёжнее.
• 64-битная поддержка для всего нативного кода — обязательна.
• Размер базового модуля — до 200 МБ; тяжёлый контент выносится в Play Asset Delivery.
• Разрешения. Каждое опасное разрешение (геолокация в фоне, SMS, список звонков) нужно обосновать в консоли — иначе отклонение.
• Уникальный applicationId — после первой публикации его сменить нельзя.

Если приложение планируется и под iOS, закладывайте требования обеих платформ сразу — у Apple свой набор правил, который мы разобрали в материале о требованиях Apple к приложениям в 2026 году. Архитектурные решения, принятые «только под Android», потом дорого переделывать.

Шаг 3. Карточка приложения и обязательные анкеты в консоли

Google Play Console не выпустит релиз, пока карточка приложения не заполнена полностью. Подготовьте заранее:

• название до 30 символов, краткое описание до 80, полное — до 4000 символов;
• иконку 512×512 px и баннер (feature graphic) 1024×500 px;
• минимум 2 скриншота на каждый поддерживаемый тип устройств (рекомендуем 4–8 — карточка с двумя скриншотами выглядит сырой и хуже конвертирует);
• рабочую ссылку на политику конфиденциальности — без неё релиз не уйдёт на проверку.

Дальше — четыре обязательные анкеты, и к ним стоит отнестись серьёзно, потому что ответы сверяются с реальным поведением приложения:

1. Безопасность данных (Data safety) — какие данные собираете, передаёте ли третьим сторонам, как шифруете. Несовпадение анкеты с фактическим трафиком приложения — частая причина блокировки уже после релиза.
2. Возрастной рейтинг — опросник IARC, по которому стор присваивает рейтинг для каждой страны.
3. Целевая аудитория — если в неё попадают дети, включаются ужесточённые правила рекламы и сбора данных.
4. Реклама и доступ — есть ли в приложении реклама и нужен ли модератору тестовый логин-пароль для проверки закрытых разделов.

Шаг 4. Тестирование: для личных аккаунтов — обязательно

В консоли четыре дорожки релизов: внутреннее тестирование (до 100 человек, обновления прилетают за минуты), закрытое, открытое и продакшн. Даже когда Google не требует тестирования, мы всегда прогоняем сборку через внутреннюю дорожку: установка из стора регулярно вскрывает проблемы, которых не видно на девелоперской сборке, — от падений на конкретных устройствах до неработающих push-уведомлений.

Для личных аккаунтов закрытое тестирование — обязательный барьер: нужно собрать минимум 12 тестировщиков, которые держат приложение установленным непрерывно 14 дней, и только после этого открывается заявка на доступ к продакшну. Тестировщики должны быть реальными: Google анализирует вовлечённость, и «мёртвые души» с одинаковым поведением приводят к отказу.

Шаг 5. Релиз, модерация и выпуск в продакшн

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

• Сроки модерации — от нескольких часов до 7 дней. Первое приложение нового аккаунта проверяют дольше и пристальнее, обновления — быстрее.
• Управляемая публикация (managed publishing) позволяет пройти проверку заранее, а кнопку «опубликовать» нажать в нужный день — удобно, когда релиз привязан к маркетинговой дате.
• Поэтапное развёртывание — выпускайте обновления сначала на 10–20 % пользователей: если в сборке критический баг, пострадает меньшинство, а откатить процент проще, чем весь релиз.

Если модератор вернул приложение с отказом — это рабочая ситуация, а не приговор: формулировки Google указывают на конкретный пункт правил, и после исправления сборку отправляют повторно без ограничений. Логика обжалования в обоих сторах похожа — пошаговый план мы описали в статье что делать, если приложение отклонили.

Сколько стоит публикация в Google Play: бюджет в тенге

Сам стор почти ничего не стоит — основные расходы лежат вокруг него. Ориентиры для Казахстана на 2026 год:

Если приложения ещё нет, начинать стоит не с аккаунта, а с продукта — посмотрите, как мы подходим к разработке мобильных приложений: грамотная архитектура на старте снимает половину проблем с модерацией на финише.

Что делать после публикации

Выход в стор — это старт, а не финиш. Без работы над видимостью приложение оседает на дне поисковой выдачи Google Play, где его никто не находит. Минимальная программа на первый месяц: собрать первые оценки и отзывы, отслеживать ANR и краши в разделе Android Vitals (плохие показатели понижают позиции), обновлять приложение хотя бы раз в 4–6 недель и системно заниматься ASO — подбором ключевых слов, тестированием иконки и скриншотов. Как выстроить эту работу целиком, мы разобрали в гайде по продвижению мобильных приложений.

Нужна помощь с публикацией или приложением под ключ? Позвоните по номеру +7 (707) 928-13-15 — подготовим смету за 24 часа.

Частые вопросы

Сколько времени занимает публикация приложения в Google Play?

Если аккаунт уже верифицирован и материалы готовы — от 1 до 7 дней: день на заполнение консоли плюс модерация. С нуля закладывайте 2–3 недели: верификация аккаунта занимает до нескольких дней, D-U-N-S для организации — до 30 дней, а личным аккаунтам нужны ещё 14 дней обязательного закрытого тестирования.

Можно ли опубликовать приложение без ИП или ТОО?

Да, личный аккаунт разработчика оформляется на физическое лицо по удостоверению личности. Но учтите два минуса: ваше имя будет публично видно в карточке приложения, и перед продакшном придётся пройти закрытое тестирование с 12 тестировщиками в течение 14 дней. Для коммерческих продуктов мы рекомендуем аккаунт организации.

Сколько стоит аккаунт Google Play и есть ли ежегодная оплата?

Регистрационный взнос — 25 $ (около 13 500 ₸ по курсу 2026 года), и платится он один раз за всё время существования аккаунта. Ежегодных платежей нет — этим Google Play выгодно отличается от App Store, где членство в программе разработчиков Apple стоит 99 $ каждый год.

Почему Google может отклонить приложение?

Самые частые причины: анкета безопасности данных не совпадает с реальным поведением приложения, нет рабочей ссылки на политику конфиденциальности, необоснованные опасные разрешения, устаревший target API level, сломанная функциональность при проверке и нарушение правил контента. В отказе Google указывает конкретный пункт правил — исправляете и отправляете сборку повторно.

Чем публикация в Google Play отличается от App Store?

Google дешевле (25 $ разово против 99 $ в год), быстрее проверяет обновления и лояльнее к функциональности. Apple жёстче модерирует дизайн, контент и встроенные покупки, зато не требует закрытого тестирования для новых разработчиков. Если планируете обе платформы, готовьте материалы параллельно — требования к графике и описаниям у сторов разные.

Сообщение Как опубликовать приложение в Google Play: пошаговая инструкция 2026 появились сначала на Applications.kz.

ASO простыми словами: чем оно отличается от SEO

Если SEO — это продвижение сайтов в Google, то ASO — это продвижение приложений внутри магазинов App Store и Google Play. Логика похожа: алгоритм магазина ранжирует карточки по релевантности запросу, а пользователь решает, скачивать ли приложение, глядя на иконку и скриншоты. Но есть принципиальные различия.

• Замкнутая экосистема. Вы оптимизируетесь не под Google, а под алгоритмы конкретного магазина с собственными правилами индексации.
• Двойная задача. ASO одновременно влияет и на видимость (поисковая выдача, категории, подборки), и на конверсию (доля установивших из увидевших карточку).
• Сигнал от поведения. Конверсия, удержание (retention), удаления и отзывы — прямые факторы ранжирования. Плохой продукт нельзя «накрутить» текстом.

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

Из чего состоит ASO: элементы оптимизации

Все элементы карточки делятся на две группы — текстовые (влияют на индексацию по ключам) и визуальные (влияют на решение установить).

Текстовые элементы

• Название (Title). Самый весомый текстовый сигнал. До 30 символов в App Store. Сюда выносится бренд + главный ключ.
• Подзаголовок (Subtitle) / Краткое описание. Второй по важности слот для ключевых слов.
• Поле ключевых слов (только iOS). 100 символов, невидимое поле для индексации. Без пробелов, через запятую, без повторов из названия.
• Описание. В Google Play индексируется и влияет на ранжирование, в App Store — нет, но работает на конверсию.

Визуальные элементы

• Иконка — первое, что видит пользователь. Тестируется в A/B.
• Скриншоты — до 10 штук. Первые 2-3 решают конверсию, должны нести выгоду, а не голый интерфейс.
• Превью-видео — до 30 секунд, поднимает доверие.
• Отзывы и рейтинг — социальное доказательство и фактор ранжирования одновременно.

Особенности ASO для Казахстана

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

• Двуязычность. Аудитория ищет и на русском, и на казахском. Грамотное ASO задействует обе локали — это расширяет семантику без конкуренции за одни и те же ключи.
• Локаль и регион. Магазины показывают карточку с учётом страны аккаунта. Метаданные нужно настраивать под казахстанскую локаль, а не оставлять дефолтную.
• Низкая конкуренция в нишах. Многие локальные запросы (доставка, банки, госуслуги, такси по конкретным городам) недонасыщены — это шанс быстро занять топ.
• Поведение пользователя. Высокая доля Android в массовом сегменте и iOS в платёжеспособном — приоритет магазина зависит от продукта.

Детальный пошаговый разбор мы собрали в материале ASO-чеклист 2026 для Казахстана — его удобно держать под рукой при запуске.

Как оптимизировать приложение: пошаговый процесс

1. Сбор семантики. Анализ запросов, по которым ищут похожие продукты, оценка частотности и конкуренции на рус/каз.
2. Анализ конкурентов. Разбор метаданных топовых приложений категории: какие ключи в названии, как построены скриншоты.
3. Сборка метаданных. Распределение ключей по слотам (название → подзаголовок → keywords) без переспама.
4. Визуальная упаковка. Иконка и скриншоты под выгоды, локализация текста на скриншотах.
5. Публикация и индексация. Ожидание переиндексации (от нескольких часов до пары дней).
6. Замер и итерации. Отслеживание позиций по ключам, конверсии, и обновление метаданных раз в 4-6 недель.

ASO почти никогда не работает в одиночку. На старте его усиливают платным трафиком — как минимум через Apple Search Ads в Казахстане, который дополнительно даёт данные о конверсии ключевых слов.

Сколько стоит ASO в Казахстане в 2026 году

Стоимость зависит от объёма работ и количества локалей. Ориентировочные диапазоны для рынка KZ:

Цены ориентировочные: финальная смета зависит от категории, числа локалей и состояния текущей карточки. Точный расчёт по вашему проекту мы готовим за 24 часа.

Типичные ошибки ASO

• Спам ключами. Повтор одних и тех же слов в названии и keywords тратит символы впустую.
• Игнор казахской локали. Потеря целого пласта органического трафика.
• Скриншоты-«голый интерфейс». Без заголовков и выгод конверсия падает.
• Разовая оптимизация. ASO — не «настроил и забыл», алгоритмы и конкуренты меняются.
• Отказ от A/B-тестов. Иконку и скриншоты нужно проверять на реальном трафике.

Кому доверить ASO

ASO даёт результат, когда связано с продуктом, аналитикой и платным трафиком. Студия Applications.kz работает с 2007 года, на счету более 300 проектов на рынках Казахстана, ОАЭ и Таиланда. Мы ведём приложения комплексно — от разработки до продвижения приложений в Алматы — и настраиваем ASO с учётом двуязычной аудитории. Обсудить задачу: +7 (707) 928-13-15.

Частые вопросы

Чем ASO отличается от рекламы приложения?

ASO — это органический канал: вы улучшаете карточку и получаете бесплатные установки из поиска магазина. Реклама (Apple Search Ads, Google App Campaigns) — платный трафик за каждый клик или установку. Они дополняют друг друга: реклама даёт быстрые данные о конверсии ключей, а ASO снижает стоимость установки и работает даже после остановки бюджета.

Как быстро виден результат от ASO?

Первые сдвиги по позициям появляются после переиндексации — обычно от нескольких часов до 2-3 дней. Устойчивый рост органики занимает 4-8 недель, потому что алгоритмы накапливают поведенческие сигналы: конверсию, удержание, отзывы. ASO — это итеративный процесс с обновлением метаданных каждые 4-6 недель, а не разовая настройка.

Нужно ли делать ASO на казахском языке?

Да, если вы ориентированы на казахстанскую аудиторию. Часть пользователей ищет приложения на казахском, и отдельная локаль расширяет семантическое ядро без конкуренции с русскоязычными ключами. Это даёт дополнительный охват практически бесплатно. Игнорировать казахскую локаль — значит добровольно отказаться от заметной доли органического трафика.

Можно ли продвигать в ASO плохое приложение?

Нет. Метаданные приведут трафик на карточку, но если приложение медленное, с багами или непонятным интерфейсом, пользователи будут удалять его и ставить низкие оценки. Алгоритмы магазинов используют удержание и рейтинг как факторы ранжирования, поэтому слабый продукт быстро откатится вниз. ASO усиливает хороший продукт, а не маскирует плохой.

Делаете ли вы ASO отдельно от разработки?

Да. Мы берём в работу ASO как для приложений, которые разработали сами, так и для готовых продуктов сторонних команд. Начинаем с аудита текущей карточки и семантики, затем формируем план работ и смету. Чтобы получить расчёт по вашему приложению за 24 часа, оставьте заявку или позвоните по номеру +7 (707) 928-13-15.

Сообщение Что такое ASO и как оптимизировать приложение: разбор для рынка Казахстана появились сначала на Applications.kz.