Роль стороннего разработчика и агента iOS

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

У нас есть веб-приложение, для которого мы теперь хотим предложить нативные приложения для iOS. Поскольку у нас нет навыков написания нативных iOS-приложений, мы нашли агентство с хорошей репутацией, которое справится с этой задачей за нас. Они попросили нас создать учетную запись разработчика Apple. Мы сделали это, нам позвонили из Apple, и на данный момент мы сертифицированы. Итак, корпоративный аккаунт.

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

Это действительно правильный путь или лучше временно передать им роль агента? Я спрашиваю, потому что моя учетная запись iCloud и другие вещи связаны с этим идентификатором.

Каков наилучший способ для такого созвездия: Сторонняя разработка и учетная запись корпоративного разработчика Apple?

Я ценю любую помощь!


person Jannick    schedule 03.04.2014    source источник


Ответы (2)


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

  1. Клиент (это вы) создает учетную запись корпоративного разработчика в Apple.

  2. Используя свою учетную запись разработчика, клиент создает идентификатор приложения, сертификат распространения и профиль обеспечения и предоставляет нам эти три элемента.

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

  4. Они используют инструмент распространения, такой как AppBlade или MobileIron, для развертывания приложения на своих устройствах.

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

К сожалению, Apple так затрудняет ведение бизнеса таким образом, поскольку это, кажется, довольно распространенная практика. Им нужен менее окольный способ отделить разработку от распространения. Но для нас, по крайней мере, этот процесс кажется рабочим и относительно безболезненным — просто требуется некоторая координация между вашей компанией и той, которая занимается разработкой.

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

person Jeff Loughlin    schedule 03.04.2014
comment
Клиент также может использовать загрузчик приложений для развертывания приложения в App Store. - person ZeMoon; 03.04.2014

Мы также просим владельца учетной записи создать для нас учетную запись администратора. Таким образом, у вас по-прежнему будет учетная запись владельца, а у нас, разработчиков, есть только учетная запись администратора. Вам нужно будет создать учетную запись для разработчиков.apple.com и iTunesConnect.

Вы можете использовать один и тот же адрес электронной почты несколько раз для developer.apple.com, но не для iTunesConnect. Поскольку ItunesConnect требует уникальный адрес электронной почты, мы просто создаем учетную запись электронной почты для каждого клиента.

person rckoenes    schedule 03.04.2014