Как развернуть Expo: практические примеры и опыт экспертов по настройке и деплою

Expo — это мощный фреймворк и платформа для разработки кроссплатформенных React Native приложений, который значительно упрощает начало работы. Однако переход от прототипа к production-релизу, особенно в условиях необходимости кастомной нативной функциональности, часто ставит разработчиков в тупик. Опытные инженеры делятся практическими шагами и примерами по развертыванию проектов Expo, от инициализации до публикации в сторах.

Начало — выбор правильного workflow. Expo предлагает два основных пути: «управляемый» (managed workflow) и «голый» (bare workflow). Управляемый workflow идеален для стартапов и проектов, где нужно быстро выпустить MVP, используя готовые решения Expo для доступа к API устройства. Вы создаете проект командой `npx create-expo-app`, и Expo берет на себя сборку и конфигурацию нативной части. Однако, если вам нужны специфические нативные библиотеки, которых нет в экосистеме Expo, или тонкая оптимизация размера бандла, рано или поздно придется переходить на bare workflow. Эксперты советуют начинать с managed, но сразу проектировать архитектуру с учетом возможного «отслоения» (eject). Используйте только те Expo модули (expo-camera, expo-location), которые имеют аналоги в сообществе React Native.

Практический пример настройки bare workflow. Допустим, вам понадобилась библиотека для обработки видео, которой нет в Expo. Выполняете `expo prebuild`. Эта команда генерирует нативные папки `android` и `ios` в вашем проекте, сохраняя при этом связь с Expo для обновлений. Затем добавляете нужную нативную библиотеку, например, `react-native-video-processing`. Вам придется вручную настроить линковку (для Android в `settings.gradle`, для iOS через Podfile). Ключевой совет: используйте `expo-modules` для создания собственных нативных модулей, если часто расширяете функциональность. Это обеспечит совместимость с будущими обновлениями Expo.

Конфигурация проекта через `app.json` (или `app.config.js`) — сердце Expo. Здесь настраиваются имя приложения, иконки, splash screen, ориентация, permissions и многое другое. Для production критически важно настроить схему версионирования (versionCode для Android, buildNumber для iOS) и разные environment переменные. Эксперты рекомендуют использовать `app.config.js` для динамической конфигурации. Пример: определение API endpoint в зависимости от сборки.

```javascript
export default ({ config }) => {
 const isProd = process.env.APP_ENV === 'production';
 return {
 ...config,
 extra: {
 apiUrl: isProd ? 'https://api.prod.com' : 'https://api.dev.com',
 enableDebug: !isProd,
 },
 android: {
 ...config.android,
 versionCode: process.env.BUILD_NUMBER || 1,
 },
 };
};
```

Сборка и деплой. Для managed workflow Expo Build Service (EAS Build) — это палочка-выручалочка. Он позволяет собирать билды в облаке без необходимости настраивать локальные среды под iOS и Android. Настройте `eas.json` в корне проекта. Определите профили сборки (development, preview, production). Пример конфигурации для production-билда в Google Play:

```json
{
 "build": {
 "production": {
 "android": {
 "buildType": "app-bundle"
 },
 "ios": {
 "enterpriseProvisioning": "universal"
 },
 "env": {
 "APP_ENV": "production"
 }
 }
 }
}
```

Запуск сборки: `eas build --platform android --profile production`. Для bare workflow вы также можете использовать EAS Build, либо перейти на полностью локальную сборку через Xcode и Android Studio. Локальная сборка дает больше контроля, но требует настройки машин и сертификатов подписи.

Работа с обновлениями (OTA updates) — одна из killer-фич Expo. Вы можете исправить мелкий баг или обновить JavaScript-код, не выпуская новую версию в стор. Настроив `expo-updates` в проекте, вы публикуете обновление командой `expo publish` (для managed) или через EAS Update (`eas update`). Важное предостережение от экспертов: никогда не публикуйте через OTA критические изменения в нативном коде или структуре проекта. Это может сломать приложение у пользователей. Всегда тестируйте обновление на канале preview перед rollout на всех пользователей.

Мониторинг и аналитика. После выхода приложения в продакшн необходимо отслеживать ошибки и производительность. Интегрируйте Sentry или BugSnag. Для Expo managed workflow есть удобный пакет `expo-sentry`. Настройте source maps загрузки в сервис, чтобы видеть стектрейсы оригинального TypeScript/JavaScript кода, а не минифицированного бандла.

Постепенное усложнение проекта — залог успеха. Не пытайтесь сразу настроить всё идеально. Начните с managed workflow, используйте EAS Build для первых билдов, подключите OTA-обновления для быстрых итераций. Когда упретесь в ограничения, аккуратно переходите к bare workflow, модуль за модулем. Документируйте все шаги, особенно связанные с настройкой окружения и подписью приложений. Это сэкономит дни нервов вам и вашей команде в будущем.