Альтернативные решения для внутреннего распределения корпоративного приложения iPhone
Клиент попросил, чтобы мы разработали собственное внутреннее приложение для управления их системами бэкенда. Однако мы - небольшая строительная компания, и я уверен, что их компания не имеет> 500 сотрудников.
Есть ли какая-либо альтернатива, уже подобная, решения распределения этого приложения к их компании, не проходя программу предприятия iPhone?
(просто для уточнения: очевидно, мы хотели бы пройти официальную программу предприятия, но видящий, как компания не имеет> 500 сотрудников, это не возможно).
ОБНОВЛЕНИЕ (27/09): кажется, что Apple удалила 500 пределов сотрудника для распределения предприятия, Посмотрите здесь. Таким образом, это, вероятно, будет нашим маршрутом теперь (который полезен, потому что приложение обращается к завершению). Я обновлю это, поскольку мы проходим процесс, если кто-либо хотел бы меня к, так, чтобы другие могли понять то, на что похож фактический процесс.
7 ответов
Вы можете представить приложение как совершенно бесплатное в AppStore, но потребовать, чтобы пользователь вошел в систему и прошел аутентификацию для его использования. Таким образом, любой может скачать его, но вы контролируете, кто может им пользоваться. Apple делает все распространение за вас, и вам не нужно беспокоиться о специальных развертываниях или ИТ-отделах.
Затем вы создаете действительно простую систему управления конфигурацией на веб-хосте (или платформе типа Google AppEngine), которая управляет аутентификацией приложений.
Когда пользователь запускает бесплатное приложение, его просят ввести имя пользователя/пароль/что угодно. Эта информация отправляется в веб-систему управления конфигурацией и подтверждается. Если приложение получает приемлемое подтверждение от системы управления конфигурацией, оно разблокирует себя для использования данным пользователем.
Приложение может либо заново проходить аутентификацию при каждом запуске (полезно, если вы хотите иметь много контроля), либо хранить локальный ключевой файл, указывающий на то, что оно прошло аутентификацию. Если при запуске приложения оно видит локальный ключевой файл, то считает себя прошедшим аутентификацию и больше не проверяет его.
Используете ли вы одну учетную запись пользователя для каждого человека или одну для всей компании - решать вам.
Такой способ распространения очень полезен, если вы хотите контролировать, кто может использовать приложение, но при этом хотите легкости развертывания, которую обеспечивает AppStore.
Apple приняла в AppStore множество приложений, использующих этот метод аутентификации на удаленном сервере (Skype - прекрасный пример).
Если вы отслеживаете UDID устройства на сервере конфигурации, вы также можете предварительно загрузить его, чтобы позволить определенному набору устройств работать.
Кроме того, все, что я описал, не является специфичным для iPhone, поэтому вы можете использовать ту же систему управления конфигурацией и концепции на других платформах, таких как Android (или даже на настольных компьютерах), если вы когда-нибудь перенесете приложение или создадите другие приложения, нуждающиеся в этом в будущем.
Кроме того, поскольку процесс аутентификации устройств не требует больших затрат процессора или данных, вы, скорее всего, никогда не понесете затрат, если будете создавать приложение на Google AppEngine, поскольку вы никогда не превысите бесплатные квоты и получите стабильность и масштабируемость архитектуры бэкенда Google.
Поскольку это конкретное приложение предназначено для управления внутренней внутренней системой, развертывание его через AppStore может показаться небезопасным, поскольку в приложение встроена служебная информация, в частности, информация, позволяющая ему подключаться к внутренней системе и проходить аутентификацию.
Решение этой проблемы заключается в том, чтобы не включать эту информацию в приложение и просто сделать ее частью ответа, который приложение получает от сервера управления конфигурацией. В принципе, приложение содержит логику, необходимую для выполнения своей функции, но без информации о подключении оно не имеет возможности управлять какой-либо внутренней системой.
Если вы заставите приложение проходить аутентификацию при каждом запуске, вы можете изменить информацию о подключении на сервере конфигурации, и приложение обновится до новой информации без необходимости нового развертывания. Пользователю просто нужно перезапустить приложение. Это дает вашему клиенту возможность гибко изменять конфигурацию своей внутренней сети, не нарушая код вашего приложения. Вы также можете сделать эту информацию настраиваемой вручную в приложении, но тогда вы понесете расходы на ИТ при настройке приложения на каждом устройстве, и если вы уже собираетесь установить систему управления конфигурацией, то лучше использовать ее.
Для дополнительной защиты вышеуказанного решения вы можете установить систему управления конфигурацией внутри компании и за ее брандмауэром, чтобы независимо от того, кто получит приложение, они не могли подключиться к системе конфигурации, если они не находятся в сети компании.
Примерно единственные реальные варианты, которые у вас есть...
- До 100 устройств как распределение ad-hoc.
- Распределение по предприятиям (требуется > 500 сотрудников)
- Каждый должен принести свое устройство в IT-центр и получить его как устройство "разработчика". (ух ты!)
- Jail-broken.
Jail-broken может звучать пугающе, но на самом деле это довольно продвинутая вещь в наши дни, и ею можно легко управлять. Тем не менее, это аннулирует гарантию (если только вы не готовы восстановить заводские настройки и не быть честным в этом вопросе;)
Тем не менее, технически это доступный вариант, и его можно заставить работать, если вы готовы все спланировать.
Дайте нам знать, что вы решите, а также о плюсах и минусах этого метода.
Еще одно очевидное, хотя и не обязательно приятное, - отправить свое приложение в магазин приложений как приложение, но доступ к нему возможен только с пароль клиента. Предполагая, что вы можете пройти через процесс магазина приложений, это может сработать для вас.
Специальное распространение ограничено 100 устройствами на приложение, это правда, но вы можете добавить проект n раз в центр разработчиков Apple, чтобы развернуть его на n * 100 устройствах
Как Apple гарантирует, что на вашем предприятии работает более 500 человек? Я бы все равно попробовал его через корпоративную программу ...
Я бы не стал делать джейлбрейк, я бы не делал специального, потому что он ограничен 100, и я бы не заставлял всех переводить свои телефоны в режим разработчика .
Для удобства обслуживания в будущем лучше всего использовать режим предприятия, так что посмотрите, сможете ли вы сориентироваться в процессе, не упоминая, что у вас может быть не совсем 500 пользователей.
Также я видел ваш комментарий о разработке с использованием MonoTouch.Я бы поговорил с Apple об этом, прежде чем вы сделаете что-либо еще, потому что, учитывая их недавние изменения в политике, я почти уверен, что это приведет к тому, что ваше приложение будет отклонено из App Store и программы Enterprise.
Edit: Я проверил веб-страницу Mono. Кажется, что Apple все еще может разрешать моно-приложения, и создатели Mono настаивают на том, что это кошерно, но вы можете рисковать тем, что ваше будущее приложение будет удалено с телефонов в любое время.
Лучшее редактирование: прямо с монофонического веб-сайта: Enterprise MonoTouch
Важно отметить, что новые условия Соглашения разработчика iPhone относятся к развертыванию AppStore, а не к программе Enterprise, которая позволяет развертывать собственные приложения для пользователей. на предприятии (с помощью программы Enterprise Deployment).
Таким образом, вы можете быть хороши в этом деле, если сможете заниматься корпоративной программой.
Оли сказала:
Единственный реальный выбор, который у вас есть, это ... До 100 устройств в режиме ad-hoc распределения. Распределение Enterprize (требуется> 500 сотрудников) Каждый должен отправить свое устройство в какой-нибудь ИТ-центр и создать его как устройство «разработчика». (yikes!) Взломанный в тюрьме.
Но для ясности (поправьте меня, если я ошибаюсь):
- если вы используете метод распространения «Ad-hoc», ваши клиенты увидят, что приложение исчезнет ровно через 3 месяца.
- только до 100 устройств можно использовать для тестирования (т. Е. Использовать в «режиме разработчика»), и, более того, приложение исчезнет через 3 месяца.
Итак, Apple не оставляет нам выбора, вы действительно большой (> 500 сотрудников) ?? хорошо, так что вы можете делать то, что хотите, и т. д., иначе ... «пока»
Кроме того, забудьте о том, что сказал Брайс ранее, приложение, подобное тому, которое он описал, будет отклонено из-за мотивации «известная аудитория».
iOS не для корпоративных приложений .... если вы не хотите полагаться на некоторых умных хакеров (например, побег из тюрьмы)
Вы можете полностью обойти процесс одобрения App Store или Enterprise Developer Program, если вы разрабатываете свое приложение как решение на чистом HTML5. Эта технология называется веб-приложениями. И они могут быть довольно продвинутыми по функциональности. Вы автоматически получаете кросс-платформенную готовность и очень простые варианты развертывания (поскольку веб-клип может распространяться через файлы конфигурации .mobileconfig). См. http://www.apple.com/webapps/whatarewebapps.html