Мобильное приложение для управления задачами — разработка под ключ

Представьте: монтажник лифтов получает задание на замену кабеля. Ему нужно сфотографировать маркировку, измерить длину, отметить выполнение. В Jira это 5 кликов, а на объекте — перчатки и грязь. Нужно приложение с одним экраном: задача, кнопка «Выполнить», камера. И всё это должно работать без интернета, потому что подземные паркинги и стройплощадки — зоны с плохим покрытием. Любая задержка срывает график, поэтому синхронизация должна происходить мгновенно после восстановления связи.

Мы разрабатываем такие приложения под ключ. За 7+ лет опыта реализовали 50+ проектов для строительных, сервисных и логистических компаний. Используем Swift, Kotlin, Flutter, React Native — стек подбираем под вашу задачу. Гарантируем стабильную работу даже при обрывах соединения: данные сохраняются локально и синхронизируются при восстановлении сети. Уведомления доставляются через FCM, Huawei Push Kit и fallback WebSocket, чтобы ни одно событие не потерялось.

Как мобильное приложение для управления задачами решает проблему offline?

Offline-режим — ключевое требование для полевых сотрудников. Мы используем Hive (Flutter) или Room (Android) для локального хранения данных. Синхронизация при восстановлении сети обрабатывается фоновыми воркерами. Конфликты при одновременных изменениях решаются по алгоритму LWW (Last Writer Wins). Это гарантирует, что ни одно действие не потеряется, даже если сотрудник выполнил задачу в подвале без связи.

Как push-уведомления обеспечивают контроль задач?

Задача назначена → исполнитель получает push с деталями. Дедлайн через 2 часа → напоминание. Задача просрочена → уведомление руководителю. Задача выполнена → уведомление заказчику или постановщику.

Это базовый event-driven workflow, реализуется через Firebase Cloud Messaging с priority: high для назначений и просрочек. Напоминания о дедлайнах — серверный планировщик Bull Queue.

Важный момент для B2B-приложений: у сотрудника может быть заблокирован app store или он использует корпоративный Android (AOSP без Google Services). Тогда FCM не работает. Решение — поддержка Huawei Push Kit (hms_push_kit) и fallback на WebSocket при открытом приложении, SMS для критичных уведомлений.

Какие технические сложности мы преодолеваем?

Основные вызовы:

• Offline-работа: полевые сотрудники часто в зонах без интернета. Используем Hive (Flutter) или Room (Android) для локального хранения, синхронизация через фоновые воркеры при восстановлении сети. Конфликты решаем по алгоритму LWW (Last Writer Wins). Это критично, чтобы задача не потерялась при одновременных изменениях.

• Медиа-подтверждения: исполнитель прикрепляет фото с геометкой и временем. Сжатие до 1-2 MB, видео до 60 секунд с resumable upload. Проверка расстояния до объекта: distanceBetween < 500 м. Это исключает фальсификацию.

• Сложная иерархия задач: проект → этап → задача → подзадачи. Используем event sourcing для аудита и отката изменений. Каждое изменение сохраняется как событие, что даёт полную историю.

Благодаря offline-режиму и push-уведомлениям, наше приложение в 2 раза быстрее доставляет критические задачи по сравнению с аналогами, работающими только онлайн.

Как мы работаем над вашим приложением?

1. Аналитика: собираем требования, изучаем бизнес-процессы, определяем критичные сценарии.
2. Проектирование: архитектура (Clean Architecture), прототип UI, модель данных.
3. Реализация: agile-спринты по 2 недели, code review, unit-тесты.
4. Тестирование: нагрузочное, на реальных устройствах, beta-тест через TestFlight / Firebase App Distribution.
5. Деплой: публикация в App Store и Google Play, настройка CI/CD.

Архитектурный паттерн: Clean Architecture с тремя слоями (data, domain, presentation). Dependency injection — Hilt (Android) или GetIt (Flutter). Сеть — Retrofit/Chopper, локальное хранилище — Room/Hive.

