Привет! Меня зовут Владислав Лаптев, я директор по инновациям в Fork-Tech. Сегодня РБК выпустил материал о том, что замедление Telegram срывает релизы мобильных приложений в России. Мы дали комментарий для этого материала, и я решил рассказать подробнее, потому что проблема не в Telegram. Проблема в том, что российские мобильные разработчики третий раз за четыре года теряют инструмент доставки сборок.
Мы создали PWS (Product Web Services) — платформу для управления цифровыми продуктами. Сегодня речь про модуль App Distribution: как мы к нему пришли, где взяли лучшее от Firebase, почему этого было мало, и как всё работает под капотом. С примерами кода из документации. Платформа включена в реестр российского ПО.
Четыре года без нормального инструмента
2022 — Google ограничивает доступ к Firebase для российских компаний. Firebase App Distribution — основной инструмент для раздачи тестовых сборок — становится недоступен. 2025 — Microsoft закрывает App Center. Apple отзывает корпоративные сертификаты (ADEP) у российских компаний. Февраль 2026 — Роскомнадзор замедляет Telegram.
После потери Firebase и App Center команды массово ушли в Telegram. Собрали ботов, через которых рассылали ссылки на скачивание сборок с внешних хранилищ — именно ссылки, а не файлы: Bot API ограничивает размер файла 50 МБ, а банковское приложение весит 80–150 МБ. Для iOS это тем более не работает — OTA-установка .ipa требует manifest.plist, который Telegram генерировать не умеет. Но деваться было некуда — Telegram стал де-факто инфраструктурным звеном CI/CD-пайплайна.
10 февраля Telegram замедлили. Да, он по-прежнему доступен. Но доля таймаутов при работе с Bot API выросла до 28% в отдельных регионах, и вектор очевиден: сегодня замедление, завтра — регулярные сбои, послезавтра — запрет использования в корпоративных процессах. Для CI/CD-пайплайна, который каждый день рассылает ссылки на сборки по группам тестирования, это уже сейчас создаёт проблемы.
Сотни сборок в месяц — и ни одного нормального инструмента на российском рынке
В крупных компаниях команды разработки мобильных приложений генерируют сотни сборок в месяц. Это 15–20 билдов в день. Каждый нужно доставить нужной группе тестирования, обеспечить установку на устройство, сохранить Release Notes, при необходимости ограничить доступ.
Когда единственный канал доставки - Telegram-бот со ссылками на внешнее хранилище, вы получаете:
Отсутствие ролевой модели. Ссылки свободно можн�� пересылать, нет разделения на роли viewer и editor. Необходимо разрабатывать собственную матрицу доступов и инструменты администрирования.
OTA для iOS невозможен. Без manifest.plist — нет установки .ipa через браузер. Нужен отдельный хостинг.
Нет аудита. Кто скачал? Когда? Информация недоступна. Необходимо прикручивать собственную систему логирования к боту.
Внешняя зависимость. Telegram не контролируется вашей компанией. Сегодня он замедлен, завтра может быть заблокирован или запрещён для корпоративного использования. Мы уже теряли инфраструктуру дважды за четыре года.
«A что RuStore?»
RuStore и PWS App Distribution решают разные задачи. RuStore — магазин приложений: публикация готового релиза для широкой аудитории. PWS — доставка предрелизных сборок внутренним командам в процессе разработки. Два разных этапа жизненного цикла.
Только Android. iOS-сборки RuStore не поддерживает — для кроссплатформенных команд это половина потребности. Нет On-Premise. Для банков, которым нужно держать сборки внутри контура, облачный сервис не подходит. VK ID вместо корпоративного SSO. Для enterprise с AD/LDAP это параллельное управление учётными записями.
В идеальном пайплайне PWS и RuStore работают вместе: сборка проходит через PWS (тестирование, QA, обратная связь), а затем релиз публикуется в RuStore для пользователей.
Почему мы этим занялись
Мы работаем с компаниями из регулируемых отраслей — банки, страхование, телеком. И видим эту проблему изнутри: вместе с нашими клиентами мы прошли через потерю Firebase, закрытие App Center, отзыв ADEP. Каждый раз — экстренный поиск замены, миграция, костыли. Это общая боль, и она подтолкнула нас к созданию платформы.
В феврале 2025 мы начали разработку PWS — платформы, которая объединяет Remote Config, Feature Flags, App Distribution и матрицу доступов. По сути — enterprise-альтернатива Firebase, которую можно развернуть On-Premise.
Что мы взяли от Firebase App Distribution
Firebase App Distribution был хорошим продуктом. Он задал стандарт рынка, и мы честно скажем: мы брали от него лучшее.
Группы тестирования — возможность создавать группы и назначать доступ к конкретным сборкам. Загрузка через API — интеграция с CI/CD. Release Notes — описание изменений, привязанное к сборке. Кроссплатформенность — Android (.apk) и iOS (.ipa) из единого интерфейса. Простота для тестировщика — получил ссылку, открыл, установил. Мы реализовали это через PWA-приложение.
Почему Firebase было мало
Нет On-Premise. Firebase — только облако Google. Для банка, которому нельзя хранить сборки за рубежом, нерешаемая проблема. PWS разворачивается на вашем сервере.
Нет корпоративного SSO. Firebase работает через Google-аккаунты. PWS интегрируется с корпоративным SSO.
Нет окружений (Environments). В Firebase нельзя разделить dev, staging, production на уровне платформы. У нас окружения закладывались с самого начала.
Нет гибкого RBAC. Нам нужно: администратор организации, администратор проекта, менеджер сборок, тестировщик с доступом к определённым группам, сервисный аккаунт для CI/CD. Мы реализовали матрицу доступов.
Что мы построили: архитектура
PWS App Distribution — экосистема из четырёх компонентов.
Консоль администратора (Web UI)
Основной интерфейс: создание проектов, загрузка сборок, управление группами тестирования, настройка доступов, Release Notes, приватный и публичный доступ.
PWA-приложение для установки
Тестировщ��к получает ссылку, открывает в браузере и видит список доступных сборок. Для Android — стандартная загрузка .apk. Для iOS — OTA-установка: браузер обращается к manifest.plist, iOS загружает и устанавливает .ipa. Без TestFlight, без App Store.
REST API
Полноценный API для автоматизации: загрузка сборок из CI/CD, получение списка релизов, распространение по группам, управление Release Notes. Документация открытая, с примерами на шести языках. Подробнее — в следующем разделе.
MCP-сервер
Платформа поддерживает Model Context Protocol — открытый стандарт для подключения AI-ассистентов (Claude, Cursor, GigaChat и других) к внешним сервисам. Через MCP-сервер агенты могут запрашивать информацию о сборках и управлять релизами программно.
Интеграция с CI/CD: примеры из документации
Самое ценное для разработчиков — возможность встроить дистрибуцию в пайплайн и забыть о ручной работе. Все примеры ниже — из публичной документации PWS.
Загрузка сборки: POST /v1/builds
Загружает файл и автоматически создаёт релиз. Версия и номер сборки извлекаются из метаданных файла:
curl -X POST "https://<DOMAIN>/v1/builds" \ -H "Authorization: Bearer <API_KEY>" \ -F "file=@app-release.apk" \ -F "description=Версия 2.5.1:\n- Исправлена авторизация по биометрии\n- Обновлён SDK платёжного шлюза"
Ответ — 202 Accepted:
{ "status": "processing", "message": "The build has been saved", "buildId": "e891fc1d-d7ab-4be5-b5a1-228a6e6716de", "releaseId": "6b35f2c5-fe2e-4654-b747-b4572783af9a", "buildNumber": 1, "buildVersion": "2.5.1" }
Распространение релиза: POST /v1/releases/{releaseId}/distribute
После загрузки сборку нужно распространить на группы тестирования. Можно указать конкретные группы и отправить email-уведомления:
curl -X POST "https://<DOMAIN>/v1/releases/6b35f2c5-fe2e-4654-b747-b4572783af9a/distribute" \ -H "Authorization: Bearer <API_KEY>" \ -H "Content-Type: application/json" \ -d '{ "access": "private", "groupIds": ["group-uuid-qa", "group-uuid-stakeholders"], "sendNotification": true, "notificationChannels": ["email"] }'
Ответ:
{ "status": "success", "message": "Test groups successfully added to the release. Notifications sent via email." }
GitLab CI: полный stage
Вот готовый stage, который собирает Release Notes из git log, загружает сборку и распространяет на группу тестирования:
# .gitlab-ci.yml distribute_to_pws: stage: distribute needs: - job: build_release artifacts: true script: # Release Notes из последних коммитов - RELEASE_NOTES=$(git log --oneline -5 --pretty=format:'- %s') # Находим собранный APK - APK_PATH=$(find app/build/outputs/apk/release -name '*.apk' | head -1) # Шаг 1: Загружаем сборку - | UPLOAD_RESPONSE=$(curl -s -X POST \ "$PWS_BASE_URL/v1/builds" \ -H "Authorization: Bearer $PWS_API_KEY" \ -F "file=@$APK_PATH" \ -F "description=$RELEASE_NOTES") - RELEASE_ID=$(echo $UPLOAD_RESPONSE | jq -r '.releaseId') - BUILD_VERSION=$(echo $UPLOAD_RESPONSE | jq -r '.buildVersion') - echo "Сборка $BUILD_VERSION загружена, releaseId: $RELEASE_ID" # Шаг 2: Распространяем на группу тестирования - | curl -s -X POST \ "$PWS_BASE_URL/v1/releases/$RELEASE_ID/distribute" \ -H "Authorization: Bearer $PWS_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "access": "private", "groupIds": ["'$PWS_QA_GROUP_ID'"], "sendNotification": true, "notificationChannels": ["email"] }' - echo "Релиз распространён на QA-группу" only: - develop - /^release.*$/ variables: PWS_BASE_URL: https://pws.company.ru # PWS_API_KEY и PWS_QA_GROUP_ID задаются в CI/CD Variables (masked)
Список релизов: GET /v1/releases
Для дашбордов или интеграции с другими системами — можно запросить список релизов, сгруппированных по версиям:
curl -s -X GET "https://<DOMAIN>/v1/releases?page=1&pageSize=50" \ -H "Authorization: Bearer <API_KEY>" | jq .
Ответ содержит версии с вложенными релизами, ссылками для скачивания и QR-кодами:
{ "status": "success", "totalCount": 2, "page": 1, "pageSize": 50, "totalPages": 1, "versions": [ { "version": "2.5.1", "totalReleases": 1, "releases": [ { "id": "7fd896a6-ab07-4f23-b584-b172279c2f3e", "number": 1, "description": "Исправления багов", "access": "private", "status": "success", "createdAt": "2026-02-12T14:30:00Z", "build": { "id": "fc764c00-d24d-49ce-83f3-e929691671ac", "scanStatus": "success", "downloadUrl": "https://<DOMAIN>/app/application/private?releaseId=...", "qrUrl": "https://storage.example.ru/qr_xxx.png" } } ] } ] }
Полная документация API с примерами: публичная документация PWS
Приватная и публичная дистрибуция
Приватная дистрибуция. Тестировщик авторизуется в системе. Доступ определяется ролью и группой. Для внутренней разработки, когда сборки содержат чувствительную бизнес-логику.
Публичная дистрибуция. Сгенерированная ссылка работает без авторизации. Для демонстрации стейкхолдерам или передачи внешним тестировщикам. Ссылку можно отозвать в любой момент.
Тип доступа задаётся при распространении релиза через API (поле access: private | public) или через консоль. Для On-Premise весь трафик остаётся внутри корпоративного контура.
Сравнение: Firebase vs. Telegram vs. RuStore vs. PWS
Возможность | Firebase | Telegram | RuStore | PWS |
Доступность в РФ | Нет | Нестабилен | Да | Да |
On-Premise | Нет | Нет | Нет | Да |
iOS (.ipa) | Да | Ссылка на собственное Web-приложение | Нет | Да |
Корпоративный SSO | Нет | Нет | Нет | Да |
Гибкий RBAC | Базовый | Нет | Нет | Да |
Окружения | Нет | Нет | Нет | Да |
Реестр РПО | Нет | Нет | Да | Да |
Как попробовать
Сейчас PWS App Distribution доступна в On-Premise варианте — мы разворачиваем платформу в контуре клиентов. Для компаний из регулируемых отраслей (банки, страхование, телеком) это основной сценарий. Если вам интересно — готовы помочь развернуть решение уже сегодня.
Параллельно мы делаем облачные демо-стенды, на которых можно самостоятельно оценить функционал: загрузить сборку, настроить группы, попробовать API. Это быстрый способ понять, подходит ли платформа вашей команде.
Мы активно готовим релиз SaaS-версии, которая станет доступна всем разработчикам без необходимости разворачивать инфраструктуру. Если хотите получить ранний доступ к SaaS — оставляйте заявку, мы включим вас в программу раннего доступа. Форма запроса раннего доступа к SaaS PWS
Документация уже открыта: Публичная документация PWS
Вместо заключения
Мы не злорадствуем по поводу ситуации с Telegram. Telegram — великолепный мессенджер, и то, что он стал инфраструктурным инструментом для разработчиков — показатель его качества. Но зависимость от внешнего канала, который вы не контролируете — это архитектурный антипаттерн.
Ситуация 2022 года повторяется. Тогда ушёл Firebase. Сейчас Telegram работает нестабильно, и нет гарантий, что завтра не станет хуже. Результат для разработчиков одинаковый — сломанный пайплайн и ручная работа.
Мы построили PWS App Distribution, потому что нам самим и нашим клиентам нужен инструмент, который контролируется компанией, работает стабильно и не зависит от внешних решений. Мы вывели его на рынок, потому что эта проблема — не только наша.
