Ми проектуємо архітектуру мобільних застосунків, щоб уникнути ситуації, коли через 6 місяців додавання push-сповіщень вимагає переписування трьох екранів через бізнес-логіку, зашиту в ViewController, або навігацію, прив'язану до AppDelegate. Наша команда з досвідом понад 7 років на ринку і з 50+ реалізованими проєктами знає, як закласти масштабованість, тестованість і продуктивність з першого дня. Проектування архітектури — це інвестиція, яка окупається при першій значній зміні вимог. Наприклад, один з наших клієнтів (логістична компанія) після рефакторингу на Clean Architecture скоротив час додавання нової функції з 2 тижнів до 2 днів (в 7 разів швидше), що зекономило понад $50 000 на доробках у перший рік, а потім економія склала ще $20 000 за півроку за рахунок зниження вартості змін на 40%. Ми гарантуємо якість архітектури, а наші сертифіковані спеціалісти використовують найкращі практики.
Який патерн архітектури обрати для вашого проєкту?
MVVM став стандартом де-факто для архітектури iOS застосунку (SwiftUI + Combine), архітектури Android застосунку (Jetpack Compose + ViewModel) і архітектури Flutter застосунку (BLoC/Riverpod). Але «поставити MVVM» без розуміння масштабу проєкту — означає ускладнити маленький застосунок або не структурувати великий. Фактори, що впливають на вибір:
- Команда та її досвід. Якщо команда не працювала з VIPER — не ставити VIPER. Освоєння патерну в продакшні дорожче за його переваги.
- Масштаб і модульність. 5 екранів — достатньо простого MVVM без Clean Architecture. 50 екранів з командою з 8 осіб — Clean Architecture обов'язкова, інакше неминучі конфлікти в спільних файлах і відсутність ізоляції.
- Вимоги до тестованості. Clean Architecture забезпечує в 3 рази кращу тестованість, ніж MVVM, але вимагає дисципліни від усієї команди.
- Платформа. iOS, Android і Flutter мають різні нативні патерни: VIPER органічний для iOS/UIKit, MVP історично популярний на Android, BLoC став стандартом для Flutter.
Чому важлива модульна архітектура мобільного застосунку?
Для великих проєктів (50+ екранів, команда 5+ осіб) модульність критична. Розбивка на feature-модулі (auth, profile, payments, feed) дозволяє паралельно вести розробку і керувати часом збірки. На iOS використовуємо Swift Package Manager, на Android — Gradle multi-module, на Flutter — Dart packages у монорепозиторії. В одному з проєктів ми впровадили модульну архітектуру і скоротили конфлікти злиття на 70%. Dependency Injection для iOS, Android та Flutter реалізується через відповідні контейнери.
Що входить у проектування архітектури?
Це не просто схема в Miro з прямокутниками «Model — View — ViewModel». Повноцінне проектування включає:
Шарова модель (layering). Визначаємо межі між шарами: Presentation / Domain / Data. Документуємо правила: domain-шар не знає про Flutter/UIKit, data-шар не знає про конкретний UI-фреймворк. Dependency Rule — залежності тільки всередину, ніколи назовні.
Dependency Injection стратегія. Вибір DI-контейнера: iOS — Resolver / Swinject / ручний чистий DI, Android — Hilt (Dagger2 з кодогенерацією), Flutter — GetIt + injectable. Проектуємо граф залежностей, визначаємо часи життя об'єктів (singleton / scoped / transient).
lib/ app/ app.dart core/ network/ database/ di/ features/ auth/ presentation/ domain/ data/ profile/ presentation/ domain/ data/ Кожен feature-модуль містить свої presentation, domain і data, що дозволяє ізолювати функції та перевикористовувати код.
Порівняння підходів до керування станом
| Критерій | BLoC (Flutter) | ViewModel (Android) | Combine (iOS) |
|---|---|---|---|
| Поріг входу | Середній | Низький | Середній |
| Тестованість | Висока | Середня | Висока |
| Реактивність | Stream | LiveData/Flow | Publisher |
| Популярність | Стандарт Flutter | Стандарт Android | Штатний iOS |
Мережевий шар: Retrofit (Android), Moya (iOS), Dio (Flutter). Interceptors для авторизації (token refresh), логування, retry-логіки. Обробка помилок: мапінг HTTP-кодів у доменні помилки, не пробрасовувати DioException у presentation-шар.
Документація архітектури
Результат роботи — не лише робочий scaffold. Документуємо у вигляді:
- ADR (Architecture Decision Records) — чому обрали саме цей патерн, які альтернативи розглядали
- Діаграми компонентів і залежностей (C4 model: Context → Container → Component)
- Coding conventions і приклади для кожного шару
- Шаблонна структура feature-модуля, якої дотримується вся команда
Практичний кейс з нашої практики
На проєкті Flutter-застосунку для логістики (30+ екранів, реальний час відстеження, офлайн-робота водія) початкова архітектура була «BLoC скрізь без чіткого розділення шарів». Через 4 місяці: BLoC напряму викликав Dio, тести не писалися (неможливо ізолювати), додавання нової функції вимагало правок у 5–7 непов'язаних файлах.
Ми провели рефакторинг на Clean Architecture з GetIt + injectable, go_router, drift для офлайн. Це зайняло 3 тижні, але наступні 6 місяців команда додавала функції в 2 рази швидше. Клієнт відзначив, що вартість змін знизилася на 40%, що в грошовому вираженні склало понад $20 000 за півроку. Вартість самого проектування архітектури склала $4 000, що окупилося за перші 2 місяці.
Порівняння архітектурних патернів
| Критерій | MVC/MVP | MVVM | Clean Architecture |
|---|---|---|---|
| Поріг входу | Низький | Середній | Високий |
| Тестованість | Низька | Середня | Висока (в 3 рази краще) |
| Масштаб команди | 1–2 ос. | 2–5 ос. | 5+ ос. |
| Час на проектування | 0.5 дня | 1 день | 3–5 днів |
| Окупність | З першого місяця | З 3-го місяця | З 6-го місяця |
Ми рекомендуємо Clean Architecture для проєктів, які планують жити понад рік і розвиватися командою. Для швидких прототипів або маленьких застосунків достатньо MVVM.
Процес і терміни
- Аудит вимог — функціональні та нефункціональні вимоги, NFR щодо продуктивності та офлайн.
- Аналіз платформи і стеку — iOS / Android / Flutter / cross-platform, наявний код якщо є.
- Проектування — вибір патернів, документування рішень, ADR.
- Реалізація scaffold — базова структура проєкту з прикладами для кожного шару.
- Код-рев'ю та онбординг — пояснення команді принципів, code review перших функцій.
Проектування архітектури займає від 3 до 5 днів. Для legacy-рефакторингу з наявним кодом — більше. Вартість розраховується індивідуально після аналізу вимог і складу команди. Замовте проектування архітектури — ми допоможемо обрати оптимальну архітектуру для вашого застосунку. Отримайте консультацію, заповнивши форму на сайті.
Згідно з Apple Human Interface Guidelines, варто орієнтуватися на платформенні патерни, але при кроссплатформенній розробці важливо дотримуватися модульності та Dependency Rule.