Судя по всему, это те самые приложения, которые были собраны на скорую руку с помощью ИИ. В базе уже 167 приложений. Проект опубликован на платформе Firehound и активно обсуждается в сообществе iOS-разработчиков на Reddit.

Что именно нашли

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

В реестре уже есть приложения с:

• десятками миллионов записей в открытых базах;
• доступными коллекциями profiles, posts, comments, likes;
• утекшими email-адресами, никнеймами, метаданными активности.

Один из лидеров антирейтинга — приложение Adult Coloring Book – Pigment. У него более 7,7 млн документов оказались доступны без какой-либо аутентификации.

Причем тут вайб-кодинг

По словам автора проекта, большинство уязвимостей выглядят одинаково: разработчики используют ИИ для генерации кода и инфраструктуры, но не понимают, что именно деплоят в прод.

Типичный сценарий:

• ИИ предлагает использовать Firebase, Supabase или MongoDB.
• Конфигурация безопасности либо отсутствует, либо остается дефолтной.
• Ключи и переменные окружения попадают в клиентский код.
• База становится публичной — иногда буквально в один клик.

Как подчеркивают участники обсуждения на Reddit, проблема не в ИИ как таковом, а в том, что вайб-кодинг часто заканчивается полным отсутствием базовой гигиены кибербезопасности.

Это не взлом — и в этом главная проблема

Важно: Firehound не эксплуатирует уязвимости. Он лишь показывает то, что уже открыто. Данные в публичной версии интерфейса частично замаскированы, но сам факт доступности никто не отрицает.

Именно это делает ситуацию неприятной: формально никто ничего не «ломал», но пользовательские данные все равно утекли.

Рассмотрим, в чем особенность пушей и почему командам стоит к ним присмотреться.

Почему сначала пуши, а потом СМСки

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

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

После 2022 года выбор сервисов для push-уведомлений стал сложнее из-за санкций. Долгое время компании пользовались и по инерции продолжают пользоваться сервисом Firebase Cloud Messaging от Google, но сейчас этот канал не может быть единственным для отправки push, так как могут возникнуть определенные санкционные риски и для бизнеса, а также другие проблемы:

• Одноразовые коды и другие уведомления — чувствительная информация. Зарубежные сервисы передают данные за пределы России, что может быть рискованно.
• Условно-бесплатные аналоги, такие как FCM, не гарантируют доставку и не предоставляют аналитику.
• Некоторые сервисы вовсе заблокированы в России, а другие не работают в Китае, где многие сейчас ведут бизнес.

Как работают push-уведомления: техническая основа

Push-уведомления основаны на клиент-серверной архитектуре, где сервер отправляет данные на устройство через специализированные сервисы. Процесс начинается с регистрации: при запуске приложения устройство генерирует токен (device token) и отправляет его на сервер разработчика. Этот токен используется для маршрутизации сообщений.

Доставка происходит через платформо-зависимые сервисы:

• APNs (Apple Push Notification service): Для iOS и macOS, требует сертификата от Apple и поддерживает богатые уведомления с изображениями и действиями.
• FCM (Firebase Cloud Messaging): Для Android, кросс-платформенный сервис от Google, интегрируется с другими каналами.
• HPK (Huawei Push Kit): Альтернатива для устройств Huawei, особенно актуальна в регионах без Google Services.
• RuStore и Aurora: Российские аналоги для Android, ориентированные на локальный рынок и совместимые с санкционными ограничениями.

Для веб-приложений используются Web Push Notifications на базе Service Workers и протокола Push API, совместимого с браузерами Chrome, Firefox и Edge. Сообщения шифруются с помощью VAPID (Voluntary Application Server Identification) для аутентификации отправителя.

Модель Pub/Sub (Publish/Subscribe) лежит в основе масштабируемых систем: издатели публикуют сообщения в топики, а подписчики (устройства) получают их асинхронно. Это позволяет обрабатывать миллионы подключений без перегрузок. WebSocket или long-polling обеспечивают постоянное соединение для минимальной задержки – часто менее 0,1 секунды.

Вызовы включают:

• Оффлайн-доставку: Если устройство выключено или без интернета, сообщение может потеряться; ретраи (повторные попытки) и каскадирование (переключение на альтернативные каналы) решают эту проблему.
• Географические ограничения: Сервисы вроде FCM могут блокироваться в некоторых странах, требуя омниканальных подходов.
• Безопасность: Уведомления с чувствительными данными (коды аутентификации) нуждаются в end-to-end шифровании, чтобы предотвратить перехват.
• Пользовательский контроль: Пользователи могут отключать пуши, поэтому важно соблюдать регуляции вроде GDPR или 152-ФЗ, избегая спама.

Преимущества пушей над SMS: низкая стоимость (почти нулевая для больших объемов), мгновенная доставка, поддержка мультимедиа (изображения, кнопки действий) и аналитика (открытия, клики).

Омниканальность и лучшие практики внедрения

Омниканальные системы объединяют несколько каналов в единую платформу, обеспечивая доставку независимо от устройства или региона. Это включает каскад: если основной канал (например, собственный WebSocket) недоступен, система переключается на FCM или APNs. Такие подходы достигают 99,9% доставки, с ретраями и мониторингом.

При выборе системы учитывайте:

• Масштабируемость: Поддержка высоких нагрузок, как во время пиковых событий (распродажи, новости).
• Аналитика: Реал-тайм отчеты о доставке, конверсии и отказах для оптимизации кампаний.
• Кастомизация: Deeplink для перехода в конкретный раздел приложения, добавление изображений, ссылок или персонализированного контента.
• Интеграция: REST API и SDK для популярных фреймворков (React Native, Flutter), чтобы внедрение заняло минимум времени.
• Соответствие регуляциям: Локализация данных, сертификаты безопасности (PCI DSS, ФСТЭК) для работы с финансовыми или государственными данными.

Лучшие практики: сегментируйте аудиторию по поведению, тестируйте A/B-варианты сообщений, интегрируйте с CRM для персонализации. Для бизнеса в e-commerce пуши идеальны для напоминаний о корзине, в банках – для транзакций, в медиа – для новостей.

MULTIPUSHED как пример омниканальной платформы

В качестве примера рассмотрим российскую систему MULTIPUSHED от МУЛЬТИФАКТОР, ориентированную на доставку уведомлений в условиях санкций и локальных требований. Она использует SaaS-модель с инфраструктурой в дата-центрах Tier3 (DataLine, Selectel, LinxCloud), защищенной от DDoS через NGENIX.

Архитектура включает Pub для приема сообщений по HTTPS API, Broker для распределения и Router для маршрутизации по каналам: собственный PUSHED, APNs, FCM, HPK, RuStore, Aurora. Sub-серверы поддерживают WebSocket Secure для онлайн-доставки, с каскадированием для оффлайн-случаев.

Процесс: устройство регистрируется, получает токен; отправитель передает сообщение Pub; система маршрутизирует и подтверждает доставку. Совместима с iOS, Android, Aurora, РОСА МОБАЙЛ, KasperskyOS и веб. SDK для Android, iOS, React Native, Flutter, Aurora и Web упрощают интеграцию.

Функции: аналитика в реальном времени, кастомизация (deeplink, изображения), глобальная доставка (включая Китай и регионы РФ). Сообщения шифруются, соответствует 152-ФЗ и PCI DSS, внесена в реестр российского ПО.

Итоговые рекомендации

Push-уведомления эволюционируют в сторону омниканальности, чтобы преодолевать платформенные барьеры и обеспечивать надежность. Для бизнеса это инструмент роста вовлеченности, но успех зависит от баланса между частотой и релевантностью.

При внедрении тестируйте на реальных сценариях, мониторьте метрики и адаптируйте под регуляции – это минимизирует риски и максимизирует отдачу.

Определяем цель

Успех приложения начинается с четкого понимания, зачем оно нужно — так становится проще определить целевую аудиторию. Это влияет не только на функционал, но и на дизайн, способы продвижения и даже тон общения с пользователями.

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

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

Чтобы убедиться, что идея действительно рабочая, проведите опросы в Telegram-каналах фрилансеров или создайте анкету. Вы можете спросить, какие функции для них наиболее актуальны: автоматический расчет налогов, интеграция с платежными системами или отслеживание времени работы. Это поможет сфокусироваться на действительно важных фичах и отсеять второстепенные.

