Transporter 1.4.5 завис в Processing: как решить проблему в 2026 году?
Transporter показывает «доставка завершена», но через несколько часов сборка всё ещё не появилась в TestFlight.
Быстрее всего не загружать файл повторно: сначала разделите локальную передачу, приём App Store Connect и серверный этап Processing. Если доставка подтверждена и 24 часа ещё не прошли, сохраните журналы и наблюдайте; после 24 часов без изменений обращайтесь в Apple, а повторную загрузку начинайте только после Failed или доказанного сбоя передачи.
Эта схема предназначена для независимых разработчиков, которые отправляют IPA или PKG через Transporter, но не видят сборку в TestFlight. Она также подходит тем, кто выпускает приложение с удалённого Mac и не уверен, повлиял ли обрыв VNC или SSH на процесс. Небольшим командам материал поможет формализовать хранение журналов, повторную отправку и эскалацию инцидента.
Важно: Apple выпустила Transporter 1.4.5 8 сентября 2026 года, указав улучшения стабильности и исправления ошибок. Apple не подтверждала, что эта версия массово вызывает зависание Processing. Отдельные случаи нельзя автоматически считать дефектом Transporter 1.4.5. Описание выпуска Transporter 1.4.5
Три статуса вместо одного: где именно остановилась сборка
Ошибка диагностики обычно появляется из-за смешения трёх разных событий. Transporter может закончить передачу файла, пока App Store Connect ещё принимает метаданные и запускает проверку. TestFlight, в свою очередь, показывает только результат последующей обработки.
| Этап | Где проверять | Что означает положительный результат | Чего он не подтверждает |
|---|---|---|---|
| Локальная передача | Transporter, журнал и история доставок | Клиент передал файл и получил ответ о доставке | Что сборка уже доступна в TestFlight |
| Приём сервером | App Store Connect, раздел Build Uploads | Сервер зарегистрировал загрузку | Что обработка завершена |
| Обработка | Build Uploads и список TestFlight | Сборка прошла необходимый серверный этап | Что предыдущие попытки относятся к правильному приложению |
Apple описывает загрузку сборок как отдельный процесс, после которого файл обрабатывается в App Store Connect. Поэтому отметка Transporter «доставлено» и отсутствие записи в TestFlight не являются взаимоисключающими событиями. Официальное описание загрузки сборок
Перед любым решением запишите в отдельный файл:
Bundle ID: <REDACTED_BUNDLE_ID>
Версия: <REDACTED_VERSION>
Build string: <REDACTED_BUILD>
Время доставки: <REDACTED_TIMESTAMP>
Идентификатор доставки: <REDACTED_DELIVERY_ID>
Команда: <REDACTED_TEAM>
Статус Transporter: <REDACTED_STATUS>
Такой журнал не должен содержать настоящий Team ID, имя приложения, путь к файлу, адрес электронной почты или токен. Для публикации отчёта достаточно обезличенных значений.
Transporter завершил передачу, а App Store Connect ещё обрабатывает файл
Если в истории Transporter есть завершённая доставка, следующий шаг — не перезапуск клиента, а проверка Build Uploads. Apple различает состояния загрузки и обработки; название статуса важнее субъективного ощущения, что «прошло уже долго». Справочник статусов загрузки сборки
| Наблюдаемая картина | Наиболее вероятное объяснение | Действие |
|---|---|---|
| В Transporter нет завершённой доставки | Передача не подтверждена | Проверить журнал, сеть и авторизацию |
| Есть доставка, в Build Uploads стоит Processing | Сервер продолжает обработку | Сохранить доказательства и ждать |
| В Build Uploads стоит Failed | Apple вернул ошибку обработки | Прочитать причину и исправить её |
| Обработка завершена, но TestFlight пуст | Неверная команда, приложение, платформа или фильтр | Сверить запись приложения и параметры |
| Статус неизменен более 24 часов | Возможна проблема обработки | Подготовить обращение в Apple |
Официальное окно в 24 часа — это не обещание, что каждая сборка появится именно за это время. Это граница, после которой отсутствие изменений можно рассматривать как аномалию и передавать инцидент на следующий уровень. Apple прямо указывает на возможность проблемы, если обработка длится более 24 часов. Инструкция по просмотру сборок и метаданных
Не стоит превращать Transporter 1.4.5 в единственное объяснение задержки. На результат могут влиять серверная обработка, неверная запись приложения, выбранная команда или содержимое конкретной сборки.
Первая проверка: действительно ли локальная доставка завершена
Окно Transporter может исчезнуть по нескольким причинам. Закрытие VNC-сеанса не равно завершению процесса, а закрытие самого Transporter не равно успешной доставке. Проверка должна идти по нескольким независимым признакам.
Шаг 1. Сохраните журнал до перезапуска
Скопируйте журнал в защищённое место и добавьте время проверки:
Дата проверки: <REDACTED_DATE>
Файл журнала: <REDACTED_LOG_FILE>
Последняя строка: <REDACTED_LAST_LOG_LINE>
Код завершения: <REDACTED_EXIT_CODE>
Если клиент вернул явную ошибку входа, сетевого соединения, чтения файла или завершился с ошибкой, это локальная проблема передачи. Если журнал содержит подтверждение доставки, не стирайте его запуском новой попытки.
Шаг 2. Проверьте процесс после повторного входа
На удалённом Mac можно проверить, остался ли процесс активным:
ps aux | grep -i '[T]ransporter'
Команда показывает только состояние процесса в момент проверки. Пустой вывод не доказывает неудачу: процесс мог уже завершиться корректно. Поэтому результат нужно сопоставить с журналом и историей доставок.
Шаг 3. Проверьте признаки сетевого сбоя
При прерванной передаче в журнале обычно есть ошибка соединения, тайм-аут или сообщение о невозможности отправить файл. Отсутствие окна Transporter после потери VNC-связи само по себе недостаточно. При использовании SSH особенно важно не путать закрытие терминала с завершением фоновой задачи.
Если процесс запускается из оболочки, для будущих публикаций стоит сохранять вывод:
nohup <REDACTED_UPLOAD_COMMAND> > <REDACTED_LOG_FILE> 2>&1 &
echo $!
Команда приведена как шаблон. Реальные параметры, токены и пути нельзя публиковать. Для автоматизированного контура полезно также изучить схему хранения журналов iOS-сервера и восстановления после разрыва, если в текущем наборе материалов нет отдельной страницы с этим сценарием.
Вторая проверка: не исчезла ли сборка из-за неверной записи
Иногда Processing воспринимают как задержку, хотя файл был отправлен не в ту запись приложения или проверяется не та команда. Это особенно вероятно при нескольких приложениях, разных платформах и нескольких учётных записях.
Сверьте значения из Archive или журнала доставки:
| Поле | Что сравнить | Частая ошибка |
|---|---|---|
| Bundle ID | Значение в финальном продукте и App Store Connect | Выбрана другая запись приложения |
| Версия | Номер маркетинговой версии | Открыта другая версия приложения |
| Build string | Значение загруженной сборки | Проверяется старая попытка |
| Team ID | Команда подписи и команда просмотра | Вход выполнен в другую команду |
| Платформа | iOS или macOS | Открыт раздел другой платформы |
| Идентификатор доставки | Значение в журнале Transporter | Поиск ведётся только по времени |
Не вставляйте настоящие значения в публичный тикет или скриншот. Используйте <REDACTED_BUNDLE_ID>, <REDACTED_TEAM_ID> и другие явные заглушки.
В App Store Connect следует открыть именно раздел сборок целевого приложения, а не полагаться на общий список уведомлений. Фильтр TestFlight тоже может скрывать ожидаемую запись, если выбрана другая версия или платформа.
Что выбирать: ждать, исправлять, повторять или эскалировать
Ниже приведён рабочий выбор, основанный на подтверждённом состоянии, а не на длительности ожидания «на глаз».
| Факты | Решение | Почему |
|---|---|---|
| Есть подтверждённая доставка, Processing продолжается, 24 часа не прошли | Ждать и сохранять журнал | Серверная обработка ещё может идти |
| Есть Failed с причиной | Исправить причину и повторить загрузку | Ошибка подтверждена самим статусом |
| Нет завершённой доставки, есть ошибка Transporter | Восстановить сеть, вход или файл и повторить | Сбой произошёл до подтверждённого приёма |
| Более 24 часов нет изменения статуса | Обратиться в Apple | Превышено официальное окно аномалии |
| Статус завершён, TestFlight пуст | Проверить приложение, команду, платформу и фильтры | Вероятна ошибка маршрутизации или просмотра |
Шаг 4. Не заменяйте Processing новой копией без причины
Повторная отправка того же build string во время Processing не является универсальным лечением. Первая сборка может обрабатываться, а вторая попытка создаст конкурирующие записи и усложнит расследование. Нельзя заранее обещать, что одинаковый build string будет принят повторно: допустимость зависит от версии, состояния первой загрузки и правил App Store Connect.
Если проблема подтверждена статусом Failed, сохраните точное сообщение и исправьте именно его. Если требуется новая сборка, значение build string должно соответствовать правилам выбранной версии. Смена инструмента на Xcode, командную строку или автоматизацию может изолировать неисправность клиента, но не гарантирует обход серверного Processing.
Шаг 5. Подготовьте обращение после 24 часов
В обращение включите:
Transporter: 1.4.5
Версия: <REDACTED_VERSION>
Build string: <REDACTED_BUILD>
Время доставки: <REDACTED_TIMESTAMP>
Идентификатор доставки: <REDACTED_DELIVERY_ID>
Статус Build Uploads: <REDACTED_STATUS>
Команда: <REDACTED_TEAM>
Bundle ID: <REDACTED_BUNDLE_ID>
Приложите журнал без секретов и укажите, что именно проверялось: Transporter, Build Uploads и TestFlight. Для сообщения о техническом поведении можно использовать Apple Feedback Assistant. Если в команде используется автоматизация, уведомления о событиях App Store Connect можно сопоставлять с журналом через официальные webhooks.
FAQ: что делать в типичных спорных ситуациях
Transporter показывает завершённую доставку, но в TestFlight нет сборки.
Сначала проверьте Build Uploads, команду, Bundle ID, версию и платформу. Завершённая доставка означает успешную передачу на следующий этап, но не мгновенную доступность TestFlight. До истечения 24 часов сохраните журнал и не создавайте дубликат без подтверждённой ошибки.
Сколько ждать, если App Store Connect показывает Processing?
Ориентиром для эскалации служит официальное окно в 24 часа без изменения состояния. Это не гарантированный срок публикации каждой сборки. До этой границы нужно наблюдать за статусом и уведомлениями, а после неё отправить Apple идентификатор доставки, журнал и обезличенные данные сборки.
Разрешена ли повторная загрузка с тем же build string?
В состоянии Processing повторная отправка не должна быть первым действием. Сначала дождитесь результата или получите Failed. После ошибки нужно проверить правила конкретной версии и допустимость значения build string. При отсутствии уверенности безопаснее запросить подтверждение у поддержки, чем скрывать исходную попытку новой загрузкой.
Пропадёт ли загрузка при разрыве удалённого Mac?
Нет автоматического вывода ни в одну сторону. VNC или SSH могут отключиться, пока процесс продолжает работать, но сетевой сбой также может завершить передачу. После восстановления доступа проверьте процесс, журнал и историю доставки. Только совпадение этих данных подтверждает результат.
Как принять удалённый Mac в качестве среды публикации
Удалённый Mac полезен не потому, что меняет правила App Store Connect, а потому, что позволяет отделить публикационный процесс от сна личного компьютера, смены домашней сети и случайного закрытия окна. Но сам по себе доступ по VNC или SSH не является доказательством надёжности.
Для первой проверки среды выполните последовательность:
- Подготовьте один обезличенный IPA или PKG с заранее записанными Bundle ID, версией и build string.
- Проверьте контрольную сумму файла до запуска Transporter и сохраните её в журнале.
- Запустите передачу на удалённом Mac, направив вывод в отдельный файл.
- Намеренно переподключите VNC или SSH, не завершая хостовый процесс.
- После восстановления доступа сравните PID, последние строки журнала и историю доставки.
- Проверьте Build Uploads, затем целевую запись TestFlight.
- Зафиксируйте, где появились результаты и какие данные понадобились для повторной проверки.
Такой тест не доказывает, что любая будущая публикация будет успешной. Он показывает, сохраняется ли процесс после разрыва сессии, доступен ли журнал и можно ли восстановить цепочку доказательств.
Если личный компьютер засыпает, меняет сеть или удаляет локальные журналы, аренда удалённого Mac для публикации может быть рациональнее покупки отдельного устройства для редких релизов. Для команды, которой важна оценка расходов, пригодится сравнение стоимости аренды Mac mini. При этом постоянная тяжёлая нагрузка, физические USB-устройства или требование полного локального контроля могут сделать собственный Mac более подходящим.
Когда удалённый Mac лучше текущей схемы, а когда нет
Текущая схема на личном компьютере часто имеет три слабых места: компьютер может уйти в сон, домашняя сеть может изменить маршрут во время передачи, а журналы остаются в закрытой пользовательской сессии. При ручном повторении также легко потерять исходный идентификатор доставки и загрузить файл ещё раз без доказательства Failed.
Удалённый Mac устраняет не серверную задержку Apple, а операционные причины: постоянный доступ к хосту, отдельное место для журналов и возможность восстановить сессию после разрыва. Поэтому аренда SFTPMAC имеет смысл для временного релиза, проверки автоматизации или небольшого числа публикаций, когда покупка отдельного Mac не оправдана. Для ежедневной предсказуемой нагрузки сначала следует провести описанный тест на реальной сборке, а не считать сам факт удалённого доступа гарантией.
Последовательность решения остаётся прежней: подтвердить локальную доставку, проверить App Store Connect, дождаться 24-часового окна, затем выбрать исправление, повторную загрузку или обращение в Apple. Такой порядок защищает от главной ошибки — уничтожить полезные доказательства новой попыткой, пока исходная сборка ещё обрабатывается.
Последнее обновление: 16 сентября 2026 года. Данные сверены с примечаниями к выпуску Transporter, описанием загрузки сборок и определениями статусов Build Uploads.