Розробка мобільного застосунку для програми лояльності
Програма лояльності без мобільного застосунку втрачає половину цінності — клієнт не видит баланс у потрібний момент, акція закінчується раніше, ніж він відкриє 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 тижні на розробку адаптера.