Как выложить приложение в testflight

Особенности сборки и доставки iOS-приложений

В этой статье мы делимся опытом сборки и доставки пользователям приложений для iOS, который накопился у студии Plarium Krasnodar в процессе отладки CI/CD.

Подготовка

Каждый человек, так или иначе связанный с разработкой приложений для устройств Apple, уже успел оценить спорное удобство инфраструктуры. Сложности встречаются повсюду: начиная с меню профиля разработчика и заканчивая инструментами отладки и сборки.

Статей об «азах» предостаточно в сети, поэтому постараемся выделить главное. Вот что нужно для успешной сборки приложения:

• аккаунт разработчика ;
• устройство на базе macOS, выступающее в роли билд-сервера;
• сгенерированный сертификат разработчика , который будет далее использоваться для подписи приложения;
• созданное приложение с уникальным ID (следует отметить важность Bundle Identifier, потому что применение wildcard ID делает невозможным использование многих функций приложения, например: Associated Domains, Push Notifications, Apple Sign In и прочих);
• профиль подписи приложения.

Сертификат разработчика следует сгенерировать через Keychain на любом устройстве на базе macOS. Очень важным является тип сертификата. В зависимости от среды приложения (Dev, QA, Staging, Production) он будет различаться (Development или Distribution), так же как и тип профиля подписи приложения.

Основные типы профилей:

• Development — предназначен для подписи приложения команды разработчиков, используется Development-сертификат (имя вида iPhone Developer: XXXXX);
• Ad Hoc — предназначен для подписи тестового приложения и внутренней проверки QA-отделом, используется Distribution-сертификат разработчика (имя вида iPhone Distribution: XXXXX);
• App Store — релизный билд для внешнего тестирования через TestFlight и выгрузки в App Store, используется Distribution-сертификат разработчика.

При генерации профилей Development и Ad Hoc также указывается список устройств , на которые можно установить билд, что позволяет дополнительно разграничить доступ для пользователей. В профиле App Store нет списка устройств, так как разграничением доступа при закрытом бета-тестировании занимается TestFlight, о котором будет рассказано позже.

Для наглядности можно представить профиль разработчика в виде таблички ниже. Так проще понять, какие параметры для сборки нам нужны и откуда их брать.

Сборка

Чтобы было проще разделять сборки по проекту и среде, используем имена профилей вида $_$ , то есть имя проекта + инстанс (зависит от среды приложения: Dev, QA, GD, Staging, Live и так далее).

При импорте на билд-сервер профиль меняет название на уникальный ID и перемещается в папку /Users/$Username/Library/MobileDevice/Provisioning Profiles (где $Username соответствует имени учетной записи пользователя билд-сервера).

Существует два способа сборки файла *.ipa — устаревший (PackageApplication) и современный (через создание XcAchive и экспорт). Первый способ считается устаревшим, так как с версии 8.3 модуль упаковки app-файла убран из дистрибутива Xcode. Для его использования надо скопировать модуль из старого Xcode (версии 8.2 и более ранних) в папку:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/

И затем выполнить команду:

Далее нужно собрать *.app-файл приложения:

-workspace — путь к файлу проекта.

-scheme — используемая схема, указанная в проекте.

-derivedDataPath — путь выгрузки собранного приложения (*.app).

CODE_SIGN_IDENTITY — имя аккаунта разработчика, которое можно проверить в Keychain (iPhone Developer: XXXX XXXXXXX, без TeamID в скобках).

PROVISIONING_PROFILE — ID профиля для подписи приложения, который можно получить командой:

Если в приложении используется дополнительный профиль (например, для Push Notifications), то вместо PROVISIONING_PROFILE указываем:

Далее полученный файл *.app следует упаковать в *.ipa. Для этого можно использовать команду вида:

Однако данный способ считается устаревшим с точки зрения Apple. Актуальным является получение *.ipa путем экспорта из архива приложения.

Для начала нужно собрать архив командой:

Отличия заключаются в методе сборки и опции SYNCHRONOUS_SYMBOL_PROCESSING , которая отключает выгрузку символов во время сборки.

Далее нам надо сгенерировать файл с настройками экспорта:

$Method — метод доставки, соответствует типу профиля подписи приложения, то есть для Development значение будет development, для Ad Hoc — ad-hoc, а для App Store — app-store.

$BundleID — ID приложения, который указан в настройках приложения. Проверить можно командой:

$DevAccName и $ProfileId — настройки имени разработчика и ID профиля подписи, которые использовались ранее и должны совпадать со значениями в настройках экспорта.

