Что разработчик мобильного приложения должен передать заказчику при сдаче проекта: код, ключи, доступы и документы

Короткий ответ: при сдаче мобильного приложения заказчик должен получить всё, чтобы выпустить следующую версию без исходного исполнителя: репозиторий с кодом приложения и сервера, инструкцию сборки, ключ загрузки Android, ключи Apple для push, доступы к консолям магазинов, серверу и сторонним сервисам, описание API, макеты и подписанный акт. Проверяется это одним тестом — новая сборка собирается по инструкции на чужом компьютере.

Эта статья — про момент приёмки собственного проекта, пока исполнитель на связи и отношения нормальные. Если подрядчик уже ушёл и приложение надо спасать, читайте разбор доработки приложения после другого разработчика. На кого оформлять аккаунты в магазинах, мы разбирали в статье об аккаунте разработчика Apple и Google Play; здесь — полная опись и как её закрепить. Правила Google и Apple сверены с их справкой на 31 октября 2026 года.

Почему «отдали код» — это ещё не передача приложения?

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

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

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

Что входит в полную передачу мобильного приложения?

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

• Исходники. Код приложения и сервера в репозиториях на вашем аккаунте, с историей, а не одной последней версией. Как устроен репозиторий и что в нём смотреть без программиста — в статье о репозитории кода для заказчика.
• Сборка. Инструкция, по которой человек со стороны соберёт приложение, и список настроек окружения: что вписать для тестовой версии, что для рабочей.
• Ключи и идентификаторы. Ключ загрузки Android, ключ push от Apple, Bundle ID и applicationId. Без них новая сборка не станет обновлением того приложения, что уже стоит у пользователей.
• Аккаунты. App Store Connect, Google Play Console, проект уведомлений и аналитики, хостинг, домен, кабинеты платёжного сервиса и SMS — все на вас.
• Документы. Описание API, макеты, список доступов и акт с пометкой, что код и доступы переданы.

Какие ключи Android нужно получить и зачем?

Если приложение подписывается через сервис Google Play, у вас должен остаться ключ загрузки: файл keystore, пароль и имя ключа. Сам ключ подписи для пользователей хранит Google. Если же разработчик подписывал приложение своим ключом без этого сервиса, этот ключ — самое ценное в проекте.

По справке Google Play о подписании приложений, при загрузке пакета App Bundle приложение по умолчанию подключается к подписанию Google Play, и ключ подписи создаёт и хранит Google. Разработчик подписывает сборки своим ключом загрузки. Если ключ загрузки пропал, его сбрасывают запросом в Play Console, и доступ к приложению сохраняется. Если ключ собственный и сервис не подключён, потерянный ключ сбросить нельзя.

Что сделать при приёмке:

1. Открыть в Play Console раздел подписания приложения и убедиться, что подписание Google Play включено.
2. Получить keystore с паролями отдельно от кода — не в репозитории и не в общем чате.
3. Сохранить отпечатки ключа подписи: их регистрируют в сервисах, которые проверяют приложение, например в картах или входе через сторонний аккаунт. После смены ключа, как пишет Google, отпечатки нужно обновить у этих сервисов.

Что с ключами и сертификатами Apple?

Сертификаты и профили Apple выпускаются внутри аккаунта разработчика, поэтому главное — чтобы это был ваш аккаунт: тогда при доступе к нему всё можно перевыпустить. Отдельно заберите ключ push в формате .p8 с его Key ID — Apple даёт скачать его только один раз.

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

Если сертификаты и профили выпускались вручную, а не автоматически через Xcode, попросите список: что выпущено, для чего, когда истекает.

Какие доступы должны остаться у заказчика?

Владельцем каждого аккаунта, от которого зависит работа приложения, должны быть вы или ваша компания: магазины, проект уведомлений, хостинг, домен, база данных, платёжный сервис, SMS, карты. Исполнителю — роль участника, которую вы отзываете сами.

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

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

