Приложение готово, дизайн утверждён, тестирование пройдено, и вы отправляете сборку в App Store. Проходит день-два, и на почту приходит письмо: «Your app has been rejected». Для заказчика это неприятный сюрприз, для команды - дополнительная работа и сдвиг сроков запуска, который иногда совпадает с уже оплаченной рекламой или анонсом. Хорошая новость в том, что причины отказов в подавляющем большинстве случаев типовые, предсказуемые и устранимые, а значит, их можно закрыть заранее.
В этой статье мы разберём самые частые причины, по которым Apple отклоняет приложения, объясним, что на самом деле стоит за формулировками в письме, как действовать после отказа и что проверить до отправки, чтобы пройти проверку с первого раза. Отдельно остановимся на особенностях, важных для проектов в Казахстане, - оплате, логинах и описании для проверяющих.
Важная оговорка: правила App Review Guidelines Apple регулярно обновляет, и конкретные требования со временем меняются. Поэтому, готовясь к публикации, всегда сверяйтесь с актуальной версией руководства на сайте Apple для разработчиков.
Как работает проверка и почему отказ - это нормально
Каждое приложение перед публикацией проходит проверку App Review: сотрудники Apple, а в части случаев и автоматические инструменты, устанавливают сборку на реальные устройства, проходят основные сценарии и сопоставляют приложение с правилами магазина. Проверяющий не знает вашего продукта, у него нет времени разбираться в нюансах, поэтому он ведёт себя как внимательный, но нетерпеливый новый пользователь: если что-то не открывается, не понятно или противоречит правилам, он отклоняет сборку и называет пункт руководства, который нарушен.
Отказ - не приговор и не оценка качества вашей работы. Это нормальная часть процесса, особенно для первой версии. Данные о доле отклонённых приложений в разных обзорах расходятся: источники называют цифры от четверти до заметно более трети первых отправок, так что единой надёжной величины нет. Важнее другое: по данным обзоров, опирающихся на отчёты Apple о прозрачности, чаще всего приложения отклоняют из-за проблем с работоспособностью и полнотой (пункт 2.1 руководства), а затем из-за вопросов приватности и юридических требований. То есть самые частые причины - не экзотические нарушения, а вполне заурядные недоработки, которые можно найти и исправить до отправки.
Приложение нестабильно или не завершено
Самая распространённая причина отказа - приложение просто не работает так, как должно, в момент проверки. Это падения при запуске или в основных сценариях, битые ссылки, пустые экраны, кнопки, которые ничего не делают, и оставленные заглушки вроде «Lorem ipsum» или тестового текста. Apple ожидает, что в магазин попадёт завершённый продукт, а не черновик, и проверяющий отклонит сборку при первых же признаках незавершённости.
Чтобы избежать этого, тестируйте приложение так, как будет тестировать проверяющий: на реальных устройствах, на разных версиях iOS и размерах экрана, включая iPad, если приложение его поддерживает, и при разном качестве интернета. Удалите все заглушки и временный контент, проверьте каждую ссылку и каждую кнопку. Особенно рискованны функции, которые зависят от сервера: если ваш тестовый сервер недоступен или медленно отвечает в момент проверки, приложение будет выглядеть сломанным. Убедитесь, что серверная часть работает стабильно и во время проверки не будет отключена на обслуживание.
Нет демо-доступа для проверяющего
Типичная ошибка для приложений с личным кабинетом: проверяющий открывает экран входа, а войти ему нечем. Он не знает ваших клиентов и не может зарегистрироваться, если регистрация требует подтверждения по SMS на казахстанский номер или одобрения менеджера. В результате он не видит основную функциональность и отклоняет сборку, ссылаясь на невозможность проверить приложение.
Решение простое, но о нём часто забывают: подготовьте рабочий демо-аккаунт и укажите его данные в специальном поле App Store Connect для заметок проверяющему. Убедитесь, что аккаунт активен, у него есть тестовые данные, а сервер не блокирует вход из другой страны, потому что проверяют приложение не в Казахстане. Если часть функций требует особых условий, например оплаты, оборудования или местоположения, объясните в заметках, как проверяющему увидеть эти функции, или предоставьте видео с демонстрацией. Чем яснее вы опишете, что делает приложение и как его проверить, тем меньше вопросов возникнет.
Приложение слишком простое: «обёртка» над сайтом
Apple не любит приложения, которые, по сути, представляют собой открытый в окне сайт, одну статичную страницу или документ без собственной ценности. Правило о минимальной функциональности (пункт 4.2) требует, чтобы приложение давало пользователю что-то, чего нельзя получить просто открыв сайт в браузере. Если ваше приложение - это веб-версия в оболочке без нативных возможностей, оно рискует не пройти проверку.
Если у вас уже есть сайт и вы хотите превратить его в приложение, продумайте, какую дополнительную ценность даёт мобильный формат: push-уведомления, работа с камерой или геолокацией, офлайн-доступ, личный кабинет, интеграция с функциями устройства, удобная навигация, специально разработанная для телефона. Если всё это не нужно, возможно, вам достаточно PWA, о котором мы писали в отдельной статье, и платить за публикацию в магазине нет смысла.
Приватность и персональные данные
Вопросы приватности - вторая по частоте причина отказов, и требования Apple здесь строгие. Если приложение собирает какие-либо данные, в App Store Connect должна быть ссылка на политику конфиденциальности, которая действительно открывается и описывает, какие данные собираются, зачем и как используются. Заполненные «пищевые этикетки» приватности (описание того, какие данные собирает приложение) должны соответствовать реальности: проверяющий и автоматические проверки сопоставляют декларацию с тем, что делает приложение.
Каждое разрешение, которое запрашивает приложение, - доступ к камере, геолокации, контактам, фото, уведомлениям - должно сопровождаться понятным объяснением, зачем оно нужно. Расплывчатые формулировки вроде «приложению нужен доступ» ведут к отказу. Запрашивайте только то, что действительно необходимо для работы функции, и в момент, когда она понадобится, а не всё сразу при запуске. Не передавайте данные пользователей сторонним сервисам, о которых не сказано в политике. Если приложение работает с данными граждан Казахстана, учитывайте и требования местного законодательства о персональных данных, о которых мы писали в отдельной статье.
Платежи и встроенные покупки
Правила оплаты - источник многих отказов, потому что они не всегда очевидны. Общее правило Apple: если вы продаёте цифровые товары или услуги внутри приложения - подписки, доступ к контенту, виртуальные бонусы, дополнительные функции, - вы обязаны использовать встроенные покупки Apple (In-App Purchase, пункт 3.1.1), а не собственную платёжную систему или перенаправление на сайт для оплаты.
При этом для физических товаров и услуг, которые предоставляются вне приложения, действует другое правило. Если ваше приложение продаёт одежду, еду, доставку или заказ такси, оплату можно принимать через сторонние платёжные способы: Kaspi Pay, банковские карты и другие. Именно это делает возможным типичный бизнес казахстанских приложений вроде интернет-магазинов, доставки и такси. Ошибка возникает на границе: приложение продаёт «доступ к курсу» или «премиум-подписку» через внешнюю оплату, и проверяющий расценивает это как обход встроенных покупок. Заранее определите, что именно вы продаёте, и выберите допустимый для этого тип платежа. Об особенностях онлайн-оплаты мы подробно писали в статье про Kaspi Pay и другие платёжные системы.
Вход через аккаунты и удаление аккаунта
Две группы требований касаются регистрации и входа. Первая: если приложение позволяет пользователю создать аккаунт, то в нём должна быть возможность удалить этот аккаунт и связанные с ним данные прямо из приложения, без необходимости писать на почту или звонить в поддержку. Многие команды упускают это требование, и приложение отклоняют уже при первой отправке. Реализовать удаление нужно заранее, вместе с логикой хранения и удаления данных на сервере.
Вторая группа связана со входом через сторонние сервисы. Если приложение предлагает вход через Google, Facebook или другие внешние аккаунты, Apple требует предложить также равноценный вариант входа с защитой приватности, например «Вход через Apple». Условия этого требования Apple уточняет, поэтому проверьте актуальную формулировку в руководстве. Простейшее решение - предложить вход по номеру телефона или e-mail, если не планируется интеграция с внешними аккаунтами.
Ask a question or leave a request
Проверим сборку по требованиям App Review, подготовим демо-доступ, политику конфиденциальности и карточку в App Store, чтобы пройти проверку с первого раза.
By submitting the form, you agree to the processing of personal data.
Метаданные: описание, скриншоты, иконка
Карточка приложения в магазине тоже проверяется. Описание, скриншоты и иконка должны точно отражать то, что приложение делает. Скриншоты не должны показывать функции, которых нет, или вводить в заблуждение, а описание - содержать упоминания других платформ, ссылки на конкурентов и непроверяемые заявления вроде «лучшее приложение в мире». Размер и формат скриншотов нужно подготовить для всех поддерживаемых устройств.
Название и иконка не должны копировать чужие бренды или использовать чужие торговые марки без права: по свежим обзорам правил, Apple ужесточила требования к тому, чтобы приложение не использовало бренд другого разработчика в названии или иконке. Не оставляйте в карточке тестовый или недописанный текст, и если приложение требует особых условий для работы, например конкретного оборудования, укажите это. Подробный разбор подготовки материалов публикации есть в нашем чек-листе для App Store и Google Play.
Контент, созданный пользователями
Если в приложении пользователи могут публиковать контент - комментарии, фото, отзывы, сообщения, - Apple требует инструменты модерации. Нужны способ пожаловаться на контент, возможность заблокировать другого пользователя, фильтрация недопустимого содержимого и понятные условия использования. Приложение без этих механизмов отклоняют, потому что оно может стать площадкой для нежелательного контента.
Это касается не только соцсетей, но и маркетплейсов, чатов, форумов и платформ с отзывами. Если вы создаёте платформу такого типа, как маркетплейс или приложение такси с отзывами, заложите модерацию на этапе проектирования, о чём мы подробно писали в статьях про маркетплейс и такси. Сроки реагирования на жалобы и контакт для обращений тоже стоит продумать заранее.
Копии, шаблонные и похожие приложения
Apple отклоняет приложения, которые копируют другие, и так называемый «спам»: множество почти одинаковых приложений от одного разработчика, собранных из одного шаблона с разными названиями. Если вы разрабатываете приложения для нескольких клиентов на основе общего шаблона, учитывайте это: у каждого приложения должна быть собственная ценность, уникальный контент и собственный бренд, а не просто смена логотипа.
Для студий это значимый риск. Если вы публикуете от одного аккаунта разработчика множество схожих приложений, проверяющий может посчитать их спамом. Решение - делать для каждого клиента отдельный аккаунт разработчика на его компанию, что мы советуем и по другим причинам: так клиент сохраняет контроль над своим продуктом, а риск блокировки одного приложения не затрагивает остальные.
ИИ и сторонние сервисы
Если в приложении используются внешние сервисы искусственного интеллекта, рекламные и аналитические библиотеки, это нужно отражать в декларации приватности. По обзорам обновлений правил, начиная с конца 2025 года Apple требует, чтобы приложения, которые передают персональные данные внешним сервисам ИИ, чётко сообщали пользователю, какому провайдеру и какие данные передаются, и получали согласие до такой передачи. Если вы встраиваете чат-бота или другие ИИ-функции, как в статье про ИИ-чат-ботов для бизнеса, предусмотрите такое уведомление.
То же относится к любым сторонним SDK: каждая подключённая библиотека может собирать данные, а ответственность за соответствие правилам несёте вы как разработчик. Перед публикацией составьте список всех подключённых сервисов и убедитесь, что они отражены в политике конфиденциальности и в декларации приватности.
Что делать, если пришёл отказ
Прежде всего, не паникуйте и внимательно прочитайте сообщение в Resolution Center в App Store Connect. В нём указан номер пункта руководства и описание нарушения, а иногда - скриншоты. Часто причина оказывается проще, чем кажется на первый взгляд: нужен демо-аккаунт, пояснение к разрешению или ссылка на политику конфиденциальности.
Если вы согласны с замечанием, исправьте проблему и отправьте новую сборку, при необходимости ответив проверяющему в Resolution Center с пояснением, что именно изменено. Если считаете, что отказ ошибочен, ответьте спокойно и по фактам, сославшись на конкретные пункты правил, без эмоций, а при необходимости можно подать апелляцию в совет по рассмотрению приложений. Для сложных случаев есть возможность обратиться к службе поддержки разработчиков Apple. Важно исправлять причину системно: приложение, отклонённое несколько раз за схожие нарушения, может подвергаться более пристальной проверке при последующих отправках.
Особенности для проектов в Казахстане
Для казахстанских приложений есть несколько типичных точек риска. Проверяющий находится не в Казахстане, поэтому всё, что завязано на местные условия, должно быть объяснено: SMS на казахстанские номера, привязка к конкретному городу, геолокация, оплата Kaspi Pay. Подготовьте демо-доступ, который работает без местного номера и местоположения, либо подробно опишите в заметках, как проверить функции.
Продумайте языки: интерфейс на казахском и русском должен быть полностью проработан, без обрывков непереведённого текста и сломанной вёрстки. Метаданные в карточке тоже лучше проверить на ошибки, особенно если вы заполняете несколько локализаций. И, наконец, заранее определите тип платежа в зависимости от того, что вы продаёте: цифровые подписки идут через встроенные покупки Apple, а физические товары и услуги, такие как доставка или такси, можно оплачивать внешними способами. Общий путь от идеи до релиза описан в нашей статье об этапах разработки мобильного приложения, а если вы ещё выбираете подход к созданию, загляните в материал о бесплатном создании приложения.
Чек-лист перед отправкой
- Приложение протестировано на реальных устройствах и версиях iOS, нет падений и битых ссылок
- Удалены заглушки, тестовые тексты и недоделанные экраны
- Серверная часть стабильна и будет доступна на время проверки
- Подготовлен рабочий демо-аккаунт, данные указаны в заметках для проверяющего
- Для особых функций (оплата, оборудование, местоположение) есть пояснение или видео
- Приложение даёт ценность сверх обычного сайта, а не просто открывает веб-страницу
- Политика конфиденциальности доступна по ссылке и соответствует реальному сбору данных
- Декларация приватности заполнена верно, все сторонние SDK и ИИ-сервисы учтены
- Каждое запрашиваемое разрешение сопровождается понятным объяснением
- Тип оплаты соответствует продаваемому: цифровое - через встроенные покупки, физическое - допустимыми способами
- Реализовано удаление аккаунта из приложения, если есть регистрация
- Если есть вход через внешние аккаунты, предусмотрен равноценный вариант
- Для пользовательского контента есть жалоба, блокировка и модерация
- Скриншоты, описание, название и иконка точны и не нарушают чужих прав
- Актуальная версия руководства App Review Guidelines сверена перед отправкой