$TeamID — десятизначный ID в скобках после имени разработчика, пример: iPhone Developer: …… (XXXXXXXXXX); можно проверить в Keychain.

Далее с помощью команды экспорта получаем необходимый файл *.ipa:

Доставка

Теперь собранный файл нужно доставить конечному пользователю, то есть установить на устройство.

Для распространения билдов Development и Ad Hoc существует множество сервисов вроде HockeyApp, AppBlade и прочих, однако в рамках данной статьи речь пойдет об автономном сервере для раздачи приложений.

Установка приложения для iOS проходит в 2 этапа:

1. Получение манифеста установки приложения через Items Service.
2. Установка файла *.ipa согласно информации, указанной в манифесте, через HTTPS.

Таким образом, нам для начала надо сгенерировать манифест установки (тип файла *.plist) командой:

Как видим, манифест содержит практически все параметры, участвующие в сборке приложения.

Версию приложения ( $AppVersion ) можно проверить командой:

Параметр $ipaUrl содержит прямую ссылку на скачивание файла *.ipa. С седьмой версии iOS приложение должно быть установлено через HTTPS. В восьмой версии немного изменился формат манифеста: были удалены блоки с настройками иконок приложения вида

Таким образом, для установки приложения достаточно простой html-страницы со ссылкой вида:

Для нужд отделов разработки и тестирования компания Plarium создала свое приложение установки билдов, которое дает нам:

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

Тестирование

Теперь речь пойдет о предрелизном тестировании приложения с помощью TestFlight .

Обязательными условиями для загрузки являются тип профиля подписи App Store и наличие сгенерированных API-ключей.

Есть несколько способов загрузки приложения:

• через Xcode (Organizer),
• через altool,
• через Application Loader для старых версий Xcode (теперь Transporter).

Для автоматической загрузки используется altool, в котором тоже есть два способа авторизации:

• App-Specific Password,
• API Key.

Более предпочтительной является загрузка приложения с помощью API Key.

Для получения API Key переходим по ссылке и генерируем ключ. Кроме самого ключа в формате *.p8, нам понадобятся два параметра: IssuerID и KeyID.

Далее скачанный ключ импортируем на билд-сервер:

Перед загрузкой приложения в TestFlight нужно выполнить валидацию приложения, делаем это командой:

Где apiKey и apiIssuer имеют значения полей со страницы генерации API-ключа.

Далее при успешной валидации выполняем загрузку приложения командой —upload-app c теми же параметрами.

Приложение будет проверено Apple в течение одного-двух дней и после станет доступным внешним тестировщикам: им пришлют на почту ссылки для установки.

Другим способом загрузки приложения через altool является использование App-Specific Password.

Для получения App-Specific Password нужно перейти по ссылке и сгенерировать его в разделе Security.

Далее следует создать в Keychain запись билд-сервера с этим паролем. С 11 версии Xcode это можно сделать командой:

$DeveloperName — имя аккаунта iOS-разработчика, используемое для логина в сервисы Apple.

$AppPswd — сгенерированный App-Specific Password.

Далее получаем значение параметра asc-provider и проверяем успешность импорта пароля командой:

Как видим, искомое значение Short Name (asc-provider) совпадает с параметром $TeamID, который мы использовали при сборке приложения.

Для валидации и загрузки приложения в TestFlight применяем команду:

В качестве значение параметра -p можно взять значение $AppPswd в незашифрованном (явном) виде.

Однако, как уже было сказано, с точки зрения работоспособности для авторизации altool лучше выбрать API Key, так как в разных версиях Xcode встречаются те или иные проблемы («не видит» Keychain, ошибки авторизации при выгрузке и прочее).

На этом, собственно, все. Желаю всем причастным успешных сборок и беспроблемных релизов в App Store.

Вступление

С каждым годом становится всё очевиднее, что для распространения тестовых версий iOS-приложений нужны специализированные сервисы. Это актуально не только для компаний, занимающихся разработкой приложений в “промышленных масштабах”, но и для инди-разработчиков. Причины: увеличение количества устройств с “нестандартным”/”не кратным” размером экрана, отличия в архитектуре центрального и графических процессоров — всё то, что раньше было повседневностью для разработки под Android, теперь становится справедливым и для iOS.

Исторически самым популярным сервисом дистрибуции являлся TestFlight — практически идеал, как в техническом отношении, так и в юзабилити. Однако, после приобретения компанией Apple в начале 2014 года, сервис претерпел ряд неоднозначных изменений, которые с одной стороны сказались негативно на его позиции лидера, а с другой дали шанс альтернативным сервисам побороться за первое место и предложить как минимум равноценную замену, а может быть и что-то более удобное и функциональное.

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

