Подхват проекта — мобильное приложение
Заберём iOS, Android или кроссплатформенное приложение у предыдущей команды. Начинаем с аудита кода, релизного процесса, backend и API, crash reports, push-уведомлений, аналитики и доступов к сторам. Дальше — стабилизация, поддержка или развитие по согласованной модели.
Что мы понимаем под подхватом
Мобильное приложение в проде — это не только исходники. Это сертификаты, ключи подписи, аккаунты сторов, CI/CD, backend-контракты, crash reports, аналитика, push и история релизов. Подхват — это восстановить контроль над всем перечисленным.
Разбор репозиториев и веток, воспроизводимая сборка под iOS и Android, сертификаты и provisioning, аккаунты App Store Connect и Google Play Console, статусы и причины отклонений, crash reporting и логи, стабильность API и платежей, push, аналитика событий, релизная история. Письменный отчёт с приоритезированными рисками. Передача доступов и письменный акт. Дальше — поддержка или развитие по согласованной модели.
Точечная правка одного экрана без аудита и без ответственности за релиз. Полная переработка концепции и дизайна без разбора текущего состояния. Работа без подтверждённых прав на исходники и согласованного доступа хотя бы на чтение. Сопровождение приложения, которое бизнесу проще закрыть и заменить новым продуктом.
Когда нужен подхват
Если совпали два-три пункта — пора смотреть, что на самом деле происходит с приложением.
Команда перестала отвечать или отвечает «через раз». Последний релиз — несколько месяцев назад, при этом задачи открыты.
После выхода новой версии iOS или Android растёт crash rate. Фикс либо не делается, либо приходит спустя недели.
App Store или Google Play возвращают сборку с замечаниями, ответ ревьюеру откладывается, релиз буксует.
Сборка собирается на одной локальной машине одного человека. Сертификаты и ключи подписи разбросаны или потеряны.
Часть пользователей не получает push, оплаты проходят со второй попытки, авторизация по соцсетям ломается после ротации ключей.
Серверные изменения регулярно ломают приложение: контракты API плывут, нет версионирования, мобильная команда не успевает.
События задублированы или не приходят, crash reporting показывает обезличенные стек-трейсы, по которым нельзя восстановить причину.
Прод горит, а воспроизвести сборку, подписать её и выложить в стор в нужный срок никто из доступных людей не может.
Кому не подойдёт
Называем заранее, чтобы не тратить ваше время и не вводить в заблуждение.
Если задача — переосмыслить продукт и нарисовать новый интерфейс без разбора текущего приложения, это работа дизайн-команды, а не подхват.
Если у вас нет подтверждённых прав на код приложения и хотя бы доступа на чтение к репозиториям и аккаунтам сторов, и получить их невозможно — мы не работаем.
Иногда честный ответ — закрыть текущее приложение и собрать новый продукт с другим бизнес-замыслом. В таком случае подхват тратит ваши деньги впустую.
Один экран, одна кнопка, без аудита и без выпуска в стор — это та же история, которая привела в текущую ситуацию. Заходим минимум через аудит и с ответственностью за релиз.
Что проверяем в первые дни
Сразу не лезем чинить. Сначала проходим по списку и фиксируем состояние, чтобы дальше работать с фактами, а не с предположениями.
Структура репозиториев, активные ветки, теги релизов, расхождение между прод-веткой и тем, что лежит в сторе.
Версии тулчейна, зависимости, скрипты сборки, signing, certificates и provisioning profiles, ключи Android-подписи и keystore.
Состояние аккаунтов, роли, статус последних сборок, причины отклонений, наличие незакрытых ревью-замечаний.
Подключённый crash reporter, частота падений, топ крашей по версиям и устройствам, наличие символизации стек-трейсов.
Состояние сервисных контрактов, схемы авторизации, статус платёжных интеграций, конфигурация push под обе платформы.
Что и куда отправляется, корректность ключевых воронок, дубли событий, расхождения между мобильной аналитикой и backend.
Список SDK, версии, наличие просроченных или несовместимых с актуальной ОС зависимостей, риск отказа стора в публикации.
Токены и секреты в коде, способы хранения пользовательских данных, network security config, certificate pinning, обработка сессий.
Что вы получаете после аудита
Артефакты остаются у вас даже в случае, если дальше работаете не с нами.
Письменный разбор кода, сборки, релизного процесса, backend, сторов, crash reports и аналитики с приоритезированными находками.
Таблица: риск, вероятность, влияние, приоритет, ответственный. Разнесена по платформам, чтобы видеть, где горит первым.
Что и в каком порядке забрать у прошлой команды: репозитории, сертификаты, ключи, аккаунты сторов, backend, аналитика, push.
Список работ после старта подхвата с оценкой трудоёмкости. Цель — снять острые риски и вернуть релизы в управляемый режим.
Сгруппирован по приоритету и платформе: что в ближайший релиз, что в следующий, что в техдолг.
Как должны выглядеть сборка, подпись, выкладка и rollout. Куда двигать процесс, чтобы релизы перестали быть событием.
Поддерживать, стабилизировать, частично переписать или переписать полностью — обоснованное решение по итогам аудита, а не «нам не нравится старый код».
Первый месяц
В первый месяц не пересобираем продукт «как нам нравится». Снимаем острые риски, чтобы релиз перестал быть лотереей.
Фиксируем версии тулчейна, зависимости и переменные окружения. Сборка iOS и Android должна получаться у любого инженера команды, а не у одного человека.
Переоформляем сертификаты и provisioning, заводим Android-keystore на вашей стороне, передаём роли в App Store Connect и Google Play Console на нужных людей.
Берём топ падений по версиям и устройствам, разбираем причины, выпускаем фикс-релиз. Не «улучшаем по дороге», а закрываем именно то, что валит пользователей.
Проходим сценарии, которые ломаются у пользователей чаще всего. Чиним обработку ошибок, повторные запросы, статусы платежей и доставку push.
Сборка, подпись, выкладка и rollout — по понятному регламенту с ответственными. Релизы перестают зависеть от того, «кто сегодня на месте».
Crash reporting с символизацией, ключевые продуктовые метрики и алёрты на проседания. Чтобы решения принимались по данным, а не по «кажется».
Чего не ломаем при переходе
Эти ограничения мы соблюдаем сами, чтобы переход был предсказуемым, а не «новая команда переделала всё под себя».
Смена идентификатора означает «новое» приложение для пользователей и потерю установленной версии. Идём на это только осознанно, с планом миграции.
Переключение Apple Developer и Google Play аккаунтов делается по отдельному чек-листу с вами как владельцем, а не «в фоне» во время фикс-релиза.
Фикс — это фикс. Любые дополнительные изменения уходят в отдельный релиз, чтобы было ясно, что именно поменялось.
Если внешний сервис меняется, делаем это с подтверждённой заменой и проверкой на тестовых сборках, а не «потом починим».
Внутри отчёта пишем как есть. За пределы проекта оценочные суждения о работе прошлой команды не транслируем.
Стек и типовые конфигурации
Заходим в проекты на стеках, с которыми работают наши команды. Если вашего нет в списке — напишите, скажем честно, готовы ли мы подхватить или порекомендуем тех, кто делает это лучше.
Flutter и React Native, включая нативные модули и мосты.
Swift, Objective-C, смешанные проекты, SwiftUI и UIKit.
Kotlin, Java, смешанные проекты, Jetpack Compose и View-стек.
Node.js, Python, PHP, REST и GraphQL, очереди и вебхуки.
GitLab CI, GitHub Actions, Fastlane, скрипты подписи под обе платформы.
App Store Connect, Google Play Console, Firebase, crash reporting, push, Docker.
Частые проблемы
Это не «страшилки». Это то, что регулярно встречается в приложениях, приходящих на подхват. Владелец продукта обычно об этом не знает.
После обновления iOS или Android растёт частота падений, особенно на свежих устройствах. Фикс не выпускался месяцами.
Платёжные, аналитические или auth-SDK в проекте на старых версиях. Стор предупреждает или уже отклоняет сборки.
Сборка не запускается без специфической локальной машины. Версии тулчейна нигде не зафиксированы, README устарел.
Apple Developer-сертификаты или Android-keystore остались у одного человека или утеряны. Без них обновление в сторе невозможно.
API-ключи, токены аналитики и push, пароли тестовых стендов закоммичены в код. После увольнения сотрудника всё ещё в истории.
Контракты API меняются без версионирования, мобильный клиент ломается на проде после серверных релизов.
Часть пользователей не получает уведомления. APNs или FCM настроены частично, токены устаревают, ошибки доставки никто не разбирает.
In-app purchases или внешние эквайринги проходят со второй попытки, статусы заказов уезжают, чеки не приходят пользователю.
События дублируются или теряются, мобильная аналитика и backend расходятся, по воронкам нельзя принимать решения.
Каждый релиз — отдельное событие на одном человеке и одной машине. Если человек заболел, релиза в этот период нет.
Чек-лист передачи доступов
Часть пунктов выглядит банально, но именно они срывают подхват мобильного приложения чаще, чем сложный код.
Типы мобильных проектов
Если ваш случай — в списке ниже, опишите его в заявке. Обсуждаем по существу: что досталось, какие риски, с чего начнём.
Каталог, заказы, личный кабинет, уведомления.
Маршруты, статусы заказов, геолокация, офлайн-режим.
Кабинет, рабочие процессы, доступ к корпоративным системам.
Продавцы и покупатели, каталог, оплаты, рейтинги.
Платежи, KYC, безопасность, журналы операций.
Курсы, прогресс, видео и контент, офлайн-доступ.
Записи, медданные, чувствительность к приватности.
In-app purchases, биллинг, отмены и возвраты.
Карты, маршруты, фоновая геолокация, разрешения.
Авторизация, роли, доступ к API основного продукта.
Шире мобильного приложения
Если нужно забрать не только мобильный клиент, но и backend, CRM, интеграции, сайт или внутреннюю админку — начните с общей страницы подхвата проекта.
Если рядом с мобильным приложением есть смежная часть, у нас уже есть отдельные страницы про подхват Python-проекта, подхват интеграций и API и подхват Telegram-бота.
FAQ
С короткой стартовой сессии и заявки на аудит. Обсуждаем, что за приложение, какие платформы в проде, что произошло с прошлой командой, какие доступы и аккаунты уже на вашей стороне. По запросу подписываем NDA. Дальше — аудит кода, релизного процесса, backend, сторов, crash reports, push и аналитики. Условия подхвата обсуждаем после отчёта.
На аудите фиксируем, на чей аккаунт оформлены App Store Connect и Google Play Console и кто числится владельцем приложений в обоих сторах. Дальше — план перевода ролей: если кабинеты оформлены на компанию заказчика, доступ восстанавливается через службы поддержки сторов с вашей стороны. Кабинеты, оформленные на личные аккаунты прошлого подрядчика, мы не «забираем» технически — это решается на стороне сторов и в рамках их процедур владельца.
Это типовая ситуация при подхвате. На аудите восстанавливаем воспроизводимую сборку: версии Xcode и Android Studio, версии Flutter или React Native, зависимости, ключи подписи, переменные окружения. Если каких-то артефактов нет на вашей стороне, отдельно фиксируем, что и у кого нужно запросить, и помогаем сформулировать запрос.
Восстановление аккаунтов сторов — отдельный сюжет на стороне владельца. Apple и Google работают только с владельцем учётной записи. Мы готовим список нужных шагов: подтверждение владения, перевод в Organization-аккаунт, выпуск новых сертификатов и ключей. Параллельно проверяем, что часть работы можно вести без store-доступа: репозитории, backend, аналитика.
Да. Подхватываем приложения и на Flutter, и на React Native. В обоих случаях аудит покрывает не только мобильный клиент, но и нативные модули, мосты и сборку под обе платформы.
Да. Заходим в нативные проекты на Swift, Objective-C, Kotlin и Java. Если внутри одной платформы код смешанный — например, исторический Objective-C и новые экраны на Swift — это учитываем в плане стабилизации и поэтапно приводим к одному состоянию.
Да, если внутри проекта есть чёткая граница ответственности по платформам. Аудит и стабилизация в этом случае фокусируются на выбранной платформе. Backend и общие сервисы при необходимости разбираем отдельно.
На аудите смотрим обе стороны. Часто мобильные баги — следствие нестабильного API, неконсистентных контрактов или сломанных вебхуков. В отчёте отделяем мобильную часть от серверной и предлагаем план по обеим. Backend можем взять в подхват вместе с приложением или оставить вашей команде, если так удобнее.
До любого релиза проверяем актуальность сертификатов и provisioning-профилей iOS, FCM-ключи и Android-подписи, отправку тестовых push на staging-устройства, сборку через CI на отдельной ветке, поведение приложения после обновления для существующих пользователей. Если каких-то секретов нет на вашей стороне, сначала составляем технический список того, что нужно восстановить со стороны заказчика, и только потом планируем релиз.
Это нормальная ситуация. Аудит мобильного приложения в этом случае фокусируется на клиенте: код Flutter или React Native, сборка, сертификаты, push-уведомления, API-контракты с backend. Контракт с серверной частью описываем отдельным разделом отчёта: какие эндпоинты используются, какие версии поддерживаются, где видны разрывы совместимости. Координацию с backend-командой ведём по согласованному регламенту.
Заказать аудит мобильного приложения
Опишите приложение, стек, что произошло с предыдущей командой и какой релиз сейчас горит. Вернёмся с конкретикой и предложим стартовую сессию.
Подхват мобильного приложения
Поля помечены под подхват приложения: что за продукт, какие платформы, что произошло, какие доступы есть.
Заявка придёт на hi@khaiam.ru. Можно написать сразу в Telegram .
Заявка отправлена
Если задача срочная, можно сразу написать в Telegram .