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

Question

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

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

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

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

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

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

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

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

Answer 1

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

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

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

После того, как вы это сделали, here является информативным справочником для распространения предприятия.

Answer 2

Вам потребуется:

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

Это довольно common practise to do this.

Answer 3

Мой вопрос в том, что это правильный способ сделать это?

Да.

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

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

Другой вариант - создать приложение и продать его вашим клиентам, используя B2B distribution mechanism.

Answer 4

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

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

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

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

EDIT: Ниже приведены ваши варианты при редактировании Development Provisioning Profile в качестве Enterprise IOS Счет:

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

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

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

Answer 5

Этот ответ имеет сведение о лучшем способе, чтобы дать 3-участник поставщик возможности подписывать приложения под учетной записью предприятия: iOS Enterprise Provisioning Profiles: How many can I have?