После разработки мобильного приложения у заказчика должны быть на руках: доступ к репозиторию с исходным кодом, ключи подписи сборок, аккаунты Apple и Google, оформленные на компанию, доступ к серверу и доменам. Если этого нет, приложение фактически остаётся под контролем подрядчика, даже если формально акт подписан и деньги заплачены. Разберём, что именно нужно забрать и как это прописать заранее в договоре.

Почему «приложение готово» не значит «код у вас»

Готовое приложение в App Store и Google Play и переданный исходный код это разные вещи. Можно годами пользоваться работающим приложением и обнаружить, что код лежит в личном репозитории уволившегося программиста, только когда понадобится срочная правка, а прежний подрядчик недоступен. Особенно часто это всплывает при смене студии или когда нужно быстро исправить ошибку под новые требования сторов.

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

Репозиторий с кодом

  • Код должен лежать в репозитории на аккаунте организации, например на GitHub или GitLab, привязанном к почте компании, а не к личному аккаунту разработчика.
  • У ответственного сотрудника компании должны быть права администратора этого репозитория, а не только доступ на чтение.
  • Если разработка велась в личном репозитории подрядчика, попросите перенести его в организацию компании до финального платежа, это делается штатными средствами GitHub или GitLab и занимает несколько минут.
  • Проверьте, что в репозитории есть история коммитов, а не архив с финальной версией без истории: история помогает понять, что и когда менялось.

Ключи подписи и сертификаты

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

  • Android. Файл ключа загрузки (.jks или .keystore), пароль к хранилищу, alias и пароль ключа. Если приложение подключено к Play App Signing, это подстраховка на случай утери ключа загрузки, но сам файл всё равно должен быть у компании.
  • iOS. Сертификаты подписи и профили обеспечения (provisioning profiles) хранятся в аккаунте Apple Developer компании, а не на личном компьютере разработчика.
  • Резервная копия. Минимум две копии ключей: в корпоративном менеджере паролей и в защищённом хранилище компании, доступном не одному сотруднику.

Аккаунты Apple и Google на компанию

Аккаунт разработчика Apple Developer Program и аккаунт Google Play Console должны быть оформлены на юридическое лицо заказчика, с почтой и реквизитами компании, а не на личный аккаунт сотрудника подрядчика. Это касается и роли внутри аккаунта: в Apple Developer Program роль владельца аккаунта (Account Holder) должна принадлежать представителю компании, у которого есть право подписывать соглашения от её имени, а подрядчику для работы достаточно роли с ограниченными правами. В Google Play Console похожим образом стоит разделять владельца аккаунта и пользователей с правами на публикацию.

Если аккаунт всё же оформлен на подрядчика, Apple и Google предусматривают процедуры передачи роли владельца и переноса приложений на другой аккаунт, но это отдельный процесс с проверкой личности и не всегда быстрый. Значительно проще оформить аккаунты правильно с самого начала, подробности в статье аккаунт разработчика Apple и Google.

Сервер, база данных и домены

  • Логин и пароль от хостинга или облачного провайдера, где развёрнут backend приложения, оформленного на компанию, а не на личную карту разработчика.
  • Доступ к базе данных: как минимум для резервного копирования, в идеале с правами администратора у технического специалиста компании.
  • Домен приложения и API зарегистрирован на компанию, доступ к панели управления DNS-записями.
  • Список переменных окружения и ключей сторонних сервисов: платёжные системы, SMS-шлюз, карты, push-уведомления.

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

Что прописать в договоре об исключительных правах

Формулировки в договоре снижают риск спора о том, кому принадлежит код. На что стоит обратить внимание, обсуждая договор с юристом:

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

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

Как проверить, что переданный код рабочий

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

  1. Попросите нового разработчика или технического специалиста склонировать репозиторий на чистой машине без старых настроек прежнего подрядчика.
  2. Соберите приложение по переданной инструкции без дополнительных вопросов автору кода.
  3. Подпишите тестовую сборку переданными ключами и убедитесь, что она устанавливается поверх текущей версии из стора без ошибки о несовпадении подписи.
  4. Проверьте, что сборка подключается к боевому серверу и работает с реальными, а не тестовыми данными.

Если сборка не собирается или ключи не подходят, лучше выяснить это сразу, пока подрядчик ещё отвечает на вопросы, а не через полгода, когда понадобится срочное обновление.

Что делать, если проект уже сдан, а доступов нет

  1. Составьте список того, чего не хватает: код, ключи, доступы к аккаунтам, документация.
  2. Свяжитесь с подрядчиком письменно, ссылаясь на пункты договора о передаче прав и материалов.
  3. Если подрядчик недоступен или отказывается, запустите процедуры восстановления доступа там, где это возможно: сброс ключа загрузки Android через Play Console, запрос смены владельца аккаунта Apple Developer Program.
  4. Для того, что восстановить нельзя, например утерянный ключ подписи старого Android-приложения без Play App Signing, обсудите с разработчиками путь наименьших потерь, вплоть до пересборки части инфраструктуры.
  5. Закажите независимый аудит текущего состояния проекта, чтобы понимать реальный объём проблем перед тем, как договариваться о дальнейшей поддержке.

Чек-лист передачи проекта коротко

  • Репозиторий с кодом в организации компании, права администратора у ответственного сотрудника.
  • Ключи подписи Android и сертификаты iOS с паролями, минимум две копии в надёжных местах.
  • Аккаунты Apple Developer Program и Google Play Console оформлены на компанию, роль владельца у представителя компании.
  • Доступ к серверу, базе данных и панели управления доменом.
  • Документация по сборке, схема API и список сторонних сервисов с указанием владельца каждого аккаунта.

Частые ошибки казахстанских компаний

  • Аккаунты оформлены на личную почту программиста «для скорости запуска», а потом человек уходит из компании или прекращает сотрудничество.
  • Код без организации-владельца. Репозиторий числится в личном профиле разработчика на GitHub, доступ компании только на чтение или вообще только просмотр демо-версии.
  • Ключи хранятся в переписке в мессенджере. Неудобно искать, а после смены телефона рискует потеряться совсем.
  • Договор без пункта о моменте передачи прав. Подписали акт, а вопрос, когда именно код становится собственностью компании, не описан.

Частые вопросы

Что именно нужно требовать у подрядчика при завершении проекта?

Доступ к репозиторию с полной историей кода, ключи подписи Android и сертификаты iOS с паролями, права администратора в аккаунтах Apple и Google, доступ к серверу и доменам, а также документацию по сборке и API.

Можно ли сменить владельца аккаунта Apple Developer Program задним числом?

Да, Apple предусматривает процедуру передачи роли Account Holder внутри организации на другого сотрудника с правом подписывать соглашения от лица компании. Это делается через настройки аккаунта и требует согласия текущего владельца.

Что если студия отказывается передавать исходный код?

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

Нужно ли хранить копию ключей отдельно от подрядчика?

Да, обязательно. Минимум одна копия ключей и паролей должна храниться в компании независимо от того, что происходит с подрядчиком, в корпоративном менеджере паролей, доступном ответственному сотруднику.

Что делать, если приложение изначально делал фрилансер, а не студия?

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

Наведём порядок с кодом и доступами

Проверим, что реально передано вашей компании, поможем забрать код, ключи и аккаунты у прежнего подрядчика и восстановим доступ там, где это возможно. Аудит и наведение порядка в проекте от 500 000 ₸. Оставьте заявку на странице контактов или в WhatsApp +7 707 928 13 15.