Короткий ответ: доработка начинается с проверки проекта
Если приложение уже установлено у пользователей, новая кнопка видна всем, а основная работа остаётся за кадром. Команде нужно повторить текущую сборку, понять её зависимости, внести изменение, проверить старые функции и выпустить обновление через аккаунт владельца. Даже опубликованное приложение может не собираться из переданных исходников: например, в архиве нет нужной конфигурации сервера или инструкции по сборке.
Поэтому стоимость доработки нельзя надёжно получить умножением числа экранов на тариф. Запросите оценку двух частей: короткой проверки того, что есть, и собственно изменения с тестами и выпуском. Если приложение собирается, проблему удаётся повторить и изменение ограничено одним участком, локальная правка может быть разумной. Если сборка не получается, сначала выясните причину. Только после этого сравнивайте замену компонента и переписывание по стоимости, сроку и влиянию на пользователей.
Реальный проект 13FOX
ProxyControl: почему одна новая функция затрагивает несколько путей
В мобильном ProxyControl пользователь импортирует профили PROXYS.IO через API-ключ, выбирает профиль, подключается и видит состояние, пинг и трафик. Если менять импорт, приёмка не может закончиться проверкой одного экрана: надо пройти путь до подключения и состояния. Кейс показывает зависимость функций, а не историю приёма чужого кода.
Что проверить до оценки и что делать, если чего-то нет
Диагностика нужна не ради отчёта «код хороший или плохой». Её результат: перечень проверенных фактов, неизвестных и следующего небольшого шага. Например, если приложение не собирается, спор о цене нового раздела пока преждевременен: сначала зафиксируйте конкретную ошибку сборки и недостающую зависимость.
| Что проверить | Подтверждение | Если не хватает |
|---|---|---|
| Право на код | Договор и разрешение передать исходники новой команде | Уточнить условия передачи до доступа к проекту |
| Исходники и история | Репозиторий с кодом, версия кода последнего выпуска, нужные библиотеки и инструкция | Найти актуальную версию и зафиксировать расхождение с магазином |
| Сборка | Повторная сборка и запуск на тестовом устройстве | Отдельно восстановить окружение и первую точку отказа |
| Публикация | Кто управляет App Store Connect/Play Console, ключами подписи обновления и тестовым выпуском | Выдать роли, проверить ключи и возможный порядок восстановления |
| Данные и сервер | API (связь с сервером), отдельная тестовая среда, внешние сервисы, правила обработки ошибок | Ограничить оценку клиентской частью или добавить сервер в план |
| Критический путь | Шаги входа, покупки или другой основной операции; известные дефекты | Составить маршрут и воспроизвести ошибку до правки |
Не отправляйте пароль от своего личного аккаунта в переписке. Apple позволяет приглашать пользователей с назначенными ролями. Порядок доступа Google Play тоже проверяйте в аккаунте владельца. Пароли, ключи и реальные данные передают только через согласованный защищённый способ и в объёме, нужном для работы.
Исправить, заменить компонент или переписать?
Решение зависит от того, где находится причина. Представьте, что после входа не открывается список заказов. Если ошибка в одном запросе и остальные сценарии работают, полная перепись не решает задачу разумнее локальной правки. Если тот же механизм чтения данных ломает заказы, профиль и оплату, замена общего компонента может оказаться надёжнее серии заплат. Переписывание обсуждайте после диагностики, когда большинство нужных изменений затрагивает основу приложения и полная цена исправлений с поддержкой старой версии выше новой реализации с сохранением пользователей и данных.
| Вариант | Когда подходит | Что попросить в оценке |
|---|---|---|
| Локальная правка | Дефект воспроизводится, причина ограничена, сборка и выпуск доступны | Точное изменение, затронутые сценарии, проверка отката |
| Замена компонента | Один общий модуль мешает нескольким функциям или безопасным обновлениям | Граница модуля, переход данных, совместимость со старым поведением |
| Новое приложение | Основной путь и архитектуру приходится менять целиком, а старый код не ускоряет работу | Переход пользователей и данных, публикация, временная поддержка старой версии |
Переписывание не всегда означает новый идентификатор приложения в магазине. Возможность выпустить новую реализацию как обновление существующего продукта зависит от аккаунта, идентификатора, подписи, правил площадки и устройства приложения. Эти условия надо проверять отдельно. Официальные инструкции Google по подписи Android-приложения и Apple по выпуску сборки показывают, почему техническое решение связано с публикацией.
Из чего складывается стоимость доработки
Попросите смету по этапам и результатам. Например, если приложение не собирается, восстановление сборки должно быть отдельной строкой, а не частью цены новой функции. Так вы увидите, платите ли за исправление ошибки, серверное изменение или выпуск. Сумму и срок можно обсуждать после проверки входных условий; фиксированная цена «за любой чужой код» скрывает эти различия.
- Диагностика: получить актуальный код, повторить сборку, пройти основной сценарий, установить причину проблемы и список неизвестных. Результатом станет короткий отчёт с вариантами действия.
- Изменение: уточнить поведение, внести правку в приложение и при необходимости в сервер, обновить зависимости только там, где это требуется.
- Проверка: проверить новую функцию и старые пути рядом с ней. В частности, после изменения входа проверяют восстановление сессии; после изменения заказа проверяют отмену, повторный запрос и оплату.
- Выпуск: подготовить релизную сборку, проверить подпись, протестировать её, подать обновление и наблюдать за ошибками после доступности пользователям. Android и Apple отдельно описывают сборку и тестирование перед выпуском.
В смете отдельно отметьте, что ещё не подтверждено: доступ к серверу, версия кода, работа стороннего API, платные библиотеки, ключи подписи, работа старого подрядчика. Например, если неизвестно, отвечает ли API оплаты на тестовом сервере, запишите отдельную проверку и условие пересмотра объёма, а не прячьте риск в «прочие работы».
После диагностики запросите у исполнителей сопоставимые варианты. В каждом должны быть цена и срок за один и тот же результат, затронутые старые функции, тесты, выпуск и неизвестные. Для переписывания отдельно считайте перенос пользователей и данных и время, пока приходится поддерживать старую версию. Скопируйте таблицу и заполните её по предложениям двух команд.
| Что сравнить | Предложение А | Предложение Б |
|---|---|---|
| Результат: что изменится для пользователя | Заполнить по смете | Заполнить по смете |
| Способ: правка, замена или новая реализация | Заполнить по смете | Заполнить по смете |
| Цена и срок после диагностики | Заполнить по смете | Заполнить по смете |
| Старые функции, перенос данных и пользователей | Заполнить по смете | Заполнить по смете |
| Тестирование, выпуск, поддержка старой версии | Заполнить по смете | Заполнить по смете |
| Неизвестные и условие пересмотра оценки | Заполнить по смете | Заполнить по смете |
Например, результат диагностики может звучать так: «тестовая версия собрана, ошибка списка заказов воспроизведена, проблема ограничена одним запросом; доступ к серверу оплаты пока не проверен». Это уже основание оценить локальную правку и отдельно обозначить риск оплаты. Фраза «код плохой, нужно всё переписать» без проверок такого основания не даёт.
Как передать приложение другой команде
Смена подрядчика и перенос приложения в другой аккаунт решают разные задачи. При обычной смене команды бизнес сохраняет свои аккаунты магазина и добавляет новых участников с нужными правами. Если приложение действительно нужно перенести между владельцами аккаунтов, действуют отдельные процедуры и ограничения Apple и Google Play. Например, после передачи требуют отдельной проверки интеграции и группы тестирования. Не начинайте перенос ради одной новой функции.
Запросите у прежней команды репозиторий, инструкцию сборки, сведения о сервере и внешних сервисах, перечень ключей без отправки секретов открытым письмом, материалы дизайна и список известных проблем. Новый исполнитель должен записать, что реально получил и что смог повторить. Даже хороший документ не заменяет проверочную сборку из переданного кода.
О правовой части передачи подробнее рассказываем в статье «Права на код приложения». Если задачи касаются регулярных обновлений и инцидентов после запуска, полезно сравнить их с технической поддержкой приложения.
Как принять доработку без сюрприза для пользователей
Проверка «новая кнопка нажимается» слишком узкая. Для каждой доработки нужен один маршрут до результата и соседние старые маршруты. В ProxyControl, например, изменение импорта профиля имело бы смысл проверять вместе с выбором профиля, подключением и отображением состояния: именно такой путь пользователь проходит в продукте.
| Проверка | Пример вопроса | Что сохранить как доказательство |
|---|---|---|
| Новое действие | Работает ли функция с обычными, пустыми и ошибочными данными? | Шаги теста и результат на устройстве |
| Старый путь | Можно ли войти, завершить покупку или основную операцию как раньше? | Перечень критических сценариев и результат повторной проверки |
| Сбой | Что увидит человек при обрыве сети, повторе запроса или недоступном сервере? | Скриншот/журнал ошибки и ожидаемое поведение |
| Релиз | Собирается ли подписанная версия и ставится ли поверх прежней? | Номер сборки, тестовый выпуск и ответственный за публикацию |
Укажите, на каких устройствах и версиях системы нужна проверка. Не обязательно тестировать всё существующее оборудование, но выбор должен исходить из устройств ваших пользователей и риска функции. После выпуска наблюдайте за ошибками именно изменённого сценария, а не считайте приёмку законченной в момент отправки сборки на проверку площадки.
Шаблон запроса, который ускорит первую оценку
Скопируйте вопросы ниже в письмо новой команде. Если ответа пока нет, так и напишите: это обозначит проверку, а не создаст ложную уверенность.
Приложение: ссылка в App Store / Google Play, платформы и версия, которую используют клиенты.
Задача: что делает человек сейчас, какой результат нужен, что именно не работает; шаги, видео или скриншот.
Код: есть ли репозиторий, инструкция сборки и контакт прежней команды.
Доступы: кто владеет аккаунтами магазинов, сервером и внешними сервисами; секреты пока не присылать.
Приёмка: какие старые действия нельзя сломать и какие устройства важны.
Результат первой встречи: список проверок, граница первого этапа, неизвестные и порядок оценки исправления.
Даже если сейчас есть только ссылка на приложение и запись ошибки, разговор можно начать. Но точную стоимость исправления безопаснее называть после проверки кода, сборки и причины сбоя. О том, как мы проводим этот первый этап, рассказано на странице доработки мобильных приложений.
Частые вопросы
Можно ли доработать приложение после другого разработчика?
Да, если у новой команды есть право работать с кодом, доступ к исходникам и способ собрать и выпустить обновление. Начните с ограниченной диагностики: она покажет, какие части проекта доступны и какие проблемы воспроизводятся.
Сколько стоит доработка мобильного приложения?
Единой цены нет. Смета состоит из проверки проекта, изменения кода и серверной части при необходимости, тестов затронутых сценариев и выпуска. Если сборка не повторяется или отсутствуют доступы, восстановление этих условий оценивают отдельным этапом.
Обязательно ли переписывать старое приложение?
Нет. Возраст кода сам по себе не основание. Если дефект локализован и приложение собирается, достаточно точечной правки. Если проблема сосредоточена в одном компоненте, его можно заменить. Переписывание сравнивают с этими вариантами, когда изменения затрагивают основу продукта или текущий код нельзя разумно поддерживать.
Нужно ли передавать подрядчику пароль от аккаунта Apple или Google?
Обычно нет. В App Store Connect можно добавить пользователя и назначить роль. Для Google Play сначала проверьте доступы и владельца аккаунта. Передача приложения между аккаунтами нужна при смене владельца аккаунта, а не при каждой смене подрядчика.
Что делать, если исходников нет?
Сначала проверьте договор, старый репозиторий, резервные копии и возможность получить материалы у прежней команды. Без исходного проекта нельзя обещать обычную правку: потребуется отдельно оценить восстановление, замену или создание нового приложения с учётом пользователей и публикации.
Источники и дата проверки
Правила доступа и выпуска сверены 23 сентября 2026 года по документации Apple App Store Connect, Apple о передаче приложения, Google Play о переносе и Android о подписи. Описание ProxyControl опирается на кейс 13FOX. Условия платформ могут измениться перед вашим релизом.
Нужно оценить доработку существующего приложения?
Пришлите ссылку на приложение, описание проблемы или функции, сведения о репозитории и о том, кто управляет аккаунтами. Мы обозначим, что уже можно оценить, что надо проверить в сборке и доступах, и предложим состав первого этапа. После диагностики обсудим варианты изменения и рамки сметы по каждому.
Для первого разговора не нужны пароли и доступы к рабочим системам.