Выбираем платформу и инструменты

Сегодня на российском рынке доминируют две мобильные операционные системы: Android (около 70% пользователей) и iOS (около 30%). Оптимальным решением будет разработка приложения для обеих платформ, особенно если вы ориентируетесь на крупные города, где доля пользователей iOS существенно выше.

Приложения под Android большинство разработчиков пишет на Kotlin, хотя Java до сих пор остается одним из вариантов из-за обширной базы готовых решений и библиотек. Основной средой выступает Android Studio — в ней есть весь необходимый инструментарий для создания, отладки и тестирования приложений. Современные разработчики активно используют Jetpack Compose для построения пользовательского интерфейса, Room для работы с базами данных, Retrofit для сетевых запросов и Dagger или Hilt для внедрения зависимостей.

В мире iOS основным языком программирования стал Swift — современный и безопасный инструмент для нативных приложений. Разработка ведется в среде Xcode, официальной IDE от Apple. Для построения интерфейсов все чаще используется SwiftUI, для управления данными — Core Data, а для сетевого взаимодействия — фреймворк Alamofire. Работа с асинхронными событиями упрощается с помощью фреймворка Combine.

При ограниченных ресурсах можно рассмотреть кросс-платформенную разработку. Так, Flutter использует язык программирования Dart и позволяет создавать производительные приложения с нативным внешним видом. React Native дает возможность применять веб-технологии для мобильной разработки, а Xamarin ориентирован на разработчиков, привыкших к экосистеме Microsoft и языку C#.

Выбор платформы и инструментов должен основываться на характеристиках вашей ЦА, требованиях к функционалу и имеющихся ресурсах. Учитывайте также, что для разных магазинов приложений (RuStore, App Store, Google Play) могут потребоваться специфические оптимизации и настройки.

Продумываем функционал

При разработке функционала важно следовать концепции MVP (Minimum Viable Product) — минимально жизнеспособного продукта. Это позволит быстрее выйти на рынок, получить обратную связь и итеративно улучшить приложение.

Возьмем для примера приложение доставки еды. В этом случае MVP должен включать:

• авторизацию пользователя через телефон, email или социальные сети;
• каталог ресторанов с фильтрацией по кухне, рейтингу и времени доставки; меню каждого заведения с фотографиями и описанием блюд;
• корзину с возможностью изменения состава заказа;
• оформление заказа с выбором адреса доставки и способа оплаты;
• отслеживание статуса заказа в реальном времени;
• профиль пользователя с историей заказов.

Важно уделить внимание и техническим аспектам функционала:

• Локальное кэширование данных. Поддерживает работу приложения при слабом интернет-соединении или его отсутствии. Сохраняет каталоги, популярные позиции и историю действий пользователя.
• Офлайн-режим. Определяет набор функций, доступных без подключения к сети. Критически важен для удержания пользователей в зонах с плохим интернетом.
• Система пуш-уведомлений. Информирует пользователей о важных событиях, статусах заказов и специальных предложениях. Повышает вовлеченность и возвращаемость в приложение.
• Многопоточная обработка. Выполняет ресурсоемкие операции в фоновом режиме. Гарантирует отзывчивость интерфейса даже при выполнении сложных задач.
• Оптимизация изображений. Внедряет алгоритмы сжатия для быстрой загрузки визуального контента. Обеспечивает комфортное использование даже при ограниченной скорости соединения.

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

Также многие игнорируют обратную связь пользователей, хотя механизмы ее сбора стоит включать уже в MVP. Недостаточное внимание к безопасности может стать критичным для приложений с личными данными и платежами. А отсутствие встроенных инструментов аналитики затрудняет понимание того, как пользователи взаимодействуют с программой.

Выбор правильной архитектуры — это фундамент, который определяет надежность, масштабируемость и удобство поддержки. Вот основные паттерны для мобильных приложений:

• MVVM — рекомендуемый Google подход с разделением UI и бизнес-логики
• MVI — однонаправленный поток данных, хорошо сочетается с реактивным программированием
• MVP — классическая архитектура. Популярна благодаря простоте реализации
• Clean Architecture — многослойный подход с упором на тестируемость и гибкость
• VIPER (iOS) — расширенный MVC со строгим разделением ответственности