№ и что	Что именно должно быть	Как проверить при приёмке
1. Репозиторий приложения	Весь код с историей изменений, в вашем аккаунте GitHub, GitLab или другого сервиса	Вы — владелец репозитория, последний коммит совпадает с версией, отправленной в магазины
2. Репозиторий сервера и админки	Код серверной части, панели управления, скриптов обмена данными	Отдельный репозиторий или папка в общем, тоже на вашем аккаунте
3. Инструкция сборки	Файл README: версии инструментов, команды, где взять настройки, как собрать для iOS и Android	Сторонний разработчик собирает по ней без звонка исполнителю
4. Настройки окружений	Список переменных для тестовой и рабочей версии: адреса серверов, ключи сервисов	Секреты переданы отдельно от кода, по защищённому каналу
5. Ключ загрузки Android	Файл keystore, пароль, алиас ключа	В Play Console включено подписание Google Play; отпечаток ключа загрузки совпадает
6. Идентификаторы приложения	Bundle ID для iOS, applicationId для Android, номер версии и сборки	Совпадают в коде и в консолях магазинов
7. Ключи Apple	Ключ .p8 для push с Key ID, сертификаты и профили, если они выпускались вручную	Всё создано в вашем аккаунте Apple Developer, а не в аккаунте исполнителя
8. Проект уведомлений и аналитики	Firebase или другой сервис push и сбора сбоев, где вы — владелец	В настройках проекта ваш аккаунт с ролью владельца
9. Аккаунты магазинов	App Store Connect, Google Play Console, при необходимости RuStore — оформлены на вас	У исполнителя роль участника, которую вы можете отозвать
10. Сервер и база данных	Хостинг, домен, база, резервные копии — на ваших аккаунтах или с вашим полным доступом	Вы входите в панель хостинга сами и видите последнюю резервную копию
11. Сторонние сервисы	Эквайринг, SMS, карты, чат поддержки: кабинеты, ключи, кто платит	Кабинеты на вашей почте, карта для оплаты — ваша
12. Описание API	Список методов сервера: что принимает и что возвращает	Есть в репозитории или по ссылке, совпадает с текущей версией
13. Макеты и графика	Файл дизайна, иконка и заставка в исходных размерах, скриншоты для магазинов	Доступ к файлу дизайна с правом редактирования
14. Список доступов	Таблица: сервис, логин или владелец, кто имеет доступ, когда продлевать	Пароли — не в этой таблице, а в менеджере паролей или переданы отдельно
15. Акт и приложение к договору	Акт сдачи-приёмки, где сказано, что код и доступы переданы	Подписан после проверки, а не до неё

Как проверить, что приложение можно собрать без исполнителя?

Попросите другого разработчика — штатного, знакомого или нанятого на пару часов — склонировать ваш репозиторий и по инструкции собрать приложение для iOS и Android, не задавая вопросов исполнителю. Собралось и установилось на телефоны — передача состоялась. Не собралось — вы нашли пробел, пока его ещё легко закрыть.

Порядок проверки:

1. Чистая машина. Сборка на компьютере, где проект раньше не собирался. Так видно, чего не хватает: версии инструментов, файла настроек, пароля к ключу.
2. Обе платформы. Сборка для Android подписывается ключом загрузки; сборка для iOS собирается в вашем аккаунте Apple.
3. Тестовый выпуск. Сборку отправляют во внутреннее тестирование Google Play и в TestFlight. Если магазин принял её как новую версию существующего приложения, идентификаторы и подпись в порядке. Как устроено тестирование до публикации — в статье о TestFlight и закрытом тестировании.
4. Сервер. Проверяющий находит в инструкции, как развернуть серверную часть на другом сервере, и хотя бы запускает её локально.
5. Уведомления и оплата. Отправить тестовый push и провести оплату на собранной версии.

Обычно это занимает рабочий день. Дороже ли это, чем принять на слово? Да, на пару часов чужой работы. Дешевле ли, чем разбираться через год с пропавшим разработчиком? Несравнимо.

Как прописать передачу в договоре ещё до старта?

Три вещи: где лежит код, в каком объёме он передаётся и какой список доступов прилагается к акту. Если этого нет в договоре, передача зависит от доброй воли исполнителя и его представления о «полном комплекте».

