App2app provisioning что это
Перейти к содержимому

App2app provisioning что это

What is a provisioning profile used for when developing iPhone applications?

What is the purpose of a provisioning profile and why is it needed when developing an iPhone application? If I don’t have a provisioning profile, what happens?

user avatar

3 Answers 3

A provisioning profile is a collection of digital entities that uniquely ties developers and devices to an authorized iPhone Development Team and enables a device to be used for testing. A Development Provisioning Profile must be installed on each device on which you wish to run your application code. Each Development Provisioning Profile will contain a set of iPhone Development Certificates, Unique Device Identifiers and an App ID. Devices specified within the provisioning profile can be used for testing only by those individuals whose iPhone Development Certificates are included in the profile. A single device can contain multiple provisioning profiles.

A Beginner's Guide to iOS Provisioning Profiles

If you’ve spent any time developing an app for iOS, then you’ve probably stumbled across the bit of the Developer Console called ‘Certificates, Identifiers & Profiles’.

Certificates, Identifiers & Profiles

This is not a blog post about how to do anything in that section.

Instead, it’s a rough guide to what everything means — in the hope of providing some relief/context when you’ve just seen the error ‘No code signing identities’ for the millionth time and feel like throwing your laptop out the window while shouting ‘Code sign this!’

(Note: this article focuses on App Store apps, rather than in-house apps, which you can create through the Apple Developer Enterprise Program.)

Why Provisioning Profiles?

Good question. The key thing is that, unlike Android, you can’t install any old app on an iOS device: it has to be signed by Apple first.1 However, when you’re developing an app, you probably want to test it before sending it to Apple for approval. Provisioning profiles are simply a way for you to do that: they’re like a ‘temporary visa’ that lets you run and test your app on a physical device. And like all good visa schemes, this means dealing with some bureaucracy.

The Components

Provisioning profiles always require the following components:2

  • A certificate
  • A unique app identifier (an ‘App ID’)

In some cases, they also require:

  • A list of devices the app can run on
The Certificate

This is a public/private key-pair, which identifies who developed the app.3 (Without such certificates, I could e.g. create an app called ‘Facebook’ and pretend that it’s an update to the actual Facebook — and hence trick you into giving me your login credentials.)

When you try to create a new certificate, you’ll be presented with several options. For provisioning profiles, the key ones are:

  • iOS App Development : a development certificate. These are for developers who want to test the app on a physical device while writing code.
  • App Store and Ad-Hoc : a distribution certificate. These are for when you’re ready to give the app to other people — first for testing (the ‘Ad-Hoc’ bit) and then for general distribution via TestFlight or the App Store.

When you join an iOS development team, you’re either a ‘Member’ or an ‘Admin’. Anyone can create development certificates, but only those with admin privileges can create distribution certificates.

The App ID

This is a unique identifier for your app. Apple recommends using a ‘reverse-domain name style string’ of the form: com.yourcompanyname.yourappname . You can then associate ‘entitlements’ to your App ID, such as iCloud, Push Notifications, Apple Pay, etc.

It’s also possible to create ‘wildcard’ App IDs, e.g. com.yourcompanyname.* , which can be used for multiple apps. While these can be useful in some cases, note that you can’t associate entitlements to them.

Extra tip: if you’re planning on releasing an Android app as well, then you should avoid using hyphens (-) in your App ID — otherwise you won’t be able to use the same one on both platforms.

The List of Devices

This is a list of devices.

This is perhaps the most annoying part of the process: if you want to distribute your app to testers (without using TestFlight), then they need to send you their device’s ‘Unique Device Identifier’ or UDID. Unfortunately, you can’t find it within iOS itself: they’ll need to connect their device to a computer.

I heartily recommend the website, which provides clear, illustrated instructions about what to do. However, you should still mentally prepare yourself for people sending you all kinds of random, irrelevant strings with the question: ‘Is this it?’ (Hint: if it’s not a 40-character, hexadecimal string, then the answer is no.4)

Creating a Provisioning Profile

