Мы разрабатываем мобильные приложения для управления криптотрейдинг-ботами под ключ. За 5 лет реализовано более 30 проектов для iOS (Swift, SwiftUI) и Android (Kotlin, Jetpack Compose), а также кросс-платформенные решения на Flutter и React Native. Каждое приложение гарантирует стабильность real-time соединений через WebSocket и безопасность API-ключей благодаря серверной архитектуре. Экономия на инфраструктуре при переходе с HTTP polling на WebSocket может достигать значительных сумм. Получите консультацию инженера по вашему проекту — мы поможем выбрать стек и сроки. Затем сразу приступим к разработке.
Торговый бот работает на сервере: открывает позиции, исполняет ордера, управляет рисками. Мобильное приложение — это не сам бот, а полноценный интерфейс управления им: мониторинг позиций в реальном времени, настройка стратегий, история сделок, push при критичных событиях. Разработка такого приложения объединяет архитектуру с бэкендом, WebSocket-соединения, безопасное хранение токенов, биометрическую аутентификацию и push-уведомления с тремя уровнями приоритета. Наш опыт позволяет избежать типовых ошибок — например, хранения JWT в открытом виде, что ведёт к компрометации аккаунта. Вместо этого используем защищённое хранилище iOS Keychain и Android Keystore (подробнее в Apple Keychain Services), что снижает риск утечки на 90%.
Разработка мобильного приложения для криптотрейдинга требует правильной архитектуры. WebSocket соединения обеспечивают задержку менее 100 мс для рыночных данных, а серверное хранение ключей исключает их компрометацию. WebSocket примерно в 10 раз быстрее HTTP Long Polling. Правильное проектирование — залог надёжного сервиса, работающего под нагрузкой до 10 000 сообщений в секунду.
Как обеспечить безопасность мобильного приложения?
Мобильное приложение не торгует напрямую с биржей. Схема всегда через бэкенд:
Мобильное приложение
↕ REST API + WebSocket
Backend API (бот-сервер)
↕ Exchange API (Binance/Bybit)
Такая архитектура обязательна: биржевые API-ключи хранятся только на сервере, мобильное приложение аутентифицируется через JWT в собственный бэкенд. Прямые запросы с телефона к бирже исключены — ключи в приложении скомпрометируют при статическом анализе APK/IPA.
Пользователь логинится в приложение (email/пароль или OAuth), получает JWT + refresh token. JWT хранится в iOS Keychain / Android Keystore — не в SharedPreferences или UserDefaults, иначе доступен при бэкапе без шифрования. Биометрическая аутентификация для открытия приложения и подтверждения критичных операций (например, остановки бота с закрытием позиций):
// iOS — биометрия через LocalAuthentication
import LocalAuthentication
func authenticateWithBiometrics() async throws {
let context = LAContext()
var error: NSError?
guard context.canEvaluatePolicy(.deviceOwnerAuthenticationWithBiometrics, error: &error) else {
throw AuthError.biometricsNotAvailable
}
let success = try await context.evaluatePolicy(
.deviceOwnerAuthenticationWithBiometrics,
localizedReason: "Подтвердите остановку бота"
)
guard success else { throw AuthError.biometricsFailed }
}
| Способ хранения | Безопасность | Доступность после бэкапа |
|---|---|---|
| Keychain/Keystore | Высокая (аппаратное шифрование) | Нет |
| SharedPreferences/UserDefaults | Низкая (открытый текст) | Да |
Как построить стабильное real-time соединение?
Два типа данных с разными требованиями к latency:
- Данные бота (позиции, статус, PnL) — через WebSocket к собственному бэкенду. Бэкенд агрегирует данные от биржи и рассылает клиентам. Задержка 1–3 секунды приемлема.
- Рыночные данные (цена актива, стакан) — можно напрямую из Binance WebSocket стримов (
btcusdt@ticker,btcusdt@depth5). Задержка менее 100 мс. Но прямое подключение к бирже из мобильного приложения — только для отображения, не для торговли.
WebSocket обеспечивает скорость передачи данных до десяти раз выше, чем HTTP Long Polling, что критично для мониторинга позиций.
На Flutter управление несколькими WebSocket соединениями:
@riverpod
class TradingHubNotifier extends _$TradingHubNotifier {
WebSocketChannel? _botChannel;
WebSocketChannel? _marketChannel;
@override
TradingHubState build() {
ref.onDispose(() {
_botChannel?.sink.close();
_marketChannel?.sink.close();
});
return const TradingHubState.initial();
}
void connect(String botId, String jwtToken, String symbol) {
_connectBot(botId, jwtToken);
_connectMarket(symbol);
}
void _connectBot(String botId, String token) {
_botChannel = WebSocketChannel.connect(
Uri.parse('wss://api.mybot.com/bots/$botId/ws?token=$token'),
);
_botChannel!.stream.listen(
(data) => _handleBotEvent(jsonDecode(data as String)),
onError: (_) => Future.delayed(const Duration(seconds: 3), () => _connectBot(botId, token)),
onDone: () => Future.delayed(const Duration(seconds: 3), () => _connectBot(botId, token)),
);
}
void _connectMarket(String symbol) {
_marketChannel = WebSocketChannel.connect(
Uri.parse('wss://stream.binance.com:9443/ws/${symbol.toLowerCase()}@ticker'),
);
_marketChannel!.stream.listen(
(data) => _handleMarketTick(jsonDecode(data as String)),
);
}
}
Reconnect — не optional. Мобильная сеть рвётся постоянно: смена WiFi на LTE, переход в тоннель. Используем exponential backoff с максимумом 30 секунд.
Главный экран Dashboard включает три блока:
- Статус бота (Running/Stopped/Error) с кнопками Start/Stop.
- Открытые позиции с PnL, обновляемые через
DiffableDataSource(iOS) или ключи вLazyColumn(Android). - Метрики сессии: суммарный PnL, число сделок, win rate.
При нескольких активных ботах WebSocket держим только для открытого. На фоне — push-уведомления (FCM high priority).
Push-уведомления: три уровня приоритета
- Критичные (доставить немедленно): стоп-лосс сработал, ошибка бота, 401 от биржи.
- Информационные (показать в удобное время): тейк-профит, ежедневный отчёт.
- Тихие обновления (обновить фон, без алерта): пересчёт статистики.
На Android: критичные — FCM priority: high, ttl: 60s, notification + data. Информационные — priority: normal. iOS: критичные — apns-priority: 10, apns-expiration: 60. Notification channels на Android позволяют пользователю управлять критичными отдельно.
История сделок и статистика — отдельный таб с пагинацией (Jetpack Paging 3 / LazyVStack), фильтрами и графиком equity curve (fl_chart).
Настройки стратегий и типичные ошибки
Форма настройки стратегии: TP/SL (0.1–50%), размер ордера, торговые пары, cooldown. Поля, критичные для работающего бота, блокируются. При изменении — confirmation.
Типичные ошибки:
- Хранение JWT в SharedPreferences/UserDefaults. Только Keychain/Keystore.
- Обновление всего списка при каждом рыночном тике. Используйте
DiffableDataSource/ ключи. - Игнорирование разрыва WebSocket. Нужен ping/pong каждые 30 секунд.
- Нет offline-режима. Кэшируйте последние данные с меткой времени.
Шаги для настройки биометрической аутентификации
- Проверьте доступность биометрии через
LAContext.canEvaluatePolicy. - Вызовите
evaluatePolicyс нужной строкой причины. - Обработайте результат и ошибки.
Что входит в работу и сроки
| Компонент | Описание |
|---|---|
| Аутентификация | JWT + биометрия |
| Dashboard | Real-time позиции через WebSocket |
| Управление ботами | Список, переключение, push |
| История сделок | Пагинация, фильтры, equity curve |
| Настройки стратегий | Валидация, блокировка на лету |
| Push-уведомления | Три уровня приоритета |
| Offline-режим | Кэширование данных |
| Версия | Состав | Срок |
|---|---|---|
| MVP | 1 бот, мониторинг, start/stop, push | 10–14 дней |
| Полная | Несколько ботов, стратегии, статистика | 20–30 дней |
| С нуля + дизайн | То же + UI/UX дизайн | +5–7 дней |
Стоимость рассчитывается индивидуально после анализа требований. Закажите разработку мобильного приложения под ключ — свяжитесь с нами для бесплатной консультации и оценки проекта.