Меню

About Ad Hoc Provisioning Profiles

Exporting Ad Hoc IPA

Apple allows app distribution for testing on registered devices using an Ad-Hoc or Enterprise provisioning profile.

The output file you create is an iOS App file (a file with an .ipa filename extension) that is then used to install your app on registered devices.

Following are the steps to export your app for testing:

  1. Register all test devices using the instructions here.
  2. Archive your app (see instructions below).
  3. Export the archive to an IPA file using either an Ad Hoc or Enterprise provisioning profile to code sign your app.
  4. Install the app on test devices.

About Ad Hoc Provisioning Profiles

An ad hoc provisioning profile is a distribution provisioning profile that allows your app to be installed on designated devices and to use app services without the assistance of Xcode.

There are 4 types of distribution provisioning profiles you can create for apps:

iOS App Store — for distributing through the apple app store.

Ad Hoc — for installing on designated devices.

Enterprise — for distributing an app within your organization.

Development — For distributing within members of your team.

Make sure you have created an Ad Hoc provisioning profile specifying an App ID that matches one or more of your apps, a set of test devices, and a single distribution certificate at the developer portal.

We warmly recommend any company to apply to Apple’s iOS Developer Enterprise Program, and sign iOS apps for internal use with an Enterprise certificate.
* Please note that this is not a legal document, and refer to Apple’s website for the exact terms of service for any Apple service.

Archiving Your App

Create an archive of your app. Xcode stores this archive in the Archives organizer.

In the Xcode project editor, choose Generic iOS Device — or your device name from the Scheme toolbar menu. (You can’t create an archive of a simulator build).

If a device is connected to your Mac, the device name appears in the Scheme toolbar menu. When you disconnect the device, the menu item changes to the Generic iOS Device .

alt

Choose Product —> Archive.

The Archives organizer appears and displays the new archive.

Xcode runs preliminary validation tests on the archive. To create an IPA file press the Distribute App button.

alt

Exporting Your App to an IPA (Ad Hoc provisioning profile)

To create an iOS App file for testing, select an archive in the Archives organizer.

alt

Click the Distribute App button. Select an export option, and click Next.

To distribute your app to users with designated devices, choose the Save for Ad Hoc Deployment . The app will be code signed with the distribution certificate.

alt

In the dialog that appears, choose a signing method and click Next.

alt

In the distributions options screen, choose the options you prefer and click Next.

alt

After you choose the signing options click Next.

alt

In the dialog that appears, review the app, its entitlements, and the provisioning profile.
Click Export and finally the Finder shows the exported files. Save it to your desired location.

Installing Your App on Test Devices Using Xcode

You can install iOS App files on devices using Xcode.

To install an app on a device using Xcode

Connect the device to your Mac.

In Xcode, choose Window > Devices and select the device under Devices.

In the Installed Apps table, click the Add button (+) below the table.

install_an_app

In the dialog that appears, choose the iOS App file and click Open.

chose file

The app is now added to the list of installed app end is installed n the device.

Accessing Logs from Xcode

Accessing raw logs on an iOS device requires hooking up that device via a USB cable to a computer. System logs often help a lot in debugging vague problems around app installation.

Many times, the error displayed on an iOS device screen is too generic, but the system logs explain more thoroughly the reason for the problem. In order to get the logs, complete the following:

  • Open Xcode.
  • Open menu Window -> Devices.
  • Select the device which you want to inspect.
  • Click on the View Device Logs button.
  • A new window will open up with up-to-date logs from the device.

Источник



Распространение приложения под 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=10.211.55.2 /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 важно знать: правильный путь к файлу по публичной ссылке должен начинаться не с “https://www.dropbox.com/”, как указано в сгенерированной ссылке, а с “https://dl.dropboxusercontent.com/”.

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» тогда только пользователи смогут открыть приложение:

Источник

Ad hoc ios инструкция

iOS Ad-Hoc Distribution Using Firebase Hosting and Storage

Full guide on how to do Ad Hoc distribution for your iOS app using Google’s Firebase Hosting and Storage

Beta testing your iOS app can be done in many ways. A few of the most common methods are:

  • Direct Deployment (via Xcode)
  • TestFlight
  • Ad-Hoc Distribution