Congratulations, you’re now ready to build your provisioning profile! Again, there are quite a few options, but the main ones are:

  • iOS App Development: for testing the app on a physical device while developing.
  • Ad Hoc: for distributing the app to non-TestFlight testers (e.g. via HockeyApp).
  • App Store: for distributing the app via TestFlight or the App Store. (Note that this one doesn’t work on its own: your app will still need signing by Apple.)

Here are the key differences between them:

Provisioning Profile


App ID

List of Devices

iOS App Development

iOS App Development

App Store and Ad-Hoc

App Store and Ad-Hoc

So when iOS attempts to install an app, it checks the following things:

  • That the private key used to sign the app matches the public key in the certificate;
  • That the App ID is correct;
  • That the entitlements required are associated with the App ID;
  • That the device itself is in the list of devices.

If anyone of these conditions fail, then the app will not install — and you’ll see a greyed-out app icon with no error message or clue for how to proceed. But at least now you have somewhere to start: you can go through those four bullet points manually, and make sure everything is as it should be. (We’ve found it’s usually an issue with the list of devices.)

The End

I hope this post helped demystify what’s going on when you create a provisioning profile. If not, then please feel free to leave a question in the comments below!


1 This doesn’t apply to the iOS simulator or a jailbroken device. [back]
2 Note that these correspond to the sections of the left-hand menu within ‘Certificates, Identifiers & Profiles’. [back]
3 Although this is all a lot more elaborate than Android’s system, one of the great advantages is that you can recreate certificates. On Android, if you lose the original private key then you’re screwed: you won’t be able to update your original app, and you’ll have to convince all your existing users to download a new one. [back]
4 I once even got sent a 40-character, hexadecimal string that wasn’t a valid UDID, and looked nothing like the actual one they eventually sent me. To this day, I still have no idea where they got it from. [back]

Распространение приложения под iOS внутри компании (Enterprise Distribute iOS App in-house)

(Осторожно, под катом трафик)
Подготовка и распространение приложения IOS внутри компании весьма непростая задача, особенно когда приложение написано на Windows с использованием Visual studio, а большинство туториалов в интернете описывают исключительно MacOS с использованием Xcode. Однако после часов сражения с детищем Apple, нам удалось свершить казалось бы невозможное, а именно: скрестить жирафа с носорогом собрать IOS приложение на Xamarin в архив Xcode, сразу на MacOS, после получить нужные файлы для распространения, и в завершении создать ссылку, по которой будет распространяться приложение.

Да, на слух вроде не очень сложно. Однако когда дело касается разработки приложений под устройства Apple, всё становится в несколько раз непонятней и сложней. И после триумфальной, но нелёгкой победы, нам захотелось оставить свой след в истории, написав сей туториал.

Предварительные условия:

1. Должен быть Enterprise аккаунт Apple — $299 в год.

1 Шаг. Создание сертификата.

1. Сперва, на Mac, нужно создать запрос для создания сертификата. Для этого нужно открыть keychain access, например, через поиск:

2. Выбрать keychain access в левом верхнем углу экрана, в выпавшем меню выбрать “certificate assistant” —> “request a certificate from a certificate authority”, откроется соответствующие окно:

3. В появившемся окне заполняем поля “User Email Address” – свою электронную почту, и “Common Name” – имя ключа. А также выбираем пункт “Saved to disk”, чтобы сохранить файл запроса на компьютер. И нажимаем кнопку “Continue”:

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

5. После успешного сохранения появится следующее окно. Нажимаем “Done”:

6. После мы можем увидеть, что создался файл запроса в месте сохранения (в данном примере на рабочем столе). Или мы можем увидеть созданный ключ в списке ключей в “keychain access”:

7. Далее нам надо создать сертификат, это мы сможем сделать на сайте Apple для разработчиков, войдя в свой аккаунт:

8. После успешного входа в аккаунт мы переходим в “Certificates, IDs & Profiles”, так же на странице сертификатов нужно убедиться, что выбрано “IOS, tvOS, watchOS”:

9. Далее на странице, в разделе “Certificates”, нужно выбрать “Production”:

10. На странице нажимаем на кнопку с изображением “+”, чтобы создать сертификат. Появится страничка, на которой надо выбрать тип создаваемого сертификата:

11. В данном примере нас интересует метод дистрибьюции In-House, поэтому типом сертификата нужно выбрать “In-House and Ad Hoc”. После нажать кнопку “Continue”:

12. После мы перейдём к следующей странице создания сертификата на которой будет описано как создать запрос на MacOS для сертификата. Мы уже создали этот запрос в предыдущих пунктах. Нажимаем кнопку “Continue”:

13. На следующем этапе вам потребуется загрузить файл запроса, который мы создали ранее на рабочем столе. После успешной загрузки нажмите “Continue”:

14. После произойдёт генерация сертификата, и на следующей странице его можно будет скачать на компьютер:

15. Скачиваем сертификат, в данном примере на рабочий стол. Так же мы можем увидеть созданный сертификат на сайте:

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

2 Шаг. Создание Apps ID.

На предыдущем шаге мы успешно создали сертификат, теперь нам нужно создать Apps ID. Для этого нужно:

1. На сайте Apple для разработчиков, в своём аккаунте перейти сперва в “Certificates, IDs & Profiles”, так же на странице сертификатов нужно убедиться, что выбрано “IOS, tvOS, watchOS”:

2. Далее на странице, в разделе “Identifiers”, нужно выбрать “App IDs”:

3. На странице нажимаем на кнопку с изображением “+”, чтобы создать App ID. Появится страничка, на которой надо выбрать настройки создаваемого ID. Настройки ID индивидуальны для вашего приложения, единственное важное уточнение – в графе App ID Suffix нужно выбрать Explicit App ID:

4. После создания App ID, его можно увидеть на сайте:

По итогу двух шагов, мы успешно получили сертификат и создали App ID. Далее нам надо при помощи созданного сертификата создать Provisioning Profiles. И это приводит нас к следующему шагу “3 Шаг. Создание Provisioning Profiles”.

3 Шаг. Создание Provisioning Profiles.

На предыдущем шаге мы успешно создали сертификат, теперь нам нужно с его помощью создать Provisioning Profiles. Для этого нужно:

1. На сайте Apple для разработчиков, в своём аккаунте перейти сперва в “Certificates, IDs & Profiles”, так же на странице сертификатов нужно убедиться, что выбрано “IOS, tvOS, watchOS”:

2. Далее на странице, в разделе “Provisioning Profiles”, нужно выбрать “ Distribution”:

3. На странице нажимаем на кнопку с изображением “+”, чтобы создать Provisioning Profiles. Появится страничка, на которой надо выбрать тип создаваемого профайла:

4. В данном примере нас интересует In-House метод дестрибьюции, соответственно выбираем тип профайла “In House” и нажимаем на кнопку “Continue”:

5. На следующей странице нужно выбрать ранее созданный, на шаге 2, App ID:

6. После нажатия кнопки “Continue” мы перейдём к выбору сертификата, мы создали его на 1 шаге. Далее нажимаем на кнопку “Continue”:

7. На следующей странице нам надо заполнить поле с именем профайла и проверить данные перед генерацией профайла:

8. После профайл будет сгенерирован и его можно будет скачать:

9. Скачиваем Provisioning Profile, в данном примере на рабочий стол. Так же мы можем увидеть созданный provisioning profile на сайте, и увидеть, что он активен:

По итогу 3 шагов мы успешно создали Provisioning Profile.

4 Шаг. Создание Xcode архивов (.xcarchive) на базе своего приложения в Visual Studio на Windows и последующего создания .ipa и .plist файлов

Предыдущие шаги выполнялись на компьютере от Apple (Mac), далее я расскажу как создавать .xcarchive в Visual Studio 2017 для Windows, сразу на Mac.

1. Для этого нам потребуется приложение Xamarin в Visual Studio, которое будет подключено к Mac:

