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

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

Эта статья для тех, у кого уже есть опубликованное приложение, а прошлый подрядчик ушёл, пропал или перестал устраивать. Как устроена ежедневная жизнь приложения после релиза, мы разбирали в статье о поддержке мобильного приложения. Здесь — момент перехода: что собрать, как проверить и как начать работу с новой командой. Правила Google и Apple сверены с их справкой на 30 октября 2026 года.

Что	Где обычно лежит	Если не получили
Исходный код приложения	Репозиторий подрядчика или его компьютер	Доработка невозможна, остаётся писать заново
Исходный код сервера и админки	Отдельный репозиторий или прямо на сервере	Приложение работает, пока жив чужой сервер
Ключ подписи Android или ключ загрузки	Файл keystore у разработчика, ключ подписи — в Google Play	Без ключа загрузки — сброс через Play Console; без собственного ключа подписи — обновлений нет
Bundle ID, applicationId, конфигурация сборки	В исходниках и в консолях магазинов	Новая сборка не станет обновлением старой
Проект Firebase и ключи push	Google-аккаунт разработчика, раздел ключей Apple	Уведомления перестают приходить
Сервер, домен, база данных, резервные копии	Хостинг на имя подрядчика	Риск потерять пользователей и их данные
Сторонние сервисы: оплата, SMS, карты, аналитика	Личные кабинеты сервисов	Отключение при смене карты или отказе подрядчика платить

Что обязательно забрать у прошлого разработчика?

Всё, что нужно, чтобы собрать новую версию и опубликовать её как обновление старой: исходный код приложения и сервера, ключ подписи или ключ загрузки Android, доступ к сертификатам Apple, конфигурацию сборки, проект Firebase, сервер, базу данных и сторонние сервисы. Аккаунты магазинов должны быть на вас.

Мобильное приложение — это не только код. Это ещё связка «аккаунт в магазине + идентификатор приложения + подпись». Если хотя бы одно звено осталось у прежнего подрядчика, новая сборка формально будет другим приложением, и магазин не предложит её вашим пользователям как обновление. Отсюда главный совет: просите не «код», а комплект.

• Исходники приложения — весь репозиторий с историей изменений, а не архив последней версии. История показывает, кто, когда и зачем менял код, и часто объясняет странные места.
• Исходники сервера и админки. Большинство приложений ходят на свой сервер за данными. Если код сервера остался у подрядчика, вы зависите от него, даже имея исходники приложения.
• Файлы и пароли подписи: keystore для Android с паролями и алиасом ключа. Про Apple — ниже.
• Конфигурация сборки: файлы окружений, адреса серверов для тестовой и рабочей версии, настройки CI, если сборка шла автоматически.
• Проект Firebase или другой сервис уведомлений и аналитики — с правами владельца на ваш Google-аккаунт.
• Сервер и данные: доступ к хостингу, домену, базе данных и резервным копиям, а в идеале — перенос всего этого на ваши аккаунты.
• Сторонние сервисы: платёжный шлюз, SMS, карты, чат поддержки. Ключи этих сервисов часто вшиты в код и привязаны к кабинету подрядчика.
• Документация: хотя бы короткая инструкция по сборке и список того, что где лежит. Если её нет, попросите прошлого разработчика записать её за час, пока он на связи.

Аккаунты App Store Connect и Google Play Console — отдельная тема: если приложение опубликовано не на вашем аккаунте, его сначала переносят. Делает это владелец текущего аккаунта, поэтому и об этом договариваются сразу.

Что лежит обычно где и чем грозит пробел — в таблице.

Почему без ключа подписи Android не выпустить обновление?

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

Здесь важно понять, какой ключ у вас на руках. С сервисом Play App Signing ключей два:

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