• Apple TestFlight
• HockeyApp
• Ubertesters
• Crashlytics (как часть Fabric)

• нет никаких гарантий, что Apple не приостановит или не прекратит его работу в любой момент
• SDK сервиса не доступно для скачивания, более того невозможно использовать сервис, если приложение использует SDK
• сервис больше не является кросс-платформенным, поддерживается только распространения приложений для iOS (подробнее)

Система оценки: сервисы будут оценены по 10-балльной шкале по каждому из разделов (Регистрация и интеграция, Основной функционал, Дополнительный функционал, Continuous Integration). Суммарная оценка позволит определить победителя (итоговое заключение войдет в последнюю часть обзора).

TestFlight от Apple

Регистрация и интеграция

• включать/отключать режим TestFlight Beta Testing для приложений (вкладка Prerelease)
• выбирать тестеров из списка доступных Internal Testers, но не имеют возможности формировать этот список на странице iTunes Connect -> Users and Roles -> TestFlight Beta Testers -> Internal
• формировать список внешних тестеров My Apps -> APP -> Prerelease -> External Testers (но для распространения версий для внешних тестеров приложение должно пройти ревью в Apple)

Пользователи из группы Admin обладают теми же правами, что и пользователи группы Technical, а также могут добавлять новых пользователей в список Internal Testers.

На данный момент установка или использование какого-либо специализированного SDK не требуется.

Основной функционал

Если сравнивать новую версию TestFlight с тем, что было доступно разработчикам ранее в рамках стандартных сервисов Apple, то она, в чем-то, несомненно, является шагом вперед. Так, например, количество тестеров увеличено с условных 100 до 1125 (из которых 100 — это доступные и раньше устройства для AdHoc распространения, 25 — это внутренние тестировщики (Internal Testers), а 1000 — внешние (External Testers)), причем если ранее привязка осуществлялась к устройству, то теперь уникальным идентификатором является Apple ID, а значит каждый тестер может проверить работу приложения на всех доступных ему (и, конечно, поддерживаемых приложением) устройствах.

Примечание (от 15 июня 2015): количество устройств, доступных при использовании AdHoc provision profiles с с 8 июня 2015 года было изменено со 100 суммарно, на 100 на каждое семейство устройств (изменение произошло после объявления на WWDC об объединении всех developers programs в одну).

Разница между внутренними и внешними тестировщиками заключается в дополнительном шаге, который добавляется во втором случае: тестовая версия приложения должна быть отправлена для обзора и одобрена специалистами Apple (Beta App Review). Причем первоначальный обзор будет проводиться более тщательно, а все последнующие могут проходить быстрее (но не обязательно). Это, конечно, накладывает определенные ограничения на процесс разработки и требует дополнительного планирования фаз тестирования приложения, с учетом неопределенности сроков прохождения обзора (как и в случае с обычным обзором приложений перед публикацие в AppStore, при отказе в публикации, повторная заявка рассматривается снова в порядке очереди).

• Приложение-клиент сервиса может быть установлен только на iOS 8.0 и выше, соответственно нет возможности тестировать приложения на устройствах с iOS предыдущих версий.
• Для распространения тестовых версий необходимо создать AppStore Distribution provisioning profile и настроить профиль приложения в iTunes Connect.
• Так как загрузка дистрибутива приложения осуществляется через стандартный визард Xcode -> Archive -> Export, необходимо чтобы проект приложения содержал 3 основных иконки.

• Количество приложений, одновременно доступных для тестирование ограничено 10.
• Сервис работает очень медленно, это касается как скорости обновления списка доступных приложений и их версий, так и скорости скачивания/установки приложений на тестовые устройства.
• Отправка отзыва с тестового устройства осуществляется при помощи приложения-клиента, но так как это обычное письмо, нет возможности прикрепить скриншот (как плюс можно отметить, то что в письмо автоматически вставляется блок с описанием характеристик тестового устройства).
• Возможность отправки отзыва появляется только, если в iTunes Connect в настройках версии имеется указание, что именно требуется протестировать (а если не будет указан адрес электронной почты для получения отзывов, то поле “To” в письме окажется незаполненным).
• Для тестирования может быть доступна только одна версия приложения (тестер не имеет возможность для выбора, настройки доступности делаются в профиле приложения в iTunesConnect).
• Поле “Feedback Email” в настройках версии приложения в iTunesConnect приходится заполнять каждый раз (логичней было бы запоминать, оставляя возможность для редактирования).
• Как не удивительно, но TestFlight в версии от Apple не является сервисом, работающим по принципу 24х7, например в конце декабря при попытке входа в iTunesConnect можно было увидеть такое сообщение: iTunes Connect is unavailable until December 29. (справедливости ради, стоит отметить, что подобные “каникулы” Apple устраивает ежегодно и рассылает уведомление за неделю до их наступления).