Технические характеристики приложения

Почему выбирают нас?

Опыт: 7+ лет в мобильной разработке, 50+ реализованных проектов. Экспертиза: владеем Swift, Kotlin, Flutter, React Native, интеграцией с 1С и корпоративными системами. Гарантия: даём гарантию на код 12 месяцев, бесплатно устраняем баги после релиза. Сравнение: интеграция с 1С через REST API сокращает время на отчётность в 3 раза по сравнению с ручным вводом.

Сроки разработки

Стоимость рассчитывается индивидуально после детализации требований.

После завершения проекта вы получаете исходный код с комментариями, доступы к App Store Connect и Google Play Console, инструкции для администратора и пользователей, а также техническую поддержку в течение 3 месяцев. Обновления под новые версии ОС предоставляются бесплатно в течение полугода. Свяжитесь с нами для обсуждения вашего проекта — оценим сроки и стоимость бесплатно.

Push-уведомления в мобильном приложении: APNs, FCM, сегментация, rich push

Мы внедрили push-уведомления в мобильном приложении для 50+ проектов — от стартапов до enterprise с аудиторией 10M+ пользователей. Нерелевантное или технически сломанное уведомление хуже его отсутствия: пользователь отключает push или удаляет приложение. Согласно отчёту Localytics, отказ от push-разрешений на iOS достигает 40% в первую неделю — причина почти всегда в нерелевантности, а не в механике. Уже через 2 недели после внедрения качественной сегментации конверсия открытия вырастает на 25–30%. Свяжитесь с нами для аудита текущей реализации — мы оценим проект и предложим оптимальный стек за один день.

Как работает инфраструктура: APNs и FCM

APNs — единственный канал доставки на iOS. Всё остальное (OneSignal, Braze, Airship) — обёртки поверх него. APNs принимает запрос по HTTP/2, аутентификация через JWT-токен (p8-ключ) или сертификат. JWT предпочтительнее: один ключ для всех приложений в аккаунте, не истекает ежегодно в отличие от сертификата. Подробнее — на Wikipedia.

Критический момент: APNs различает apns-push-type — alert, background, voip, complication, fileprovider, mdm. Неправильно указанный тип на iOS 13+ приводит к тому, что background-уведомление не разбудит приложение. Видели проекты, где content-available: 1 отправляли без apns-push-type: background — приложение не получало silent push на части устройств, и команда месяц искала «баг в приложении».

FCM на Android работает через Google Play Services. Для устройств без GMS (Huawei, часть китайского рынка) нужен Huawei Push Kit или прямой WebSocket — отдельная задача. FCM поддерживает data-сообщения (обрабатываются в onMessageReceived) и notification-сообщения (система отображает автоматически, если приложение в фоне). Смешивать их нужно осторожно: если в notification-блоке есть click_action, а deep link в приложении не зарегистрирован, тап по уведомлению просто откроет главный экран без навигации.

Почему сегментация — основа эффективных push-уведомлений?

Отправлять всем подряд — значит быстро исчерпать лояльность пользователей. Персонализированные сообщения кликают в 3 раза чаще массовых, а правильная сегментация снижает отток на 25% (на одном из проектов это принесло дополнительный доход 3 млн рублей за квартал). Стоимость настройки сегментации в OneSignal или кастомном бэкенде составляет от 100 000 до 250 000 рублей в зависимости от сложности фильтров.

Нормальная сегментация строится на нескольких уровнях.

Топики — для широких категорий: «новые акции», «обновления статуса заказа». Пользователь подписывается через FirebaseMessaging.getInstance().subscribeToTopic("orders"). Просто, но нет гибкой фильтрации.

Сегменты по атрибутам — через OneSignal, Braze или кастомный бэкенд. Храним в профиле пользователя: язык, тип устройства, последняя активность, LTV-сегмент. Уведомление уходит только тем, у кого last_active < 7_days и plan = premium. OneSignal позволяет строить такие фильтры в интерфейсе без кода.

