Сборка iOS устанавливается на одном тестовом iPhone, но отклоняется на другом: как проверить, что причина в профиле provisioning, а не в несовместимости версии iOS?
Нужно установить на оба устройства один и тот же артефакт, проверить совместимость версии iOS с параметрами сборки, а затем сопоставить идентификатор второго устройства с профилем provisioning. Если версия iOS поддерживается, но устройство не входит в профиль или его профиль просрочен, причина находится в code signing, а не в совместимости ОС.
Code signing появился в iOS как механизм доверия к исполняемому коду и контроля способов его распространения. Мобильная ОС должна отличать приложение, подписанное доверенным разработчиком, от произвольного кода, а разработчик — ограничивать установку тестовой сборки зарегистрированными устройствами.
Provisioning profile связывает идентификатор приложения, сертификат подписи, разрешённые устройства и набор entitlements. Для App Store-сборок действует другая модель распространения: устройство обычно не перечисляется в профиле так, как для development или ad hoc-сборок.
Одинаковое сообщение об ошибке установки может быть следствием разных причин: устройство не включено в профиль, профиль или сертификат истёк, не совпадает идентификатор приложения, либо сборка требует более новую версию iOS. Эти причины требуют разных исправлений, поэтому повторная сборка без диагностики не доказывает источник сбоя.
Ошибка в проверке совместимости приводит к ложному выводу, что конкретная модель iPhone или версия системы не поддерживается. Ошибка в подписи, наоборот, может быть принята за нестабильность установщика или повреждение пакета.
Сначала фиксируют один и тот же IPA и устанавливают его на оба устройства. Нельзя сравнивать сборки, созданные разными настройками или в разные моменты: изменение профиля, сертификата или минимальной версии ОС уже меняет условия эксперимента.
Затем проверяют:
Если сборка требует iOS 17, а второе устройство работает на iOS 16, профиль не является причиной: установка невозможна из-за минимальной версии ОС. Если обе системы подходят, а второй UDID отсутствует в development или ad hoc-профиле, установщик отклонит пакет независимо от того, что на первом устройстве он работает.
Полезно проверить журнал установки и подпись самого пакета, а не ориентироваться только на текст, показанный пользовательским интерфейсом. В диагностике нужно установить, на каком этапе возникает отказ: проверка подписи, проверка профиля, проверка устройства или проверка требований к ОС.
Ограничение подхода: успешная установка на одном устройстве не доказывает полную совместимость с другим. Она подтверждает только то, что конкретный артефакт прошёл проверки на первом устройстве. Кроме подписи и версии ОС, могут отличаться аппаратные возможности, региональные ограничения и доступность entitlements.
Команда передала ad hoc-сборку тестировщику. На iPhone ответственного инженера она установилась, а на телефоне нового тестировщика появилась ошибка установки.
Рассматривались два варианта. Первый — пересобрать приложение с более низкой минимальной версией iOS: это могло бы помочь при несовместимости ОС, но не исправило бы отсутствие устройства в профиле и создало бы риск тестирования неподдерживаемой конфигурации. Второй — заменить provisioning profile без проверки: это быстро, но не показывает, была ли причиной подпись, срок действия профиля или параметры приложения.
Выбрали проверяемый путь: сравнили версии iOS, зафиксировали хеш одного IPA, проверили Bundle ID и нашли UDID нового устройства в списке профиля. Версии ОС подходили, но UDID отсутствовал. После регистрации устройства и выпуска нового ad hoc-профиля та же сборка с обновлённой подписью установилась. Это подтвердило проблему provisioning, а не совместимости ОС.
1. Достаточно ли добавить UDID устройства в provisioning profile, не меняя IPA?
Нет. Изменённый профиль должен быть встроен в подписанный пакет, а пакет — корректно переподписан. Само изменение записи в портале разработчика не меняет уже переданный IPA и не исправляет его embedded-профиль.
2. Доказывает ли успешная установка, что приложение будет работать на устройстве?
Нет. Установка подтверждает прохождение проверок подписи, профиля и базовых требований платформы. Во время запуска или работы могут проявиться отсутствие entitlement, недоступное аппаратное API, неподдерживаемая функция ОС или ошибка, зависящая от модели устройства.
3. Может ли App Store-сборка требовать добавления UDID каждого тестировщика?
Обычно нет: App Store использует модель распространения через магазин и проверку права пользователя на загрузку, а не ad hoc-список устройств. Если сборку распространяют через TestFlight, действуют правила TestFlight и срок доступности тестовой сборки; это не следует смешивать с development или ad hoc-подписанием.