Важное значение имеет также выбор технологий для хранения и передачи данных. Для локальной работы подойдут SQLite + Room, Realm или DataStore; для сетевого взаимодействия на Android чаще всего используют Retrofit + OkHttp, а в реактивных сценариях — Ktor Client.

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

Создаем удобный интерфейс

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

Эффективный UI/UX строится на пяти ключевых принципах:

1. Очевидность (интуитивное понимание интерфейса);
2. Экономия внимания (минимум шагов для достижения цели);
3. Консистентность (единообразие элементов с одинаковой функциональностью);
4. Обратная связь (видимый результат каждого действия);
5. Прощение ошибок (возможность отмены операций).

Современные инструменты значительно ускоряют создание качественных интерфейсов. Дизайнеры используют Figma, Adobe XD и Sketch для прототипирования. Android-разработчики предпочитают Jetpack Compose и Material Design Components. Для iOS актуальны SwiftUI, UIKit и Human Interface Guidelines от Apple.

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

Проводим тестирование

Юзабилити-тесты с фокус-группами, A/B-тестирование элементов и аналитика пользовательского поведения дают объективную картину взаимодействия клиентов с приложением.

Комплексное тестирование включает два основных направления:

1. Автоматизированное тестирование: unit-тесты (JUnit, XCTest) для проверки отдельных компонентов; интеграционные тесты для проверки взаимодействия между модулями; UI-тесты (Espresso, XCUITest) для проверки интерфейса; end-to-end тесты для имитации полного пользовательского сценария.
2. Ручное тестирование: функциональное (соответствие требованиям), тестирование производительности (работа под нагрузкой), юзабилити (оценка удобства), кросс-платформенное тестирование (проверка на разных устройствах) и тестирование подключений (поведение при различном качестве интернет-соединения).

Для этого используют специализированные инструменты: Firebase Test Lab для запуска тестов на множестве устройств, Crashlytics для мониторинга сбоев, Android Profiler и Xcode Instruments для анализа производительности. А Accessibility Scanner помогает адаптировать интерфейс для людей с ограниченными возможностями, расширяя потенциальную аудиторию.

Публикуем приложение

После тестирования и исправления проблем наступает ответственный момент публикации. Каждый магазин приложений имеет свои особенности процесса:

• Google Play: создание аккаунта разработчика ($25 единоразово); подготовка материалов (иконка, скриншоты, видео, описание); загрузка APK/App Bundle; заполнение формы оценки контента; настройка дистрибуции и ценообразования; ожидание проверки (до 2 дней).
• App Store: регистрация в Apple Developer Program ($99/год); создание записи в App Store Connect; подготовка маркетинговых материалов; загрузка сборки из Xcode; заполнение информации о возрастных ограничениях; ожидание рассмотрения (1-7 дней).
• RuStore: бесплатное создание аккаунта; подготовка материалов; загрузка APK; заполнение метаданных; быстрая модерация (до часа).

Перед публикацией важно убедиться в соответствии приложения правилам магазина, подготовить политику конфиденциальности и настроить аналитику для мониторинга производительности с первого дня.

Поддерживаем и обновляем

После выпуска начинается непрерывный процесс поддержки и совершенствования продукта. Разработчики регулярно исправляют найденные ошибки, добавляют новые функции и улучшают работу уже существующих.

Для эффективного мониторинга используют комплексные аналитические инструменты: Firebase Crashlytics для отслеживания сбоев, Firebase Analytics/Google Analytics для анализа пользовательского поведения, RuStore Remote Config — бесплатный аналог Firebase, Mixpanel для углубленного анализа пользовательских путей, AppMetrica от Яндекса как комплексное решение для российского рынка.

Автоматизация процессов разработки критически важна для регулярных релизов. CI/CD-системы (GitHub Actions, GitLab CI, Bitrise, Fastlane) позволяют автоматизировать сборку, тестирование и публикацию обновлений, значительно сокращая время выхода новых версий.

Оптимальная стратегия обновлений включает регулярный график релизов (каждые 2-4 недели) с четким приоритетом задач: критические исправления, новые функции, оптимизация производительности. В тренде современной разработки: персонализация на основе ИИ, многофункциональные суперапп-решения, адаптация под новые форм-факторы устройств и повышенное внимание к приватности данных.

