Понимание профилей обеспечения и Airwatch MDM - PullRequest
0 голосов
/ 10 сентября 2018

Я поддерживаю несколько корпоративных приложений для iOS, которые распространяются с помощью AirWatch MDM. Первоначально первая пара приложений была распределена по одному и тому же профилю предоставления по шаблону.

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

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

У меня есть пара вопросов с точки зрения Airwatch / MDM:

  • Рекомендуется ли каждому приложению в формате предприятия иметь свой собственный профиль или поделиться профилями, если это возможно?

  • Можно ли распространять профиль с возможностями удаленно?

  • Когда срок действия сертификата истекает, есть ли возможность исправить приложения без обновление каждого приложения в масштабах всего предприятия с использованием устаревшего сертификат

  • Могу ли я отозвать активный сертификат, который используется для опубликованных внутри приложений, до истечения срока действия, не влияя на них?

  • С точки зрения администрирования сертификатов, должны ли мы создать общий Apple ID с общим логином или привязать его к одному конкретному разработчику?

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

1 Ответ

0 голосов
/ 07 ноября 2018

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

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

Можно ли распространять профиль с возможностями удаленно?

Да, но распространение нового профиля через Airwatch не всегда работает. Это скорее проблема подписания, чем возможностей

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

Мой совет - создать новую версию приложения и подписать IPA с новым профилем обеспечения, а затем выпустить его в качестве обновления. И дополнительным преимуществом является то, что вы будете отслеживать, кто имеет более старую версию (которая перестанет работать после истечения срока действия профиля), в то время как новая версия будет работать просто отлично.

Когда срок действия сертификата истекает, можно ли как-то исправить приложения, не обновляя каждое приложение на предприятии, используя сертификат с истекающим сроком действия?

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

Могу ли я отозвать активный сертификат, который используется для опубликованных внутри приложений, до истечения срока действия, не влияя на них?

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

Источник: https://help.apple.com/developer-account/#/dev7d381a7ff

См. Документацию Apple по управлению просроченными сертификатами, она длинная, но исчерпывающая.

С точки зрения администрирования сертификатов, должны ли мы создать общий Apple ID с общим логином или привязать его к одному конкретному разработчику?

Используйте роли. Агент команды является администратором учетной записи и используется только тогда, когда вам нужно принять новую TOS, продлить членство и т. Д. Настройте учетные записи разработчиков (я предпочитаю одну для каждого разработчика, чтобы у каждого был свой собственный сертификат разработчика) и сделайте руководителя группы администратором учетной записи develoepr. Таким образом, руководитель группы может настроить приложения для развертывания, в то время как разработчик сосредоточится на кодировании.

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

Поддержка ваших мобильных приложений, выпуск обновлений для новых выпусков iOS и исправление ошибок - трудоемкое занятие. И так же поддержание сертификатов и развертывание приложений. Вы также должны взимать плату с этих клиентов, если вы делаете B2B

...