Поясню для начинающих, что при разработке под iOS для установки на девайс большую часть времени вы собираете приложение в development режиме, т.е. только для себя.
Но в какой-то момент требуется начинать выдавать заказчику результат работы на «посмотреть».
Для этого используется особый вид сборки AdHoc Distribution. Нужно сходить к Apple’у и создать distribution provisioning profile. После чего собирать приложение, подписывая его этим профилем. В профиле прописываются все идентификаторы девайсов, на которые планируется это приложение устанавливать на этом этапе.
В итоге при билде под AdHoc, XСode создает файл с расширением .ipa, который уже можно установить на все, прописанные в профиле, девайсы. Например через iTunes.
Возникает вопрос как лучше всего передать вашему клиенту получившуюся сборку. Да, можно просто отправить файл по почте например, или выложить на файлообменник и пусть бедняга сам устанавливает его через iTunes на свой девайс. Но если вы цените время своего клиента или вам лень объяснять ему как это сделать, ну или вы просто милый и приятный человек, то вам стоит задуматься, а нет ли другого, более удобного способа.
What is Ad Hoc Reporting?
Об одном из таких способов, с автоматизацией выдачи из Xcode читаем под катом!
На этой стезе уже давно промышляет достаточно прихлебателей, которые, надо признать довольно не плохо справляются с этой задачей. Одним из заслуженных сервисов является например TestFlight. Суть в том что они дают возможность вашему клиенту (или бета тестерам) установить ваше приложение через их сервис. Для этого все бета тестеры должны установить на свои девайсы их приложение. И в дальнейшем, когда они получают по почте уведомление о выходе очередной вашей сборки — они запускают это приложение, находят там ваше обновленние и устанавливают его себе через их интерфейс.
Но и эта схема, я бы сказал, не идеальна.
Во-первых это подразумевает что вам все равно придется объяснять заказчику как ему зарегистрироваться в TestFlight, как установить их приложение себе (его нет в AppStore, установка происходит с их сайта).
Так же в этом случае мы не упрощаем себе жизнь на своей стороне — каждый раз нужно сначала собрать очередной AdHoc билд в Xcode, затем в его окне Organizer выбрать опцию AdHoc distribution, указать правильный профиль и сохранить .ipa файл на диск. Затем зайти на сайт TestFlight, и залить туда этот .ipa, написать комментарий, не забыть выставить разрешения для тех кому этот билд предназначен. Очень, очень много телодвижений.
К тому же часто сервис бывает не доступен, или просто скорость загрузки такова, что процесс установки приложения сваливается по таймауту.
Особенно не приятно бывает слышать от заказчика, что ваше приложение почему-то не устанавливается, когда ты точно знаешь что это не так, и ты проверил загрузку из TestFlight сам.
В итоге для меня последней каплей стал тот факт что они пока что не поддерживают установку на iOS7, под которую мы ведем разработку нашего последнего проекта.
What’s an Ad Hoc Committee and what does it do?
И тогда мы пришли к решению, которое оказалось проще для обеих сторон.
Сейчас вся вышеописанная процедура сводится к двум шагам. Я, как и раньше, выбираю в Xcode archive build (так обычно собираются сборки под AdHoc). После чего пишу заказчику что приложение обновлено. Все.
Теперь заказчик просто заходит со своего девайса по определенному адресу в интернете (адрес не меняется и он может сохранить его в закладки). У него появляется всплывающее окно — не хотите ли установить приложение, он конечно же хочет, приложение устанавливается. Все счастливы.
И вот что нужно сделать, чтобы прийти к этой нирване.
Магия установки приложений через мобильный браузер.
Сначала немного о той магии, которая позволяет устанавливать приложения по URL.
Это уже давным давно существующая возможность, и на ней собственно и основаны все эти сервисы аля TestFlight.
Есть такой протокол itms-services:, с помощью которого на iOS в частности осуществляется установка приложений из браузера. Протокол подразумевает что будет загружен .plist файл c определенной структурой, где, в том числе, указана и ссылка на .ipa файл. В результате это обрабатывается iOS как запрос на установку приложения.
Т.е. нам первым делом понадобится создать какую-нибудь простенькую (или не очень, как хотите) HTML страницу. Рядом положить наш волшебный .plist файл и .ipa билд.
Здесь я подразумеваю что для такого хранения используется Amazon S3 хранилище. Завести свой аккаунт на Amazon Web Services проще простого и я не буду здесь это описывать. Хранение и раздача таких мизерных объемов выйдет вам в какие-то копейки, которые мне лениво подсчитывать здесь, сейчас не об этом.
Итак создаем наши файлы, вот так может выглядеть наш HTML. Назовем его, скажем index.html. Главное чтобы в нем были ссылки по itms-services: протоколу
Как видите, здесь внедрен список, потому что мы не хотим ограничиваться только одним приложением, у нас их будет несколько. И каждое из них устанавливается по отдельной ссылке.
В самом адресе itms-services://. нужно изменить только mybucketname и название .plist файла. Т.е. замените их соответственно на название своего bucket на Amazon S3, куда вы все это сложите, и на имя вашего .plist (имя файла не имеет никакого значения и может не совпадать с названием приложения).
Сам .plist выглядит вот так:
items assets kind software-package url http://mybucketname.s3.amazonaws.com/MyApp1.ipa metadata bundle-identifier com.mycoolcompanyname.myapp1 bundle-version 1.0 kind software title MyApp1
Понятное дело, здесь тоже нужно заменить название mybucketname в строке ключа software-package. И указать ваше название .ipa файла вместо MyApp1.ipa. И не забудьте поменять строку ключа bundle-identifier. Вместо com.mycoolcompanyname.myapp1 впишите свой bundle id, который вы использовали при билде этого приложения в Xcode.
Ну и укажите желаемое имя приложения в ключе title.
Отлично! Уже теперь вы можете собирать приложение под AdHoc distribution и ручками выкладываеть его на S3 в этот bucket. После чего его можно будет установить по ссылке mybucketname.s3.amazonaws.com/index.html открыв ее в мобильном браузере.
Кстати для ручной заливки на S3 рекомендую приложение CyberDuck. Сам остановился на нем, как на наиболее удобном варианте под MacOs.
Одна важная деталь, не забывайте выставлять права доступа к .ipa файлу на public-read. В CyberDuck это делается правой кнопкой на файле > Info и добавить группу Everybody с правами Read.
Но этот вариант тоже не для ленивых, поэтому идем дальше.
Автоматизация в Xcode. Пишем post-actions скрипт.
Чтобы уж совсем ничего не пришлось делать мы напишем маленький скрипт.
В Xcode существует возможность напихивать свои скрипты практически во все этапы при сборке приложения.
Нас, в данном случае, интересует только сборка в архив (именно так мы всегда собираем приложение для AdHoc Distribution).
Поэтому добавим post-action на завершающем этапе для этой схемы.
Заходим в Xcode, открываем диалог редактирования схем. Далее будет несколько поясняющих скриншотов. Они сделаны в beta версии Xcode 5, но Xcode 4.6 эта возможность тоже присутствует, и интерфейс в этой части практически не отличается.
Итак кликаем название вашего таргета в том месте где оно указано в левой верхней части главного окна Xcode. В появившемся диалоге выбираем пункт Edit Scheme…
В диалоге редактирования схем находим схему Arhive и кликаем маленький треугольник рядом с ее названием, развернутся несколько подпунктов. Последний из них и будет нужный нам Post-actions.
В выпадушке в этом окне выберите название вашего таргета. Это означает что все переменные в скрипте, вроде $ например, будут браться соответствующие ему.
Вот такой скипт используем мы:
SIGNING_IDENTITY=»iPhone Distribution: MyCoolCompanyName (G4DHGXDY2)» PROVISIONING_PROFILE=»$/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 «$/Library/Developer/Xcode/Archives/$» | /usr/bin/grep xcarchive | /usr/bin/sed -n 1p ) DSYM=»$/Library/Developer/Xcode/Archives/$/$/dSYMs/$.app.dSYM» APP=»$/Library/Developer/Xcode/Archives/$/$/Products/Applications/$.app» /usr/bin/open -a /Applications/Utilities/Console.app $LOG echo -n «Creating .ipa for $. » > $LOG /bin/rm «/tmp/$.ipa» /usr/bin/xcrun -sdk iphoneos PackageApplication «$» -o «/tmp/$.ipa» —sign «$» —embed «$» >> $LOG echo «Created .ipa for $» >> $LOG echo -n «Uploading to S3. » >> $LOG /opt/local/bin/s3cmd put —acl-public —force —guess-mime-type /tmp/$.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=»$/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).
Что такое Ad Hoc в Wi-Fi сети, для чего нужен и как настроить на Windows 10, 7 и XP?
Всем привет! Ad hoc – это режим беспроводной сети, которая не имеет постоянной структуры и строится «на лету», благодаря сопряжению пары устройств. Такой режим еще называют IBSS (Independent Basic Service Set) или P2P «точка-точка». Чтобы его реализовать, достаточно, чтобы оба устройства были снабжены Wi-Fi адаптерами, а в операционной системе, через которую с ними можно взаимодействовать, были установлены драйвера.
Принцип работы Ad hoc
Для режима Ad Hoc необходимо минимум оборудования. Главное, чтобы каждая станция была наделена WiFi–адаптером. Создавать какую-либо сеть при этом не нужно.
[FAQ] In-House Apps, Ad Hoc Distribution – распространение приложений в обход App Store
Если вы хотите увидеть на нашем сайте ответы на интересующие вас вопросы обо всём, что связано с техникой, программами и сервисами Apple, iOS или Mac OS X, iTunes Store или App Store, пишите нам через форму обратной связи.
К нам поступил следующий вопрос:
Добрый день, уважаемая редакция! К вам есть вопрос насчёт возможных способов распространения приложений не через App Store. Допустим, есть программа, которую цензоры точно не пропустят, но я хочу распространять её сам. Какие у меня есть альтернативы? Я много чего прочитал про Ad Hoc и In-House, но особой ясности это не прибавило. Когда подходит каждый из этих способов? И что такое Custom B2B Apps?
Это какой-то третий способ распространения или разновидность In-House Apps?
Вы правы, существует два способа распространения iOS-приложений не через App Store, которые официально поддерживаются Apple – In-House Apps и Ad Hoc Distribution. Различий между ними много:
- Ad Hoc Distribution – механизм распространения приложений для бета-тестирования (либо для небольших компаний). Разработчик приобретает стандартную подписку iOS Developer Program (за 99 долларов в год) и получает право прикрепить к своему аккаунту 100 iOS-устройств. Затем он компилирует IPA-файл программы, подписывает её своим собственным сертификатом и создаёт к ней профайл – небольшой файлик, содержащий информацию о том, какая именно программа и на какие устройства может быть установлена. Бета-тестеры или конечные пользователи должны будут поставить профайл, после чего смогут установить через iTunes или со специальным образом организованной веб-страницы подписанную разработчиком программу. Если профайла нет, если в нём не указано нужное устройство, если профайл не соответствует сертификату разработчику – ничего не получится. Распространение софта посредством Ad Hoc весьма удобно, но есть существенное ограничение – максимум 100 целевых устройств. Для коммерческого продукта это не аудитория.
- In-House Apps – особый вид внутренних приложений, которые создаются компаниями для своих работников. От имени компании приобретается подписка Developer Enterprise Program (уже за 299 долларов в год), к которой прилагается другой тип сертификата разработчика. От iOS Developer Program он отличается тем, что количество совместимых устройств никак не ограничивается. Напротив, раньше Apple требовала, чтобы In-House Apps ставились минимум на 500 гаджетов, но пару лет назад и это ограничение сняли. Ещё интереснее другое – приложение, подписанное сертификатом Developer Enterprise Program, ставится на любые устройства! Никакие регистрации UDID не требуются, никаких дополнительных проверок нет. Но не всё так прекрасно. Во-первых, зарегистрироваться в Developer Enterprise Program могут только компании, имеющие номер D-U-N-S (а ещё Apple оставляет за собой право запросить у вас нотариально заверенные апостилированные копии учредительных документов). Во-вторых, соглашение с Apple требует, чтобы: а) распространяемый софт был бесплатным; б) он распространялся только среди работников компании. Конечно, Apple не уследит за всеми, однако стоит помнить об этих ограничениях – если вдруг на вас обратят внимание (либо кто-то из доброжелателей накатает донос), ваш сертификат будет аннулирован без права восстановления.
Подчеркнём: при использовании данных способов ваше приложение не проходит через цензоров App Store, поэтому вы вольны распространять абсолютно любой софт. Про HIG и Review Guidelines можно забыть. Этим-то In-House Apps и Ad Hoc Distribution отличаются от упомянутых вами Custom B2B Apps. B2B Apps – приложения для закрытого от посторонних глаз раздела App Store для корпоративных пользователей, где действуют особые условия покупки (например, оптовые контракты). Такие приложения тоже подвергаются цензуре, поэтому данный вариант вряд ли будет вам интересен.
Источник: appstudio.org