Продвигаем приложение

На рынке огромная конкуренция, и без активного продвижения ваш продукт просто затеряется среди тысяч других программ. Важную роль здесь играет ASO (App Store Optimization) — оптимизация для магазина приложений. В некоторых случаях был зафиксирован рост установок до 70% благодаря сильным ASO-стратегиям.

Для Android-приложений это означает настройку страницы так, чтобы пользователи легко находили ваш продукт. Здесь важно правильно подобрать ключевые слова для описания, создать привлекательную иконку и подготовить качественные скриншоты. Чтобы понять, какое оформление работает лучше, разработчики всё чаще используют A/B-тесты — такая возможность есть, например, в RuStore. Она позволяет сравнить разные версии карточки приложения и выбрать ту, которая эффективнее привлекает пользователей.

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

Еще один инструмент для продвижения приложений — социальные сети. Здесь можно показывать функционал программы, общаться с пользователями, отвечать на их вопросы и рассказывать о новых опциях. Это помогает создать активное сообщество вокруг продукта. Так, к примеру, В 2023 году компания Geozilla, разработчик приложения для отслеживания местоположения близких, провела кампанию по продвижению с инфлюенсерами в социальных сетях. В рамках сотрудничества удалось собрать более 1 миллиона просмотров, а коэффициент конверсии из кликов в установки приложения составил 24%.

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

Собственный сайт или блог разработчика тоже может привлечь внимание к приложению, особенно если у вас уже есть известный бренд.

Подводим итоги

Создание успешного приложения начинается с четкого определения цели и понимания потребностей пользователей. Затем нужно выбрать подходящие технологии, продумать необходимые функции, спланировать архитектуру и разработать понятный интерфейс. Обязательно проведите тщательное тестирование перед запуском. После публикации важно регулярно обновлять приложение на основе отзывов пользователей и данных аналитики, а также активно продвигать его в магазинах приложений и социальных сетях.

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

iOS или Android? React Native или Flutter? Собираем все новости и гайды по мобильной разработке тут.

В этой статье на основе опыта работы с Firebase расскажу о плюсах, минусах и альтернативах использования этой платформы. Текст будет полезен тем, кто разрабатывает или планирует разрабатывать мобильные приложения.

В основе статьи — онлайн BoF-сессия на IT-конференции Mobius 2024, во время которой я обсуждал Firebase с коллегой Сергеем Мясниковым из ВКонтакте, Кириллом Поповым из ОК, Артёмом Ковардиным из RuStore и Алексеем Гладковым — мобильным разработчиком, автором проекта Mobile Developer.

Что такое Firebase?

Платформа Firebase популярна как набор решений для упрощения разработки мобильных приложений. С помощью её инструментов можно развернуть бэкенд со своей серверной логикой, подключить push-сообщения и аналитику, получать отчёты об ошибках, проводить A/B-тестирование. Платформа облачная: все ресурсы приложений, в том числе базы данных и клиентская аналитика, хранятся на серверах Google.

Самые востребованные инструменты Firebase:

• Firebase Cloud Messaging (FCM) — позволяет отправлять push-сообщения на устройства пользователей;
• облачная служба Firebase Remote Config — позволяет вносить изменения в конфигурацию приложения в режиме реального времени;
• сервис Firebase Crashlytics — помогает находить в приложениях причины зависаний, сбоев и медленной работы, собирать ошибки с продакшена, систематизировать их и фильтровать;
• сервис Firebase Performance Monitoring — инструмент для аналитики, позволяет отслеживать ключевые метрики: использование памяти, CPU, сетевого трафика;
• сервис Google Analytics — инструмент для продуктовой аналитики, позволяет получать информацию об использовании приложений и вовлечённости пользователей.
  

Именно с этих инструментов независимые разработчики и стартаперы обычно начинают знакомство с Firebase.

Альтернативы Firebase: почему они важны?

У Firebase действительно много полезных инструментов для мобильной разработки. Однако некоторые из них несовершенны и могут замедлить развитие проекта. Именно поэтому важны альтернативы, с которыми можно более точечно работать над продуктом.

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

