Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

Автоматизация выдачи AdHoc сборки приложения из Xcode для установки на девайс клиента

Anna | 2.07.2014 | нет комментариев
Поясню для начинающих, что при разработке под iOS для установки на девайс огромную часть времени вы собираете приложение в development режиме, т.е. только для себя.
Но в какой-то момент требуется начинать выдавать клиенту итог работы на «посмотреть».
Для этого применяется специальный вид сборки AdHoc Distribution. Необходимо сходить к Apple’у и сделать distribution provisioning profile. Позже чего собирать приложение, подписывая его этим профилем. В профиле прописываются все идентификаторы девайсов, на которые планируется это приложение устанавливать на этом этапе. В результате при билде под AdHoc, XСode создает файл с растяжением .ipa, тот, что теснее дозволено установить на все, прописанные в профиле, девайсы. Скажем через iTunes.Появляется вопрос как отменнее каждого передать вашему заказчику получившуюся сборку. Да, дозволено легко отправить файл по почте скажем, либо выложить на файлообменник и пускай бедняга сам устанавливает его через iTunes на свой девайс. Но если вы цените время своего заказчика либо вам лень пояснять ему как это сделать, ну либо вы легко милый и славный человек, то вам стоит задуматься, а нет ли иного, больше комфортного метода.

На этой стезе теснее давным-давно промышляет довольно прихлебателей, которые, нужно признать достаточно не нехорошо справляются с этой задачей. Одним из снисканных сервисов является скажем TestFlight. Суть в том что они дают вероятность вашему заказчику (либо бета тестерам) установить ваше приложение через их сервис. Для этого все бета тестеры обязаны установить на свои девайсы их приложение. И в последующем, когда они получают по почте уведомление о выходе следующий вашей сборки — они запускают это приложение, находят там ваше обновленние и устанавливают его себе через их интерфейс.

Но и эта схема, я бы сказал, не совершенна.
Во-первых это подразумевает что вам все равно придется пояснять клиенту как ему зарегистрироваться в TestFlight, как установить их приложение себе (его нет в AppStore, установка происходит с их сайта).
Так же в этом случае мы не упрощаем себе жизнь на своей стороне — всякий раз необходимо вначале собрать следующий AdHoc билд в Xcode, после этого в его окне Organizer предпочесть опцию AdHoc distribution, указать верный профиль и сберечь .ipa файл на диск. После этого зайти на сайт TestFlight, и залить туда данный .ipa, написать комментарий, не позабыть выставить разрешения для тех кому данный билд предуготовлен. Дюже, дюже много телодвижений.
К тому же Зачастую сервис бывает не доступен, либо легко скорость загрузки такова, что процесс установки приложения сваливается по таймауту.
Исключительно не славно бывает слышать от клиента, что ваше приложение отчего-то не устанавливается, когда ты верно знаешь что это не так, и ты проверил загрузку из TestFlight сам.
В результате для меня последней каплей стал тот факт что они пока что не поддерживают установку на iOS7, под которую мы ведем разработку нашего последнего плана.
И тогда мы пришли к решению, которое оказалось проще для обеих сторон.

Теперь каждая вышеописанная процедура сводится к двум шагам. Я, как и прежде, выбираю в Xcode archive build (так обыкновенно собираются сборки под AdHoc). Позже чего пишу клиенту что приложение обновлено. Все.
Сейчас клиент легко заходит со своего девайса по определенному адресу в интернете (адрес не меняется и он может сберечь его в закладки). У него возникает всплывающее окно — не хотите ли установить приложение, он безусловно же хочет, приложение устанавливается. Все радостны.

И вот что необходимо сделать, Дабы прийти к этой нирване.

Магия установки приложений через мобильный браузер.

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

Есть такой протокол itms-services:, с поддержкой которого на iOS в частности осуществляется установка приложений из браузера. Протокол подразумевает что будет загружен .plist файл c определенной конструкцией, где, в том числе, указана и ссылка на .ipa файл. В итоге это обрабатывается iOS как запрос на установку приложения.
Т.е. нам первым делом потребуется сделать какую-нибудь простенькую (либо не дюже, как хотите) HTML страницу. Рядом положить наш магический .plist файл и .ipa билд.