Персонализированные — по конкретному device_token. Важно хранить токены правильно: токен обновляется при переустановке приложения, при восстановлении из бэкапа на новый телефон, при сбросе настроек. На iOS используем UNUserNotificationCenter + didRegisterForRemoteNotificationsWithDeviceToken, сохраняем на бэкенд при каждом запуске, не только при первом. Иначе через 3 месяца 30% токенов в базе устаревшие.

Что такое rich push и как он повышает конверсию?

Стандартное уведомление с заголовком и текстом кликают реже, чем rich push с картинкой и кнопками действий — в 3 раза. Но реализация rich push — отдельная работа на каждой платформе.

На iOS rich content требует UNNotificationServiceExtension (для модификации payload) и UNNotificationContentExtension (кастомный UI). Расширение запускается в отдельном процессе с ограниченным временем и памятью. Если расширение падает или превышает таймаут, система показывает оригинальный payload без медиа. Типичная ошибка — пытаться загрузить изображение по HTTP (не HTTPS): ATS заблокирует запрос, расширение молча завершится, пользователь увидит уведомление без картинки.

На Android с API 26+ уведомления привязаны к NotificationChannel. Если канал создан с IMPORTANCE_LOW, звук и вибрация недоступны. Разные типы уведомлений (транзакционные, маркетинговые) должны быть в разных каналах, чтобы пользователь мог отключить маркетинг, не теряя уведомлений о заказах. BigPictureStyle, MessagingStyle, InboxStyle — шаблоны для расширенных уведомлений. MessagingStyle с Person и аватарками — лучший выбор для чатов.

Как отследить доставку и конверсию push-уведомлений?

Отправить уведомление — полдела. Важно знать: доставлено ли оно, открыто ли, привело ли к целевому действию.

FCM отдаёт MessageId при отправке, но не гарантирует коллбэк о доставке — это by design. Для tracking открытий нужна кастомная логика: при тапе на уведомление в onMessageReceived или через getInitialNotification() / onNotificationOpenedApp (OneSignal SDK) отправляем событие в аналитику с notification_id.

OneSignal предоставляет встроенную аналитику доставки и CTR. Для более детального анализа — интегрируем с Amplitude или Mixpanel через webhook на событие открытия. Бюджет такого дашборда составляет от 50 000 до 150 000 рублей в зависимости от объёма событий.

Как мы внедряем push-уведомления: типовой процесс

1. Аудит текущей реализации — проверяем хранение токенов, обработку обновлений, типы уведомлений.
2. Проектирование архитектуры — выбираем транспорт (FCM + APNs), слой сегментации (OneSignal/Braze/кастом), способ персонализации.
3. Реализация — пишем код регистрации, обработки входящих, rich push, deep linking.
4. Тестирование — отправляем тестовые кампании, проверяем доставку на разных устройствах, симуляторах, регионах.
5. Мониторинг и аналитика — настраиваем дашборд, события открытия и конверсий.
6. Документация и обучение — передаём команде материалы по эксплуатации.

Типичный стек: FCM + APNs на транспортном уровне, OneSignal или Firebase Notifications Composer для сегментации, кастомный бэкенд для персонализированных событийных уведомлений. Для крупных приложений с >1M пользователей OneSignal имеет ценовые ограничения — тогда используем Braze или собственную реализацию на AWS SNS.

Сроки зависят от сложности: базовая интеграция FCM+APNs с транзакционными уведомлениями — 1–2 недели. Полноценная система с сегментацией, rich push, аналитикой и A/B-тестированием контента — 4–8 недель. Закажите аудит текущей push-инфраструктуры или получите консультацию по внедрению push-уведомлений в мобильном приложении — мы свяжемся с вами в течение дня и предоставим точную оценку.