TestFlight — официальный инструмент Apple для бета-тестирования. Работает просто: загружаешь сборку в App Store Connect, отправляешь ссылку тестировщикам, они устанавливают приложение и пишут, что сломалось. Никаких сторонних сервисов, никаких обходных схем.

Звучит несложно, но на практике многие разработчики тратят дни на настройку, потому что не понимают, как устроена система изнутри. Разберём по шагам.

Как устроен TestFlight

Apple разделяет тестировщиков на два типа: внутренние и внешние.

Внутренние тестировщики — это члены вашей команды в App Store Connect. Максимум 100 человек. Они получают доступ к сборке сразу, без дополнительной проверки Apple. Подходит для разработчиков, дизайнеров, менеджеров — всех, кто работает над приложением.

Внешние тестировщики — до 10 000 человек. Это могут быть клиенты, пользователи из листа ожидания, блогеры. Перед тем как открыть доступ, Apple проверяет сборку — обычно занимает от нескольких часов до суток. Проверка менее строгая, чем при полном ревью App Store, но базовые требования те же: приложение должно запускаться и не нарушать Guidelines.

Каждая сборка живёт в TestFlight 90 дней. После этого срока тестировщики не смогут её установить — придётся загружать новую версию.

Что нужно перед стартом

Несколько вещей нужно подготовить заранее.

Apple Developer Program. Без платного аккаунта ($99 в год) TestFlight недоступен. Бесплатный аккаунт позволяет устанавливать приложение только на устройства, зарегистрированные в вашем профиле, — это не TestFlight, это локальная сборка.

Bundle ID и запись в App Store Connect. Зайди в App Store Connect, создай новое приложение, укажи Bundle ID — тот же, что в Xcode. Без этого шага загрузить сборку не получится.

Provisioning profile для дистрибуции. В Xcode выбери схему «App Store» при архивации. Если подписано неправильным профилем — Transporter и Xcode Organizer откажутся загружать архив.

Загружаем первую сборку

Есть три способа загрузить сборку в App Store Connect.

Через Xcode Organizer. Самый простой путь. Открываешь Product → Archive, ждёшь, пока Xcode соберёт архив, жмёшь Distribute App → App Store Connect → Upload. Xcode сам подпишет и отправит. Минус — занимает время и привязывает к конкретной машине с Xcode.

Через Transporter. Отдельное приложение из Mac App Store. Принимает файл .ipa, загружает в Apple. Удобно, если сборку делает CI, а загружает другой человек.

Через Fastlane. Если у тебя уже настроен CI/CD — это лучший вариант. Команда fastlane pilot upload загружает сборку, добавляет список тестировщиков, отправляет приглашения. Всё автоматически, без GUI.

После загрузки подожди 10–30 минут — Apple обрабатывает сборку. Статус в App Store Connect изменится с «Processing» на «Ready to Submit» или на имя конкретной группы тестировщиков.

Создаём группы тестировщиков

Группы — главный инструмент управления доступом. В одном приложении можно создать несколько групп и открывать им разные сборки.

Типичная схема:

  • Internal — команда разработки. Получают каждую сборку сразу.
  • Beta — лояльные пользователи, которые готовы терпеть баги. Получают сборку после базовой проверки внутри команды.
  • Soft Launch — широкая аудитория. Открываете ближе к релизу, когда приложение уже стабильно.

Для внешних групп укажи описание тестирования — что именно хочешь проверить. Apple это не проверяет строго, но тестировщики видят текст при установке и понимают, чего от них ждут.

Как набрать тестировщиков

Есть несколько рабочих способов.

Публичная ссылка. В настройках группы включи «Public Link» — получишь ссылку вида testflight.apple.com/join/.... Размести её где угодно: в Telegram-канале, на сайте, в соцсетях. Любой, у кого есть iPhone с iOS 14+, может перейти по ссылке и стать тестировщиком. Лимит по-прежнему 10 000 человек.

Приглашение по email. Если хочешь контролировать, кто тестирует — вводи адреса вручную или загружай CSV-файл. Человек получит письмо с инструкцией.

Через приложение TestFlight. Тестировщикам нужно скачать приложение TestFlight из App Store — без него установить бета-версию не получится. Это единственное, что они должны сделать сами.

Реальная цифра из практики: при выходе на широкую аудиторию через публичную ссылку конверсия «перешёл по ссылке → установил» составляет 40–60%. Часть людей видит требование установить TestFlight и уходит. Учитывай это при планировании.

Что тестировщики видят и могут делать

Когда пользователь устанавливает приложение через TestFlight, он видит плашку «Beta» на иконке. В самом приложении TestFlight есть кнопка «Отправить отзыв» — она позволяет написать текст и прикрепить скриншот прямо из приложения.

Ещё один способ сбора фидбека — скриншот с long press. Если пользователь делает скриншот на устройстве, TestFlight предлагает сразу отправить его разработчику с комментарием. Это работает автоматически, ничего настраивать не нужно.