Direct deployment is great if you know your testers personally and can easily meet up with them and connect their devices to your computer. Even in this case though, you will have to arrange another meeting if any changes are made to the app. Usually this testing method is only suitable for yourself, or for cases where updates are not common.

TestFlight is an excellent option, and greatly simplifies this entire process, but it has one main negative: Your app must pass the approval process for the App Store. For many, this isn’t much of an obstacle, but for me, with a very rudimentary app that is far from complete, this obstacle was signifcant enough to deter me from TestFlight (for these early stages).

Ad-Hoc distribution has the remote deployment benefits of TestFlight, without the approval process requirement. It allows you to deploy your app to anyone in the world, provided they do a few small (one time) steps to send you information about their device. Delivering updates is also very straightforward.

For me, I have no direct hosting capabilities, and I was already using Firebase in my project, so Firebase Hosting was a perfect solution for hosting a website, and Firebase Storage was a perfect solution for storing files on a server. AWS could achieve similar things, of course, but I found the APIs for AWS to be much less friendly.

  1. Apple Developer Account (Paid)
  2. Xcode
  3. Firebase Project (start here)

This guide will accomplish the steps detailed on this page. I found it very helpful, but not completely clear on the full implementation.

Follow the steps here to set up the Python SDK.

As one of the steps in the link above, you will generate a service account key. This needs to be placed in the same directory as the provided python program for it to run (or you can modify the python program to look for the key in a different location).

Читайте также:  Проверка жесткого диска с помощью программы HDDScan

Never share this key with anyone or post it anywhere. Anyone with access to it has complete control over your Firebase project.

To set up Firebase Hosting, you will need to perform the steps on this page. I recommend doing this in your own folder within the project directory. This will generate a firebase.json file and a «public» folder containing a placeholder HTML file for your website.

For my website, I simply modified the generated HTML file to have a single button which installs the app. That HTML file is included in the repo as index.html (with a placeholder link instead of the actual link). I will explain more about that file later.

You will need to edit prepareImages.py and prepareDeploy.py to have the correct Firebase bucket name (replace «bucket-name» with your actual bucket name). You can either use the default bucket, or specify a custom bucket. Find more information about this here.

You must also replace «app-name» in prepareDeploy.py with your desired app name. This must match the app-name specified later in the guide.

Apple Developer Portal

Before deploying your app, you will need to do two things in the developer portal:

  1. Add test devices
  2. Generate an Ad-Hoc provisioning profile with those devices included

These steps will need to be repeated every time you add new testers. For details on these steps, see the following two sections.

Adding Test Devices

Obtaining the UDID of devices

Adding test devices will be done using the UDID of the device. So, before you can add a user’s device, they will need to obtain its UDID.

This can be done using either iTunes or Xcode. Assuming the user is remote, iTunes is likely the easier option, because many people already have it installed. Follow these steps to find the UDID of a device in iTunes.

If the user does have Xcode, or you are able to meet them in person and connect their device to your computer, the UDID can be easily found in Xcode by connecting the device and navigating to Window->Devices and Simulators. Then, the UDID will be displayed after the label «Identifier» when you select the device.

As with the service account key, do not share your UDID or the UDIDs of any of your testers with anyone. Doing so could allow illegitimate apps to be installed to those devices.

Once you have the UDID of the device(s) in question, you are ready to add them to your developer account.

Then, follow these steps to add a device:

image

image

Generating an Ad-Hoc Provisioning Profile

Once you’ve added devices, you can create a provisioning profile with those devices included. This is done in the same area of the developer portal as the device adding:

image

image

image

image

After that point, the steps should be straightforward. Once finished, make sure to download your new provisioning profile.

Deploying Your App

Once your users are added and your provisioning profile has been created, you are ready to deploy your app.

You must have two images prepared before deploying your app. They will determine what your app icon looks like once the app is installed to someone’s device. They must be 57×57 and 512×512. I have provided black placeholder images with these sizes.

Once you have your images, run prepareImages.py:

(images must be in the same directory as prepareImages.py)

This will upload these images to Firebase Storage and make them public so that you can use the same links to access them every time. This makes the following steps much smoother.

