Expo или чистый React Native: какой подход выбрать
Практика3 минРедакция Innovialabs
Коротко
Для большинства новых проектов разумно начинать с Expo: нативный код он не запрещает, а подключается через development builds и config plugins. Чистый React Native оправдан, когда вы активно правите нативные проекты вручную.
Коротко: что выбрать
Раньше выбор звучал как «удобный, но ограниченный Expo» против «гибкого, но трудоёмкого React Native». Сейчас это уже не так. Expo умеет работать с любыми нативными модулями через development builds, а нативные проекты генерирует из конфигурации.
- Expo — хороший вариант по умолчанию для нового приложения: быстрый старт, готовые модули, облачные сборки и OTA-обновления.
- Bare React Native — когда команда сама ведёт папки
ios/иandroid/, глубоко правит нативный код или встраивает React Native в существующее нативное приложение.
Документация React Native сама рекомендует начинать новые проекты с фреймворка, и Expo — основной такой фреймворк.
Сравнение по пунктам
| Критерий | Expo (managed + prebuild) | Bare React Native |
|---|---|---|
| Старт проекта | Минуты, без настройки Xcode и Android Studio | Нужно настроить нативное окружение |
| Нативные модули | Любые, через development build | Любые, подключаются вручную |
| Нативные проекты | Генерируются из app.json и плагинов | Хранятся в репозитории и правятся руками |
| Обновление версии RN | Обновление SDK, проекты пересоздаются | Ручной перенос изменений в нативных файлах |
| Сборка | EAS Build в облаке или локально | Локально или свой CI |
| OTA-обновления | EAS Update из коробки | Нужно подключать отдельно |
Expo Go и development builds
Expo Go — приложение из магазина, в котором можно запустить проект без сборки. Удобно для прототипа, но внутри только тот набор нативных модулей, что есть в Expo Go.
Как только нужна библиотека со своим нативным кодом, переходите на development build — собственную debug-сборку вашего приложения с нужными модулями. Работать с ней так же удобно: горячая перезагрузка, отладка, но уже с вашим нативным кодом.
Config plugins и prebuild
Prebuild (npx expo prebuild) генерирует папки ios/ и android/ из конфигурации. Этот подход Expo называет Continuous Native Generation: нативные проекты — это результат сборки, а не исходник, который нужно поддерживать.
Изменения в нативных файлах (Info.plist, AndroidManifest, Gradle) описываются через config plugins:
{
"expo": {
"plugins": [
["expo-camera", { "cameraPermission": "Камера нужна для сканирования QR-кодов" }]
]
}
}
Если нужной настройки нет в готовом плагине, можно написать свой — это небольшая функция на JavaScript, которая модифицирует нативную конфигурацию при prebuild.
EAS Build и EAS Update
- EAS Build собирает iOS и Android в облаке, управляет сертификатами и профилями подписи. Mac для iOS-сборки не обязателен.
- EAS Submit отправляет сборки в App Store Connect и Google Play.
- EAS Update доставляет обновления JavaScript и ассетов без публикации новой версии в магазине. Важно: обновление совместимо только со сборкой с тем же runtime version. Если менялся нативный код, нужна новая сборка через магазин.
eas build --platform all --profile production
eas update --branch production --message "Fix checkout"
OTA-обновления не должны менять суть приложения — магазины разрешают так исправлять ошибки и обновлять контент, но не обходить ревью.
Когда prebuild или «eject» действительно нужен
Термин eject устарел: вместо него вы запускаете prebuild и, при желании, коммитите сгенерированные папки. Делать это и вести нативные проекты вручную стоит, если:
- нужны правки нативного кода, которые неудобно выразить config plugin;
- вы встраиваете React Native в существующее iOS/Android-приложение;
- в команде есть нативные разработчики, которые привыкли работать с Xcode и Gradle напрямую.
Даже в bare-проекте можно использовать модули Expo и EAS — это не взаимоисключающие варианты.