Тут я подразумеваю что для такого хранения применяется Amazon S3 хранилище. Завести свой аккаунт наAmazon Web Services проще простого и я не буду тут это описывать. ark!Следственно добавим post-action на завершающем этапе для этой схемы.
Заходим в Xcode, открываем диалог редактирования схем. Дальше будет несколько объясняющих скриншотов. Они сделаны в beta версии Xcode 5, но Xcode 4.6 эта вероятность тоже присутствует, и интерфейс в этой части фактически не отличается.

Выходит кликаем наименование вашего таргета в том месте где оно указано в левой верхней части основного окна Xcode. В появившемся диалоге выбираем пункт Edit Scheme…
В диалоге редактирования схем находим схему Arhive и кликаем небольшой треугольник рядом с ее наименованием, развернутся несколько подпунктов. Конечный из них и будет необходимый нам Post-actions.

В выпадушке в этом окне выберите наименование вашего таргета. Это обозначает что все переменные в скрипте, как бы ${PRODUCT_NAME} скажем, будут браться соответствующие ему.

Вот такой скипт используем мы:

SIGNING_IDENTITY="iPhone Distribution: MyCoolCompanyName (G4DHGXDY2)"
PROVISIONING_PROFILE="${HOME}/Library/MobileDevice/Provisioning Profiles/20DB9849-4CFE-4005-81F6-1A594119839B.mobileprovision"
LOG="/tmp/post-build-upload-to-s3.log"

DATE=$( /bin/date  "%Y-%m-%d" )
ARCHIVE=$( /bin/ls -t "${HOME}/Library/Developer/Xcode/Archives/${DATE}" | /usr/bin/grep xcarchive | /usr/bin/sed -n 1p )
DSYM="${HOME}/Library/Developer/Xcode/Archives/${DATE}/${ARCHIVE}/dSYMs/${PRODUCT_NAME}.app.dSYM"
APP="${HOME}/Library/Developer/Xcode/Archives/${DATE}/${ARCHIVE}/Products/Applications/${PRODUCT_NAME}.app"

/usr/bin/open -a /Applications/Utilities/Console.app $LOG

echo -n "Creating .ipa for ${PRODUCT_NAME}... " > $LOG

/bin/rm "/tmp/${PRODUCT_NAME}.ipa"
/usr/bin/xcrun -sdk iphoneos PackageApplication "${APP}" -o "/tmp/${PRODUCT_NAME}.ipa" --sign "${SIGNING_IDENTITY}" --embed "${PROVISIONING_PROFILE}" >> $LOG

echo "Created .ipa for ${PRODUCT_NAME}" >> $LOG

echo -n "Uploading to S3... " >> $LOG

/opt/local/bin/s3cmd put --acl-public --force --guess-mime-type /tmp/${PRODUCT_NAME}.ipa "s3://mybucketname/MyApp.ipa" >> $LOG

echo "Done." >> $LOG
/usr/bin/open "https://basecamp.com/path-to-your-project-to-let-people-know-of-new-build"

Выходит в открывшемся окне видим /bin/sh в первой строке ввода. Оставляем там это значение.
В пустое поле внизу копипастим данный скрипт.

Сейчас нам предстоит отредактировать пару значений в нем под вашу конфигурацию. А именно, нужно прописать верное значение в переменную SIGNING_IDENTITY и прописать положительную ссылку на ваш нынешний provisioning profile в переменной PROVISIONING_PROFILE.

Я делаю это так. Cохраняемся тут — жмем OK внизу, выходим в Build Settings плана и находим там раздел Code Signing Identity.
В нем есть все надобные значения. Но «услужливый» Xcode показывает их в человеко-читаемом виде и к тому же не дает выделять прямо там.

Кликаем правой кнопкой на наименование вашего signing identity (что-то как бы iPhone Distribution:…). Откроется поп-ап, в котором в самом низу будет опция Other… Выбираем ее и вот он каждый наш комплект параметров в текстовом виде и даже рачительно выделен.

В предыдущих версиях Xcode это выглядело приблизительно вот так:

