Проверка приложений Apple, которая обычно занимает один-два дня, у части разработчиков растянулась на три-четыре недели. Для команд, выпускающих новые продукты или срочные исправления, это уже не мелкая операционная помеха, а риск сорвать релиз, рекламную кампанию и обещания клиентам — знакомая проблема и для российских команд, работающих на мировой рынок.
На форумах Apple Developers множатся сообщения с одинаковым сюжетом: приложение надолго остаётся в статусе ожидания проверки. Разработчики называют сроки в несколько недель; компания D1 Tech, например, пишет, что ждёт с 19 сентября. О похожем опыте сообщают и участники Reddit. Об этом пишет The Register.
Контраст особенно заметен на фоне собственных ориентиров Apple. В правилах App Review компания указывает, что не менее 50% отправленных сборок обычно проверяются менее чем за 24 часа, а 90% — менее чем за 48 часов. Формально это не гарантия для каждого конкретного приложения, но разница между двумя днями и почти месяцем слишком велика, чтобы списать её на обычную выборочную проверку.
Задержки касаются не только дебютантов App Store. В аналогичной ветке жалоб в феврале как минимум 74 разработчика писали о многонедельном ожидании, причём часть из них отправляла не новое приложение, а обновления уже опубликованных продуктов с исправлениями ошибок. Для бизнеса это неприятнее, чем задержка запуска: баг может быть найден после выкладки, поддержка уже получает обращения, а исправленная версия лежит в очереди без понятного срока выхода.
Apple пока публично не объяснила, почему образовалась очередь. The Register запросил комментарий у компании, но на момент публикации ответа не получил. В марте Business Insider связывал похожие задержки с быстро растущим потоком приложений, созданных с применением ИИ. В апреле The Information сообщало, что число отправок выросло на 84%. Эти сообщения не доказывают причину нынешней пробки, но описывают вполне правдоподобную нагрузку: генеративные инструменты снижают цену создания первой версии приложения, а App Review всё равно должна проверять безопасность, приватность, платежи, контент и соблюдение правил площадки.
Ускорение разработки здесь играет против инфраструктуры публикации. Один разработчик с ИИ-помощником способен быстро собрать несколько вариантов одного сервиса, шаблонный клиент для очередной ниши или приложение с минимальными отличиями от уже существующих. Автоматизация может отсеять часть однотипных нарушений, но спорные случаи и жалобы пользователей по-прежнему требуют ручной работы. Если входящий поток действительно растёт быстрее пропускной способности модерации, очередь будет бить прежде всего по обычным командам, а не только по создателям одноразовых приложений.
Для мобильных команд это повод пересмотреть календарь релизов. Проверка приложений Apple перестаёт быть коротким финальным этапом, который можно заложить между пятничным мерджем и понедельничным запуском. Обновления с критичными исправлениями стоит готовить раньше, а маркетинговые даты — не привязывать жёстко к отправке сборки в App Store. Отдельно полезно держать серверные переключатели функций: они не заменят обновление клиента, но позволят выключить проблемный сценарий или не включать недоделанную возможность до прохождения ревью.
Проблема затрагивает и продактов. Если исправление зависит от новой версии приложения, поддержку, партнёров и клиентов лучше заранее снабдить понятным планом: временным обходом, сроком следующей коммуникации и объяснением ограничений. Молчаливый статус ожидания в консоли разработчика плохо сочетается с обещанием «починим к вечеру». Для B2B-продуктов, где приложение — лишь один из каналов доступа, полезно заранее продумать веб-альтернативу для критичных операций.
Apple строит App Store на обещании контролируемого качества и безопасности, поэтому полностью убрать проверку ради скорости компания вряд ли захочет. Но если недельные задержки станут нормой, площадке придётся объяснить разработчикам правила очереди и показать, как она масштабирует App Review. Иначе проверка приложений Apple превратится из защитного барьера в непредсказуемый узкий канал, который команды будут учитывать так же внимательно, как лимиты API и сбои облачной инфраструктуры.
