Поддержка мобильных приложений: что входит и сколько это стоит на самом деле

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

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

Каждый год Google и Apple поднимают планку. И не спрашивают разрешения.

С 31 августа 2026 года Google Play требует от всех действующих приложений таргет не ниже Android 15 (API 35), а от новых и обновлённых — Android 16 (API 36); срок можно продлить до 1 ноября по отдельному запросу в консоли. Приложение при этом не пропадает у тех, кто им уже пользуется, — оно перестаёт быть видимым для новых пользователей с более свежим Android на телефоне. Так прямо написано в официальной справке Play Console.

У Apple логика жёстче и раз в год. С 28 апреля 2026 года любая новая сборка, загруженная в App Store Connect, обязана быть собрана в Xcode 26 под SDK iOS 26 — иначе её просто не примут на проверку. Это не разовая акция: Apple задаёт новый минимум SDK ежегодно, вслед за очередным релизом iOS, и требование касается только новых отправок и обновлений — то, что уже опубликовано, само по себе никуда не денется.

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

Ориентир простой: 15–25% от бюджета разработки в год. Эту вилку независимо друг от друга называют несколько студий, и в неё обычно закладывают серверную инфраструктуру, адаптацию под новые версии iOS и Android, хотфиксы и продление сертификатов и аккаунтов разработчика.

На практике инфраструктура для среднего проекта — это отдельно ещё 10–30 тысяч рублей в месяц, независимо от процента на поддержку. А развитие: новые экраны, функции, интеграции — считается сверху, отдельной статьёй, обычно ещё 20–50% от суммы разработки в год.

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

Ищите не просто разработчика на подхвате, а именно службу поддержки мобильных приложений — с понятным сроком реакции на бумаге, а не обещанием «напишите, если что».

Требования площадок — не единственное, что меняется без вашего участия. У push-уведомлений, например, своя история.

В 2024 году Google остановил поддержку старого протокола push-уведомлений — Firebase Cloud Messaging Legacy HTTP. Дал время на переход, а потом просто отключил старый способ отправки. Приложения, которые не успели перейти на новый формат HTTP v1 заранее, буквально за одну ночь перестали слать пуши — не с ошибкой в логах, которую кто-то заметит через месяц, а сразу и молча для всех получателей.

То же самое с сертификатами. У Apple сертификат push-уведомлений и профиль публикации истекают раз в год — их продлевают руками в кабинете разработчика, и без напоминания об этом легко забыть, если этим никто конкретный не занимается. С платёжными SDK похожая картина: старые версии библиотек Google Pay и Apple Pay периодически перестают поддерживаться, и оплата в приложении может однажды просто отвалиться без единой строчки нового кода с вашей стороны.

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

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

Дальше приложение никто не трогал почти год: договора на поддержку не было, разработчик разошёлся с проектом сразу после публикации. За это время Google подняла требуемый таргет, и новые клиенты — как раз в сезон открытия точки — не могли поставить приложение из Play Store, хотя старые продолжали копить баллы как ни в чём не бывало. Искать, кто вообще может внести правку в чужой код без документации, пришлось уже в разгар открытия, а не заранее.

На поиск подрядчика, который согласился разбираться в чужом коде без единой строчки комментариев, ушло почти три недели — и всё это время новые гости открывшейся точки узнавали про карту лояльности из объяснений бариста, а не сами. Правку в итоге сделали за один день. Три недели заняло не программирование, а именно поиск того, кто вообще возьмётся.

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

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

Аутсорс на ретейнере закрывает как раз этот разрыв: платите за доступность команды, а не за конкретное число часов, и в договоре заранее прописан срок реакции на каждый тип проблемы. Разница с разовым вызовом фрилансера на правку одна, но решающая: ретейнер обязывает следить за датами вроде дедлайнов Google и Apple заранее, а разовая правка — только реагировать, когда уже сломалось.

Не всем приложениям она нужна в одинаковом объёме. Витрина без личного кабинета и без оплаты внутри может спокойно пережить год без активного сопровождения — риск в том, что однажды придётся разом закрывать несколько накопившихся требований площадок.

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

Разбираетесь, что для вашего бизнеса выгоднее — разработка с нуля, доработка того, что уже есть, или PWA: курс «Вайб-кодинг: с нуля до первой оплаты»