Однако есть и некоторые уникальные возможности: так, например, клиент сервиса (приложение TestFlight) единственный, кто наверняка знает статус установки тестовой версии, альтернативные решения попросту не имеют возможности использовать системные функцие, позволяющие реализовать подобное.

Примечание: статус установки — смена индикации процесса установки, привычная пользователям AppStore. Когда поочередно статус меняется Get — Install — Installing — Open. В других сервисах дистрибуции эта цепочка выглядит так: Install — Installing — Install — приложения попросту не знают результат, был ли установлен тестовый дистрибутив или нет. В случае же с Apple TestFlight цепочка имеет привычный вид: Install — Installing — Open.

Иконка обновленного приложения TestFlight (правильнее будет сказать, что это абсолютно новое native приложение, разработанное в Apple). Ниже пример иконки тестовой версии приложения — оранжевая “точка” позволяет определить, что это не версия из AppStore.

“Страховка” Apple от обвинений в распространении спама.

Apple не разрешает загрузку дистрибутивов без изменения версии или номера сборки.

Достаточно лаконичная и понятная страница администрирования версий приложения для тестирования.

Письмо-приглашение для участия в тестировании, HTML-форматирование не слишком оптимизировано для мобильных платформ (справедливости ради, хочу отметить, что приложение Mail отображает такие письма корректно, но письма от других сервисов отображаются нормально и в OWA).

Приложение TestFlight: информация о доступном для тестирования приложении.

Приложение TestFlight единственное умеет определять результат установки тестовой версии (кнопка Install поменялась на Open) — преимущество, полученное с переходом к Apple.

Письмо с отправленным из приложения TestFlight отзывом. Кроме скудного форматирования и невозможности добавить вложения, можно отметить еще один недостаток: отправленные отзывы попадают только в почтовый ящик, в iTunes Connect эта информация не сохраняется и недоступна.

Резюмируя, можно сказать, что обновленная версия TestFlight просто работает. В данный момент она не имеет особых конкурентных преимуществ (речь идёт о функционале, а не неоспоримом преимуществе — принадлежности компании Apple, которое пока в большей мере является потенциалом).

Дополнительный функционал

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

Обновление (5 мая 2015): с релизом Xcode 6.3 разработчикам стал доступен Crashes Organizer. Новый функционал, несомненно, хороший признак того, что Apple продолжает развивать свои сервисы, но, к сожалению, компания всё ещё отстаёт от других сервисов:

When you open the Crashes organizer, Xcode begins refreshing the crash reports for your apps. Xcode downloads the top crash reports—crash reports with the most number of occurrences on unique devices—that occurred during the past two weeks. However, there may be up to a three day delay between when you first distribute your app and when crash reports are available in Xcode.

Три дня задержки и период архивного доступа в две недели выглядит несколько обескураживающе.

Continuous Integration

Примечание: описанные далее нюансы использования сервисов как части непрерывной интеграции (continuous integration) в данном обзоре подразумевают, что она будет делаться на основе решения, предлагаемого компание Apple. То есть при помощи Mac OS X Server и Xcode bots — подробно на организации такой интеграции я не буду останавливаться, возможно это станет темой для отдельной статьи. Желающие могут ознакомиться с темой самостоятельно, например, обратившись к официальному руководству от Apple.

Каким бы странным это не казалось, но на данный момент не существует возможности для публикации приложений в Apple TestFlight в автоматическом режиме. Я надеюсь, что этот большой недостаток будет исправлен компанией в одном из ближайших крупных обновлений Xcode, тем более что в оригинальном TestFlight такая возможность имелась.

Как провести бета-тестирование приложений iOS с помощью TestFlight

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