iPhone Distribution: MyCoolCompanyName (G4DHGXDY2)
20DB9849-4CFE-4005-81F6-1A594119839B

Соответственно первая строка вписывается в переменную SIGNING_IDENTITY в скрипте.
А вторая — это код вашего профиля — легко замените им выделенную часть в адресе для переменной PROVISIONING_PROFILE, как показано ниже.

PROVISIONING_PROFILE=”${HOME}/Library/MobileDevice/Provisioning Profiles/20DB9849-4CFE-4005-81F6-1A594119839B.mobileprovision”

В новом Xcode 5 — эти два значения разнесены на отдельные записи в сегменты Code Signing Identity. Следственно то же действие необходимо проделать два раза. Вначале скопировать наименование identity, после этого код для provisioning profile.

Как видим, скрипт исполняет два примитивных действия. Вначале получившийся в итоге сборки .app файл трансформирует в .ipa. После этого данный .ipa заливает на S3. В процессе работы скрипта так же создается .log файл куда пишется все что происходит. Данный .log файл кладется во временную папку (туда же куда и .ipa) и открывается системной утилитой Console Дабы мы могли видеть ход выполнения скрипта.

Осталась только одна тайна — как же работает заливка на S3.

Заливаем сборку на Amazon S3 с поддержкой скрипта

На самом деле не вовсе, не будем мараться с ручной заливкой на S3, это хлопотно, воспользуемся для этого готовой утилиткой (S3cmd).

Мы с вами на маке, следственно ставимее через MacPorts. Кто не в курсе, это инструмент, тот, что разрешает ставить на мак каждые не присущие ему линуксовые изыски. Если у вас не установлен MacPorts — ставим по одной из ссылок для вашей версии MacOS (Mountain LionLion либо Snow Leopard).

Дальше ставим саму утилиту s3cmd. С MacPorts это делается предельно легко.

В терминале набираем:

sudo port install s3cmd

Появится запрос ввести пароль, введите пароль менеджера и начнется установка. Она занимает около минуты.
Все, утилита установлена, сейчас давайте ей скажем наш пароль от S3 (когда вы регистрируетесь на Amazon Web Services) вам дадут ключ и тайный код (не спрашивайте в чем разница между этими двумя представлениями, но необходимы оба).

Выходит набираем в терминале:

s3cmd --configure

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

Скажем это выглядит вот так:

Enter new values or accept defaults in brackets with Enter.
Refer to user manual for detailed description of all options.

Access key and Secret key are your identifiers for Amazon S3
Access Key: XXXXXздесь должен быть ваш ключXXX
Secret Key: YYYYздесь должен быть ваш секретYYY

Encryption password is used to protect your files from reading
by unauthorized persons while in transfer to S3
Encryption password: 
Path to GPG program: 

When using secure HTTPS protocol all communication with Amazon S3
servers is protected from 3rd party eavesdropping. This method is
slower than plain HTTP and can't be used if you're behind a proxy
Use HTTPS protocol [No]: No

On some networks all internet access must go through a HTTP proxy.
Try setting it here if you can't conect to S3 directly
HTTP Proxy server name: 

New settings:
  Access Key: XXXXXпоказывают вновь ваш ключXXX
  Secret Key: YYYYпоказывают вновь ваш секретYYY
  Encryption password: 
  Path to GPG program: None
  Use HTTPS protocol: False
  HTTP Proxy server name: 
  HTTP Proxy server port: 0

Test access with supplied credentials? [Y/n] Y
Please wait...
Success. Your access key and secret key worked fine :-) 

Now verifying that encryption works...
Not configured. Never mind.

Save settings? [y/N] y
Configuration saved to '/Users/st/.s3cfg'

Ну вот и все, сейчас в скрипте необходимо только исправить наименование вашего S3 bucket и наименование приложения в строке:

/opt/local/bin/s3cmd put –acl-public –force –guess-mime-type /tmp/${PRODUCT_NAME}.ipa «s3://mybucketname/MyApp.ipa» >> $LOG

Позже чего — дозволено легко запустить билд под archive (Xcode > Product > Archive) и все должно трудиться. Ваше приложение окажется залитым по указанному адресу.

Источник: programmingmaster.ru

Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB