Розробка мобільних додатків
Клієнт приходить з працюючим прототипом на React Native, який починає сипатися при 10 000 DAU: список пригальмовує, push-повідомлення приходять через раз, а release build на Android 14 падає з IllegalStateException при спробі відкрити камеру. Продукт є, але під навантаженням він розвалюється. Це типова точка входу — не «хочемо додаток з нуля», а «у нас є щось, що перестало справлятися».
Мобільна розробка сьогодні — це не вибір між iOS та Android. Це архітектурні рішення, які приймають на старті і з якими живуть роками. Ми маємо 8+ років досвіду, понад 50 реалізованих проєктів — від фінтеху до AR-додатків. Наша команда пропонує оцінити ваш проєкт та отримати roadmap під ключ.
Чому варто обирати нативну розробку?
iOS-додатки на Swift та SwiftUI дають прямий доступ до HealthKit, ARKit, CoreML, StoreKit 2. Android на Kotlin з Jetpack Compose — до CameraX, WorkManager, ML Kit. Нативний стек виправданий, коли додаток зав'язаний на платформенні API, вимагає максимальної продуктивності або працює з біометрією та Secure Enclave.
На практиці нативна розробка обирається для:
- Фінтех-додатків з biometric authentication та роботою з NFC (Apple Pay, Google Pay)
- Медичних рішень з інтеграцією HealthKit / Google Fit
- AR-додатків на ARKit / ARCore
- Ігор та інтерактивних 3D на Metal / Vulkan
- Додатків, де критична анімація на 120 fps (ProMotion на iPhone 13 Pro+)
SwiftUI закриває 80% UI-завдань швидше, ніж UIKit — економія часу на верстці сягає 30–40% порівняно з попереднім поколінням. Але складні кастомні комірки, кастомні переходи, робота з UIScrollView на низькому рівні залишаються за UIKit. Реальні проєкти використовують обидва фреймворки через UIHostingController та UIViewRepresentable.
На Android Jetpack Compose став production-ready. LazyColumn з remember та derivedStateOf рекомпозується тільки там, де потрібно — це принципово інша модель проти XML + RecyclerView з DiffUtil. Але Compose вимагає розуміння: неправильно використаний State у LazyListScope гарантує непотрібні рекомпозиції та просадку FPS.
Коли кросплатформа виграє: Flutter та React Native
Flutter рендерить UI через власний рушій Skia / Impeller — платформа не бере участі у відмальовуванні. Це означає піксельну точність на всіх пристроях та відсутність платформених артефактів. Платформенні компоненти (Maps, Camera, WebView) підключаються через platform channels, що додає складності, але не блокує.
React Native використовує нативні компоненти через JSI (JavaScript Interface). З появою New Architecture (Fabric + TurboModules) синхронні виклики з JS у нативний код стали працювати без серіалізації через JSON-міст. Це важливо для анімацій та жестів — react-native-reanimated 3 тепер виконує worklets прямо на UI thread.
Порівняння за ключовими параметрами:
| Критерій | Flutter | React Native | Нативний (iOS/Android) |
|---|---|---|---|
| Єдиний UI | Так (Skia/Impeller) | Ні (нативні віджети) | Ні |
| Продуктивність | Близька до нативної | Залежить від JS thread | Максимальна |
| Час до ринку | Швидше нативного | Швидше нативного | Повільніше |
| Платформені API | Через channels | Через modules/JSI | Прямий доступ |
| Розмір команди | 1 команда | 1 команда | 2 команди |
| Екосистема | pub.dev (Dart) | npm (JS/TS) | Swift Package Manager / Maven |
KMM (Kotlin Multiplatform Mobile) вирішує інше завдання — не UI, а бізнес-логіку. Shared-модуль на Kotlin компілюється в .framework для iOS та в Android-бібліотеку. UI залишається нативним на кожній платформі. Це робоче рішення для команд, у яких вже є iOS та Android розробники і які хочуть позбутися дублювання логіки (парсинг, кешування, валідація).
Що входить у розробку мобільного додатку
Кожен проєкт включає повний цикл: від аудиту до публікації. Ми передаємо клієнту:
- Документацію: технічне завдання, архітектурна схема, REST/GraphQL специфікація, дизайн-система.
- Доступи: репозиторій, сертифікати, облікові записи розробника (Apple Developer, Google Play Console).
- Навчання: інструкції з експлуатації, CI/CD налаштування, супровід першого тижня після релізу.
- Підтримка: гарячі виправлення, моніторинг crash-free rate (ми тримаємо 99,5%+), оновлення сумісності з новими версіями ОС.
UX/UI для мобайлу: не просто Figma
Дизайн мобільного додатку — це не перенесення веб-макету на маленький екран. iOS Human Interface Guidelines та Material Design 3 формують очікування користувачів від жестів, таймінгу анімацій, щільності інформації. Відступ від цих норм — не «унікальний стиль», а когнітивне навантаження.
Прототипування в Figma з Auto Layout та Component Properties дозволяє зібрати реалістичний інтерактивний прототип до написання рядка коду. Розробники отримують design tokens — кольори, типографіку, відступи — та імпортують їх напряму через Figma Variables API. Це скорочує кількість ітерацій на етапі верстки на 50%.
Для перевірки UX-гіпотез до розробки використовуємо Maze або UserTesting — тестуємо конкретні сценарії на прототипі, не на готовому додатку.
Backend для мобільного додатку
Мобільний клієнт споживає API — REST або GraphQL. Вибір між ними не релігійний: GraphQL виправданий при складній вкладеній структурі даних і коли різні екрани запитують різні набори полів однієї сутності. REST з JSON:API або OpenAPI простіше в кеші (HTTP cache headers) та моніторингу.
Для real-time — WebSocket (Socket.IO, native WS) або Server-Sent Events для односпрямованого потоку. gRPC з protobuf — для high-throughput сценаріїв та внутрішніх мікросервісів.
Push-сповіщення через FCM (Firebase Cloud Messaging) та APNs (Apple Push Notification service). Пряма інтеграція або через OneSignal / Braze — залежить від вимог до сегментації аудиторії та A/B-тестування сповіщень.
Аналітика та моніторинг: що відбувається після публікації
Firebase Crashlytics показує crash-free rate — нормою вважається 99,5%+. Нижче 99% — критично. Crashlytics групує схожі креші за stack trace та показує, на яких пристроях та версіях ОС вони концентруються. Це перше, що налаштовуємо перед релізом.
Продуктова аналітика — Firebase Analytics, Amplitude або Mixpanel. Воронки, retention, session duration. Важливо не кількість подій, а правильна таксономія: user_id, session_id, app_version, platform. Без цього дані не сегментувати.
Performance monitoring — Xcode Instruments (Time Profiler, Allocations, Leaks) для iOS, Android Profiler (CPU, Memory, Network, Energy) для Android. Для Flutter — DevTools з Timeline та Memory views.
AI в мобільному додатку: на пристрої чи в хмарі
CoreML на iOS дозволяє запускати .mlmodel прямо на пристрої. YOLOv8, MobileNetV3, кастомні моделі класифікації — без мережі, без затримки, без відправлення даних на сервер. Convert2CoreML або coremltools конвертують моделі з PyTorch/TensorFlow.
На Android — TensorFlow Lite з прискоренням через NNAPI (Neural Networks API) або ML Kit для готових задач: розпізнавання тексту, облич, штрих-кодів, переклад.
LLM-інтеграція — через API (OpenAI, Anthropic, Gemini) з потоковою відповіддю через SSE. На пристрої поки реально тільки невеликі моделі (Phi-3-mini, Gemma 2B) — через llama.cpp з Metal/Vulkan backend.
Публікація в App Store та Google Play
App Store Review Guidelines — документ, який треба читати перед початком розробки, а не перед відправкою на рев'ю. Відхилення за 4.3 (Spam — додаток занадто схожий на інші), 2.1 (App Completeness — crashable demo), 3.1.1 (не реалізовано In-App Purchase там, де це потрібно) — це тижні втраченого часу.
Google Play менш суворий, але Play Integrity API став обов'язковим для додатків, що працюють з платіжними даними. MEETS_STRONG_INTEGRITY — вимога для фінтех.
Fastlane автоматизує збірку, підписання та публікацію. match керує сертифікатами через git-репозиторій. CI/CD — GitHub Actions або Bitrise. Кожен merge в main — автоматична збірка та відправка в TestFlight / Firebase App Distribution для тестування.
Архітектура мобільного додатку: рішення, які складно переробити
MVVM — базовий патерн і для iOS (Combine + @Published), і для Android (ViewModel + StateFlow). BLoC на Flutter дає передбачуваний потік подій: Event → BLoC → State. Clean Architecture додає шари (Data, Domain, Presentation) та робить бізнес-логіку незалежною від UI-фреймворку.
VIPER на iOS та TCA (The Composable Architecture) — для великих додатків з великими командами, де важлива ізольованість фіч та тестованість кожного компонента.
Вибір архітектури на старті визначає, наскільки легко додати feature через рік і наскільки складно буде тестувати логіку окремо від UI.
Орієнтири за термінами
Терміни розробки залежать від складності, наявності готового дизайну та бекенду:
| Тип проекту | Орієнтовний термін |
|---|---|
| MVP (1 платформа, базові фічі) | 6–10 тижнів |
| Повноцінний додаток (2 платформи) | 3–6 місяців |
| Складний продукт з AI/AR/фінтех | 6–12 місяців |
| Редизайн та рефакторинг існуючого | 4–8 тижнів |
Вартість розраховується індивідуально після аналізу вимог — ТЗ, дизайн-макети, опис інтеграцій. Замовити консультацію та отримати попередню оцінку можна у нашій команді. Зв'яжіться з нами — ми підготуємо пропозицію під ключ.