• Место хранения кода. Ваш репозиторий указывается в договоре или приложении к нему с первого дня — исполнитель работает сразу в нём, а не переносит код в конце.
• Объём. Формулировка «в объёме, достаточном для сборки, развёртывания и доработки» сильнее, чем просто «исходный код»: она покрывает настройки, инструкцию и серверную часть.
• Опись как приложение. Таблица из этой статьи, сокращённая под ваш проект. В акте — отметка, что код и доступы по описи переданы.
• Аккаунты до старта. Магазины, хостинг и проект уведомлений вы заводите на себя заранее и приглашаете исполнителя. Тогда в конце переносить почти нечего.
• Права. Отдельно стоит прочитать, что договор говорит о правах на код. У нас исключительное право на код остаётся у исполнителя, а заказчик получает лицензию на весь срок действия права: исходники в его репозитории, любой сервер, любые подрядчики, публикация в магазинах на его аккаунтах. Логотип, иконка приложения, тексты и фирменный стиль, созданные для заказчика, переходят к нему.

Когда полная опись не нужна и какие ошибки встречаются?

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

Ошибки, которые встречаются чаще всего:

• Подписать акт до проверки. Акт — это подтверждение, что вы всё получили. После него просить недостающее можно, но разговор уже другой. По договору студии на проверку есть 5 рабочих дней, и если за это время не подписать акт и не прислать замечания, работы считаются принятыми, — планируйте проверку сборки на эти дни.
• Принять архив вместо репозитория. В архиве нет истории, а через месяц уже непонятно, какая версия в магазине.
• Хранить пароли в репозитории. Ключи сервисов и keystore не должны лежать вместе с кодом, особенно если к репозиторию потом получат доступ другие подрядчики.
• Забыть про сервер. Приложение без сервера часто бесполезно: в нём не будет каталога, профилей и заказов.
• Не проверить, кто платит. Сервис на карте исполнителя отключится в момент, когда он перестанет платить, и никто не успеет предупредить.
• Сделать опись после конфликта. Тогда это уже не опись, а переговоры. Список, согласованный до старта, никого не обижает.

Как передаём приложения мы?

Мобильное приложение для iOS и Android из одного кода стоит у нас от 200 000 ₽, срок — от 2 недель для базового объёма; цену и срок фиксируем в договоре до старта. Передача проекта — последний этап работы, а не одолжение после неё.

• Код с первого дня у вас. По договору исходный код размещается в вашем репозитории, указанном в приложении к договору, в объёме, достаточном для сборки, развёртывания и доработки. В том же приложении — ваш хостинг и аккаунты.
• Аккаунты на вас. Аккаунты разработчика Apple и Google Play оформляются на заказчика, мы работаем в них по приглашению. Подробнее — на странице разработки мобильных приложений.
• Акт. В акте прямо сказано, что результат работ, включая исходный код, и доступы переданы. Оплата 50 % до старта и 50 % по акту.
• После сдачи. Гарантия — 30 календарных дней с даты акта: ошибки по нашей вине исправляем бесплатно. Дальше — поддержка от 7 900 ₽ в месяц или любой другой подрядчик: всё нужное для этого у вас уже есть.

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

Короткие ответы на частые вопросы

Обязан ли разработчик отдать исходный код мобильного приложения?

Только если это записано в договоре. Поэтому до старта пропишите, что код передаётся в ваш репозиторий в объёме, достаточном для сборки и доработки, и приложите опись передачи.

Что делать, если ключ подписи Android потерян?

Если приложение подписывается через Google Play, потерянный ключ загрузки можно сбросить запросом в Play Console. Если разработчик подписывал собственным ключом без этого сервиса, по справке Google такой ключ при потере сбросить нельзя — поэтому его копию заказчик должен получить при сдаче.

Нужно ли заказчику самому хранить сертификаты Apple?

Сертификаты выпускаются в аккаунте разработчика, поэтому важнее, чтобы аккаунт был ваш. Отдельно сохраните ключ для push в формате .p8: Apple даёт скачать его только один раз.

Достаточно ли архива с кодом вместо репозитория?

Для запуска — иногда да, для развития — нет: в архиве нет истории изменений и часто не хватает настроек сборки. Если архив, то вместе с инструкцией и проверкой сборки.

Сколько времени занимает проверка передачи?

Сама проверка сборки обычно укладывается в рабочий день, если опись согласована заранее. По договору студии на подписание акта или замечания есть 5 рабочих дней — планируйте проверку на этот срок.

Услуги и кейсы по теме: мобильные приложения · заказная разработка · типовые договоры · цены и сроки