Разработка мобильного приложения для учёта финансов (Personal Finance)
Приложения для личных финансов объединяют несколько технически нетривиальных задач: банковская интеграция с нестандартными API, работа с несколькими валютами и конвертацией, корректная категоризация транзакций, и всё это в контексте жёстких требований к безопасности данных. Добавь сюда iCloud/Google Drive синк — и получаешь проект, который «простым» не назовёшь.
Банковская интеграция
Самая сложная и неоднородная часть. Три основных подхода:
Open Banking / PSD2 (Европа). Стандартизированные API: Nordigen (теперь GoCardless), Salt Edge, TrueLayer. Авторизация через OAuth2 с redirect обратно в приложение через Deep Link (ASWebAuthenticationSession на iOS, Custom Tabs на Android). Транзакции приходят в формате JSON с полями creditorName, transactionAmount, bookingDate. Звучит просто — но каждый банк интерпретирует стандарт по-своему: у одних сумма приходит как строка, у других — как число; у некоторых pending-транзакции дублируются после подтверждения.
Импорт выписок (CSV/OFX/MT940). Fallback для банков без API. Парсинг MT940 — это отдельная боль: формат наполовину стандартизирован, наполовину кастомизирован каждым банком. Для OFX используем готовые библиотеки, для CSV — пишем конфигурируемый парсер с маппингом колонок.
Ручной ввод. Всегда нужен как основа. Быстрый ввод с виджетом на экране блокировки (iOS 16+ WidgetKit с intent), или шорткат в Dynamic Island.
Категоризация транзакций
Правильная авто-категоризация через ML — это не «настроим ChatGPT и готово». Хорошо работает on-device модель: обученный классификатор по creditorName и transactionAmount. На iOS — CoreML с кастомной моделью, обученной на размеченных транзакциях. На Android — TensorFlow Lite. Главное — fallback через rules-engine: если ML дал низкую уверенность (confidence < 0.7), предлагаем пользователю выбрать категорию и обновляем локальную историю классификации.
Мультивалютность
Хранить суммы в minor units (целых числах), не в float. 10.99 USD = 1099 cents. Иначе потеряешь центы при накоплении транзакций из-за погрешности float. Курсы валют — кешируем, обновляем через ExchangeRates API или Fixer.io. Конвертация для отчётов — всегда по курсу на дату транзакции, не по текущему.
Безопасность
Данные о транзакциях шифруются в базе через SQLCipher (React Native / Flutter) или через NSFileProtection.completeUnlessOpen (iOS). Biometric lock через LocalAuthentication / BiometricPrompt — обязательно. Токены банковских API хранятся в Keychain (iOS) / Android Keystore, никогда в UserDefaults или SharedPreferences.
Процесс работы
Начинаем с аудита: какие банки нужно интегрировать, целевые страны (это определяет Open Banking provider), нужна ли мультивалюта, модель монетизации. Проектируем схему данных, особенно accounting model: двойная запись (double-entry) или упрощённая. Разрабатываем, тестируем на реальных банковских аккаунтах в sandbox-режиме, затем на продуктивных с реальными транзакциями.
Ориентиры по срокам
Ручной учёт с категориями, бюджетами и базовой аналитикой — 5–8 недель. Полный продукт с Open Banking интеграцией, ML-категоризацией, мультивалютой, виджетами и экспортом — 16–24 недели. Стоимость рассчитывается индивидуально после анализа требований.
| Сценарий | Примерный срок |
|---|---|
| Ручной учёт, одна валюта, базовые отчёты | 5–8 недель |
| + Импорт CSV/OFX | +2–3 недели |
| + Open Banking интеграция (1–2 банка) | +4–6 недель |
| + ML-категоризация on-device | +2–4 недели |
| + Виджеты, шорткаты, синк | +3–5 недель |