· 8 мин чтения
React Native или нативная разработка: где кросс-платформа ломается
Мы предлагаем React Native по умолчанию, но есть четыре типа задач, на которых честно отправляем клиента на нативную разработку.
За пять лет мы выпустили 9 приложений: 11 на React Native, 3 нативных. Расскажу, по какому признаку принимаем это решение, потому что обычно его принимают по стоимости, а это неправильный критерий.
Почему по умолчанию React Native
Одна кодовая база вместо двух. На типовом проекте — приложение с авторизацией, списками, формами, картами и push-уведомлениями — экономия выходит около 40 % по сравнению с двумя нативными командами. Плюс обе платформы развиваются синхронно, не бывает ситуации, когда Android-версия отстаёт на два релиза.
Для 8 проектов из 10 этого достаточно, и пользователь не отличит такое приложение от нативного.
Четыре случая, когда мы говорим «нет»
1. Фоновая работа с геолокацией
Трекинг курьера или такси, который должен работать со свёрнутым приложением и выключенным экраном. iOS и Android агрессивно убивают фоновые процессы, и обходить это нужно платформенными средствами. В React Native это делается через нативные модули, то есть вы всё равно пишете нативный код, но ещё и через прослойку. Проще писать сразу нативно.
2. Bluetooth и работа с устройствами
Приложение, которое общается с медицинским прибором, замком, кассой или датчиком. Библиотеки для React Native существуют, но на каждой нестандартной прошивке начинаются расхождения в поведении между iOS и Android, и отладка съедает всю экономию.
3. Обработка видео и камера сложнее съёмки
Распознавание документов в реальном времени, фильтры, дополненная реальность. Здесь нужен прямой доступ к кадрам с камеры, и передача их через мост React Native даёт заметные задержки.
4. Анимации как основа продукта
Не «карточка плавно появилась», а продукт, в котором анимация — это суть: редакторы, игры, интерактивные обучающие приложения. Reanimated закрывает многое, но если анимация в каждом элементе и должна держать 120 кадров, нативная разработка даёт запас.
Чего в этом списке нет
Нет пунктов «большой список», «много данных», «сложная бизнес-логика». Это самые частые опасения заказчиков, и они не обоснованы. Список на 50 000 элементов на React Native скроллится нормально, если он написан правильно.
Проблема почти никогда не в React Native, а в том, что разработчик рендерит весь список сразу вместо виртуализации. Это исправляется кодом, а не сменой платформы.
Как мы это проверяем до договора
Если по описанию задачи есть сомнения, мы делаем технический прототип за свой счёт: 3–5 дней, одна рискованная функция, проверка на реальном устройстве. Это дешевле, чем выяснить через четыре месяца, что архитектура не подходит.
На приложении для курьеров мы делали именно так. Главный риск был в офлайн-синхронизации: приложение должно писать данные без сети и корректно сливать их потом. Прототип занял четыре дня и показал, что React Native здесь справится. Проект собрали на Flutter по другой причине — у заказчика был свой разработчик на Dart, которому предстояло поддерживать приложение.
Коротко
- Кросс-платформа — разумный выбор по умолчанию, а не компромисс
- Решение определяется типом задачи, а не бюджетом
- Четыре красных флага: фоновая геолокация, Bluetooth, обработка кадров камеры, анимация как продукт
- В спорных случаях прототип на неделю дешевле ошибки на четыре месяца