Уявіть: літній парафіянин намагається прослухати проповідь на iPhone 6s. Аудіо переривається при переході в інший застосунок, шрифт надто дрібний, а сповіщення про найближчу службу не приходить. Така ситуація — результат відсутності грамотної роботи з фоновим аудіо, Dynamic Type та push-сповіщеннями. Ми накопичили рішення цих задач для церковних застосунків, які працюють на пристроях 5–7-річної давності.
Як працює розклад і сповіщення?
Розклад богослужінь — календар з подіями, що повторюються, та винятками. Локальна копія в Core Data (iOS) або Room (Android) із синхронізацією при запуску. Події, що повторюються (семантика iCalendar RRULE), зручніше зберігати як правило + список винятків, а не як N окремих записів.
Push-сповіщення за годину до служби — через FCM або APNs. На клієнті також локальні сповіщення через UNUserNotificationCenter (iOS) або AlarmManager + NotificationCompat (Android) як резерв для користувачів без стабільного інтернету.
Локальні сповіщення: покроково
- Запитати дозвіл:
UNUserNotificationCenter.current().requestAuthorization(options:). - Створити контент:
UNMutableNotificationContent()із заголовком та тілом. - Задати тригер:
UNCalendarNotificationTrigger(dateMatching:repeats:). - Додати запит:
UNUserNotificationCenter.current().add(request).
На Android — NotificationCompat.Builder + AlarmManager.setExact().
Як влаштована медіатека проповідей?
Аудіо та відео проповіді — основний контент. Відео через HLS від CDN (AVPlayer з AVAsset(url: m3u8URL)), аудіо — AVAudioPlayer або AVPlayer залежно від формату. Background audio обов’язковий: користувачі слухають під час поїздки.
Background audio на iOS: AVAudioSession з категорією .playback, UIBackgroundModes: audio в Info.plist, MPRemoteCommandCenter для керування з Control Center та AirPods (play/pause, наступний трек, перемотування). Без MPRemoteCommandCenter — сповіщення в системному плеєрі не показується, AirPods не керують відтворенням. Для коректної роботи налаштування MPRemoteCommandCenter обов’язкове — докладніше в документації Apple.
На Android — MediaSessionCompat + MediaBrowserServiceCompat + сповіщення з MediaStyle. ExoPlayer у ForegroundService для background playback. PlayerNotificationManager з ExoPlayer автоматично створює медіа-сповіщення з керуванням.
Пошук по проповідям — full-text search через API. Фільтр за спікером, датою, серією. Offline-доступ для завантажених матеріалів — зберігаємо в FileManager (iOS) або getExternalFilesDir() (Android).
Чат громади: готове SDK чи власне рішення?
Загальний чат — або через стороннє SDK (Stream Chat, SendBird), або самостійна реалізація на WebSocket. Для невеликих громад (до 500 осіб) готові SDK з freemium моделлю вигідніші за часом розробки та вартістю. Stream Chat SDK для iOS та Android надає готовий UI — ChatChannelVC / ChannelListFragment — з можливістю кастомізації.
| Критерій | Stream Chat | Власна реалізація |
|---|---|---|
| Час впровадження | 1–2 дні | 2–4 тижні |
| Вартість | Безкоштовний тариф до 10k MAU | Витрати на сервер + розробка |
| Можливості | Модерація, реакції, файли | Повний контроль, але складніше |
Модерація контенту — ролі адміністратора та модератора. Видалення повідомлень, блокування користувачів. Це обов’язкова функція для релігійної спільноти.
Як обробляються пожертви?
Вбудований збір пожертв — найбільш регульована частина. На iOS не можна просто вбудувати свою платіжну форму для цифрових товарів/послуг — Apple вимагає StoreKit. Але пожертви для НКО/релігійних організацій не є покупкою цифрового контенту, тому WebView із зовнішньою платіжною формою (Stripe, PayPal) допустимий. Це потрібно явно прописати в призначенні застосунку при рев’ю — інакше ризик відхилення за гайдлайном 3.1.1.
На Android обмежень менше — нативна Stripe SDK (com.stripe:stripe-android) з PaymentSheet дає готовий UI для введення карти.
Регулярні пожертви — підписки через Stripe Billing. Керування з застосунку: скасування, зміна суми. Економія на комісії Stripe порівняно з власним платіжним шлюзом може бути значною.
Підтримка старих пристроїв: на що звернути увагу?
Мінімальна версія iOS 14 (охоплює понад 95% активних пристроїв). Android мінімум API 26 (Android 8). На iOS 14 немає AsyncImage — використовуємо Kingfisher. Без @Observable (iOS 17) — ObservableObject + @Published.
Шрифт — Dynamic Type (UIFont.preferredFont(forTextStyle:), sp одиниці на Android). Літні користувачі часто збільшують шрифт у налаштуваннях системи — застосунок має коректно реагувати без переповнення тексту.
| Які пристрої ми тестуємо? |
|---|
| iPhone 6s (iOS 14), iPhone 8, iPhone X, iPod touch 7, Samsung Galaxy S8 (Android 8), Galaxy J5, Xiaomi Redmi Note 5. На кожному пристрої перевіряємо масштабування шрифту, фонове відтворення, push-сповіщення. |
Що входить у роботу? (Deliverables)
| Етап | Результат |
|---|---|
| Аналіз | ТЗ, архітектурна схема, прототип UX |
| Дизайн | Pixel Perfect макети під iOS та Android, адаптація під Dynamic Type |
| Розробка | Нативний код на Swift/Kotlin, інтеграція API, push-сертифікати |
| Тестування | QA на реальних пристроях, UI-тести, навантажувальне тестування |
| Публікація | Завантаження в App Store Connect та Google Play Console, обхід гайдлайнів |
| Підтримка | 3 місяці баг-фіксів та консультацій після релізу |
Терміни та вартість
Розклад + медіатека з background audio + push-сповіщення — 4–6 тижнів. Чат + пожертви + offline — 2–3 місяці. Вартість розраховується після аналізу вимог. Зв'яжіться з нами для оцінки вашого проєкту — ми підготуємо комерційну пропозицію за 2 дні.
Гарантії та досвід
Ми гарантуємо проходження App Store Review та Google Play Review, відповідність гайдлайнам (Section 4.2, 5.1) та захист персональних даних. 5+ років на ринку мобільної розробки, 30+ релізів. Отримайте консультацію з архітектури застосунку вже сьогодні.