Все отзывы приходят в App Store Connect в раздел TestFlight → Feedback. Там же видно, на каком устройстве и версии iOS воспроизошла проблема.

Крашлоги тоже собираются автоматически — в том же разделе Feedback. Если пользователь разрешил диагностику на своём устройстве, лог прилетит к тебе.

Версии, сборки и номера — как не запутаться

Apple различает Version Number и Build Number.

Version Number — то, что видит пользователь: 1.0, 1.1, 2.0. Меняется, когда выходит новая версия приложения.

Build Number — внутренний счётчик. Для каждой загружаемой сборки он должен быть уникальным в рамках одной версии. Загрузил 1.0 (build 1), нашёл баг, исправил — загружаешь 1.0 (build 2). Если номер повторится — App Store Connect откажет.

Практический совет: используй дату и время как build number. Например, 20260507.1315 — дата 7 мая 2026, время 13:15. Такие номера всегда уникальны и сразу говорят, когда была собрана версия. В Fastlane это настраивается одной строчкой.

Автоматические обновления для тестировщиков

По умолчанию TestFlight обновляет приложение автоматически, если тестировщик включил эту опцию. Удобно — не нужно каждый раз просить людей обновиться вручную.

Но иногда это мешает. Если ты тестируешь конкретную версию и хочешь, чтобы тестировщик оставался на ней, — предупреди его отключить автообновления в настройках TestFlight.

Как выстроить процесс бета-тестирования

Простая схема, которая работает:

  1. Внутреннее тестирование (1–3 дня). Команда разработки проходит основные сценарии. Фиксируете очевидные баги, крашлоги, проблемы с UI.

  2. Закрытая бета (1–2 недели). Приглашаете 50–200 лояльных пользователей. Просите пройти конкретные сценарии, задаёте вопросы. Собираете структурированный фидбек.

  3. Открытая бета (1–2 недели). Публикуете публичную ссылку, набираете широкую аудиторию. На этом этапе важно следить за крашлогами и количеством установок.

  4. Релиз. Та же сборка, что прошла открытую бету, отправляется на ревью App Store.

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

Частые ошибки

Не указывать, что тестировать. Люди устанавливают приложение, тыкают несколько минут и удаляют. Без чёткого задания бета-тест превращается в сбор случайных впечатлений.

Открывать бету слишком рано. Если приложение крашится при старте или основной флоу не работает — тестировщики просто уйдут и больше не вернутся. Лучше задержать бету на неделю и выйти со стабильной версией.

Игнорировать крашлоги. Отзывы люди пишут редко. Крашлоги — объективные данные, которые собираются автоматически. Проверяй их после каждой сборки.

Не сегментировать аудиторию. Если все тестировщики в одной группе и получают одну сборку — ты не можешь тестировать разные версии фичи одновременно. Группы решают эту задачу.

Забывать про 90-дневный срок. Если тестирование затянулось и сборка протухла — придётся загружать новую только для того, чтобы тестировщики снова получили доступ. Следи за датами.

TestFlight и App Store Review

Важный момент, который часто упускают: сборка для TestFlight и сборка для App Store — это один и тот же архив. Когда ты закончишь тестирование и захочешь опубликоваться — ты просто выбираешь ту же сборку в App Store Connect и отправляешь на ревью. Не нужно пересобирать.

Это означает, что конфигурация, которую ты тестировал — production URL, production ключи, release-настройки — должна быть в сборке с самого начала. Не меняй ничего перед отправкой на ревью. Меняй сборку — значит, тестировал другое.

Интеграция с CI/CD

Если собираешь приложение вручную — рано или поздно это станет узким местом. Минимальная автоматизация: настроить GitHub Actions или Bitrise так, чтобы при пуше в ветку beta автоматически собиралась и загружалась новая сборка в TestFlight.

Fastlane lane для этого выглядит примерно так:

lane :beta do
  increment_build_number
  build_app(scheme: "MyApp")
  upload_to_testflight(skip_waiting_for_build_processing: true)
end

Три строки — и каждый коммит в бета-ветку автоматически становится доступным тестировщикам через час.

Если нужна помощь

Тестирование — это часть разработки, а не отдельная история. Если ты заказываешь iOS-приложение у подрядчика, уточни заранее: входит ли настройка TestFlight и бета-тестирование в работу? Некоторые студии выставляют это отдельной строкой, другие включают по умолчанию.

В REEXY (r3xy.ru) процесс бета-тестирования через TestFlight входит в стандартный цикл разработки мобильного приложения — клиент получает доступ к сборкам ещё до релиза и может проверить всё сам, не дожидаясь публикации в App Store.

Краткая выжимка

TestFlight — зрелый инструмент без значимых альтернатив для iOS. Настройка занимает пару часов при первом запуске. Главное — не технические детали, а процесс: кто тестирует, что именно, как собирается фидбек и как быстро исправляются баги.

Хорошая бета сокращает количество проблем после релиза в App Store. Плохая бета — это когда все установили, никто ничего не написал, а потом в отзывах появляется однозвёздочный «не работает».