Какова наилучшая практика для распределения корпоративных клиентов iOS?

Существует много информации о распределении iOS. Я думаю, что я понимаю разные модели распределения, но я ищу наилучшую практику для распространения приложения для клиента.

У меня есть клиент, у которого есть учетная запись разработчика Enterprise, и использует AirWatch для MDM. Вот как я собираюсь рекомендовать им, чтобы мы распространяли приложение в своей организации, поскольку у них нет ни одного технического персонала, у которого есть какой-либо опыт разработки Xcode или iOS, и им не будет предоставлен доступ к исходному коду:

  • Добавьте меня как участника своей учетной записи разработчика
  • Я создаю приложение, используя свой сертификат
  • Я даю им файл .ipa и plist для распространения через MDM или веб-сайт.

Это правильный способ сделать это? Что, если я собираюсь продать это же приложение трем клиентам, я бы сделал это по-другому? Есть ли что-то еще, что нужно сделать для распространения через AirWatch?

Опять же, поиск лучшей практики и то, как другие справляются с этой ситуацией. Просьба уточнить, есть ли у меня что-то неправильно.

ОБНОВЛЕНИЕ: Спасибо всем за ответы. Из того, что я узнал, как это делается, напрямую зависит от того, как клиент хочет справиться с ситуацией. В итоге клиент добавил меня в качестве администратора в свой аккаунт (мы работали вместе совсем немного). Мне удалось создать профиль распространения, создать и развернуть приложение для них. Не все клиенты сделают это по соображениям безопасности. В этом случае им нужно будет предоставить вам сертификат, как указано ниже, или вам нужно будет создать приложение на одной из своих машин, как сказал Бакей ниже... или через Apple, чтобы распространять приложение для них.

Не исправляйте эту информацию, если она неверна. Я действительно думаю, что это полезная информация для многих разработчиков.

Я принимаю ответ Патрика, потому что он ближе всего к тому, что я на самом деле сделал.

ОТВЕТЫ

Ответ 1

Есть два способа сделать это, но для обоих вы должны быть добавлены как член команды разработчиков вашего клиента. Как только вы это сделаете, вы (или, скорее всего, ваш клиент) выберете погоду, чтобы использовать свой собственный сертификат или собственный сертификат распространения, которым вы будете управлять.

Это можно сделать в любом случае, это только вопрос того, кто будет иметь право в будущем отправлять приложения с тем же сертификатом в той же учетной записи. Этот орган находится во владении связанной ключевой парой сертификата. Если вы добавлены в команду клиента dev и загрузите свой сертификат распространения, у вас не будет этого ключа и вы не сможете подписывать сборки рассылки с соответствующими профилями подготовки.

Следовательно, вы должны либо получить экспорт .p12 сертификата (который содержит ключ) из клиента для установки на вашем компьютере, чтобы вы могли его подписать. Это позволит вам отправить с вашего компьютера, но у вас есть свой секретный ключ clien'ts, который они хотели бы защитить. Другой вариант - использовать свой собственный запрос на подпись сертификата для создания сертификата распространения на учетной записи разработчика клиента. В этой ситуации только вы имеете контроль над сертификатом, и клиент должен создавать новые, если они захотят работать с другими разработчиками в будущем.

Как только вы это сделали, здесь является информативным руководством по распределению предприятий.

Ответ 2

Как агент предприятия, я скажу вам, что, если ваш клиент не живет под скалой (технически говорящий о портале Apple dev), я сомневаюсь, что они откажутся от частного ключа и сертификата. Если у них есть нулевой законный/контрактный доступ к исходному коду, который вы создали, единственный курс действий, говорящий на основе опыта, будет для вас, чтобы посетить их объект с исходным кодом, скомпилировать его на своем поле, в котором находится закрытый ключ и сертификации корпоративного дистрибутива, сборки и доставки IPA и, наконец, вернуть источник с собой. Вот как я скомпилировал каждую сборку у стороннего поставщика, где мы не являемся владельцем источника и его необходимо развернуть внутри.

На обратной стороне этого аргумента, если клиент по какой-то дикой причине хочет отказаться от ключей к своему замку предприятия и экспортировать закрытый ключ и сертификат распространения предприятия для вас... ради ВАШЕГО Я получит в письменной форме, каков объем вашего использования с этим сертификатом и каким-то образом документирует тот факт, что вы удалили ключ и сертификат после завершения процесса. Не открывайте себя на ответственности, потому что, если они разделяют это с вами, у них есть шанс, что они также могут поделиться им с кем-то другим, и, как мы все знаем, не все разработчики играют по правилам. Вы бы не хотели, чтобы вас обвинили в создании какого-нибудь мошеннического приложения под их именем.

Что касается повторного подписания файла IPA... AirWatch не позволит вам это сделать. AW допрашивает IPA при его загрузке, и он отмечает, что встроенный профиль подготовки не соответствует повторно подписанному IPA и баку. Это становится ситуацией с курятиной и яйцами, когда вам необходимо настроить профиль на устройстве перед установкой приложения, однако AirWatch не позволит вам развернуть приложение, если указанный выше встроенный профиль не является правильным.

Кроме того, @Caleb корректно относится к B2B, но модель ценообразования идет от проекта к устройству (iOS). Другими словами, если ваш контракт "вы можете установить это приложение на неограниченное количество устройств", то подход B2B будет взорван на всех лицах.

EDIT: Ниже приведены ваши варианты при редактировании Development Provisioning Profile в учетной записи предприятия iOS: Development Profile

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

Теперь вот ваши "опции" для редактирования Enterprise Provisioning Profile: Enterprise Profile

Как вы можете видеть, у вас нет возможности редактировать, какие пользователи или устройства портала могут использовать этот профиль, потому что он привязан к агенту CSR/private key и развертывается глобально.

Ответ 3

Вам понадобится:

  • Их сертификат.
  • Профиль их предоставления.

Это довольно обычная практика для .

Ответ 4

Мой вопрос: правильно ли это сделать?

Да.

Что делать, если я собираюсь продать это приложение 3 клиентам, я бы сделал это по-другому?

Нет, ты сделаешь то же самое. Вам нужно будет создавать приложение отдельно для каждого клиента, используя каждый сертификат распространения клиента.

Другой вариант - создать приложение и продать его своим клиентам с помощью механизма распределения B2B.