Новые приложения, загруженные в Google Play в формате App Bundle, подключаются к Play App Signing автоматически. А вот старые приложения, которые годами выпускались как APK, могли остаться на собственном ключе разработчика. Про такой ключ Google пишет прямо: если он потерян, сбросить его не получится. Поэтому первый вопрос новому подрядчику при приёмке — в каком режиме подписывается приложение. Ответ виден в Play Console на странице подписания приложений.

Если приложение ещё на собственном ключе и ключ у вас, его стоит перевести на Play App Signing: Google позволяет передать существующий ключ через утилиту PEPK, а для следующих выпусков завести отдельный ключ загрузки. После этого риск «ключ остался у человека, который уволился» исчезает.

В Apple ситуация мягче. Сертификаты распространения выпускаются внутри аккаунта разработчика, и при доступе к нему их можно создать заново. Истёкший или отозванный сертификат, по данным Apple, не трогает приложения, которые уже в App Store, если членство действует, — просто загрузить подписанную им сборку уже нельзя (справка Apple о сертификатах). С уведомлениями строже: с истёкшим сертификатом push-сервиса отправить уведомление не получится. Поэтому при передаче проверяют, чем подписываются push — сертификатом с датой окончания или ключом, — и кто может его перевыпустить.

Как оценить состояние кода и сборки?

Собрать проект на чистой машине по инструкции, установить на реальные телефоны и пройти главные сценарии. Затем посмотреть код, зависимости и сервер. Такой аудит занимает несколько рабочих дней и даёт ответ: можно ли выпускать правки сразу или сначала нужен ремонт.

Порядок, которым пользуемся мы:

1. Сборка с нуля. Клонируем репозиторий и собираем по документации, без помощи прошлого разработчика. Если не собирается — это первая находка: значит, часть проекта существовала только на его компьютере.
2. Версии инструментов и библиотек. Магазины регулярно поднимают требования к сборкам: Apple принимает только сборки из свежих версий Xcode и SDK, Google требует свежий целевой API Android. Если проект давно не обновлялся, первая же правка потребует обновить всё вокруг. Конкретные сроки на октябрь 2026 года — в статье о поддержке после запуска.
3. Сценарии на телефонах. Регистрация, вход, оплата, уведомления, главные экраны — на нескольких моделях iOS и Android. Сравниваем с тем, что видят пользователи в магазине.
4. Код. Структура, повторяющиеся куски, обработка ошибок, тесты, есть ли в коде пароли и ключи сервисов, которые давно пора вынести.
5. Сервер. Есть ли описание API, можно ли развернуть сервер в другом месте, как устроены резервные копии, кто им владеет.
6. Сбои и отзывы. Статистика падений в консолях магазинов и последние отзывы пользователей: на что жалуются прямо сейчас.

Итог аудита — короткий документ: что работает, что сломано, что устарело, что нужно сделать до первой новой функции и сколько это стоит. Если технология выбрана неудачно для ваших задач, это тоже будет в отчёте; как сравнивать варианты, мы разбирали в статье «Натив, Flutter или React Native».

Признак	Скорее дорабатывать	Скорее переписывать
Сборка	Проект собирается по инструкции, пусть и после обновления библиотек	Не собирается, нужные версии инструментов давно не поддерживаются
Технология	Актуальная: Swift, Kotlin, Flutter, React Native свежих версий	Устаревший или закрытый фреймворк, под который никто не пишет
Код	Понятная структура, логика не размазана по экранам	Одни и те же правила продублированы в десятке мест, правка ломает соседнее
Сервер	Есть описание API, сервер можно поднять у себя	Сервер — «чёрный ящик» на чужом хостинге без исходников
Планы	Нужно добавить функции к работающему продукту	Продукт меняется по сути: другая модель, другие пользователи, другой дизайн

Доработать или переписать: признаки

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

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

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

Признаки обоих вариантов собраны в таблице.

Первые две недели нового подрядчика

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

Примерный план:

• Дни 1–2. Список доступов и запрос недостающего у прошлого разработчика, приглашение в консоли магазинов с рабочими ролями, перенос репозитория на ваш аккаунт.
• Дни 3–5. Сборка с нуля, проверка на телефонах, разбор сервера, обновление инструментов, если без этого магазины не примут сборку.
• Дни 6–8. Отчёт по аудиту, оценка срочных исправлений, решение «дорабатываем или переписываем».
• Дни 9–10. Небольшой релиз: исправление пары заметных ошибок из отзывов или обновление под требования магазина. Первая сборка, подписанная и опубликованная новой командой.

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

Задачи и приёмка у нас идут через личный кабинет с доской проекта: вы видите, что в работе и что ждёт вашей проверки, а не ищете статус в переписке.

Когда это не нужно и какие ошибки бывают?

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

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

• Принять архив вместо репозитория. Архив последней версии не показывает, что собиралось в магазин. Нужен репозиторий с историей и меткой версии, которая сейчас опубликована.
• Забыть про сервер. Приложение на телефонах работает, пока работает чужой сервер. Подрядчик перестанет платить за хостинг — и приложение у всех пользователей покажет пустой экран.
• Сразу ставить новые функции. Без проверки сборки первая же задача упрётся в обновление инструментов, и сроки поедут.
• Не проверить договор с прошлым подрядчиком. Посмотрите, какие права на код вы получили и можно ли передавать его другим исполнителям для доработки. Как это обычно устроено, — в статье «Кому принадлежит код после разработки», а общий порядок передачи проекта — в материале о смене разработчика и аудите чужого кода.
• Отзывать доступы прежней команды в первый день. Сначала убедитесь, что новая команда собрала и опубликовала версию. Потом отзывайте — все и сразу, включая ключи сервисов, которые знает прежний подрядчик.
• Переписывать «по ощущениям». Решение о переписывании без отчёта по аудиту часто означает, что вы заплатите дважды за одни и те же функции.

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

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

1. Репозиторий приложения на вашем аккаунте, с историей и меткой опубликованной версии.
2. Репозиторий сервера и админки, инструкция по развёртыванию.
3. Ключ загрузки или ключ подписи Android с паролями; понятно, подключено ли приложение к Play App Signing.
4. Аккаунты App Store Connect и Google Play Console — ваши; прежняя команда приглашена пользователями, а не владеет ими.
5. Ключи и сертификаты push: кто их выпускал, когда истекают, кто может перевыпустить.
6. Проект Firebase и аналитика — с вашим аккаунтом в роли владельца.
7. Сервер, домен, база данных и резервные копии — на вас или с вашим полным доступом.
8. Платёжный шлюз, SMS, карты и другие сервисы — кабинеты на вашей компании.
9. Короткий документ: как собрать, как выпустить, где что лежит.
10. Тестовые учётные записи для проверки приложения, в том числе та, что указана для проверяющих магазина.

Если вы приходите к нам с готовым приложением, начинаем с этого списка и аудита. Объём доработки считаем после аудита, дальнейшее сопровождение — поддержка и развитие от 7 900 ₽/мес по абонентке или разово по задачам. Если по итогам решим писать заново, базовый тариф «Мобильное приложение» — от 200 000 ₽ и от 2 недель: iOS и Android из одного кода, публикация под вашими аккаунтами, исходники приложения и сервера в вашем репозитории и инструкция по выпуску новых версий. Наш договор прямо даёт согласие на сублицензии подрядчикам, которых вы привлекаете для обслуживания и доработки, так что следующая смена команды пройдёт по этому же чек-листу без сюрпризов. Типовые договоры и акты открыты в разделе «Документы».

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

Можно ли доработать мобильное приложение без исходного кода?

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

Что делать, если прошлый разработчик потерял ключ подписи Android?

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

Сколько занимает аудит чужого мобильного приложения?

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

Нужно ли разрешение прошлого разработчика, чтобы другая студия дорабатывала его код?

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

Можно ли сменить технологию, не теряя пользователей в магазинах?

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

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