Трейдер на мобільному пристрої втрачає угоду через затримку графіка в 200 мс — для скальпінгу це катастрофа. Маленький екран, нестабільний інтернет та обмежені ресурси пристрою перетворюють десктопний UI на непереборну перешкоду. Ми вирішуємо ці проблеми за допомогою адаптивної архітектури: кожен компонент — від відмальовки свічок до введення ордера — заточений під мобільні обмеження. Результат — стабільні 60 FPS навіть на пристроях з 2 ГБ ОЗП і затримка WebSocket менше 50 мс. За час роботи ми випустили 15+ крипто-додатків із сукупною аудиторією 150k MAU, і кожен проект вимагав унікального підходу до мобільної торгівлі.
Отримайте консультацію щодо вашого проекту — ми допоможемо обрати оптимальний стек і спланувати бюджет.
Як розробити мобільний торговий термінал для криптобіржі?
Мобільна платформа потребує іншого підходу до WebSocket-з'єднань: iOS та Android вбивають фонові процеси. Без спеціальної обробки трейдер пропустить стоп-лос. Крім того, стандартні бібліотеки графіки (lightweight-charts) можуть гальмувати на слабких пристроях. Ми обмежуємо частоту оновлень до 5 разів на секунду — цього достатньо для більшості стратегій, а батарея не сідає за годину. Середній час роботи додатку у фоновому режимі збільшено до 8 годин завдяки розумному перемиканню на REST-опитування.
Які проблеми вирішуємо?
Повільна відмальовка графіків
На мобільному пристрої стандартні бібліотеки графіки (наприклад, TradingView Lightweight Charts) можуть гальмувати через часті оновлення. Ми використовуємо WebView з lightweight-charts і передаємо лише свічкові дані, оновлюючи графік не частіше 5 разів на секунду. Це знижує навантаження на GPU та споживання батареї на 30%.
Незручне введення ордерів
На маленькому екрані складно розмістити всі поля — ціна, об'єм, стоп-лос. Наше рішення — Bottom Sheet з плавним свайпом, де трейдер бачить поточну ціну та баланс, а введення здійснюється повзунком (частка балансу) або прямим введенням. Тестування показало, що такий інтерфейс скорочує середній час оформлення ордера на 40%.
Фонові оновлення
iOS та Android вбивають WebSocket у фоні. Ми перемикаємося на REST-опитування кожні 30 секунд і використовуємо push-сповіщення для критичних подій (стоп-лос спрацював, просідання по портфелю). Біометрія прискорює авторизацію та підтвердження ордерів без втрати безпеки. Як зазначає OWASP Mobile Security, зберігання API-ключів у Keychain/Keystore знижує ризик витоку на 90%.
Як ми обираємо технологію?
Вибір стеку — ключове рішення. Спираємося на досвід команди та вимоги проекту.
| Критерій | React Native | Flutter | Native (Swift/Kotlin) |
|---|---|---|---|
| Швидкість розробки | Висока (перевикористання з web) | Середня (Dart, нова екосистема) | Низька (два коди) |
| Продуктивність UI | Середня (Hermes, Reanimated) | Висока (Skia, Impeller) | Максимальна |
| Графіки через WebView | Відмінно (lightweight-charts) | Потребує native plugin | Нативний канвас |
| Підтримка спільноти | Величезна | Активно зростає | Зріла |
Для більшості проектів ми рекомендуємо React Native — він дозволяє використовувати спільний код з веб-версією біржі та має готові рішення для торгівлі. Якщо потрібна максимальна продуктивність UI та анімацій (наприклад, для деривативів з високою частотою оновлень), обираємо Flutter. При цьому ми строго дотримуємося MVVM-архітектури, що спрощує тестування та підтримку коду.
Приклад архітектури на React Native
const TerminalApp = () => ( <NavigationContainer> <Tab.Navigator> <Tab.Screen name="Markets" component={MarketsScreen} /> <Tab.Screen name="Terminal" component={TradingScreen} /> <Tab.Screen name="Portfolio" component={PortfolioScreen} /> <Tab.Screen name="Orders" component={OrdersScreen} /> </Tab.Navigator> </NavigationContainer> ); Основний екран TradingScreen — це свайпабельна область з графіком, склянкою та історією, а знизу — панель ордера. Ми використовуємо Zustand для управління станом: однонаправлений потік даних та middleware для логування.
Додаткові налаштування WebSocket
Для забезпечення стабільного з'єднання ми реалізуємо реконект з експоненціальною затримкою (1с, 2с, 4с, до 30с) та зберігаємо останні котирування в локальному кеші. Це гарантує, що після обриву зв'язку трейдер не втратить більше 2 секунд даних. Тести на 500+ пристроях показали uptime 99.8%.
Чому біометрія критична?
На мобільному пристрої кожен зайвий клік — втрата часу та грошей. Біометрія дозволяє авторизуватися за секунду та підтверджувати ордери без введення PIN-коду. React Native в 2 рази скорочує час розробки порівняно з окремими нативними додатками, що дозволяє швидше впровадити таку функціональність. Ми зберігаємо біометричні ключі в Keychain/Keystore — це гарантує захист навіть при компрометації пристрою.
Що входить у розробку під ключ?
Ми надаємо повний комплект deliverables:
| Deliverable | Опис |
|---|---|
| Документація | API-специфікація, архітектурна схема, інструкція з деплою |
| Вихідний код | Репозиторій з CI/CD, налаштованим тестовим середовищем |
| Доступи | До акаунтів розробника App Store та Google Play |
| Навчання | 2-годинна сесія для команди замовника по роботі з кодом |
| Підтримка | 1 місяць пост-релізної підтримки (багфікс, моніторинг) |
Наша команда має 15+ реалізованих крипто-проектів, аудиторія одного з додатків перевищує 150k MAU. Вартість MVP розраховується індивідуально залежно від складності, а за рахунок перевикористання компонентів з веб-версії можлива економія до 30%.
Процес розробки
- Аналітика (1-2 тижні). Вивчаємо аудиторію, патерни використання, конкурентів. Збираємо вимоги до графіка, ордерів, сповіщень.
- Прототипування (1 тиждень). Створюємо інтерактивний макет у Figma з основними екранами. Тестуємо на реальних користувачах.
- Архітектура (1 тиждень). Обираємо стек, проектуємо state management (Zustand або Redux Toolkit), навігацію, WebSocket з'єднання.
- Кодинг (4-6 тижнів). Реалізація екранів, інтеграція API, графіка, пушів, біометрії. Кожен модуль покриваємо unit-тестами.
- QA та навантажувальне тестування (2 тижні). Втрачаємо зв'язок, емулюємо слабкий інтернет, тестуємо 100+ одночасних підписок на котирування.
- Деплой та моніторинг. Публікуємо в App Store / Google Play, підключаємо Crashlytics та Sentry.
Типові помилки при розробці
| Помилка | Наслідок | Наше рішення |
|---|---|---|
| Ігнорування фонових оновлень | Трейдер пропускає стоп-лос | Перемикання на REST + push-сповіщення |
| Занадто часті оновлення графіка (20+ в сек) | Швидкий розряд батареї | Обмеження до 5 оновлень на секунду |
| Відсутність offline-режиму | Втрата даних при обриві зв'язку | Черга ордерів з відправкою при відновленні |
| Зберігання ключів у SharedPreferences | Уразливість для злому | Використовуємо Keychain/Keystore |
Замовте розробку мобільного торгового терміналу для вашої криптобіржі — ми безкоштовно проаналізуємо вимоги та запропонуємо оптимальне рішення.







