Розробка мобільного застосунку для конференції – під ключ

Конференція на 2000 учасників: розклад змінюється щогодини, Wi-Fi падає, а учасники одночасно сканують бейджі на вході. Звичайний мобільний застосунок цього не витримає — потрібна архітектура з офлайн-режимом, кешуванням та push-синхронізацією. Ми спеціалізуємося на таких проєктах вже 5+ років (на ринку з 2019 року), реалізували понад 30 застосунків для заходів — від 200 до 5000 учасників. За цей час виробили перевірені рішення, які економлять до 30% бюджету за рахунок повторного використання модулів.

Розклад: як відобразити сотні доповідей без лагів?

Розклад конференції — сітка за часом і залами. На iOS: UICollectionView з кастомним UICollectionViewLayout, де кожна доповідь — це комірка з позицією (startTime) та розміром (duration). Compositional Layout тут не підходить — потрібна повна кастомізація позиціонування. Кастомний layout у 3 рази ефективніший за стандартний при складних сітках. prepare() обчислює UICollectionViewLayoutAttributes для кожної доповіді заздалегідь.

На Android — RecyclerView зі стандартним LinearLayoutManager і кастомними ItemDecoration не дасть потрібного результату. Або кастомний RecyclerView.LayoutManager, або Compose Canvas для відмальовування сітки розкладу напряму.

Персональний розклад — користувач додає доповіді «в закладки». Зберігається локально в UserDefaults / SharedPreferences плюс синхронізується з обліковим записом. Конфлікт розкладу (дві доповіді в один час) — явне попередження при додаванні.

Чому кастомний layout для розкладу?

Стандартні компоненти не забезпечують точного позиціонування комірок за часом. Кастомний layout дає повний контроль над візуальним розташуванням, що критично для сітки з overlapping-доповідями та динамічною зміною розмірів.

Offline-режим обов'язковий. Конференційний Wi-Fi часто перевантажений. Повний розклад кешуємо при першому запуску, оновлюємо за наявності мережі. URLCache для HTTP-відповідей з Cache-Control: max-age=300 на сервері. Доповідачі можуть запізнюватися, зали змінюватися — оновлення приходять через push-повідомлення з content-available: 1 (silent push) для інвалідації кешу.

Реєстрація: як обробити 5000 учасників за годину?

QR-код для реєстрації учасника — зашифрований ticketId у QR. Волонтери на вході сканують через AVMetadataMachineReadableCodeObject (iOS) або ML Kit BarcodeScanning (Android). Валідація в реальному часі через API — відповідь за < 500 мс навіть при 50 одночасних скануваннях. Це прискорює реєстрацію на 40% порівняно з паперовими бейджами. Посилання: AVMetadataMachineReadableCodeObject та ML Kit BarcodeScanning — перевірені рішення.

Кеш валідованих квитків на пристрої сканера: якщо API недоступний — перевіряємо за локальною копією. Ризик: хтось може використати старий квиток повторно. Рішення — offline cache тільки для read, запис на сервер при відновленні зв'язку.

QR-код учасника — генеруємо в застосунку через CoreImage.CIQRCodeGenerator (iOS) або zxing-android-embedded (Android) з ticketId. Високий рівень корекції помилок (CIQRCodeInputCorrectionLevelH) — QR читається навіть з подряпиною на екрані.

Push та live-оновлення: як гарантувати доставку змін?

Зміни в розкладі (перенесення доповіді, зміна залу, скасування) — push у реальному часі. FCM з priority: high для гарантованої доставки. Клієнт показує banner поверх поточного екрану через UIView.animate або snackbar у Compose.

Нагадування за 15 хвилин до закладок — локальні сповіщення через UNUserNotificationCenter. Не Firebase для цього — локальні сповіщення працюють без інтернету. При зміні розкладу — переплановуємо сповіщення: UNUserNotificationCenter.removePendingNotificationRequests(withIdentifiers:) + новий UNNotificationRequest.

Як забезпечити своєчасну доставку push?

Комбінація FCM з високим пріоритетом та локальних сповіщень гарантує, що користувач отримає оповіщення навіть при слабкому інтернеті. Silent push оновлює кеш без зайвих завантажень.

Нетворкінг та взаємодія

Список учасників з фільтром за інтересами, компанією, роллю (доповідач, відвідувач, спонсор). Обмін контактами — QR-код профілю або NFC через CoreNFC.NFCNDEFReaderSession (iOS) / NfcAdapter.getDefaultAdapter() (Android). NFC у 2 рази швидше QR — обмін займає менше секунди. NFC для обміну vCard — миттєво, без камери.

Чат доповідача з аудиторією — live Q&A. WebSocket канал на доповідь, питання з upvote. Модератор обирає питання для озвучування. На сервері: Redis Pub/Sub для broadcast питань та голосів усім підключеним клієнтам.

Карта конференц-центру

Схема будівлі — SVG або растрове зображення з накладанням інтерактивних точок залів. PDFKit (iOS) для векторних планів. Навігація до залу — стрілка з поверхом, не повний маршрутний граф (надлишково для однієї будівлі). Indoor Positioning через iBeacon (CLBeaconRegion) для наближення до конкретного залу — опціонально, потребує наявності beacon-інфраструктури.

Що входить в роботу

• Документація: технічне завдання, архітектурна схема, опис API.
• Вихідний код: приватний репозиторій з CI/CD, code review.
• Доступи: App Store Connect / Google Play Console, TestFlight, Firebase App Distribution.
• Навчання: інструкція для адміністраторів конференції, відеотуторіали.
• Підтримка: 2 місяці після релізу — виправлення помилок, адаптація під нові вимоги.

Процес і терміни

Як ми розробляємо: покроковий план

1. Аналіз вимог: вивчаємо сценарії використання, навантаження, інтеграції.
2. Проєктування: створюємо архітектурну схему, обираємо стек.
3. Реалізація: ітеративна розробка з демо кожні 2 тижні.
4. Тестування: навантажувальне тестування симуляцією 5000+ одночасних запитів.
5. Деплой: публікація в App Store та Google Play з поетапним rollout.

Розклад (сітка + закладки + offline) + push-повідомлення + бейджі (QR сканування) — 6–8 тижнів. Нетворкінг + чат Q&A + карта + live-оновлення — 2–3 місяці. Вартість розраховується після аналізу вимог. Орієнтовна вартість базової версії — від 200 000 грн. Зв'яжіться з нами для попередньої оцінки проєкту. Отримайте консультацію — ми підберемо оптимальне рішення під вашу конференцію.