2. В решение нужно выбрать проект IOS, нажав на него правой кнопкой мыши. В появившемся меню выбрать “Properties”. В открывшемся окне выбрать пункт “ios bundle setting”. Далее выбрать в “bundle setting” – “manual provisioning”, а ниже в графе “manual provisioning” выбрать свой сертификат и профайл который мы создали на предыдущих этапах:

3. В проекте IOS нужно выбрать файл Info.plist и убедится что “bundle identifier” совпадает с нужным App ID:

4. После откройте командную строку разработчика в Visual Studio (от имени администратора) “Developer Command Prompt for VS 2017” и либо перейдите в директорию с ios проектом, либо укажите полный адрес при создании команды. Данная команда создаст архив .xcarchive на Mac из Visual Studio. Сам по себе архив не содержит нужных нам для распространения .ipa и .plist файла поэтому после генерации архива нам потребуется создать их. Подробнее о том как создавать архив можно узнать здесь.

Команда: msbuild /p:Configuration=Release /p:ServerAddress= /p:ServerUser=xamUser /p:Platform=iPhone /p:ArchiveOnBuild=true /t:»Build» MyProject.csproj

5. После успешного выполнения команды на Mac должен был создастся архив. Нам надо запустить Xcode, в нём выбрать “Windows” и в этом меню выбрать “Organazer”. Там в разделе “Archive” мы увидим созданный архив .xcarchive:

6. Теперь нам надо создать файлы .ipa и .plist, на основе созданного архива.

При помощи их мы сможем распространять своё приложение минуя AppStore, например, внутри компании. Далее нам надо нажать кнопку “Distribute App”. В появившемся меню выбрать “Enterprise” и нажать кнопку “Next”:

7. Далее нужно выбрать устройства, на которые можно распространять и обязательно выбрать “include manifest for over-the-air installation”, для того чтобы можно было скачать приложение из браузера:

8. В следующем окне нужно указать “Name” – имя приложения; “App URL” – путь к .ipa файлу;”Display Image URL” – Путь к иконке 57х57;”Full Size Image URL” – Путь к иконке 512х512.

Важно что бы сервер на котором размещены файлы .ipa и .plist, был с шифрованием, то есть обязательно https. В примере используется сервис dropbox. При использовании сервиса dropbox важно знать: правильный путь к файлу по публичной ссылке должен начинаться не с “”, как указано в сгенерированной ссылке, а с “”.

9. На следующем этапе нам нужно выбрать созданные сертификат и Provisioning Profile:

10. После мы увидим успешно собранное приложение, и мы должны выбрать куда сохранить папку с приложением, которое мы после будем распространять:

11. После сохранения на рабочем столе создалась папка. Содержимое папки вы можете видеть на скриншотах ниже, при генерации создаётся 4 файла .plist и обычно 1 .ipa, но в проверочном приложении это немного не так, но нас в данном случае будет интересовать файл у которого в имени только название нашего приложения. Что касается 4 файлов .plist, то далее нам понадобится файл “manifest.plist”. Для установки приложения нужен plist, в котором описаны предустановочные свойства. Подробнее узнать о Enterprise Distribution и посмотреть как выглядит manifest.plist можно здесь:

Таким образом на данном шаге мы успешно создали .ipa и .plist файлы приложения, созданного в Visual Studio 2017, и которые мы будем использовать для In-House дестрибьюции.

5 Шаг. Распространение приложения

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

1. Сперва нам нужно разместить файлы (иконки, .ipa файл и manifest.plist) на dropbox и делаем их доступными по ссылке:

2. После создаём html файл, следующего содержания:

3. Далее выкладываем этот html файл на локальный IIS (или ваш сайт), и пройдя по данной ссылке с мобильного устройства нам предложат установить приложение. После установки приложения пользователю нужно подтвердить доверие сертификату на устройстве Settings → General → Device Management → «Enterprise Name» тогда только пользователи смогут открыть приложение:

Добавить комментарий

Ваш адрес email не будет опубликован.