Когда говорят о доверии к технологической платформе, обычно вспоминают безопасность, качество инструментов разработки или стабильность операционной системы. Для разработчика доверие гораздо более прикладное понятие. Оно означает возможность планировать жизненный цикл продукта хотя бы на несколько шагов вперед: выпустить новую версию, исправить ошибку или уязвимость, добавить функцию и сохранить доступ к своей аудитории.
Не менее важным становится другой вопрос: сможет ли разработчик через год или два также свободно поддерживать продукт и взаимодействовать с пользователями. Особенно заметен этот риск в экосистеме Apple. И дело не в том, что iOS стала хуже, как технологическая платформа. Проблема находится в другой плоскости. Жизненный цикл приложения в iOS сильно зависит от решений одного владельца платформы. И российские разработчики за последние годы получили практический опыт того, что доступ к отдельным элементам этой инфраструктуры может измениться независимо от качества самого продукта.
Масштаб подобных рисков подтверждает и статистика самой Apple: согласно App Store Transparency Report за 2025 год, из 2 045 приложений, удаленных из App Store по требованиям государственных органов по всему миру, 1 213 пришлось на российский сегмент — около 59% от общего числа таких удалений.
Закрытость Apple была всегда. Изменилось восприятие риска
iOS никогда не была открытой операционной системой. Apple исторически контролирует правила публикации приложений, процесс модерации, сертификаты, магазин, отдельные системные сервисы и значительную часть платежной инфраструктуры.
Закрытая система может оставаться предсказуемой: разработчик знает требования, выполняет их, проходит модерацию и планирует работу продукта в рамках установленных правил. Проблема возникает тогда, когда команда понимает, что соблюдение этих правил уже не гарантирует сохранение доступа к инфраструктуре.
Компания может годами поддерживать работающий продукт, соблюдать технические требования платформы и при этом потерять доступ к отдельной программе, сертификатам или инфраструктурному сервису. Именно здесь возникает платформенный риск: судьба продукта начинает зависеть не только от того, насколько хорошо он сделан.
Зависимость не заканчивается на магазине приложений
App Store — наиболее заметная часть экосистемы, но далеко не единственная. Современное мобильное приложение может зависеть от целой цепочки платформенных инструментов: сертификатов, push-уведомлений, механизмов авторизации, платежной инфраструктуры и других системных сервисов.
Удаление приложения из App Store может затронуть и уже установленный продукт: например, после удаления MAX пользователи iPhone сохранили доступ к приложению, но перестали получать push-уведомления о новых сообщениях и звонках. Ранее с аналогичной проблемой сталкивались пользователи банковских приложений: после удаления из App Store push-уведомления переставали работать у нескольких крупных российских банков.
Приложение в такой ситуации никуда не исчезает и продолжает технически работать, а разработчики неизменно находят решение для возникших проблем. Но один из привычных способов взаимодействия пользователя с сервисом меняется вслед за изменением инфраструктуры платформы. Для бизнеса это означает, что необходимо оценивать устойчивость не только самого приложения, но и всех критически важных сервисов вокруг него.
Хорошим примером служит платежная инфраструктура. С 1 апреля 2026 года Apple прекратила поддержку оплаты подписок и цифровых покупок в России через счета мобильных операторов. При этом пользователи могут продолжать оплачивать покупки при наличии средств на балансе Apple Account.
Для разработчика это означает, что платформенный риск затрагивает уже не только возможность распространения и поддержки приложения, но и его монетизацию: изменение доступных платежных механизмов может напрямую влиять на возможность пользователей оплачивать цифровые продукты и продлевать подписки, независимо от качества самого приложения.
Почему именно в iOS последствия особенно заметны
Контроль магазина приложений сам по себе не является уникальной особенностью Apple. Google Play также устанавливает собственные правила, модерирует приложения и может ограничивать аккаунты разработчиков. Ключевая разница заключается в том, что происходит после потери основного канала.
Android предполагает несколько способов распространения приложений. Разработчик может использовать разные магазины или распространять приложение через собственный сайт. Но технически возможность сохранить другой путь к аудитории существует.
В iOS модель остается гораздо более закрытой. Apple постепенно допускает альтернативную дистрибуцию приложений, однако такие механизмы сейчас работают лишь в отдельных регионах: например, в Европейском союзе, Японии и Бразилии. Для российского рынка сопоставимого официального резервного канала нет.
Таким образом, для российского разработчика риск связан не столько с самим фактом контроля Apple над App Store, сколько с отсутствием равноценного резервного канала дистрибуции: если основной канал становится недоступен, быстро перенаправить пользователей на другой официальный способ установки приложения фактически невозможно.
Поэтому App Store для российского разработчика фактически остается основной массовой точкой доступа к владельцам iPhone.
В случае мобильной разработки проблема возникает не потому, что App Store обязательно перестанет работать, а потому, что у разработчика практически нет равноценного сценария на случай потери доступа к нему. Именно закрытость экосистемы увеличивает последствия каждого отдельного ограничения.
Платформенный риск отделился от продуктового
Именно это, на мой взгляд, является главным изменением для разработчиков последних лет. Раньше большинство рисков мобильного продукта можно было рассматривать преимущественно как продуктовые. Нужно написать качественный код, пройти модерацию, обеспечить безопасность, привлечь пользователей и поддерживать приложение.
Теперь рядом с этим появился самостоятельный вопрос: насколько устойчив сам канал доступа к пользователю. Можно увеличить команду разработки, улучшить архитектуру, провести аудит безопасности и быстрее выпускать обновления. Но ни одна из этих мер не дает разработчику контроля над доступом к сертификатам, правилами конкретного магазина или изменениями платформенной инфраструктуры.
Для разработчика принципиально важно и сохранение возможности обновлять продукт: само по себе то, что уже установленное приложение продолжает запускаться, еще не означает сохранения полноценного жизненного цикла — возможности выпускать новые версии, исправлять ошибки и уязвимости и адаптировать продукт к изменениям платформы.
Поэтому снижение доверия здесь связано не с оценкой iOS как технологической платформы, а со степенью уверенности в том, что нынешние условия работы с экосистемой можно закладывать в долгосрочный продуктовый план. Командам все чаще приходится смотреть на мобильную платформу не только как на технологическую среду, но и как на внешнего поставщика критически важной инфраструктуры.
При этом речь идет не об одном отдельном ограничении, а о постепенном накоплении изменений: за последние годы для российского рынка последовательно менялись условия продаж устройств, работы платежных сервисов, доступности отдельных приложений и способов их оплаты, и каждое такое изменение само по себе не делает экосистему неработоспособной, но в совокупности снижает ее предсказуемость для долгосрочного планирования.
Основной риск для разработчика возникает именно из накопительного эффекта таких изменений: каждое отдельное ограничение может быть преодолимо, но их последовательное появление сокращает число доступных альтернатив и постепенно повышает зависимость бизнеса от решений владельца платформы.
Резервный сценарий становится частью разработки
В результате платформенный риск становится уже не только техническим, но и инвестиционным фактором: принимая решение о развитии продукта и вложениях в мобильную разработку, компания вынуждена оценивать не только размер аудитории и стоимость разработки, но и вероятность того, что через несколько лет сможет на сопоставимых условиях распространять, обновлять и монетизировать свой продукт.
Главный вывод из этой ситуации: не необходимость отказаться от конкретной платформы, а необходимость снижать критическую зависимость от любой одной внешней системы.
Где-то возможно развитие полноценной веб-версии, где-то — присутствие на нескольких мобильных платформах. В других случаях компании могут уменьшать зависимость от отдельных проприетарных сервисов.
Раньше резервный сценарий можно было воспринимать как дополнительную страховку на случай маловероятной проблемы. Теперь российский опыт показывает, что вопрос необходимо задавать еще на этапе проектирования продукта: какие критические процессы контролирует сама команда, а какие полностью зависят от внешней платформы?
В итоге вопрос уже не в том, насколько качественной остается iOS. Для разработчика важнее другое: может ли он рассчитывать, что привычные условия работы с платформой сохранятся через год или два. Последние годы показали, что такой уверенности становится меньше, и зависимость от одной закрытой экосистемы приходится учитывать как отдельный риск.
Возврат к списку