Общие бизнес-правила
Модели, валидация, API и сценарии не расходятся без причины между платформами.
Один продукт с управляемыми платформенными различиями
Кроссплатформенная разработка мобильных приложений
Разрабатываем кроссплатформенные приложения для iOS и Android на React Native и Expo. Общую бизнес-логику сочетаем с платформенными возможностями, проектируем API, offline-работу, безопасность, тестирование и публикацию.
Что за услуга?
Что такое кроссплатформенное мобильное приложение?
Кроссплатформенная разработка подходит, когда продукту нужны версии для iOS и Android с общей бизнес-логикой и согласованным выпуском функций. S.O.L CORP сравнивает требования с возможностями React Native и нативной разработки, выделяет платформенные различия и заранее проверяет сложные интеграции. Выбор технологии основывается на сценариях, а не только на желании сократить бюджет.
Практическая ценность
Что получает продукт от общей архитектуры
Платформенная адаптация
Системные возможности и интерфейс проверяются на iOS и Android отдельно.
Управляемые релизы
Окружения, версии, сборки и подписи имеют документированный процесс.
Проверяемое качество
Тесты охватывают логику, API, устройства, сеть, разрешения и обновления.
Сценарии продукта
Когда подходит кроссплатформенная разработка
Корпоративное приложение
Заявки, задачи, документы, согласования, уведомления и доступ по ролям.
Личный кабинет
Профиль, обращения, статусы, подписки, платежи и безопасная работа с API.
Сервис заказов
Каталог, корзина, доставка, оплата, история и уведомления о состоянии.
Полевой процесс
Фото, геопозиция, чек-листы, offline-очередь и синхронизация после восстановления сети.
Сервис с регулярным возвратом
Контент, события, напоминания и персональные сценарии с контролем уведомлений.
Архитектура разработки
Что входит в кроссплатформенное мобильное приложение
Граница общего и платформенного кода определяется по функциям, рискам и правилам площадок, а не по желаемому проценту переиспользования.
- 01
Продуктовые сценарии
Роли, задачи, экраны, навигация, исключения, offline и критерии результата.
- 02
UX/UI двух платформ
Компоненты, состояния, размеры, клавиатура, системные зоны, доступность и тёмная тема при необходимости.
- 03
Общий слой приложения
Модели, бизнес-правила, API-клиент, валидация, состояние и повторно используемые экраны.
- 04
Платформенные адаптеры
Разрешения, push, камера, файлы, платежи, ссылки, хранилище и фоновые задачи.
- 05
API и авторизация
Сессия, обновление токена, права, ошибки, повторы, отмена, лимиты и безопасная передача.
- 06
Сборки и окружения
Development, staging и production, конфигурация, версии, сертификаты и владение аккаунтами.
- 07
Тестирование
Логика, компоненты, интеграции, устройства, сеть, разрешения, обновление и регрессия.
- 08
Публикация и передача
Пакеты, метаданные, review notes, политика, доступы, исходный код и регламент поддержки.
Результаты проекта
Что передаётся заказчику
Исходный код
Репозиторий, структура модулей, конфигурация и история изменений.
Сборки
Подписанные пакеты согласованных окружений и воспроизводимый процесс сборки.
Документация
Архитектура, API, платформенные ветки, доступы и эксплуатационные ограничения.
Протокол QA
Устройства, версии, сценарии, найденные ограничения и результат повторной проверки.
Выбор архитектуры
Кроссплатформенное, нативное приложение или PWA
| Формат | Когда подходит | Что получает заказчик |
|---|---|---|
| React Native и Expo | Бизнес-сценарии близки на двух платформах, а нативные возможности доступны через проверяемые модули. | Общий продуктовый контур с платформенными адаптерами и отдельными сборками. |
| Нативная разработка | Критичны уникальные API, графика, фоновые режимы или максимально глубокая интеграция конкретной платформы. | Две специализированные кодовые базы и команды с большей свободой платформенной реализации. |
| PWA | Достаточны возможности браузера, важен быстрый доступ по ссылке, а магазины и глубокие API не обязательны. | Веб-приложение без полной модели нативной установки и части системных возможностей. |
Экспертная методика
Как применяем метод SHARED-BOUNDARY-01
Функции распределяются на общие, платформенные и требующие нативных модулей. После технического прототипа команда формирует архитектуру, правила дизайна и матрицу устройств. Релизный процесс включает автоматические проверки, ручное тестирование и отдельную приёмку сборок для каждого магазина.
Сравниваем варианты
Оцениваем кроссплатформенный и нативный подход по функциям, срокам и стоимости владения.
Выделяем различия
Фиксируем особенности iOS и Android, чтобы общий код не ухудшал ключевые сценарии.
Проверяем релизы
Тестируем сборки и требования магазинов отдельно для каждой операционной системы.
Фрагмент спецификации
Как проверяется offline-синхронизация заявки
Пример MOB-SYNC-07 показывает принцип. Реальная модель данных и стратегия конфликта определяются для проекта.
- Условие
- Авторизованный пользователь заполняет обязательные поля и прикладывает фото при нестабильном соединении.
- Действие
- Приложение валидирует данные, сохраняет локальную операцию с уникальным идентификатором и отправляет её после восстановления сети.
- Результат
- Сервер создаёт одну запись, приложение связывает ответ с локальной операцией и показывает подтверждённый статус.
- Критерий приёмки
- Повтор не создаёт дубль, ошибка сохраняет возможность повторной отправки, выход из приложения не теряет очередь, iOS и Android дают одинаковый бизнес-результат.
Сроки и стоимость
От чего зависит оценка мобильного приложения
Оценка зависит от числа ролей, сценариев, экранов, API, offline-режима и платформенных возможностей. Влияют авторизация, push, камера, геопозиция, файлы, платежи, deep links, фоновые задачи, аналитика, дизайн-система, доступность, число устройств, backend, администрирование, миграции, публикация и поддержка. Готовый API с документацией отличается от одновременной разработки сервера. Не входят автоматически аккаунты разработчика, комиссии площадок, платные SDK, юридические тексты, контент и рекламное продвижение. До старта проверяем критические библиотеки и правила магазинов. Мы не обещаем точный срок review, одобрение, число установок, рейтинг или коммерческий результат.
Пример решения
Мобильный кабинет для выездного процесса
- Задача
- Сотрудник должен получать задания, прикладывать фото и фиксировать результат при нестабильной сети, а руководитель видеть статус в корпоративной системе.
- Решение
- Выделяем общий маршрут и данные, проектируем offline-очередь, платформенные разрешения камеры и уведомлений, API с идемпотентностью, состояния синхронизации и тесты двух платформ.
- Результат
- единый бизнес-процесс работает на двух платформах, платформенные различия изолированы, а потеря сети имеет проверяемое состояние.
Этапы работы
Как разрабатываем кроссплатформенное приложение
- 1
Исследуем продукт
Фиксируем пользователей, сценарии, данные, устройства, платформы и ограничения.
- 2
Проверяем архитектуру
Прототипируем критические SDK и определяем общие и платформенные границы.
- 3
Проектируем интерфейс
Создаём сценарии, состояния, дизайн-систему и интерактивный прототип.
- 4
Разрабатываем и интегрируем
Реализуем приложение, API, авторизацию, данные, адаптеры и аналитику.
- 5
Тестируем и публикуем
Проверяем устройства, сборки, подписи, материалы и передаём приложения на review.
Управление рисками
Что чаще всего ломает кроссплатформенный проект
Погоня за процентом общего кода
Искусственное объединение усложняет системные функции и ухудшает пользовательский опыт.
Непроверенный SDK
Критическая библиотека может не поддерживать нужную версию, сборку или платформенный сценарий.
Неописанная сеть
Без правил повтора, отмены и конфликта приложение теряет действия или создаёт дубли.
Поздняя подготовка review
Аккаунты, подписи, privacy, metadata и demo-доступы блокируют выпуск после завершения кода.
Опыт, экспертиза и доверие
Кто отвечает за архитектуру мобильного продукта
Методика S.O.L CORP основана на анализе задачи, проверке исходных данных и применении профильной документации. Для каждой услуги мы определяем состав работ, ограничения, критерии результата и порядок проверки. Решения адаптируются под конкретный проект и согласуются с заказчиком до начала реализации.
- Ответственный за материал
- S.O.L CORP
- Область компетенции
- Разработка цифровых продуктов с 2017 года, React Native, Expo, TypeScript, API, авторизация, offline, интеграции, мобильный UX/UI, тестирование и публикация
- Дата проверки
Связанные этапы и услуги
Вопросы и ответы
Ответы на вопросы о кроссплатформенной разработке
Будет ли один код для iOS и Android?
Значительная часть продукта может быть общей, но системные функции и интерфейс иногда требуют отдельных файлов или адаптеров. Мы заранее фиксируем границу и не обещаем формальный процент переиспользования.
React Native выглядит как нативное приложение?
Интерфейс строится из нативных компонентов, но качество зависит от дизайна, реализации и платформенных паттернов. Мы проверяем размеры, жесты, клавиатуру, системные зоны и доступность отдельно.
Для чего используется Expo?
Expo предоставляет инструменты конфигурации, development build, доступ к API устройств, сборку и отправку. Режим проекта выбирается после проверки функций и библиотек, а не только ради быстрого старта.
Можно ли работать без интернета?
Можно, если offline входит в требования. Нужно определить локальные данные, очередь операций, конфликт, повтор, безопасность и момент подтверждения сервером. Это отдельная архитектурная задача.
Кому принадлежат аккаунты магазинов?
Для корпоративного продукта аккаунты, сертификаты и права должны принадлежать заказчику. Мы подключаемся с выданной ролью и документируем процесс, не принимая владение продуктом на себя.
Гарантируете ли публикацию?
Нет. Мы готовим сборку, metadata, review notes и проверяем актуальные требования, но окончательное решение и срок проверки определяют Apple и Google.
Нужен ли отдельный backend?
Если приложение хранит общие данные, роли, заказы или синхронизацию, нужен API и серверная логика. Можно интегрироваться с существующей системой либо разработать backend отдельным контуром.
Как поддерживаются новые версии систем?
После обновлений iOS, Android, React Native, Expo и правил магазинов проверяются зависимости, target API, сборка и ключевые сценарии. Регламент обновлений согласуется как сопровождение.
Начнём с задачи
Обсудим мобильное приложение?
Опишите пользователей, ключевые сценарии, iOS/Android, API, offline, push, камеру, платежи, существующий дизайн и желаемый выпуск. Не отправляйте секреты и ключи через форму. Мы определим вопросы исследования и критический прототип.
support@solcorp.ru Пн–Пт, 10:00–19:00 МСК