Релиз в App Store, Google Play или RuStore — точка, с которой начинается эксплуатация продукта, а не её завершение. Пока приложение лежит на витрине без единого обновления, вокруг него продолжает меняться всё: выходят новые версии ОС, магазины поднимают требования к целевым версиям SDK, у библиотек находят уязвимости, истекают сертификаты подписи и push, а внешние сервисы — платёжные шлюзы, карты, аналитика — меняют версии своих API.
Приложение, которое не обновляют, не ломается в один день. Оно медленно теряет совместимость: сначала перестают приходить push, потом магазин отказывается принимать новую сборку, потом само приложение пропадает из выдачи для новых пользователей на актуальных версиях ОС. К этому моменту исправить ситуацию уже дороже и дольше, чем было бы регулярно поддерживать её на протяжении года.
Почему приложение нельзя «сдать и забыть»
У необходимости поддержки есть несколько независимых источников, и каждый из них работает по своему расписанию — не дожидаясь, пока у владельца приложения появится время или бюджет.
Ежегодные требования магазинов к версиям SDK
Apple и Google обновляют мобильные ОС раз в год и параллельно ужесточают требования к тому, с какой версией SDK должно быть собрано загружаемое в магазин приложение. Это не пожелание, а условие публикации: без соответствия требованию новая сборка не проходит модерацию.
| Площадка | Требование | Срок |
|---|---|---|
| Google Play | Новые приложения и обновления существующих — target API level 36 (Android 16) | С 31 августа 2026 года; по отдельным приложениям можно запросить отсрочку до 1 ноября 2026 через форму в Play Console |
| Google Play, приложения без обновлений | Приложения с target API level ниже 35 перестают показываться в поиске и на витрине новым пользователям на устройствах с более новой версией Android, чем целевая у приложения | Действует по мере распространения новых версий Android; уже установленные копии продолжают работать у существующих пользователей |
| App Store | Приложения и обновления должны быть собраны Xcode 26 с SDK iOS 26 / iPadOS 26 (для tvOS и visionOS — соответствующие версии SDK 26) | С 28 апреля 2026 года — для всех новых сборок, загружаемых в App Store Connect |
Требование к SDK — это версия инструмента сборки, а не минимальная версия iOS, на которой обязано работать приложение: поддержку старых версий iOS (deployment target) можно оставить прежней, обновив только Xcode и SDK, которыми собирается проект.
Устаревание библиотек и уязвимости
Мобильное приложение почти всегда собрано из десятков сторонних зависимостей: SDK аналитики, платёжных систем, карт, авторизации, UI-компонентов. У части из них со временем находят уязвимости, часть — авторы перестают поддерживать, часть — требует обновления вслед за новой версией ОС. Без регулярного обновления зависимостей риск накапливается незаметно: одна устаревшая библиотека сама по себе редко критична, а десяток неактуальных одновременно — уже полноценная поверхность для атаки. Насколько тяжело даётся такое обновление, отчасти зависит от технологии, выбранной ещё на этапе разработки, — у нативных и кроссплатформенных приложений здесь разные риски и точки отказа.
Истечение сертификатов и ключей
У части технических элементов приложения есть срок действия, и он не связан с тем, как часто выходят обновления самого продукта.
- Сертификат Apple Push Notification service (.p12) действует один год и требует ручного продления; более современная альтернатива — ключ авторизации APNs (.p8, токен-based), который не имеет срока действия и настраивается один раз для всех приложений разработчика.
- Сертификат разработчика iOS (Apple Distribution) для подписи приложения также выдаётся на ограниченный срок и требует переоформления в Apple Developer Program.
- Ключ подписи Android-приложения (upload key / app signing key) обычно выпускается с очень большим сроком действия, но его потеря или компрометация — серьёзная проблема: без доступа к ключу подписи нельзя выпустить обновление под тем же приложением в Google Play.
Если срок действия сертификата истекает незаметно для владельца — например, потому что доступ к аккаунту разработчика был только у бывшего подрядчика, — push-уведомления могут перестать приходить пользователям без каких-либо предупреждений в самом приложении.
Изменения во внешних API и SDK
Платёжные шлюзы, карты, сервисы SMS, push-провайдеры и аналитические системы периодически меняют версии своих API и объявляют старые устаревшими (deprecated) с конечной датой отключения. Если приложение не обновляется, в какой-то момент интеграция просто перестаёт работать — часто без возможности откатиться назад, потому что старая версия API уже отключена на стороне поставщика.
Что входит в поддержку
Под словом «поддержка» разные подрядчики и заказчики нередко понимают разные наборы работ, поэтому в договоре стоит явно перечислить, что в неё входит, а что оплачивается отдельно как развитие.
| Вид работ | Что делается | Регулярность | Статус |
|---|---|---|---|
| Мониторинг крашей и сервера | Отслеживание падений приложения, ошибок сервера, доступности API и базы данных | Постоянно (автоматические алерты) | Обязательно |
| Исправление ошибок | Разбор и устранение багов, найденных пользователями или мониторингом | По мере поступления, с приоритизацией по критичности | Обязательно |
| Обновления под новые ОС и SDK | Пересборка и тестирование под новые версии iOS/Android, соответствие требованиям магазинов к target SDK | 1–2 раза в год, по расписанию Apple и Google | Обязательно |
| Обновление зависимостей и безопасность | Обновление библиотек, закрытие уязвимостей, продление сертификатов и ключей | Регулярно, по мере выхода патчей | Обязательно |
| Хостинг и резервное копирование | Администрирование сервера, бэкапы базы данных, восстановление после сбоев | Постоянно | Обязательно |
| Ответы пользователям и работа с отзывами | Реакция на негативные отзывы в сторах, сбор обратной связи из тикетов поддержки | Постоянно или по расписанию | Обычно обязательно |
| Мелкие доработки интерфейса | Правки текстов, небольшие изменения UI без изменения логики | По запросу | По желанию |
| Развитие: новые функции | Проектирование и разработка новых сценариев по результатам аналитики | По плану развития продукта | По желанию, отдельный бюджет |
Первые пять строк таблицы — тот минимум, без которого приложение рискует выпасть из магазина или перестать работать технически. Последние две — уже не поддержка в строгом смысле, а развитие продукта: их разумно планировать и оценивать отдельно, чтобы не смешивать в одном бюджете «чтобы не сломалось» и «чтобы стало лучше».
Модели организации поддержки
Организовать поддержку можно несколькими способами, и выбор обычно зависит от того, насколько активно развивается продукт и есть ли в компании технический специалист, способный ставить задачи подрядчику.
| Модель | Как работает | Плюсы | Минусы |
|---|---|---|---|
| Своя команда | В штате есть разработчик(и), отвечающие за приложение | Быстрая реакция, глубокое знание продукта, накопленный контекст | Дорого для небольшого приложения; риск зависимости от одного человека |
| Подрядчик по договору поддержки | Абонемент или пакет часов в месяц у студии-разработчика или другого подрядчика | Предсказуемый бюджет, формализованные сроки реакции (SLA) | Нужно чётко описать состав работ в договоре; при смене подрядчика — передача проекта |
| Почасовая оплата по факту | Оплата только за выполненные задачи без ежемесячного абонемента | Гибкость, платите только за реальную работу | Нет гарантии приоритета в очереди подрядчика; риск задержки при аварии |
| Гибрид | Небольшой абонемент на обязательный минимум (мониторинг, критичные баги) + почасовая оплата развития | Баланс предсказуемости и гибкости | Требует более детального договора, чем каждая модель по отдельности |
Для приложения, которое разрабатывал внешний подрядчик, логичным первым шагом обычно становится договор поддержки с тем же исполнителем — он уже знает архитектуру и код. Но стоит заранее уточнить, что именно входит в абонемент, как приложение выбиралось на этапе разработки — критерии выбора подрядчика на поддержку во многом пересекаются.
SLA и приоритеты инцидентов
Чтобы не договариваться о сроках реакции в момент, когда что-то уже сломалось, приоритеты и время реакции стоит зафиксировать в договоре заранее. Ниже — пример структуры SLA, а не норма: конкретные часы и стоимость реакции каждая пара заказчик-подрядчик определяет для себя сама, исходя из критичности сервиса и готовности платить за более быструю реакцию.
| Приоритет | Пример | Условное время реакции | Условное время устранения |
|---|---|---|---|
| Критичный | Не работает вход, оплата не проходит, приложение падает при запуске у всех пользователей | До 1 часа | До нескольких часов |
| Высокий | Не работает важная функция (например, поиск или запись), но обходной путь есть | В течение рабочего дня | 1–3 рабочих дня |
| Средний | Ошибка затрагивает часть пользователей или не мешает основному сценарию | 1–2 рабочих дня | В следующем плановом релизе |
| Низкий | Косметические дефекты интерфейса, неточности в текстах | По плану | По плану, без фиксированного срока |
Указанные часы и дни — только пример для обсуждения условий, а не отраслевой стандарт: приложение, где критичный сбой означает потерю выручки каждую минуту, обычно требует более короткого времени реакции и, соответственно, более высокой стоимости абонемента, чем небольшой внутренний сервис.
Мониторинг и сигналы
Без мониторинга о проблеме обычно узнают из потока негативных отзывов в сторе — то есть тогда, когда часть пользователей уже успела столкнуться со сбоем и уйти. Разумный минимум сигналов, которые стоит отслеживать:
- Отчёты о крашах и ANR (Application Not Responding на Android) — сервисы вроде Crashlytics или встроенных отчётов Play Console и App Store Connect показывают, на каких экранах и устройствах приложение падает чаще всего.
- Рейтинг и отзывы в сторах — резкое падение рейтинга или всплеск однотипных жалоб почти всегда указывает на конкретный баг в свежем релизе.
- Метрики сервера — время ответа API, доля ошибок 5xx, нагрузка на базу данных.
- Алерты — автоматические уведомления, которые приходят ответственному специалисту при превышении порога ошибок или падении сервиса, а не только раз в неделю при ручной проверке дашборда.
Какие именно продуктовые и технические метрики стоит отслеживать регулярно, помимо аварийных сигналов, разобрано в статье «Метрики мобильного приложения» — там же о том, как отличить временный всплеск от системной проблемы.
Как спланировать бюджет на год
Бюджет поддержки удобно делить на две части с разной логикой планирования.
- Обязательная часть. Обновления под новые версии ОС и SDK, продление сертификатов и ключей, обновление зависимостей, хостинг, бэкапы, мониторинг и исправление найденных ошибок. Эти работы происходят независимо от планов развития продукта, и их разумно зафиксировать в договоре как определённое число часов или абонемент на год.
- Развитие. Новые функции, доработки по результатам аналитики, эксперименты. Эту часть логичнее не фиксировать на год вперёд, а пересматривать поквартально — по факту того, какие гипотезы подтвердились и какие доработки окупаются.
Оценивать обе части удобнее в часах работы специалистов, а не фиксированной суммой: так проще сравнить предложения подрядчиков и пересчитать бюджет при изменении ставки команды. Иногда как отправную точку для обсуждения используют процент от трудоёмкости первоначальной разработки в год — это не статистика и не рыночная норма, а грубая эвристика, которую всё равно стоит уточнять декомпозицией по работам из таблицы выше. Подробнее о том, как считается сама разработка и что заложить в архитектуру ради дешёвой поддержки, — в статье о стоимости разработки мобильного приложения.
Если поддержку ведёт не тот, кто разрабатывал
Смена подрядчика на поддержке — обычная ситуация, но она требует, чтобы у владельца приложения на руках было всё необходимое для передачи проекта независимо от того, кто разрабатывал первую версию.
Что должно быть у владельца приложения
- Исходный код в репозитории, доступ к которому принадлежит владельцу, а не личному аккаунту разработчика
- Доступы к аккаунтам Apple Developer Program, Google Play Console, RuStore, оформленным на юрлицо или ИП владельца
- Ключи подписи приложения (Android keystore, iOS-сертификаты) и понимание, где и как они хранятся
- Доступы к хостингу, базе данных и панелям сторонних сервисов (аналитика, платежи, push, карты)
- Техническая документация: архитектура, схема базы данных, список интеграций и переменных окружения
- Настроенный процесс сборки и выкладки (CI/CD) или хотя бы описанная вручную процедура релиза
Если части списка нет, до подписания договора с новым подрядчиком стоит провести короткий технический аудит: он покажет, что можно передать сразу, а что придётся восстанавливать. Отсутствие кода или доступов не делает поддержку невозможной, но обычно превращает её в более медленную и дорогую задачу.
Частые ошибки
Многие проблемы поддержки начинаются ещё до релиза — с пропущенного регресса и теста обновления поверх старой версии; об этом статья «Тестирование мобильного приложения».
- Нет бюджета на поддержку. Все средства заложены на разработку первой версии, а обновления под новые ОС, продление сертификатов и хостинг оказываются неожиданными расходами уже после запуска.
- Аккаунты оформлены на подрядчика. Аккаунт разработчика Apple, Google Play Console или домен привязаны к личным данным исполнителя — при смене подрядчика или конфликте владелец рискует потерять доступ к собственному приложению.
- Письма магазинов о новых требованиях игнорируются. Уведомления о будущих требованиях к target SDK приходят на почту, привязанную к аккаунту разработчика, за несколько месяцев до дедлайна — и часто остаются непрочитанными, если за аккаунтом никто не следит.
- Нет мониторинга. О проблеме узнают из отзывов пользователей в сторе, а не из алертов, — то есть с задержкой в дни или недели.
- Обновления копятся «на потом». Год без обновлений зависимостей и SDK превращается в один большой рискованный релиз вместо серии небольших предсказуемых обновлений.
Частые вопросы
Что будет, если не обновлять приложение год?
Ничего не произойдёт мгновенно: установленные копии продолжат работать у существующих пользователей. Но новую сборку магазин может отказаться принимать, если не выполнены актуальные требования к target SDK, а на новых версиях ОС приложение может начать хуже работать или пропасть из выдачи для новых пользователей. Плюс за год накапливаются необновлённые зависимости и потенциальные уязвимости.
Обязательно ли обновлять приложение под каждую новую версию iOS и Android?
Обязательного требования обновляться в день выхода новой версии ОС нет, но требования магазинов к минимальной версии SDK, которой собрано приложение, обновляются ежегодно и распространяются на любую новую загружаемую сборку. Поэтому на практике заложить хотя бы одно обновление под актуальные SDK в год приходится, даже если в самом продукте ничего не менялось.
Как часто нужно выпускать обновления?
Универсального числа нет: это зависит от темпа развития продукта и найденных ошибок. Но минимум — одно обновление в год под актуальные требования магазинов к SDK, плюс внеплановые релизы при критичных багах и обновлениях зависимостей с уязвимостями.
Можно ли поддерживать приложение без исходного кода?
Технически иногда можно декомпилировать или восстановить часть логики, но это медленнее, дороже и рискованнее, чем работа с оригинальным кодом, а часть решений (сертификаты, ключи подписи) без доступа к оригинальным файлам восстановить нельзя вовсе — потребуется публикация как нового приложения. Поэтому доступ к исходному коду и ключам стоит гарантировать себе ещё на этапе разработки.
Кто отвечает за сервер приложения?
Зависит от условий договора поддержки: администрирование хостинга, бэкапы и мониторинг сервера могут входить в общий абонемент поддержки, а могут быть отдельной услугой хостинг-провайдера. Это стоит явно прописать в договоре — «сервер» как ответственность иначе легко теряется между разработчиком и владельцем приложения.
Что такое гарантийный период и чем он отличается от поддержки?
Гарантийный период — это бесплатное исправление подрядчиком ошибок, допущенных при разработке, в течение ограниченного времени после сдачи проекта (обычно от нескольких недель до нескольких месяцев). Поддержка — платная услуга на постоянной основе, которая включает не только исправление ошибок, но и обновления под новые версии ОС, мониторинг и развитие продукта, и действует уже после окончания гарантийного периода.
Поддержка приложения: минимальный чек-лист на год
- В договоре или плане зафиксировано хотя бы одно обновление под актуальные требования Apple и Google к SDK
- Настроен мониторинг крашей, ошибок сервера и оценок в сторах с автоматическими алертами
- Известны сроки действия сертификатов и ключей (APNs, подпись приложения) и ответственный за их продление
- Аккаунты разработчика и домены оформлены на владельца приложения, а не на подрядчика
- Есть доступ к исходному коду, документации и переменным окружения независимо от текущего подрядчика
- Обязательная часть поддержки и развитие продукта разделены в бюджете и не конкурируют за одни и те же часы
Итог
Поддержка мобильного приложения — это не опция, которую можно отложить до появления свободного бюджета, а расписание, которое диктуют внешние факторы: ежегодные требования магазинов к SDK, сроки действия сертификатов, устаревание библиотек и изменения в сторонних API. Достаточно заложить обязательный минимум — мониторинг, обновления, продление ключей и хостинг — в договор или план на год, разделить его с бюджетом развития и заранее убедиться, что доступы и код принадлежат владельцу приложения, а не подрядчику. По сути, поддержка — это продолжение тех же этапов разработки, только после релиза: тогда переход между исполнителями и адаптация к новым требованиям Apple и Google перестают быть авральными задачами и становятся частью обычной эксплуатации продукта.