App Store Connect API 4.6: что делать, если отчёт INSTALLS перестал обновляться? 2026

Новые отчёты INSTALLS после App Store Connect API 4.6 не формируются, а исторические отчёты по-прежнему можно скачать в пределах условий Apple. Не запускайте бесконечные повторы: сначала подтвердите статус отчёта, сохраните доступную историю и разделите штатное отсутствие новых данных и техническую ошибку. Изменение API и дату выпуска Apple указывает в примечаниях к App Store Connect API 4.6 и на странице выпуска.

Эта инструкция пригодится разработчикам, которые поддерживают автоматическое скачивание отчётов App Store Connect и должны отличать изменение их жизненного цикла от проблем с доступом, сетью или скриптом.
Она также адресована инженерам, отвечающим за macOS CI и за дашборды, где пропуск файла может исказить историю или вызвать ложное уведомление.

Последняя проверка — 7 ноября 2026 года; дата выпуска сверена со страницей Apple, а сведения о запросах и доступности — с документацией по отчётам и описанием доступности Sales and Trends. При обновлении Apple этих материалов проверьте выводы повторно.

Почему INSTALLS перестал обновляться, а задача всё ещё запускается

App Store Connect API 4.6 — не просто очередное изменение версии, которое можно нейтрально обработать обновлением клиента. В документации Apple для этой версии указано изменение статуса отчётов INSTALLS: новые отчёты больше не создаются. Существующие исторические файлы при этом не следует считать автоматически удалёнными или недоступными: Apple отдельно описывает доступность отчётов и условия их получения. Проверяйте эти два утверждения по отдельности, а не делайте вывод по одному пустому ответу.

Это различие важно, потому что работающий планировщик не гарантирует, что источник данных продолжает выпускать новые файлы. Задача может успешно проснуться по расписанию, подключиться к API и записать результат, который означает «нового отчёта нет». Если логика трактует любой такой результат как временную ошибку, CI будет повторять запрос, шуметь в оповещениях и расходовать ресурсы, хотя сам отчёт уже не формируется.

Вместе с тем изменение жизненного цикла отчёта не оправдывает любые ошибки. Истёкшие или неправильно настроенные учётные данные, недостаточный доступ, некорректные параметры запроса, сетевые сбои и регрессия парсера остаются самостоятельными причинами неудачи. Сверьте фактическую цель запроса и параметры с описанием API для получения Sales and Trends reports, а требования к доступу — с руководством Apple по App Store Connect API.

Практическая проверка должна ответить на несколько отдельных вопросов:

• Отправляет ли задача запрос именно за INSTALLS, или после изменения конфигурации она стала запрашивать другой тип отчёта?
• Сохранились ли параметры, идентификаторы приложения и разрешения, необходимые для чтения данных?
• Получил ли скрипт ответ от API, и как именно он был классифицирован: нет нового отчёта, отказ в доступе, ошибка запроса или проблема соединения?
• Не превращает ли обработчик пустой результат в «файл с нулевыми установками»?
• Не продолжает ли планировщик повторять заведомо бесполезную операцию без условия остановки?

Последний пункт особенно легко упустить: задача может выглядеть как проблема macOS CI, хотя сама macOS-машина доступна, а несовместимость возникает между ожидаемым результатом скрипта и фактическим состоянием отчёта.

Сначала проверьте поведение, затем выбирайте реакцию

Используйте этот список перед тем, как менять расписание или объявлять инцидент. Отмечайте только то, что подтверждено логами или проверкой запроса, а не предположениями по графику.

• [ ] Зафиксируйте версию API и конфигурацию запроса, которыми пользуется задача.
• [ ] Подтвердите, что запрашивается именно INSTALLS, и проверьте параметры по документации Apple.
• [ ] Сверьте ожидаемое поведение отчёта с примечаниями к API 4.6 и страницей доступности Sales and Trends.
• [ ] Проверьте, получил ли клиент ответ, и сохраните исходные сведения о запросе и результате с учётом правил обращения с секретами.
• [ ] Убедитесь, что код различает отсутствие нового файла и сбой авторизации, соединения, запроса или разбора.
• [ ] Проверьте, не попало ли отсутствие отчёта в базу как нулевое значение.
• [ ] Отключите автоматические повторы для подтверждённого штатного отсутствия нового INSTALLS-файла.
• [ ] Отдельно проверьте скачивание доступного исторического отчёта и обработку некорректного ответа.

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

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

