Альтернативные решения для корпоративного приложения для корпоративных приложений iPhone

Ответ 1

Вы можете отправить приложение как совершенно бесплатное приложение в AppStore, но потребовать, чтобы пользователь выполнил вход и аутентифицировал его использование. Таким образом, любой может загрузить его, но вы можете контролировать, кто может его использовать. Apple делает все для вас, и вам не нужно беспокоиться о развертываниях Ad-Hoc или ИТ-отделах.

Затем вы создаете действительно простую систему управления конфигурацией на веб-хосте (или платформе, такой как Google AppEngine), которая управляет аутентификацией приложений.

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

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

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

Этот стиль дистрибуции очень полезен, если вы хотите контролировать, кто может использовать приложение, но хотите, чтобы легкость развертывания, предоставляемая AppStore.

Apple приняла множество приложений в AppStore, которые используют этот метод аутентификации на удаленном сервере (Skype - прекрасный пример).

Если вы отслеживаете UDID устройства на сервере конфигурации, вы также можете предварительно загрузить его, чтобы разрешить работу определенного набора устройств.

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

Кроме того, поскольку действие аутентифицирующих устройств не является процессором или интенсивностью данных, вы, вероятно, никогда не понесете затраты, если вы построите это на Google AppEngine, так как вы никогда не перейдете к свободным квотам, и вы получите стабильность и масштабируемость Google бэкэнд-архитектура.

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

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

Если вы выполняете аутентификацию приложения при каждом запуске, вы можете изменить информацию о подключении на сервере конфигурации, и приложение обновится до новой информации без необходимости нового развертывания. Пользователю просто нужно перезапустить приложение. Это дает вашему клиенту гибкость в изменении внутренней конфигурации сети без аннулирования кода приложения. Вы также можете настроить эту информацию вручную в приложении, но при этом вы должны устанавливать ИТ-затраты при настройке приложения на каждом устройстве, и если вы уже собираетесь настроить систему управления конфигурацией, вы также можете ее использовать.

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

Ответ 2

Я изучал это вчера и сегодня, и кажется, что Apple только что (на прошлой неделе) удалила потребность 500 сотрудников для развития предприятия. Тем не менее, я считаю, что вам нужно будет разработать/развернуть для конкретного клиента с помощью инструментария разработки, зарегистрированного клиентом.

Итак, если вы работаете с клиентом A и клиентом B, оба клиента A и B должны будут подписаться с Apple в качестве бизнес-разработчиков, после чего вы сможете разрабатывать приложения для них (как подрядчика) и использовать их инструменты для создавать и развертывать на своих предприятиях. Я бы подумал, что было бы хорошей идеей для вашей компании также зарегистрироваться в качестве разработчика бизнеса.

Apple по-прежнему требует, чтобы DUN и Bradstreet DUNS подписались как бизнес-разработчик.

Ответ 3

О единственном реальном выборе, который у вас есть, есть...

• До 100 устройств в виде ad-hoc.
• Предпринимательское распределение (требуется > 500 сотрудников)
• Каждый человек должен перенести свое устройство на какой-то ИТ-центр и создать его как "разработчик". (Yikes!)
• Тюрьма разбитым.

Разрушенная тюрьмой может показаться страшной, но на самом деле она довольно продвинутая, теперь-в-днях, и ее можно легко управлять. Тем не менее, это лишает вас гарантии (если вы не хотите восстановить-to- factory и не будете честны в этом;)

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

Сообщите нам, что вы решите, и плюсы и минусы этого метода.

Ответ 4

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

Ответ 5

Оли сказала:

О единственном реальном выборе у вас есть... До 100 устройств в виде ad-hoc. Предпринимательское распределение (требуется > 500 сотрудников) Каждый должен перейти на свое устройство до какого-то ИТ-центра и получить встроенное устройство. (Yikes!) Тюрьма-сломаны.

Но быть ясным (исправьте меня, если я ошибаюсь):

• Если вы используете метод распределения "Ad-hoc", ваши клиенты увидят, что приложение исчезнет через ровно 3 месяца.
• для тестирования может использоваться до 100 устройств (т.е. используется в "режиме разработчика" ), и, кроме того, приложение исчезнет через 3 месяца.

Итак, Apple не дает нам выбора, ты действительно большой (более 500 сотрудников)? нормально, так что вы можете делать то, что хотите, и т.д., иначе... "bybyby"

Кроме того, забудьте о том, что сказал ранее "Брайс", приложение, подобное тому, которое он описал, будет отклонено с мотивацией "лимитированной аудитории".

iOS не для корпоративного приложения.... если вы не хотите полагаться на некоторых умных хакеров (т.е. джейлбрейка)

Ответ 6

Распределение ad-hoc ограничено до 100 устройств на одно приложение, это правда, но вы можете добавить проект n раз в центр разработчика Apple, чтобы вы могли развернуть его на n * 100 устройствах

Ответ 7

Как яблоко гарантирует, что ваше предприятие имеет более 500 человек? Я бы все равно пропустил программу предприятия...

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

Для будущей ремонтопригодности, корпоративный режим - это путь, поэтому посмотрите, можете ли вы перемещаться по этому процессу, не упоминая, что у вас может быть не 500 пользователей.

Кроме того, я видел ваш комментарий о разработке с использованием MonoTouch. Я бы поговорил с Apple об этом, прежде чем делать что-либо еще, потому что, учитывая недавние изменения в политике, я уверен, что это приведет к тому, что ваше приложение будет запрещено в App Store и Enterprise.

Изменить: я проверил веб-страницу Mono. Кажется, что Apple все еще может позволить моно приложениям, а создатели Mono настаивают на том, что она кошерная, но у вас может возникнуть риск того, что ваше будущее приложение будет вытаскиваться с телефонов в любое время.

Лучшее редактирование: прямо с моно-сайта: Enterprise MonoTouch

Важно отметить, что новые условия соглашения с разработчиками iPhone предназначены для развертывания AppStore, а не для корпоративной программы, которая позволяет развертывать собственное приложение для пользователей на предприятии (с использованием программы Enterprise Deployment).

Таким образом, вы можете быть там до тех пор, пока можете попасть в корпоративную программу.

Ответ 8

Вы можете полностью обойти одобрение App-Store или Enterprise Developer Program, если вы разрабатываете приложение как чистое решение HTML5. Эта технология называется webapps. И они могут быть довольно продвинутыми по функциональности. Вы автоматически получаете перекрестную готовность и очень простые варианты развертывания (поскольку веб-клип может быть распространен через конфигурационные файлы .mobileconfig) См. http://www.apple.com/webapps/whatarewebapps.html

Ответ 9

Существует другое решение: собственный магазин приложений:

http://rhomobile.com/products/rhogallery/

к сожалению, только в сочетании с RhoHub.

Или: http://www.appcentral.com/

Дополнительная информация: http://www.apple.com/iphone/business/integration/mdm/ http://www.cio.com/article/638175/Emerging_Tech_Alternatives_to_Apple_App_Store_For_Enterprises?page=2&taxonomyId=3002

Ответ 10

Теоретически предлагаемое решение о публикации бесплатного приложения, предназначенного для одной компании, недействительно, поскольку опубликованные приложения в магазине приложений не должны быть предназначены для "ограниченной аудитории" (независимо от того, что это означает), в соответствии с:

http://appreview.tumblr.com/post/952395621/cannot-be-intended-for-a-limited-audience

Кто-нибудь пробовал это с успехом? Любые другие идеи?