Комментарии 21
Спасибо, отличный пост.
Ещё можно устанавливать приложения ad-hoc — вроде бы ограничено сотней устройств.
Но, к примеру, Vodafone и T-Mobile распространяют предварительную версию приложения Joyn (аналог WhatsApp от опсосов) — его может установить любой прямо с сайта опсоса минуя аппстор.
Кто-нибудь знает, как это сделано? Если там есть ограничение по количеству устройств, то как оно контролируется?
Но, к примеру, Vodafone и T-Mobile распространяют предварительную версию приложения Joyn (аналог WhatsApp от опсосов) — его может установить любой прямо с сайта опсоса минуя аппстор.
Кто-нибудь знает, как это сделано? Если там есть ограничение по количеству устройств, то как оно контролируется?
вариант с ad-hoc тут не подходит (т.к. мало того что ограничение в 100 устройств, так еще надо указать при создании профайла какие именно устройства — т.е. указать их уникальные номера). Остается только вариант с in-house распространением, но тут тоже не все так просто, т.к. требования у Apple такие, что приложения распространяемые с Enterprise аккаунта должны использоваться только сотрудниками компании. Возможно эти операторы просто договорились с Apple и для них сделали исключение. Других вариантов просто не вижу.
А как производится обновление приложения у пользователей?
при обновлении версии приложения на сайте необходимо сообщить об этом пользователям (или разработать приложение так, чтобы оно само проверяло обновления с сайта). Пользователь заходит на страничку и по нажатию на ссылку — ему устанавливается обновленное приложение. При этом необходимо помнить что у новой версии bundle-identifier должен быть таким же как у предыдущей (иначе приложение не обновится, а установится как новое)
Да уж, скоро дойдет до того, что будут писать статьи и выкладывать видео-гайды «как очистить корзину» например.
А вы сами попробуйте это сделать. Я около года назад пытался разобраться с этим методом распространения и plist файлами и ведь ни одного понятного руководства не нашел! Убил приличное количество времени на «метод тыка».
Ребята, вы гуглом пользоваться умеете? первая же ссылка полуторагодичной давности stackoverflow.com/questions/5546581/how-to-distribute-ios-application-wirelessly-without-managing-udids-and-recompil
Зря Вы так. Мы тоже убили немало времени на то, чтобы заставить все это работать. Поэтому посчитал полезным опубликовать данный пост.
Я до сих пор не знаю как очистить корзину. Каждый раз переустанавливаю OS X, когда место заканчивается. Дайте ссылку на статью, в которой описывается как очистить корзину.
в закладки. Спасибо
Где-то прочитал, что на одно устройство одновременно можно установить enterprise (in-house) приложения только от одного разработчика.
Т.е. две компании А и B разрабатывают iOS приложения у каждой компании своя подписка на Enterprise program, появляется клиент C у которого один единственный iPhone и вот на этот айфон он не сможет поставить одновременно приложения от A и от B.
Кто-нибудь может подтвердить или опровергнуть? Якобы это официальное ограничение.
Именно поэтому клиент C заводит свой собственный enterprise аккаунт и дает к нему доступ разработчикам.
И кстати насчет последнего пункта. Скажем у клиента есть enterprise аккаунт а я для него разрабатываю приложение. Так ли необходимо клиенту давать мне полный доступ к iOS Developer Program (логин и пароль)? Если я соберу Xcode archive и вышлю его заказчику, сможет ли он его переподписать своим сертификатом? Я ведь могу этот архив переподписывать Ad-Hoc и Distribution сертификатами.
Т.е. две компании А и B разрабатывают iOS приложения у каждой компании своя подписка на Enterprise program, появляется клиент C у которого один единственный iPhone и вот на этот айфон он не сможет поставить одновременно приложения от A и от B.
Кто-нибудь может подтвердить или опровергнуть? Якобы это официальное ограничение.
Именно поэтому клиент C заводит свой собственный enterprise аккаунт и дает к нему доступ разработчикам.
И кстати насчет последнего пункта. Скажем у клиента есть enterprise аккаунт а я для него разрабатываю приложение. Так ли необходимо клиенту давать мне полный доступ к iOS Developer Program (логин и пароль)? Если я соберу Xcode archive и вышлю его заказчику, сможет ли он его переподписать своим сертификатом? Я ведь могу этот архив переподписывать Ad-Hoc и Distribution сертификатами.
Про ограничения — не слышал. Далее по пунктам:
1. Компания разработчик должна иметь подписку по Developer Program. Приложение разрабатывается как обычно. А Enterprise program как раз должен себе купить клиент, т.к. это программа именно по распространению приложений, а не программированию. Более того в этой программе есть ограничения — нельзя распространять приложение вне той компании, на которую куплена Enterprise program. У разработчиков не должно быть Enterprise программ… они им просто не нужны.
2. По подписи приложения. Вы можете клиенту выслать весь исходный код, клиент его откроет в Xcode и подпишет своим Provisioning Profile. Потом скомпилирует и создаст архив. Т.е. клиент имея только архив — не сможет его переподписать, т.к. нужно сначала скомпилировать проект с нужным профайлом
1. Компания разработчик должна иметь подписку по Developer Program. Приложение разрабатывается как обычно. А Enterprise program как раз должен себе купить клиент, т.к. это программа именно по распространению приложений, а не программированию. Более того в этой программе есть ограничения — нельзя распространять приложение вне той компании, на которую куплена Enterprise program. У разработчиков не должно быть Enterprise программ… они им просто не нужны.
2. По подписи приложения. Вы можете клиенту выслать весь исходный код, клиент его откроет в Xcode и подпишет своим Provisioning Profile. Потом скомпилирует и создаст архив. Т.е. клиент имея только архив — не сможет его переподписать, т.к. нужно сначала скомпилировать проект с нужным профайлом
Не совсем уверен насчет некоторых моментов.
Насчет первого. Все-таки она называется 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 аккаунту, а мне хотелось бы знать можно ли совсем исключить обмен какими-либо паролями или логинами.
Насчет первого. Все-таки она называется 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 аккаунту, а мне хотелось бы знать можно ли совсем исключить обмен какими-либо паролями или логинами.
Автору респект и благодарность. Очень вовремя.
P.S.: Субботний холиварчик вспомнился.
P.S.: Субботний холиварчик вспомнился.
И так мы нарушаем условия пользования подпиской. Ынтерпрайз распространение это только для распространения внутри компании. Нельзя вот так взять и начать по этой подписке распространять приложения.
В чем отличие от testflightapp.com?
Столкнулся с проблемой публикации приложений.
Мне помогло следующее:
Разместил IPA и PLIST на HTTPS
Добавил в PLIST название программы:
Мне помогло следующее:
Разместил IPA и PLIST на HTTPS
Добавил в PLIST название программы:
<string>software</string>
<key>title</key>
<string>Your App Name</string>
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как распространять iOS приложения минуя AppStore