NOTE: If you do not need to change the images before deploying, you will only need to do this step once.

  1. Archive your app by going to Product->Archive
  2. Navigate to your archive via Window->Organizer
  3. Select your archive and click Distribute App
  4. Choose Ad-Hoc as the distribution method
  5. Edit the distribution options as desired. Make sure to check «Include manifest for over-the-air installation»
  6. Enter links for the ipa and images.

For this step, you must provide links to three files. Enter the following links:

Replace app-name in the first link with whatever you wrote in the «Name» field above all the link fields.

You can choose anything for app-name. Just make sure you are consistent and use the same app-name when editing prepareDeploy.py

You can find your bucket-name by navigating to https://console.firebase.google.com and clicking on Develop (if not selected) and then Storage. It should display gs://bucket-name.appspot.com at the top and if you ran prepareImages.py earlier you should also see two images in a list.

Note that you have not uploaded your .ipa file yet, so that link will not work if you click on it. This is expected.

  1. Choose «Manually manage signing»
  2. Select the signing certificate you used to create your Ad-Hoc provisioning profile, and then select the downloaded provisioning profile
  3. Once finished, click Export
  4. When prompted where to export the archive, choose the archives folder in this repo’s folder. You may choose another folder, but then you will have to edit prepareDeploy.py to look in that folder instead.

NOTE: prepareDeploy.py will look in the «archives» folder, find the latest archive, and upload files from that archive to your bucket. If you would rather have it directly upload files from known file locations, the file can easily be edited to do that. Look at prepareImages.py for an example of this.

  1. Navigate to the location of prepareDeploy.py and run it

Your Firebase site’s HTML file must contain a specifically formatted link in order for the tapping of the link to correctly install the app on a tester’s device.

If using the provided HTML file, you can just edit bucket-name to be your bucket name. You can also edit the other text in this app to have your app name and any new features you might have added to the app.

If using your own HTML file, you must have a link that is formatted as follows:

This link must begin with itms-services://?action=download-manifest&url= . What follows is an encoded public link to your recently uploaded manifest.plist file. If your link includes other normally encoded characters, you will need to encode it yourself or it will not work when tapped on. I found this site helpful for encoding.

Once the HTML file is edited appropriately, you are finally ready to deploy your site!

If you followed the steps for setting up Firebase Hosting earlier, you should have only one step remaining. Navigate to the folder containing your firebase.json file and public folder (which contains the index.html file you just edited) and run the following:

Once this completes, it will print the link where your website is currently hosted. Keep this link for the next step.

Installing Your App

If you included your own device in the provisioning profile, you can test the same installation process your testers will follow.

Simply navigate to the link provided in the last step and tap the «INSTALL APP» button (or whatever format of link you chose). If you’ve followed all the steps above, your app should begin installing immediately to your device!

Now, you just need to provide this link to your testers and they will be able to install your app. You can recommend that they save it as a bookmark or a web clip on their home screen so that it is easy for them to come back to later when you make changes to the app.

Also, if you have push notifications configured for your app, you can send one out to direct them to this link every time you have a new update available.

Hopefully this guide helped you out. I found this seemingly simple process to be quite annoying, and most of the links I followed to get this working for myself left out a few very important details that costed me tons of time. My hope is that this guide does not leave out any of these vital details, and saves you some time. If something looks missing or wrong, feel free to add an issue and I will get to it as soon as I can.

Читайте также:  Измельчают вс электроизмельчители с режущим механизмом

About

Full guide on how to do Ad Hoc distribution for your iOS app using Google’s Firebase Hosting and Storage

Источник

Как распространять iOS приложения минуя AppStore

При создании мобильного приложения под iPad для одной крупной компании перед нами встал вопрос — как распространять данное приложение. Самый распространённый вариант — конечно, через AppStore.

Но данный вариант нам не подошел, так как приложение создавалось для работников компании, а не для общего пользования. Остался только второй вариант — Enterprise Program (подробнее о Developer Program и Enterprise Program).

