Как распространять iOS приложения минуя AppStore

При создании мобильного приложения под iPad для одной крупной компании перед нами встал вопрос — как распространять данное приложение. Самый распространённый вариант — конечно, через AppStore.

Но данный вариант нам не подошел, так как приложение создавалось для работников компании, а не для общего пользования. Остался только второй вариант — Enterprise Program (подробнее о Developer Program и Enterprise Program).

Клиент купил лицензию, мы занимались разработкой, и вот настало время выкладывать приложение. До этого мы выкладывали приложения в AppStore, а вот опыта работы с in-house приложениями (они предполагают внутреннее использование в компании и не предназначены для выкладывания в общий доступ) не было. К нашему удивлению, мы не нашли полноценных статей, описывающих данный процесс, поэтому решили составить некую инструкцию, которая поможет сэкономить кому-то время.

Получение пакета файлов приложения



Итак, после того как разработка завершена, необходимо выполнить следующие шаги:
  1. Создать Distribution-сертификат (подробное описание процесса).
  2. Создать Distribution Provisioning Profile
  3. Подписать приложение соответствующим Provisioning Profile и создать пакет, который потом можно распространять. Для этого в XCode в меню Product нужно выбрать Archive и отметить пункт — Save for Enterprise or Ad-Hoc Deployment.



  4. Далее выбрать подпись (необходимо выбрать тот provisioning profile который создали выше)



  5. Сохранить полученный пакет. Не забудьте поставить галочку рядом Save for Enterprise Distribution (без этого вы не сможете получить plist-файл). В поле Application URL указываем полный путь к ipa файлу на сервере (http://www.yoursite.com/dir/yourFile.ipa)





На выходе мы получим ipa- и plist-файлы, их уже можно переслать людям, которым нужно установить приложение. Но для установки на iPad (iPhone) необходимо подключить его к компьютеру (при этом пользователям Windows необходимы еще и некоторые танцы с бубном).

Установка приложения через интернет



А как быть, если под рукой нет компьютера? Это как раз был наш случай, так как приложение предназначалось для торговых представителей компании заказчика, а они по роду своей деятельности чаще всего находятся в пути и не имеют компьютера под рукой. Встал вопрос: «А как же распространять in-house приложения (кстати, то же самое справедливо и для Ad Hoc distribution — прямой установки файла-сборки приложения через iTunes), не используя компьютер?» Всё оказалось просто, даже очень просто!

Нужно выложить ранее созданные ipa- и plist-файлы на сервер, к которому есть http (или https) доступ. Затем создать простой html-файл, в котором будет ссылка на plist-файл следующего вида:

<a href="itms-services://?action=download-manifest&url=#your_plist_file_path.plist#">Install</a>


И заменить #your_plist_file_path.plist# на полный путь к своему plist-файлу (важный ньюанс: в имени plist-файла не должно содержаться пробелов). Т.е. код должен получиться примерно таким:

<a href="itms-services://?action=download-manifest&url=http://www.yoursite.ru/dirname/yourFile.plist">Install</a>


Пользователь, зайдя на сайт со своего iPhone или iPad, нажмет на эту ссылку и получит сообщение: «Хотите ли вы установить данное приложение?». Вот, собственно, и всё.

Пара мелочей



Дополнительное преимущество распространения in-house состоит в том, что приложение не проходит проверки в Apple, и соответственно, не «зависает» там на 1-2 недели (а иногда и больше), что очень полезно для исправления ошибок и внесения срочных изменений.

Все описанное работает и для распространения приложения путем Ad Hoc. Единственное отличие: при создании Provisioning Profile необходимо выбрать соответствующий пункт в Distribution Method и привязать Provisioning Profile к профайлу устройства (иначе приложение не будет работать).



Также можно посмотреть порядок действий на видео.

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 21

    0
    Спасибо, отличный пост.
      0
      Ещё можно устанавливать приложения ad-hoc — вроде бы ограничено сотней устройств.
      Но, к примеру, Vodafone и T-Mobile распространяют предварительную версию приложения Joyn (аналог WhatsApp от опсосов) — его может установить любой прямо с сайта опсоса минуя аппстор.
      Кто-нибудь знает, как это сделано? Если там есть ограничение по количеству устройств, то как оно контролируется?
        +4
        вариант с ad-hoc тут не подходит (т.к. мало того что ограничение в 100 устройств, так еще надо указать при создании профайла какие именно устройства — т.е. указать их уникальные номера). Остается только вариант с in-house распространением, но тут тоже не все так просто, т.к. требования у Apple такие, что приложения распространяемые с Enterprise аккаунта должны использоваться только сотрудниками компании. Возможно эти операторы просто договорились с Apple и для них сделали исключение. Других вариантов просто не вижу.
        0
        А как производится обновление приложения у пользователей?
          0
          при обновлении версии приложения на сайте необходимо сообщить об этом пользователям (или разработать приложение так, чтобы оно само проверяло обновления с сайта). Пользователь заходит на страничку и по нажатию на ссылку — ему устанавливается обновленное приложение. При этом необходимо помнить что у новой версии bundle-identifier должен быть таким же как у предыдущей (иначе приложение не обновится, а установится как новое)
          –14
          Да уж, скоро дойдет до того, что будут писать статьи и выкладывать видео-гайды «как очистить корзину» например.
            +5
            А вы сами попробуйте это сделать. Я около года назад пытался разобраться с этим методом распространения и plist файлами и ведь ни одного понятного руководства не нашел! Убил приличное количество времени на «метод тыка».
            +4
            Зря Вы так. Мы тоже убили немало времени на то, чтобы заставить все это работать. Поэтому посчитал полезным опубликовать данный пост.
              0
              Я до сих пор не знаю как очистить корзину. Каждый раз переустанавливаю OS X, когда место заканчивается. Дайте ссылку на статью, в которой описывается как очистить корзину.
              –2
              в закладки. Спасибо
                0
                Где-то прочитал, что на одно устройство одновременно можно установить enterprise (in-house) приложения только от одного разработчика.
                Т.е. две компании А и B разрабатывают iOS приложения у каждой компании своя подписка на Enterprise program, появляется клиент C у которого один единственный iPhone и вот на этот айфон он не сможет поставить одновременно приложения от A и от B.
                Кто-нибудь может подтвердить или опровергнуть? Якобы это официальное ограничение.

                Именно поэтому клиент C заводит свой собственный enterprise аккаунт и дает к нему доступ разработчикам.

                И кстати насчет последнего пункта. Скажем у клиента есть enterprise аккаунт а я для него разрабатываю приложение. Так ли необходимо клиенту давать мне полный доступ к iOS Developer Program (логин и пароль)? Если я соберу Xcode archive и вышлю его заказчику, сможет ли он его переподписать своим сертификатом? Я ведь могу этот архив переподписывать Ad-Hoc и Distribution сертификатами.
                  +1
                  Про ограничения — не слышал. Далее по пунктам:

                  1. Компания разработчик должна иметь подписку по Developer Program. Приложение разрабатывается как обычно. А Enterprise program как раз должен себе купить клиент, т.к. это программа именно по распространению приложений, а не программированию. Более того в этой программе есть ограничения — нельзя распространять приложение вне той компании, на которую куплена Enterprise program. У разработчиков не должно быть Enterprise программ… они им просто не нужны.

                  2. По подписи приложения. Вы можете клиенту выслать весь исходный код, клиент его откроет в Xcode и подпишет своим Provisioning Profile. Потом скомпилирует и создаст архив. Т.е. клиент имея только архив — не сможет его переподписать, т.к. нужно сначала скомпилировать проект с нужным профайлом
                    0
                    Не совсем уверен насчет некоторых моментов.

                    Насчет первого. Все-таки она называется iOS Developer Enterprise Program, т.е. подразумевает точно такую же разработку как и обычная Developer Program, совсем не правда что Enterprise нужна исключительно для распространения. Тогда пришлось бы покупать отдельно Developer чтобы разработать, а потом Enterprise чтобы распространить в своей компании in-house. Enterprise действительно предназначена для разработки «под себя» и не позволяет публикацию в App Store, но, например вот тут есть информация что можно устнавливать свои in-house приложения на устройства клиентов (Customer) только если эта установка происходит на территории вашей компании или проводится сотрудником вашей компании. Apple отмечает что может проверить соблюдение этого пункта в любой момент, но насколько я понял, многие его не соблюдают и используют такой способ распространения. Единственный минус — на один девайс можно ставить in-house приложения только от одного Enterprise аккаунта (опять же только читал, на практике еще не приходилось проверять). Вот как раз поэтому клиент покупает Enterprise лицензию для разработки, хотя никакой разработки фактически не делает, зато избавляется от ограничений. Люди из отдела маркетинга не очень любят такой подход, им нужно продать решение клиенту как можно более простым способом. Если приходится просить каждого клиента открыть себе Enterprise аккаунт — это не самый простой вариант с точки зрения маркетинга. Можно было бы публиковать в App Store, но этот вариант под вопросом, поскольку это специфическое B2B приложение (с завязкой на серверный компонент) и может не пройти Review. Вариант с Volume Purchase Program тоже не совсем подходит. Во-первых (может это уже и не так) но этот способ доступен только для клиентов в США, во-вторых клиент по-прежнему должен сделать лишние телодвижения и завести себе Volume Purchase Program аккаунт, зато требования к приложению будут менее жесткие и будет учитываться B2B специфика.

                    Ну а по второму пункту, не для всех приемлем вариант «отправить исходники клиенту», это работает когда клиент является единственным заказчиком и платит в том числе и за исходники. А если компания пишет приложение и будет потом продавать его многим клиентам как готовое решение — высылать каждому исходики никак нельзя. Поэтому обычно клиент дает доступ к своему Developer Enterprise аккаунту, а мне хотелось бы знать можно ли совсем исключить обмен какими-либо паролями или логинами.
                  +1
                  Автору респект и благодарность. Очень вовремя.

                  P.S.: Субботний холиварчик вспомнился.

                    +1
                    И так мы нарушаем условия пользования подпиской. Ынтерпрайз распространение это только для распространения внутри компании. Нельзя вот так взять и начать по этой подписке распространять приложения.
                      +1
                      Каким образом  Apple  может проверить что устройства на которые установлено приложение не являются корпоративными, если даже UDID 'ы в таком случае нигде не проходят?
                        0
                        Согласен,
                        моя практика (1.5 года пользуюсь enterprise program) показывает, что по можно ставить любые аппы на любые девайсы, и никаких проблем.
                      0
                      В чем отличие от testflightapp.com?
                        0
                        Столкнулся с проблемой публикации приложений.

                        Мне помогло следующее:
                        Разместил IPA и PLIST на HTTPS

                        Добавил в PLIST название программы:
                        <string>software</string> <key>title</key> <string>Your App Name</string>
                          0
                          Начиная с iOS 7.1(если мне не изменяет память) такой способ работает только по HTTPS.

                        Only users with full accounts can post comments. Log in, please.