Пока всё идёт хорошо, вопрос владения не поднимается. Он возникает в неудачный момент: подрядчик перестал отвечать, поднял цену или закрылся. Разберём, что нужно иметь на руках, чтобы приложение оставалось вашим.
Аккаунты в магазинах
Главное. Аккаунт разработчика Apple и Google должен быть оформлен на вашу компанию, а подрядчик — иметь в нём права доступа, которые вы можете отозвать. Если приложение опубликовано в аккаунте студии, оно принадлежит студии: вы не сможете выпустить обновление, изменить описание или снять приложение.
Перенести приложение из чужого аккаунта в свой возможно — обе площадки это поддерживают, — но только при согласии владельца. Без согласия остаётся один путь: публиковать заново, теряя отзывы, оценки, накопленную историю и всех установленных пользователей.
Ключи подписи
Android-приложение подписывается ключом, и обновление принимается только с тем же ключом. Потерянный ключ означает, что обновить приложение нельзя — только выпустить новое, с нуля. У Google есть услуга хранения ключа на их стороне, и если она была включена, ситуация спасаема. Если нет — ключ должен быть у вас.
У Apple проще: сертификаты перевыпускаются в аккаунте разработчика, лишь бы аккаунт был ваш.
Исходный код
Код должен лежать в репозитории, доступ к которому есть у вас, а не только у подрядчика. Проверьте, что там действительно то, что работает у пользователей: бывает, что в репозитории лежит версия полугодовой давности, а рабочая живёт на ноутбуке разработчика.
Простая проверка: попросите собрать приложение из репозитория и сверьте номер версии с той, что в магазине.
Сервер и сервисы
Отдельным списком: доступ к серверу, база данных и резервные копии, домен и кто им управляет, сертификат шифрования, проект Firebase или другой сервис уведомлений, ключи платёжных систем, почтовые и SMS-сервисы.
Проект Firebase заслуживает внимания: если приложение живёт в проекте подрядчика, вы не управляете уведомлениями и не видите статистику. Перенести приложение в свой проект можно, но это требует новой версии в магазине.
Документация
Минимум, который экономит недели новому разработчику: как собрать и выпустить приложение, какие переменные окружения нужны, где что лежит на сервере, какие внешние сервисы подключены и с какими учётными записями. Одного файла на несколько страниц обычно достаточно.
Если передача уже сорвалась
Ситуации бывают разные, и почти все решаемы. Нет доступа к аккаунту, но есть исходники — публикуем в вашем аккаунте, продумав перевод пользователей. Нет ни того ни другого — приложение восстанавливается по опубликованной версии: интерфейс, логика и обмен с сервером разбираются, но это дольше и дороже, чем передача по-хорошему.
Мы такие переходы делали не раз, включая случаи, когда прежний подрядчик просто исчез. Если вы сейчас в такой ситуации — опишите, что осталось на руках, и мы скажем, что из этого восстановимо.
Чек-лист
Аккаунты Apple и Google на вашу компанию. Ключ подписи Android у вас. Репозиторий с рабочим кодом, доступ ваш. Сервер, база, резервные копии. Домен и сертификат. Firebase и платёжные ключи. Документация по сборке и выпуску. Семь пунктов, которые стоит проверить до того, как они понадобятся.
Как передать приложение между аккаунтами
Обе площадки поддерживают перенос опубликованного приложения в другой аккаунт, и это лучший сценарий: сохраняются установки, отзывы, оценки и позиции в поиске магазина.
В App Store это делается через запрос на передачу: владелец инициирует, принимающая сторона подтверждает. Есть условия — у приложения не должно быть неоплаченных обязательств и незавершённых проверок, а принимающий аккаунт должен быть организацией с заполненными налоговыми и банковскими данными.
В Google Play перенос делается обращением в поддержку с подтверждением обеих сторон. Дольше, чем у Apple, но работает.
Главное условие в обоих случаях — согласие прежнего владельца. Поэтому вопрос об аккаунтах стоит решать в начале работы, а не тогда, когда отношения испортились.
Что записать в договор
Несколько строк, которые избавляют от большинства проблем. Исключительные права на код и дизайн переходят заказчику после оплаты. Аккаунты в магазинах оформляются на заказчика, подрядчик получает доступ как разработчик. Ключ подписи и все сертификаты передаются заказчику и хранятся у него. Исходный код размещается в репозитории заказчика. При завершении работ подрядчик передаёт документацию по сборке и выпуску.
Ни один из этих пунктов не ущемляет добросовестного подрядчика — мы сами так работаем. Отказ включить их в договор говорит о многом заранее.
Приёмка: что проверить до последнего платежа
Соберите приложение из переданного репозитория на своей стороне и сверьте с тем, что в магазине. Войдите в аккаунты разработчика своими учётными данными и убедитесь, что видите приложение и можете подать обновление. Проверьте, что ключ подписи у вас на руках и им действительно подписана текущая версия. Зайдите на сервер и посмотрите, есть ли резервные копии и настроено ли их создание по расписанию.
Эти четыре проверки занимают полдня и делают передачу настоящей, а не формальной. Проводить их нужно до финального расчёта — после него мотивация помогать резко снижается.