Клиент купил лицензию, мы занимались разработкой, и вот настало время выкладывать приложение. До этого мы выкладывали приложения в AppStore, а вот опыта работы с in-house приложениями (они предполагают внутреннее использование в компании и не предназначены для выкладывания в общий доступ) не было. К нашему удивлению, мы не нашли полноценных статей, описывающих данный процесс, поэтому решили составить некую инструкцию, которая поможет сэкономить кому-то время.

Получение пакета файлов приложения

Итак, после того как разработка завершена, необходимо выполнить следующие шаги:

  1. Создать Distribution-сертификат (подробное описание процесса).
  2. Создать Distribution Provisioning Profile
  3. Подписать приложение соответствующим Provisioning Profile и создать пакет, который потом можно распространять. Для этого в XCode в меню Product нужно выбрать Archive и отметить пункт — Save for Enterprise or Ad-Hoc Deployment.

Далее выбрать подпись (необходимо выбрать тот provisioning profile который создали выше)

Сохранить полученный пакет. Не забудьте поставить галочку рядом Save for Enterprise Distribution (без этого вы не сможете получить plist-файл). В поле Application URL указываем полный путь к ipa файлу на сервере (http://www.yoursite.com/dir/yourFile.ipa)

На выходе мы получим ipa- и plist-файлы, их уже можно переслать людям, которым нужно установить приложение. Но для установки на iPad (iPhone) необходимо подключить его к компьютеру (при этом пользователям Windows необходимы еще и некоторые танцы с бубном).

Установка приложения через интернет

А как быть, если под рукой нет компьютера? Это как раз был наш случай, так как приложение предназначалось для торговых представителей компании заказчика, а они по роду своей деятельности чаще всего находятся в пути и не имеют компьютера под рукой. Встал вопрос: «А как же распространять in-house приложения (кстати, то же самое справедливо и для Ad Hoc distribution — прямой установки файла-сборки приложения через iTunes), не используя компьютер?» Всё оказалось просто, даже очень просто!

Нужно выложить ранее созданные ipa- и plist-файлы на сервер, к которому есть http (или https) доступ. Затем создать простой html-файл, в котором будет ссылка на plist-файл следующего вида:

И заменить #your_plist_file_path.plist# на полный путь к своему plist-файлу (важный ньюанс: в имени plist-файла не должно содержаться пробелов). Т.е. код должен получиться примерно таким:

Пользователь, зайдя на сайт со своего iPhone или iPad, нажмет на эту ссылку и получит сообщение: «Хотите ли вы установить данное приложение?». Вот, собственно, и всё.

Пара мелочей

Дополнительное преимущество распространения in-house состоит в том, что приложение не проходит проверки в Apple, и соответственно, не «зависает» там на 1-2 недели (а иногда и больше), что очень полезно для исправления ошибок и внесения срочных изменений.

Все описанное работает и для распространения приложения путем Ad Hoc. Единственное отличие: при создании Provisioning Profile необходимо выбрать соответствующий пункт в Distribution Method и привязать Provisioning Profile к профайлу устройства (иначе приложение не будет работать).

Также можно посмотреть порядок действий на видео.

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Читают сейчас

Редакторский дайджест

Присылаем лучшие статьи раз в месяц

Скоро на этот адрес придет письмо. Подтвердите подписку, если всё в силе.

  • Скопировать ссылку
  • Facebook
  • Twitter
  • ВКонтакте
  • Telegram
  • Pocket

Похожие публикации

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

Автоматизация бизнес-процессов. Ad-hoc изменения на примере из жизни. Часть 3

Решение проблем с Ad Hoc Distribution под Windows

Курсы

Профессия iOS-разработчик
Веб-разработка для начинающих
Разработка приложений на Kotlin
Разработка под Android: базовый уровень
Разработка на C#

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Минуточку внимания

Комментарии 21

Где-то прочитал, что на одно устройство одновременно можно установить enterprise (in-house) приложения только от одного разработчика.
Т.е. две компании А и 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. Потом скомпилирует и создаст архив. Т.е. клиент имея только архив — не сможет его переподписать, т.к. нужно сначала скомпилировать проект с нужным профайлом

Не совсем уверен насчет некоторых моментов.

Насчет первого. Все-таки она называется 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 аккаунту, а мне хотелось бы знать можно ли совсем исключить обмен какими-либо паролями или логинами.

Источник