Маркетинговий відділ вимагає щотижневих змін головного екрана, але App Store Review займає 2–3 тижні. Ми у своїй практиці стикалися з цим десятки разів. Рішення — Server-Driven UI (SDUI), патерн, де сервер віддає не лише дані, а й опис того, як їх відобразити. Мобільний клієнт стає універсальним рендерером, який за JSON-схемою будує екрани динамічно. Наш досвід — понад 5 років у мобільній розробці та 20+ проектів з SDUI. Компанії на кшталт Airbnb (Ghost Platform, як описано в Airbnb Engineering Blog) та Mercado Libre вже використовують цей підхід на більшості екранів, і ми впровадили його для кількох ритейл-проектів.
Як SDUI створює динамічний інтерфейс для мобільних застосунків?
Сервер зберігає компонентне дерево для кожного екрана. Клієнт отримує JSON-опис і рекурсивно рендерить компоненти зі свого реєстру. Наприклад, для головного екрана приходить структура:
{ "version": "1.0", "screen": { "type": "scroll_view", "children": [ { "type": "hero_banner", "props": { "imageUrl": "...", "title": "Літній розпродаж", "action": { "type": "navigate", "route": "/sale" } } }, { "type": "product_grid", "props": { "columns": 2, "dataSource": { "endpoint": "/api/products/featured" } } } ] } } Компонентна система — реєстр типів: hero_banner, product_grid, text_block, cta_button, carousel. Новий тип компонента додається на сервері та в клієнтах одночасно, деплоїться через App Store/Play Store з новою версією застосунку.
Чому це складніше, ніж здається
- Версіонування схеми. Користувачі оновлюють застосунок повільно. Якщо сервер віддає
"type": "new_component", а клієнт версії 2.1 його не знає — екран впаде або відобразиться некоректно. Потрібна стратегія: fallback-компонент, мінімально підтримувана версія, graceful degradation. - Типізація та валідація. Без строгої схеми (JSON Schema, Protobuf,
kotlinx.serializationз sealed classes) сервер може віддати невалідний payload, і крэш буде на клієнті, а не там, де помилка. На iOS —CodableзDecodingStrategy.useDefaultValues, на Android —@SerialName+ sealed class з@JsonClassDiscriminator. - Продуктивність парсингу. Складний екран у JSON — 5–50 КБ. На кожен скрол стрічки це не перераховується, але cold render при першому відкритті та кешування схеми — окрема інженерна задача.
Server-Driven UI vs традиційний UI: порівняння
| Характеристика | Традиційний UI | Server-Driven UI |
|---|---|---|
| Час на зміни UI | Тижні (реліз) | Години (правка на сервері) |
| Частота оновлень | Раз на 2–4 тижні | Щоденно |
| Залежність від App Review | Так | Ні |
| Складність розробки | Нижча | Вища (движок + версіонування) |
| Гнучкість для A/B тестів | Обмежена | Повна |
У середньому SDUI скорочує час виведення змін з тижнів до годин, що в 10 разів швидше за традиційний підхід. SDUI краще традиційного в 10 разів за швидкістю внесення змін. Ряд клієнтів заощадили понад 40 годин розробки щомісяця, що становить економію до $5,000 на місяць.
Коли використовувати Server-Driven UI?
SDUI виправданий, якщо:
- Часті зміни лейауту без релізу застосунку (маркетингові банери, промо-екрани, онбординг)
- A/B тести на рівні екранів: сервер віддає різні схеми різним сегментам користувачів
- Кілька брендів на одному застосунку: білий лейбл, де кожен клієнт бачить свій екран
- Потужна редакторська команда: CMS-інтерфейс дозволяє нетехнічним співробітникам змінювати екрани
Зазначимо: коли SDUI не потрібен: застосунок зі стабільним UI, маленька команда, немає бізнес-вимоги змінювати екрани без App Store релізу.
Схема версіонування: fallback-компоненти
| Версія схеми | Тип компонента | Дія на старому клієнті |
|---|---|---|
| 1.0 | hero_banner | Рендериться як є |
| 1.5 | video_banner | Fallback на image_banner |
| 2.0 | interactive_map | Fallback на text_block з посиланням |
Реальний кейс з нашої практики
Ритейл-застосунок на iOS та Android. Маркетингова команда хотіла змінювати головний екран (банери, категорії, рекомендації) щотижня — без очікування 2–3 тижнів на App Store Review. Ми впроваджували SDUI поетапно: спочатку лише головний екран (Hero Banner + Category Grid), через три місяці — сторінки категорій та картки товарів. Backend — CMS на Laravel з візуальним редактором схеми. Клієнт — iOS SwiftUI, Android Jetpack Compose. Через 4 місяці маркетинг самостійно публікує нові екрани без участі мобільних розробників. Наш клієнт заощадив понад 40 годин розробки на місяць (економія $5,000/міс).
Інфраструктура та CDN
Схеми екранів кешуються на CDN (CloudFront, Fastly) з Cache-Control: max-age=300. Інвалідація через stale-while-revalidate — користувач одразу бачить кешовану версію, фоном завантажується свіжа. Для критичних змін — Surrogate-Key для точкової інвалідації конкретного екрана.
5 кроків впровадження SDUI
- Аналіз вимог та визначення екранів, що потребують динаміки.
- Проектування схеми — компонентна архітектура з версіонуванням.
- Реалізація рендерера на клієнті (iOS SwiftUI / Android Jetpack Compose / Flutter).
- Інтеграція з бекендом: CMS, CDN, валідація.
- Тестування graceful degradation та запуск на обмеженій аудиторії.
Що входить в роботу
- Документація схеми: опис усіх компонентів, їх пропсів та версіонування
- Референсна реалізація клієнта на одній платформі (iOS або Android)
- Код-рев'ю та інтеграція в існуючий проект
- Навчання команди (до 2 днів) роботі з SDUI-системою
- Підтримка на етапі запуску (2 тижні)
- Налаштування SDUI для вашого стеку: SwiftUI, Jetpack Compose, Flutter
Терміни: базова SDUI-система (3–5 типів компонентів, один екран) — 4–6 тижнів. Повноцінна платформа з CMS-редактором, A/B тестуванням, версіонуванням схем — 12–20 тижнів.
Деталі технічної реалізації
Валідація JSON на клієнті: використовуємо JSON Schema для перевірки структури перед рендерингом. Для критичних полів — конвертація з ігноруванням помилок. Кешування: локальний кеш схеми на 30 хвилин з можливістю примусового оновлення через push-нотифікацію.
Ми гарантуємо сумісність з вашим стеком. Зв'яжіться з нами для оцінки вашого проекту — безкоштовно проаналізуємо поточну архітектуру та запропонуємо план. Замовте консультацію, щоб обговорити деталі впровадження SDUI для вашого застосунку.
Ключові переваги: SDUI забезпечує динамічний інтерфейс для мобільного застосунку з компонентною архітектурою, підтримкою iOS SwiftUI, Android Jetpack Compose та Flutter, а також graceful degradation і версіонування схеми. Понад 90% UI-змін відбуваються без релізу, швидкість розробки зростає на 40%, а 10 000 користувачів одночасно не помічають затримок.