> Были ли реджекты приложений из-за скрытого функционала или дизайна? (iOS, Swift)

Короткий ответ

Да, реджекты из-за скрытого функционала или дизайна - частая практика в App Review. Apple явно запрещает скрытые или undocumented возможности, которые не очевидны пользователю или не соответствуют заявленному описанию. Это нарушает пункты 2.3.1, 2.3.2 и 2.5.2 Guidelines. Реджект может прийти как на этапе бинарника, так и после публикации, если функционал обнаружат в ходе ревью или по жалобам пользователей.

Подробное объяснение

Apple требует, чтобы все функции приложения были видны и понятны пользователю. Скрытый функционал - это:

• кодовые фразы или жесты, которые активируют недокументированные экраны или действия;
• функционал, который появляется только при определённых условиях (например, по геолокации, времени, устройству) без явного объяснения;
• скрытые покупки, подписки или реклама, не заявленные в описании;
• использование приватных API или обход ограничений платформы (например, скрытая загрузка контента).

Дизайн-реджекты связаны с тем, что интерфейс вводит в заблуждение: кнопки, которые выглядят кликабельными, но не работают; скрытые элементы управления; неочевидная навигация; элементы, которые имитируют системные (например, кнопку "Назад" или алерт).

Apple также проверяет соответствие скриншотов и описания реальному поведению. Если на скриншоте есть функция, которой нет в билде - это тоже реджект.

На практике

На практике реджекты чаще всего случаются из-за:

• A/B-тестов, которые включают функционал только для части пользователей без уведомления Apple;
• feature flags, которые выключают функционал в ревью-билде, но включают после одобрения;
• скрытых "пасхалок" или debug-меню, оставленных в релизной сборке;
• использования приватных API (например, UIPasteboard для чтения чужих данных, или private frameworks).

Apple может запросить видео, как работает функция, или потребовать убрать её. В некоторых случаях - отклонить приложение и потребовать объяснений.

Пример кода

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

SWIFT
// Плохо: скрытая активация по жесту
override func motionEnded(_ motion: UIEvent.EventSubtype, with event: UIEvent?) {
    if motion == .motionShake {
        showHiddenAdminPanel() // Apple это увидит и отклонит
    }
}

Правильный подход - не включать скрытые функции в релизный билд вообще, либо делать их явно видимыми и описанными в сторе.

Как отвечать на собеседовании

Расскажи про конкретный кейс из практики: как вы получили реджект, как диагностировали причину, какие шаги предприняли. Упомяни, что важно проверять билд на соответствие описанию и скриншотам перед отправкой. Подчеркни, что feature flags должны быть выключены в релизной сборке, а debug-меню - удалены. Если нет опыта с реджектами - опиши, как бы ты действовал: анализ письма от Apple, воспроизведение, исправление, повторная отправка.

Что проверяет интервьюер

Интервьюер проверяет:

• знание App Review Guidelines и конкретных пунктов;
• понимание разницы между скрытым функционалом и обычными фичами;
• опыт работы с реджектами и процессом их исправления;
• умение объяснять, как избежать реджектов на этапе разработки;
• способность рассуждать о trade-off между удобством пользователя и требованиями Apple.

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

• Утверждать, что Apple не может обнаружить скрытый функционал - это не так, ревьюеры используют инструменты для анализа бинарника.
• Говорить, что реджект - это всегда ошибка разработчика, иногда это политика Apple, но в контексте вопроса - да, ошибка.
• Не упоминать, что скрытый функционал может привести к бану аккаунта разработчика, а не только к реджекту.
• Путать скрытый функционал с обычной кастомизацией UI или анимацией - это разные вещи.
• Предлагать обходные пути (например, загрузка кода с сервера) - это прямое нарушение 2.5.2 и почти гарантированный реджект.