Разработка мобильного приложения для системы лояльности

Разработка мобильного приложения для системы лояльности

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

Где ломаются типичные реализации

Рассинхрон баланса. Кассир начисляет баллы — клиент видит старый баланс ещё 10 минут. Причина — кеш без инвалидации: баланс запрашивается при открытии приложения, кешируется в NSUserDefaults или SharedPreferences без TTL, и не обновляется после push-события с бэкенда. Решается через APNS/FCM Data Message (silent push) с loyalty_balance_updated payload — приложение тихо делает фоновый рефреш через URLSession background task или WorkManager.

Цифровая карта в офлайне. Штрихкод или QR клиентской карты должен работать без интернета — кассовый сканер не зависит от connectivity пользователя. Генерация на клиенте из member_id + hmac_secret через HMAC-SHA256 с ротацией каждые N секунд (как TOTP) решает задачу без постоянного API-запроса. Barcode рендерится через ZXingObjC / ZXing-Android-Embedded или нативными средствами — CIFilter(name: "CICode128BarcodeGenerator") на iOS.

Уровни и прогресс-бар. Переход между уровнями (Silver → Gold) должен показываться анимированно в момент начисления, а не при следующем открытии. Если бэкенд присылает событие tier_upgraded в push — приложение должно открыть экран с анимацией Lottie, а не просто обновить цифру. Это требует корректной обработки UNUserNotificationCenter foreground presentation + deep link в SceneDelegate/onOpenURL.

Отдельная боль — персональные предложения. Если офферы подгружаются одним bulk-запросом раз в час, пользователь видит неактуальное предложение. Лучшая схема: OffersFeedRepository с paging через Jetpack Paging 3 или собственный курсор, инвалидация по push, локальный кеш в Room/Core Data с expires_at.

Архитектура и стек

Для большинства loyalty-проектов выбираем Flutter (единая кодовая база iOS + Android) или React Native — зависит от того, есть ли уже RN-команда на стороне клиента. Нативный Swift/Kotlin оправдан, если приложение интегрируется с Wallet (Apple Wallet Passes + Google Wallet API) — там нативный SDK удобнее.

Ключевые интеграции:

• Apple Wallet / Google Wallet — PKPassLibrary на iOS для добавления/обновления карты прямо из приложения. Pass обновляется через push-уведомление с webServiceURL — сервер присылает новый .pkpass с актуальным балансом автоматически.
• Firebase Crashlytics + Analytics — трекинг конверсии в активацию карты, redemption rate по офферам.
• Branch.io или Firebase Dynamic Links — deep link для реферальной программы («Пригласи друга»).
• RevenueCat — если в loyalty-приложении есть premium-подписка (расширенные привилегии уровня).

Структура данных на клиенте: MemberProfile (id, tier, balance, card_number), OfferList (paged, cacheable), TransactionHistory (infinite scroll, Room/Core Data). Отдельный SyncManager слушает FCM Data Messages и инвалидирует нужный кеш точечно, не дёргая весь профиль целиком.

Процесс работы

Аудит существующей программы лояльности и API → проектирование схемы синхронизации данных → UI/UX дизайн экранов (баланс, история, каталог офферов, карта) → разработка → интеграция с кассовой системой → QA (особенно сценарии офлайн + push-события) → публикация → поддержка.

Если бэкенд ещё не готов — параллельно проектируем API-контракты (OpenAPI 3.0) и разрабатываем моки через WireMock / MSW.

Ориентиры по срокам

MVP с балансом, историей операций, QR-картой и базовыми офферами — 4–8 недель. Полноценное приложение с Apple/Google Wallet, персональными предложениями, push-кампаниями и реферальной механикой — 2–3 месяца. Интеграция с нестандартной кассовой системой добавляет 2–3 недели на разработку адаптера.