Кросс-платформенные мобильные приложения без сожалений
Когда одной кодовой базы на React Native достаточно, когда начинается борьба с платформой и какая работа по релизу остаётся без бюджета.
Универсального ответа нет
Спор «кросс-платформа или натив» обычно идёт про вкус. Вкус тут ни при чём. Это вопрос о списке фич, и ошибка в нём стоит месяцев.
Я выпускал и так, и так. Android на Kotlin с распознаванием документов через OpenCV и общим модулем Kotlin Multiplatform в Crossinx. Три приложения GlavUpDK, где комплекс Avto сделан на React Native с Expo поверх бэкенда на FastAPI, а клиент OTRS намеренно нативный. И моё собственное iOS-приложение, которое говорит с умным кольцом по Bluetooth Low Energy.
Кросс-платформа подходит, когда приложение это в основном формы и списки
Если экраны это списки, формы, карточка объекта и вызов API, одна кодовая база на React Native будет честным выбором. Платишь один раз за навигацию, авторизацию и сборку, получаешь оба стора.
Avto как раз такой: заявки на сервис, данные автомобилей, логин, уже существующий бэкенд. Expo закрыл сборку, обновления и store lanes, и ничего из этого не требовало платформы.
Натив, когда фича это сама платформа
Решающий сигнал простой: ключевая фича это возможность платформы или экран. Bluetooth, пайплайны камеры, работа в фоне, слияние данных датчиков, шифрованное локальное хранилище. Если что-то из этого и есть продукт, кросс-платформенный слой превращается в прослойку-переводчик между вами и железом, и весь проект вы боретесь с ней.
Приложение для кольца очевидный случай: чтение бинарного протокола конкретного устройства по BLE, обработка переподключений, паузы между опросами. Ничему из этого не место за мостом JavaScript.
Офлайн тоже важен. Приложение Gosti работает на мероприятиях дипломатического протокола, где сети может не быть. Локальное шифрованное хранилище, биометрический барьер перед экспортом и блокировка скриншотов это не те фичи, которые я мог бы взять из кросс-платформенного плагина и доверять им.
Как на самом деле выглядит общий код
Kotlin Multiplatform оказался лучшей серединой, которую я пробовал: доменная модель, валидация и бизнес-правила живут в одном месте и компилируются нативно под Android и iOS, а интерфейс у каждой платформы свой. Общим становится код логики, а не экраны. Так нужные части остаются общими, и интерфейс не приходится загонять в компромисс.
Закладывайте бюджет на релизный пайплайн, а не только на код
Мобильные проекты реально съезжают на сборке и на сторе. Ключи подписи, версии, фермы устройств для тестов, скриншоты, отказы ревью из-за отсутствующих деклараций приватности. Я это автоматизирую: lanes в Fastlane на iOS, EAS на Android, CI гоняет тесты на устройствах с гейтом по покрытию, чтобы красная сборка не стала релизом.
В демо эта работа не видна, и она решает, выпускать обновления каждый месяц или один раз.
Правило, по которому я решаю
Напишите список фич, отметьте всё, что требует платформы, и посчитайте. Ноль или один пункт, и кросс-платформа выигрывает по цене. Три и больше, и натив выигрывает по времени, хотя в первый день кажется дороже.
Ошибка в том, чтобы выбрать кодовую базу на вкус, а вопрос платформы обнаружить на четвёртый месяц, когда архитектура уже сложилась вокруг неверного ответа.