Дашборд должен отличать отсутствие данных от нулевого значения

Когда загрузчик перестаёт получать новые файлы, риск переносится из CI в аналитику. Наиболее опасный вариант — присвоить установкам значение «0», если отчёт отсутствует. Ноль означает измеренное значение, а отсутствие файла — что данных за этот период нет. Если смешать эти состояния, линия графика может показать искусственное падение, а расчёты конверсии и оповещения начнут описывать не поведение пользователей, а изменение доступности отчёта.

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

Проверьте весь путь значения, а не только интерфейс:

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

Также выясните, какие потребители используют INSTALLS косвенно: ежедневные сводки, отчёты для продуктовой команды, сравнительные графики или внутренние выгрузки. Исправленный экран не решает проблему, если downstream-задача продолжает трактовать пропущенную строку как ноль. Для определения смысла показателей ориентируйтесь на официальные определения метрик App Store Connect, а не на названия колонок в собственном дашборде.

Не выводите из остановки INSTALLS вывод об остановке всех метрик установок или всех отчётов App Store Connect. Сверяйте определение каждого источника и его доступность отдельно: похожее название не означает одинаковую методику или одинаковый период обновления.

Исторические файлы требуют собственного архива

Возможность скачать исторические данные и автоматическое хранение вашей копии — разные вещи. Доступность файла через API зависит от условий Apple, типа отчёта и периода, который ещё можно запросить; прежний успешный запуск не доказывает, что тот же файл будет всегда доступен. Поэтому, если INSTALLS нужен для воспроизводимой аналитики, не полагайтесь только на возможность повторно получить его из App Store Connect.

Сначала определите, какие периоды уже сохранены локально или в хранилище команды. Для каждого файла зафиксируйте идентификатор отчёта, приложение, временной интервал, дату получения и результат проверки целостности. Затем сверяйте перечень сохранённых данных с тем, что ещё можно запросить по правилам доступности Sales and Trends. Не обещайте бизнес-заказчикам полное восстановление истории, пока не проверили фактические файлы.

Рекомендуемый порядок переноса в архив:

• Составьте перечень уже загруженных файлов и периодов, за которые отчёты отсутствуют.
• Попробуйте запросить доступные исторические данные согласно документации и зафиксируйте не только успешные, но и неуспешные периоды.
• Сохраните исходные файлы отдельно от нормализованных таблиц, чтобы последующая смена парсера не уничтожила первичные данные.
• Проверьте, что архивная копия доступна команде, резервируется и не зависит от временного каталога CI-агента.
• Добавьте в описание набора данных границу между последним полученным отчётом и периодами, для которых свежих INSTALLS уже нет.

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

Замена INSTALLS требует проверки смысла, а не похожего названия

Запрос на «другой показатель вместо INSTALLS» сначала нужно перевести в конкретную бизнес-задачу. Требуются ли вам события установки, сведения о пользовательском привлечении, использование приложения или оценка поведения пользователей? Это разные вопросы. Показатель с похожей подписью не становится заменой, пока не совпадают определение, область охвата, правила учёта и период получения.

Apple публикует разные материалы по аналитическим отчётам и метрикам. Например, отдельно описаны отчёт об установках и удалениях приложений и Platform App Installs. По самим названиям нельзя заключить, что один из них является прямым продолжением или эквивалентом INSTALLS из Sales and Trends. Прежде чем менять показатель в отчёте, прочитайте определения и проверьте, доступен ли нужный набор вашей команде в соответствующем интерфейсе и с подходящими правами.

Для оценки кандидата зафиксируйте:

• Что именно измеряет метрика и какое событие считается основанием для учёта.
• Как она соотносится с периодом, платформой и сегментами, на которых строился прежний отчёт.
• Можно ли получить историю и с какой даты она фактически начинается.
• Как меняются группировки, фильтры и трактовка отсутствующих значений.
• Подтверждена ли пригодность в вашей аналитической задаче, а не только возможность технически скачать данные.

До проверки помечайте новый показатель как отдельную метрику. Не склеивайте его со старым рядом и не пересчитывайте исторические значения так, словно методика не менялась. Если команда использует отчёт для сравнения периодов, добавьте пояснение о разрыве в методологии. Это честнее, чем создать бесшовный график, который выглядит убедительно, но сравнивает разные определения.

Как адаптировать macOS CI без бесполезных повторов

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

Начните с разделения обработки результата на понятные ветви. Штатное отсутствие нового отчёта должно завершать конкретную попытку без повторов, но оставаться видимым в журнале и статусе мониторинга. Ошибка доступа должна направлять инженера к проверке роли и ключа. Ошибка запроса — к параметрам и формату. Сетевую нестабильность можно обрабатывать по правилам вашей инфраструктуры, но только когда журнал действительно показывает временную проблему соединения. Не объединяйте все варианты в условие «файл не найден — повторить».

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

Проведите проверку двумя отдельными сценариями:

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

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

Если для автоматизации нужны дополнительные рекомендации по эксплуатации удалённой машины, на странице руководств UDPMac можно подобрать материалы по работе с удалённой средой. При этом App Store Connect API сам по себе не требует запуска на Mac: выбирайте платформу по фактическим зависимостям задачи, а не по названию отчёта.

Сравните варианты обработки и оцените риски

Ниже приведена качественная инженерная оценка, а не статистика Apple. «Высокая» означает, что вариант хорошо защищает корректность данных при условии правильной реализации; она не является обещанием доступности самого отчёта.

• Оставить прежний загрузчик с повторами. Защита от ложного нуля — низкая, шум в CI — высокий, пригодность для новых INSTALLS — отсутствует. Такой подход лишь повторяет прежнее ожидание, не меняя состояния источника, и может затруднить поиск настоящих ошибок.
• Считать отсутствие файла нулём. Защита дашборда от неверной интерпретации — низкая. Это самый рискованный путь для продуктовой аналитики: штатное отсутствие данных становится измеренным падением.
• Сохранить историю и отдельно маркировать отсутствие новых данных. Защита исторического ряда — высокая, прозрачность для команды — высокая. Потребуется поправить схему хранения и визуализацию, зато исчезновение новых точек не маскируется под нулевое значение.
• Подменить INSTALLS похожей метрикой без валидации. Сопоставимость — низкая, риск ошибочных сравнений — высокий. Используйте новый источник отдельно, пока не сверены определения и не подтверждена пригодность для нужного решения.
• Разделить проверку истории и реакцию на новый запуск. Диагностическая ценность — высокая. Такой вариант помогает сохранить рабочее чтение архива и одновременно исключить повторы, которые не могут создать отсутствующий отчёт.

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

Когда арендованный Mac помогает, а когда нет

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

Аренда удалённого Mac от UDPMac может быть удобнее, если вам нужен постоянно доступный macOS-узел для соседних задач: например, для процессов, связанных с Xcode, подписанием или другими инструментами, которых нет в вашей Linux-среде. В этом случае можно централизовать расписание, хранение рабочих файлов и проверку журналов на отдельной машине, не покупая физический Mac. Варианты удалённого доступа и размещения стоит соотнести с вашей сетью и требованиями команды; описание инфраструктурных вариантов есть на странице центров обработки данных UDPMac.

Но аренда Mac не возвращает генерацию INSTALLS и не является обязательным условием для запросов App Store Connect. Если ваши скрипты переносимы, CI уже надёжен, а macOS-специфичных задач нет, разумнее оставить их на текущей платформе. Если же вам нужен временный или отдельный macOS-узел для связанных процессов, оцените варианты удалённого Mac от UDPMac по реальным требованиям к доступу, хранению и сопровождению, сохраняя изменения отчёта и состояние источника раздельными понятиями.

Часто задаваемые вопросы