Есть ещё одна причина, почему важны альтернативы Firebase: разработчикам необходимо поддерживать свои продукты на версиях Android без сервисов Google, например на ОС, собранных на базе AOSP. Но вне зависимости от операционной системы и её версии лучше держать в голове (а желательно в инструментарии) запасные варианты на случай, если что-то пойдёт не так.

Чем можно заменить FCM?

Push-сообщения — один из самых востребованных инструментов Firebase. Часто именно из-за него разработчики начинают использовать эту платформу в своих проектах; у них просто нет вариантов — push-сообщения используют Google-сервисы, которые, в свою очередь, имеют «системные привилегии».

Однако если вы собираетесь делать приложение для рынка России, то крайне желательно рассмотреть и другие инструменты и подумать над запасными решениями. Часть рынка РФ занимают, например, смартфоны Huawei, в которых нет сервисов из Google Play.

• RuStore Push — фактически альтернативный вариант для доставки push-сообщений, причём со своим транспортом. Чтобы упростить интеграцию, есть и омниканальное решение — Universal Push. Благодаря ему в рамках одного SDK можно обеспечить отправку в HMS, FCM и RuStore. Использование универсального API позволит подготовить некоторый fallback-механизм и поможет несколько повысить доставляемость уведомлений.
• Отдельные вендоры смартфонов разрабатывают свои решения для своих устройств. Например есть облачная служба Push Kit для рассылки уведомлений. С помощью неё можно отправлять push-сообщения на устройства Android и iOS, а также в веб-приложения.
• Если вы работаете в сфере B2B, то на рынке есть много MDM-решений — некоторые из них базируются на AOSP со своим транспортом для push-сообщений и со своим сервисом, который интегрируется в инфраструктуру заказчика. Этот вариант обычно используют компании, чтобы управлять устройствами сотрудников.

Когда проект только стартует, в нём обычно используется лишь Firebase. В дальнейшем желательно сразу заложить в проект несколько вариантов: например, RuStore Push, HMS Core, Firebase и один из омниканальных сервисов, — это позволит обезопасить себя и повысить доставляемость

Remote Config: какие есть аналоги?

Второй по популярности инструмент Firebase — Remote Config. Из названия понятно, что сервис позволяет добавлять в приложение параметры, которые можно изменять удалённо с бэкенда. Он достаточно легко интегрируется в мобильные приложения — как на Android, так и на iOS.

Одно из главных достоинств Remote Config — аналитика. Благодаря этому инструменту можно проводить A/B-тесты и изучать аудиторию приложения на основе таких критериев, как возраст или увлечения.

В качестве альтернативы FRC можно назвать RuStore Remote Config, который также позволяет конфигурировать приложения и проводить A/B-тесты. Это решение доступно для приложений на устройствах c Android и iOS и позволяет заменить Firebase.

Возможность конфигурировать свои приложения и проводить А/В-тесты — важная часть любого проекта, которая помогает делать его лучше для пользователей. Я советую диверсифицировать риски и использовать разные инструменты, чтобы не зависеть от одного сервиса

Анализ ошибок: Firebase vs Tracer

Анализ ошибок — один из важнейших параметров, на которые опираются при создании и развитии приложений. Если баги не устранять, они могут потянуть за собой ухудшение UX, потерю лояльности и отток аудитории, а также смещение фокуса с написания продуктового кода на исправление ошибок.

Сервис Firebase Crashlytics предоставляет подобную функциональность поиска ошибок. Он пользуется популярностью среди разработчиков, однако возможности сервиса сравнительно ограничены: в нём неудобный поиск, неточная группировка событий (ошибок, ANR) по типу, нет инструментов для работы с non-fatal ошибками, из-за чего они могут создавать свалку. И это только небольшой список проблем — на деле их гораздо больше.

В вопросе анализа ошибок у Firebase есть крепкая альтернатива — сервис Tracer от ОК. Если сравнивать эти два инструмента, то Tracer не только предлагает похожую функциональность по анализу, но и расширяет инструментарий разработчика. В нём есть:

• полнотекстовый поиск по стектрейсу;
• полноценный поиск по User ID — не только крешей, но и любых событий;
• возможность самому на клиенте решать, как группировать ошибки. Например, отдельно отслеживать все баги, связанные с авторизацией;
• поиск и фильтрация по любым полям и атрибутам;
• поддержка A/B-тестов;
• возможность профилирования и анализа утечек памяти в продакшене с загрузкой дампов памяти.

Мы начали создавать Tracer, когда разработчики Crashlytics, по ощущениям, совсем его забросили. Главная страница долго грузилась, сервис не умел сортировать ошибки по количеству задетых пользователей, не было полноценного поиска. В какой-то момент мы с коллегами решили делать свой продукт, в котором не было бы этих проблем

Ещё одна альтернатива Crashlytics — сервис Sentry. Это open-source проект, главная особенность которого — возможность развёртки внутри собственной инфраструктуры. Это позволяет минимизировать риски, связанные с утечкой чувствительных данных: например, словарей обфускации или логов с пользовательскими данными. Однако в России легально приобрести и развернуть self-hosted решение от Sentry не выйдет. К тому же на больших объёмах данных оно работает не идеально. И при всём этом требует затрат на поддержку и инфраструктуру.

Аналитика от Firebase: альтернативы есть

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

Сервис для аналитики от Firebase — Google Analytics — позволяет увидеть общую картину того, что происходит в приложении. Однако для глубокого погружения он не очень подходит — для этого лучше использовать более локальные решения. Кстати, их довольно много: Google Analytics можно назвать самым легко заменяемым продуктом от Firebase.

Например, сервис MyTracker от VK. Он ориентирован на российский рынок, менее загружен, чем Performance Monitoring. Соответственно, позволяет более точно анализировать ключевые показатели мобильных приложений, эффективность источников трафика и монетизации. С помощью него можно сегментировать аудиторию и строить прогнозы LTV, оттока. Сервис интегрирован с RuStore и другими альтернативными сторами. На данных и сегментах MyTracker работают Remote Config и могут работать push-уведомления RuStore.

Ещё один вариант — написать свой движок для аналитики.

Аналитика от Google позволяет только примерно представить, что происходит с приложением. Если вам необходимо детальное понимание, то лучше всегда держать „второе мнение“. Обычно мы используем внешние системы аналитики и самописные вещи. В этом есть значительный плюс: не надо отдавать важные и персонализированные данные о пользователях сторонней компании

Архитектурная гибкость

Запуститься совсем без Firebase невозможно, однако у инструментов этой платформы есть альтернативы. Те решения, о которых я рассказал, дополнят необходимую функциональность. Я не призываю навсегда отказаться от Firebase — просто рекомендую проектировать архитектуру так, чтобы была возможность переключиться на другой инструмент. Благодаря этому вы сможете закрыть свои потребности, работать быстрее либо с бо́льшим удобством.

На днях компания представила несколько новых инструментов для разработки. Среди них наиболее интересными стали Firebase Predictions, о которой мы расскажем далее, и интеграция с Crashlytics, которая займётся анализом багов в приложениях.

Firebase Predictions

Данная технология использует машинное обучения для того, чтобы лучше понимать пользователей и их будущие действия. Система подскажет, кто купит больше всех, а кто совсем воздержится от трат. Это позволит сделать ваше приложение более персонализированным. Подобный анализ не является чем-то инновационным — новинкой стала простота использования. Predictions работает на основе алгоритмов компании Google, которая является владельцем Firebase.

Сервис пока находится в стадии беты, более подробную информацию можно найти на сайте компании.

Интеграция с Crashlytics и A/B Testing

Crashlytics отслеживает баги в приложении и классифицирует их, тем самым помогая вам правильно расставить приоритеты при исправлении ошибок. Данное обновление станет доступно в ближайшее время.

Внося изменения в проект, не всегда можно предугадать реакцию пользователей. При помощи A/B Testing разработчик сможет протестировать новую функцию на небольшом количестве устройств. Система автоматически проводит ряд экспериментов для выяснения наилучших параметров приложения. Желающим опробовать эту фичу советуем ознакомиться с документацией.

Редизайн консоли

Консоль для разработчиков получила новый дизайн, что ожидаемо, учитывая добавление новых сервисов. На главном экране разместили больше информации о проекте. Все инструменты поделили на четыре основные категории: разработка, стабильность, аналитика и рост.