Зачем приложению поддержка после запуска
Мобильное приложение живёт в постоянно меняющейся среде. Apple и Google каждый год выпускают новые версии iOS и Android, магазины поднимают требования к сборкам, сторонние сервисы обновляют API, а пользователи находят сценарии, которые не встретились при тестировании.
Если приложение не поддерживать, проблемы копятся незаметно: сначала ломается вёрстка на новом iPhone, потом перестают приходить push-уведомления, а затем магазин отказывается принимать обновление, потому что сборка не соответствует новым требованиям.
Поддержка — это плановая работа, которая сохраняет приложение рабочим и позволяет в любой момент выпустить исправление или новую функцию.
Что входит в сопровождение приложения
Состав работ зависит от проекта, но базовый набор у большинства приложений похож:
- Адаптация к новым версиям iOS и Android: проверка на бета-версиях систем, исправление вёрстки и поведения.
- Обновление SDK, библиотек и инструментов сборки под требования App Store, Google Play и RuStore.
- Исправление ошибок, найденных пользователями или системой мониторинга.
- Мониторинг сбоев и производительности: отчёты о падениях, медленные экраны, ошибки сервера.
- Поддержка серверной части: обновления, резервные копии, контроль доступности, продление сертификатов и доменов.
- Поддержка интеграций с CRM, 1С, платёжными сервисами и кассами, когда у них меняется API.
- Работа с магазинами: продление аккаунтов разработчика, обновление анкет о данных и политики конфиденциальности, ответы на замечания модерации.
- Небольшие доработки: новые баннеры, правки текстов, изменения в каталоге или бонусной программе.
Крупные новые функции — например, подписки или чат — обычно оформляются отдельной задачей с оценкой, а не входят в регулярную поддержку.
Обязательные обновления: требования магазинов
Самая недооценённая часть поддержки — требования магазинов, которые появляются независимо от ваших планов.
Пример 2026 года: с 28 апреля Apple принимает только сборки, созданные в Xcode 26 с SDK iOS 26, а Google Play с 31 августа требует для новых приложений и обновлений целевой уровень Android 16 (API 36). Опубликованные приложения ниже Android 15 (API 35) перестают показываться новым пользователям на свежих устройствах.
Такие изменения происходят ежегодно. Если приложение два года не обновлялось, первое же исправление может потребовать заметной работы: обновить зависимости, переписать устаревшие участки кода и заново пройти проверку.
Регулярные расходы помимо работы разработчиков
Помимо часов команды, у приложения есть собственные постоянные расходы. Их стоит учитывать в бюджете отдельно.
| Статья расходов | Как оплачивается | Комментарий |
|---|---|---|
| Аккаунт Apple Developer Program | 99 $ в год | Без активного аккаунта приложение пропадает из App Store |
| Аккаунт Google Play Console | 25 $ единоразово | Повторной оплаты не требует |
| RuStore | Бесплатно | Комиссия только с платных приложений и покупок |
| Сервер и база данных | Ежемесячно | Зависит от нагрузки и выбранного хостинга |
| Сторонние сервисы | По тарифам сервисов | Карты, СМС-коды, рассылки, аналитика, хранение файлов |
| Эквайринг и онлайн-касса | Комиссия и тарифы провайдеров | Если в приложении есть оплата |
Модели оплаты поддержки
На рынке встречаются три основные модели. Каждая подходит своему типу проекта.
| Модель | Как устроена | Кому подходит |
|---|---|---|
| Почасовая оплата | Оплачивается фактически затраченное время по согласованной ставке | Приложениям со стабильным функционалом и редкими задачами |
| Абонемент | Фиксированный пакет часов в месяц и гарантированное время реакции | Проектам, где важна скорость реакции и есть регулярный поток задач |
| Годовой бюджет | Сумма планируется как доля от стоимости разработки и распределяется по году | Компаниям, которым нужно заложить поддержку в годовой бюджет |
Ориентир, который часто приводят студии в открытых обзорах рынка: годовые расходы на поддержку составляют примерно 15–25% от стоимости разработки. Это рыночная оценка, а не правило — для простого приложения без интеграций сумма может быть ниже, для сервиса с оплатой, 1С и высокой нагрузкой — выше. Реальный объём мы оцениваем после аудита конкретного проекта.
От чего зависит стоимость поддержки
Две похожие внешне программы могут требовать очень разного объёма сопровождения. На стоимость влияют:
- Количество платформ и технология: одна кроссплатформенная кодовая база или две нативные.
- Число интеграций — каждая CRM, 1С, касса или служба доставки может изменить API.
- Наличие собственного сервера и админ-панели.
- Требования к скорости реакции: исправить в течение рабочего дня или в течение часа круглосуточно.
- Качество кода и документации, особенно если приложение досталось от другого подрядчика.
- Частота релизов и объём доработок, которые вы планируете.
Чем больше интеграций и модулей в приложении, тем важнее регулярная поддержка. Про интеграции с учётными системами подробнее — на отдельных страницах.
Как выглядит поддержка на практике
Хорошее сопровождение строится вокруг понятного процесса, а не разовых просьб «посмотрите, что-то сломалось». Обычно мы договариваемся о нескольких вещах.
Канал для заявок: где вы сообщаете об ошибке и как отслеживаете её статус. Приоритеты: критическая ошибка, из-за которой клиенты не могут оформить заказ, решается в первую очередь, а правка текста ждёт ближайшего плана работ. Время реакции: в какие часы команда на связи и как быстро берёт задачу в работу.
Плановые обновления выпускаются по графику: например, раз в месяц собираются накопленные исправления и небольшие доработки, проходят тестирование и уходят в магазины. Срочные исправления выпускаются отдельно.
Раз в год, обычно к выходу новых версий iOS и Android, стоит закладывать проверку приложения на свежих системах и обновление инструментов сборки. Так вы не столкнётесь с требованиями магазинов в последний момент.
И наконец, отчётность: какие задачи выполнены, сколько времени ушло, какие риски видит команда. Это помогает планировать бюджет и понимать, на что уходят деньги.
Как сократить расходы на сопровождение
Часть затрат на поддержку закладывается ещё на этапе разработки. Аккуратная архитектура, автоматические сборки, подключённый мониторинг сбоев и понятная документация делают каждое следующее обновление дешевле.
Второй способ — не откладывать обновления. Регулярно поднимать версии библиотек небольшими шагами проще и дешевле, чем раз в два года делать большую миграцию.
Третий — сразу оформлять аккаунты разработчика, сервер и домены на компанию. Тогда смена подрядчика не превращается в восстановление доступов.
Поддержка приложений в IT-STATUS Mobile
Мы сопровождаем приложения, которые разработали сами, а также можем оценить проект, сделанный другой командой. Начинаем с аудита: проверяем код, версии SDK, сервер, интеграции и доступы, затем предлагаем удобный формат работы.
Если приложение ещё только планируется, стоимость разработки можно посчитать в калькуляторе, а затем обсудить с нами, как будет устроена поддержка после запуска.