Для тех, кто не знаком, Apple предлагает приложение под названием TestFlight, которое позволяет разработчикам, бета-тестерам и даже обычным пользователям опробуйте тестовые версии приложений, которые еще не были опубликованы в App Store. По сути, это дает вам ранний доступ к новым функциям за несколько недель, а иногда и месяцев до публичного выпуска. Несмотря на то, что они, как правило, содержат ошибки и подвержены сбоям, многие пользователи iOS и iPadOS, похоже, заинтересованы в установке бета-версий своих любимых приложений. И чтобы быть ясным, это отличается от более широких бета-программ iOS/iPadOS, поскольку вместо бета-тестирования операционной системы вы проводите бета-тестирование отдельных приложений. Итак, вы хотите сами стать бета-тестером и помогать разработчикам? В этом случае читайте дальше, чтобы узнать, как тестировать приложения iOS с помощью TestFlight на своем iPhone и iPad.

Как бета-тестировать приложения на iPhone и iPad с помощью TestFlight

Прежде чем вы получите начала, мы хотели бы отметить, что вы не можете получить доступ к бета-тестам просто так. Вам понадобится либо личное приглашение, либо общедоступная ссылка Testflight, чтобы получить доступ к бета-версиям приложения. Это полностью зависит от разработчика приложения, хотя у многих разработчиков есть общедоступные бета-версии для получения отзывов о своих приложениях.

Сначала загрузите и установите TestFlight из App Store.

Теперь откройте приложение и нажмите« Продолжить »на странице приветствия, чтобы получить доступ к главному меню.

В отличие от скриншота ниже, все здесь будет пусто. Теперь, если у вас есть код приглашения, который обычно отправляется по электронной почте, нажмите «Активировать» в правом верхнем углу.

Далее введите код и нажмите «Погасить».

Если вы обычный пользователь, вам нужно найти общедоступную ссылку TestFlight. Вы можете просмотреть и найти его с помощью простого поиска в Google. Когда у вас есть ссылка, просто нажмите на нее, чтобы открыть приглашение в TestFlight. Вы увидите страницу, похожую на указанную здесь. Нажмите «Принять».

Теперь подождите пару секунд, и параметр« Принять »изменится на« Установить ». Просто нажмите «Установить», чтобы продолжить.

Если на вашем устройстве установлена ​​общедоступная версия приложения, вы получите следующее приглашение заменить текущую версию на тестовую. Чтобы подтвердить и продолжить установку, просто выберите «Установить».

Готово. Вы успешно установили бета-версию приложения iOS на свой iPhone.

Где вы можете найти приложения iOS/iPadOS для бета-тестирования?

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

Посетите app.airport.community , чтобы найти приложения, в которых вы можете зарегистрироваться для участия в бета-тестировании.

Как прекратить бета-тестирование приложений на iPhone и iPad

В большинстве случаев обычные пользователи не собираются использовать бета-версии приложений в долгосрочной перспективе. Что еще более важно, если тестовая версия приложения часто дает сбой и недостаточно хороша для повседневного использования, вы захотите вернуться к общедоступной версии. Итак, вот как это сделать:

Перейдите в главное меню приложения TestFlight и выберите приложение, бета-тестирование которого вы хотите остановить.

Прокрутите страницу приложения вниз и нажмите« Остановить тестирование », как показано ниже.

Когда вам будет предложено подтвердите свое действие, выберите «Остановить тестирование» во всплывающем окне.

Вы почти у цели. Вы больше не будете получать обновления для бета-версий приложения.

Даже если вы прекратили участие в бета-версии, имейте в виду, что бета-версия приложения все еще установлена ​​на вашем устройстве. Он не будет автоматически удален с вашего устройства. Вам нужно будет удалить его вручную, а затем загрузить общедоступную версию приложения из App Store.

Вы будете получать обновления для приложений, которые вы тестируете в бета-версии, в приложении TestFlight, а не в App Store.. Вы можете включить автоматические обновления, если не хотите возиться с этим. Для этого просто нажмите на значок своего профиля Apple ID, а затем выберите «Автоматические обновления» в меню настроек.

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

Кроме того, разработчик может удалить вас из программы бета-тестирования в любой момент, когда они захотят, а вы в основном не контролируйте его, если нет открытых слотов для публичного тестирования. Лично это случилось со мной, когда я бета-тестировал Discord, и я не могу повторно присоединиться, так как слоты заполнены. Если вы не используете приложение активно, вы можете быть исключены из программы бета-тестирования этого приложения, поскольку количество доступных слотов ограничено.

Вы заинтересованы в установке бета-версий приложений на свой iPhone или iPad? Вы в настоящее время бета-тестирование каких-либо приложений, грядущих версий iOS/iPadOS или чего-то еще? Поделитесь с нами своим опытом и оставьте свое личное мнение и отзывы в разделе комментариев ниже.