Перед первой публикацией разработанного мной приложения WeCount я был уверен, что главная причина возможного отказа — ошибки в коде или проблемы в пользовательских сценариях. На практике оказалось наоборот: за всё время App Review к функциональности приложения не возникло ни одного вопроса. Почти все замечания касались исключительно регистрации пользователя.
За два месяца переписки, нескольких отказов подряд и телефонных разговоров с командой App Review, этап регистрации был полностью переписан. В этой статье я расскажу, какие выводы сделал, и почему первоначальная архитектура оказалась ошибочной.
Cтатья не является универсальной инструкцией по прохождению App Review. Требования Apple могут меняться, а описанный опыт относится к одному конкретному приложению. Однако надеюсь, что мой путь поможет другим разработчикам избежать хотя бы части тех ошибок, которые допустил я.
Что мы строили
WeCount — приложение для учёта расходов в совместных поездках или походах компанией в ресторан, когда нужно посчитать, кто за что заплатил и кто кому сколько должен перевести.
Пользователь создаёт событие, добавляет в него друзей из своей адресной книги, а затем участники вносят чеки и распределяют расходы между собой. Приложение рассчитывает итоговый баланс и показывает, кто и кому должен перевести деньги, чтобы закрыть все взаимные расчёты.
Поскольку приложение многопользовательское, его участники должны находить друг друга. В качестве уникального идентификатора я выбрал номер телефона.
Это выглядело естественным решением: друзья уже есть в телефонной книге, поэтому приложение могло быстро находить их и добавлять в совместные события.
Именно вокруг этой идеи была построена первоначальная регистрация. Как позже выяснилось, именно она стала причиной основных проблем при прохождении App Review.
Первая версия регистрации. Почему она казалась правильной
Первая версия регистрации казалась мне практически идеальной.
После ввода номера телефона сервер отправлял Push‑уведомление с кодом подтверждения на устройство пользователя. После ввода этого кода регистрация завершалась.
Такой подход выглядел быстрее и удобнее классического подтверждения по SMS, которые иногда приходят с задержкой. Кроме того, стоит это дороже, чем отправка Push.
Логика казалась простой: если пользователь получил Push с кодом и успешно его ввёл, значит он точно владеет устройством, на котором зарегистрирован указанный номер телефона. Для моего сценария этого казалось более чем достаточно.
Поэтому, когда App Review отклонил приложение, я даже не подумал, что проблема в самой идее регистрации. Мне казалось, что ревьюеры просто не поняли архитектуру, и достаточно подробно объяснить, как всё устроено.
В замечании App Review также говорилось, что пользователь может не согласиться на получение Push‑уведомлений. Я сделал очевидный, как мне тогда казалось, вывод: проблема не в подтверждении номера телефона, а в зависимости регистрации от Push. Значит, нужно добавить альтернативный канал.
Добавляем e‑mail как альтернативный канал
Решение выглядело очевидным: если Push недоступен, необходимо предусмотреть другой способ подтверждения.
Я быстро реализовал подтверждение через e‑mail, попутно исправил несколько мелких проблем с ручным вводом кода, и снова отправил приложение на проверку.
Пришёл отказ.
Затем ещё несколько подряд.
Несмотря на это, я всё ещё был уверен, что проблема не в самой регистрации, а в том, что App Review неправильно понимает архитектуру приложения.
Push и e‑mail не являлись идентификаторами пользователя и не участвовали в модели данных. Это были лишь временные каналы подтверждения номера телефона.
Мне казалось, что осталось только найти способ объяснить это ревьюерам.
Неожиданности во время проверки
После нескольких одинаковых отказов с шаблонными ответами стало понятно, что переписка ни к чему не приводит. Мне перестало хватать предположений о том, что именно происходит во время проверки.
Тогда я решил посмотреть на процесс глазами App Review и добавил подробное серверное логирование.
Результаты оказались неожиданными.
Во‑первых, Push‑уведомления были намеренно отключены. Ревьюеры просто отклоняли системный запрос на их получение. Сразу стало понятно, почему Apple так настойчиво указывала, что регистрация не должна зависеть от Push.
Во‑вторых, в качестве адреса электронной почты использовался test@test.com. Стало очевидно, что e‑mail не рассматривается как реальные контактные данные пользователя, а служит лишь техническим способом пройти сценарий регистрации. Я зарегистрировал для ревьюеров специальный почтовый ящик и добавил данные для входа в описание билда.
Именно тогда я впервые задумался, что App Review проверяет вовсе не конкретную реализацию регистрации. Скорее, они сознательно моделируют ситуации, в которых приложение не должно зависеть от доступности того или иного канала связи.
Но тогда я ещё не понимал, к какому выводу меня приведёт эта мысль.
Что же на самом деле проверял App Review
Чтобы прекратить затянувшуюся переписку, я договорился о телефонном разговоре с руководителем команды App Review.
Я подробно рассказал об архитектуре приложения, объяснил, почему в качестве идентификатора выбран номер телефона и какую роль играют Push и e‑mail.
Разговор занял всего несколько минут. Практически по всем вопросам мы пришли к согласию. Руководитель подтвердил, что основной сущностью действительно является номер телефона, а Push и e‑mail — лишь вспомогательные способы подтверждения. Из разговора я вышел практически уверенным, что следующий билд наконец пройдёт проверку.
Но пришёл очередной отказ.
Именно тогда стало понятно, что мы с App Review говорили об одном и том же, но делали разные выводы.
Да, Push и e‑mail действительно не являются основными сущностями приложения. Но именно поэтому они вообще не должны использоваться как способ подтверждения номера телефона.
Более того, я наконец увидел главную проблему своего решения. Ни Push, ни e‑mail не подтверждали владение самим номером телефона. Пользователь мог указать любой номер (в том числе чужой), а затем успешно пройти подтверждение через Push или e‑mail на своём устройстве.
Получалось, что подтверждался канал связи, но не тот идентификатор, который приложение использовало как основную сущность пользователя. Именно это, как я теперь понимаю, и пытался донести App Review с самого начала.
Финальная версия
После этого регистрация была полностью переписана. Из неё исчезли Push и e‑mail как способы подтверждения.
Остались только два варианта, которые действительно подтверждали владение номером телефона:
SMS с кодом;
звонок на бесплатный номер.
На этот раз я был уверен, что регистрация полностью соответствует той логике, которой придерживается App Review.
Но отказ пришёл снова.
Причина оказалась неожиданной. Аккаунты App Review были привязаны к реальным телефонным номерам, однако принимать SMS и совершать или принимать звонки с этих номеров было невозможно. Получалось, что пройти регистрацию обычным способом ревьюеры физически не могли.
После ещё одного телефонного разговора мы нашли решение. Для App Review был добавлен специальный демонстрационный режим, позволяющий пройти регистрацию без использования недоступных им каналов подтверждения. При этом обычная регистрация для пользователей осталась без изменений.
После этого приложение наконец прошло проверку.
Выводы
До прохождения App Review мне казалось, что Apple в первую очередь оценивает работоспособность приложения и удобство пользовательских сценариев.
На практике оказалось иначе. Основной интерес вызвала не функциональность приложения, а то, насколько архитектура регистрации соответствует принципам Apple в отношении идентификации пользователя и минимизации собираемых данных.
Главный вывод, который я сделал: не стоит воспринимать замечания App Review буквально. Одно сообщение редко описывает проблему целиком. Если исправлять каждое замечание по отдельности, можно несколько раз переписать код и всё равно получать отказы. Намного важнее понять принцип, которым руководствуется App Review, отклоняя приложение.
Второй вывод оказался не менее важным. App Review — то не противостояние разработчика и Apple. Телефонные разговоры показали, что ревьюеры готовы обсуждать архитектуру и объяснять свою позицию. Проблема чаще возникает не из‑за нежелания помочь, а из‑за того, что короткие шаблонные комментарии легко трактовать неверно. На прохождение этого процесса у меня ушло больше двух месяцев и несколько последовательных отказов.
Если мой опыт поможет кому‑то избежать хотя бы части этих ошибок, значит, эта статья была написана не зря.
