Планирование обновления до Expo SDK 58: iOS 27, React Native 0.88 и новые инструменты

SDK Expo 58 не определяется одной ключевой особенностью. Вместо этого сразу представлен длинный список изменений: поддержка iOS 27, React Native 0.88, ускоренная сборка для Android, более дешевые вызовы нативных модулей, виджеты на главном экране Android, интеграция с Siri через App Intents, CLI для разработки агентов, более совершенный Expo Router и экспериментальный трансформатор на основе Rust для Metro. В этом руководстве список отсортирован по практическому влиянию, чтобы вы могли понять, какие изменения затронут ваш кодовый базис, какие предоставляются бесплатно, какие все еще находятся в стадии тестирования, и как выполнить обновление без нарушения работы приложения в производстве.

Рассматривайте SDK 58 как бета-версию, потому что это так и есть

На момент написания SDK 58 находится в бета-версии, и компания Expo ожидает, что эта фаза продлится примерно три-четыре недели. Перед планированием чего-либо вокруг даты выпуска проверьте лог изменений Expo для узнания текущего статуса.

Период бета-тестирования — идеальное время для тестирования: кода вашего приложения, библиотек сторонних разработчиков, пользовательских нативных модулей, процесса сборки и любого написанного вручную нативного кода. Не стоит обновлять SDK в производственном приложении непосредственно перед выходными. Однако для побочных проектов и внутренних инструментов бета-тестирование представляет собой способ с низким риском ознакомиться с будущими изменениями и выявить проблемы на ранней стадии, пока ещё есть время их устранить на этапе разработки.

iOS 27 и жизненный цикл, основанный на сценах

Значительная часть стимулов к созданию SDK 58 связана с iOS 27. Приложения, скомпилированные с использованием SDK iOS 27, используют модель жизненного цикла, основанную на сценах, от Apple, и Expo переработало свою нативную инфраструктуру в соответствии с этой моделью.

Небольшое введение поможет понять ситуацию. В старой модели UIApplicationDelegate управлял всим приложением: одном окном и одним набором функций запуска и обработки событий на переднем плане. Модель сцен разделяет эти обязанности, так что каждый экземпляр интерфейса (сцена) имеет собственный цикл жизни, обрабатываемый депутатом сцены. Задачи, ранее находившиеся в депутате приложения, такие как реагирование на активацию приложения или обработка входящих URL-адресов, могут быть перенесены в функции обратной связи на уровне сцен.

В типичном проекте Expo эта замена должна оставаться незаметной. Однако она имеет значение, если вы настроили нативную часть приложения. Распространённым примером является дополнительная настройка в функции запуска депутата приложения, например, метод на Swift, показанный ниже (без выделения синтаксиса):

func application(
  _ application: UIApplication,
  didFinishLaunchingWithOptions launchOptions:
  [UIApplication.LaunchOptionsKey: Any]?
) -> Bool {
  // Custom initialization
  return true
}

Если в вашем файле AppDelegate.swift содержится значительная объёмная пользовательская логика, часть её может теперь относиться к обработке сцен, а не к единому глобальному окну приложения. Expo рекомендует ознакомиться с руководством по миграции жизненного цикла сцен, если вы вносите изменения в делегата нативного приложения.

Какие проекты требуют более тщательного рассмотрения

Многие приложения Expo вообще не загружают файл AppDelegate.swift, и в таких случаях миграция должна пройти без проблем. Однако в более крупных приложениях со временем накапливается нативный код, и именно здесь возникает риск. Тщательно проверьте свой проект для iOS, если в нём имеется нативная настройка для чего-либо из следующего:

• инициализация SDK аналитики
• обработка глубоких и универсальных ссылок
• SDK для аутентификации
• уведомления типа push
• SDK для нативных платежей

Каждый из этих элементов обычно связан с функциями возврата при запуске или по URL, именно они подвержены влиянию модели сцен. Тестируйте эти процессы явно, не предполагая, что успешная сборка означает работоспособное приложение.

React Native 0.88 и строгая API TypeScript

Бета-версия SDK 58 поставляется вместе с кандидатом на выпуск React Native 0.88. Поэтому обновление Expo подразумевает учет всех изменений как в React Native 0.87, так и в 0.88, а не только одной версии.

Первым изменением, с которым вы, скорее всего, столкнетесь, будет строгая API TypeScript, которая ужесточает критерии того, что считается публичной API React Native. Основными жертвами становятся импорты, обращающиеся к внутренним файлам:

import Something from 'react-native/Libraries/...';

Программы и библиотеки уже много лет используют такие глубокие импорты, обычно потому что публичная точка входа не предоставляла необходимых функций. Это всегда срабатывало случайно: пути к внутренним файлам могли меняться или изменять свою структуру в любой версии без предупреждения. React Native теперь четко разделяет публичные и приватные модули, и кодбаза с большим количеством глубоких импортов должна рассматривать версию SDK 58 как сигнал к их устранению. Если какая-либо библиотека в вашей иерархии зависимостей использует подобные импорты, проверьте, не была ли уже выпущена более новая версия с исправлением.

Удалённые API, такие как InteractionManager

Исчезли и некоторые старые API, причём InteractionManager — один из тех, которые стоит искать. Код, который откладывает выполнение ресурсоёмких операций до завершения анимаций и взаимодействий, часто выглядит следующим образом:

InteractionManager.runAfterInteractions(() => {
  loadHeavyContent();
});

Рекомендуемой заменой является стандартный API для обработки состояния в покое:

requestIdleCallback(() => {
  loadHeavyContent();
});

Семантика схожа, но не идентична. InteractionManager ожидал завершения зарегистрированных взаимодействий, тогда как requestIdleCallback выполняет функцию-компенсатор, когда у потока JavaScript появляется свободное время. В большинстве случаев, когда требуется «загрузить это после появления экрана», эта разница не имеет значения, но если вы рассчитываете на то, что он будет ждать окончания определенной анимации, проверьте его поведение на реальном устройстве.

В небольших приложениях такая миграция обычно происходит быстро. В старых приложениях с большим количеством зависимостей выполняйте обновление на отдельной ветке и позвольте компилятору TypeScript выявить все проблемы перед тем, как что-либо менять. Ошибки компилятора станут вашим списком проверок при миграции.

Более быстрая сборка чистых версий Android

expo-modules-core теперь поставляется с заранее скомпилированными нативными библиотеками для Android. Ранее при создании чистой сборки для Android значительная часть времени уходила на компиляцию C++-кода, от которого зависят модули Expo. SDK 58 полностью исключает этот этап.

По данным самой Expo, при использовании пустого приложения SDK 58 на устройстве Apple M3 Pro время сборки в режиме отладки для Android сократилось с примерно 80 секунд до примерно 39 секунд. Ваши показатели будут отличаться в зависимости от размера проекта и оборудования, но экономия достигается за счёт полного пропуска этой процедуры, поэтому она должна проявиться в любом проекте, использующем модули Expo.

В среде CI преимущества умножаются. Команда, которая создает по двадцать запросов на pull request в день, каждый из которых запускает сборку для Android, оплачивает затраты на компиляцию при каждом запуске, причем машины CI часто начинают работу с чистыми кэшами. Сокращение времени на полминуты один раз не кажется значимым. Однако если это сокращение достигается при каждой локальной чистой сборке, при каждом задании CI, на каждой ветке с функциями и при каждой сборке релиза, это в сумме приводит к значительным затратам времени и ресурсов. Скорость сборки также является формой производительности, только она измеряется в минутах работы разработчика, а не в частоте кадров.

Дешевле становятся вызовы между JavaScript и нативным кодом

Работа над улучшением производительности в SDK 58 не ограничивается только сборкой. Expo также снизил стоимость вызовов нативных модулей, причем большинство улучшений наблюдается на iOS. Передача длинных строк происходит значительно быстрее, а обещания, возвращаемые асинхронными нативными функциями, имеют меньший объем накладных расходов.

Чтобы воспользоваться этими улучшениями, вам не нужно ничего менять: существующие модули Expo автоматически получают эти улучшения после обновления.

Это особенно важно для приложений, которые часто переходят от JavaScript к нативному коду. Рассмотрим пример такого вызова:

const result = await SomeNativeModule.processLargePayload(data);

Нативная функция может выполнять свою работу быстро, но при каждом вызове все равно требуется преобразование аргументов в нативные типы и последующее преобразование результата обратно в значения JavaScript. Если приложение выполняет такие вызовы тысячи раз, например при обработке потока данных с датчиков или синхронизации крупных объемов данных, небольшая экономия на каждом таком переходе дает заметный эффект.

Expo Modules 2.0: нативные классы вместо DSL

Для команд, которые пишут собственные нативные модули, Expo Modules 2.0 представляет собой одно из самых значимых изменений. На момент написания этого текста он находится в бета-версии как для iOS, так и для Android.

Текущий API Expo Modules описывает модуль с помощью DSL: это блок определения, в котором объявляются функции, свойства и события. Expo Modules 2.0 использует более традиционный подход — вы пишете обычный класс на Swift или Kotlin и аннотируете те его элементы, которые должны быть доступны в JavaScript.

Практический результат заключается в том, что ваш нативный код выглядит как настоящий нативный код: Swift остается Swiftом, а Kotlin — Kotlinом, без необходимости сначала изучать специфический для фреймворка слой. Это снижает барьеры для разработчиков, которые знают платформу, но не Expo, а также помогает инструментам для автоматического кодирования, поскольку в их данных для обучения гораздо больше примеров обычного кода на Swift и Kotlin, чем кода на DSL Expo.

Существует также аспект производительности. Связи могут генерироваться во время сборки вместо того, чтобы решаться динамически во время выполнения, и тесты производительности Expo показывают значительное улучшение в нескольких микротестах. Микротесты изолируют отдельную операцию, поэтому они редко приводят к однозначному ускорению работы приложения; сами по себе они не являются основанием для перепроектирования нативной архитектуры. Если вы хотите узнать более подробно, почему статические связи быстрее, в статье Nitro Modules: как статические связи превосходят React Native TurboModules рассматривается тот же принцип. Особенностью Expo Modules 2.0 является то, что он делает модули одновременно проще для написания и быстрее, что представляет собой редкое сочетание.

Виджеты главного экрана на Android

expo-widgets теперь поддерживает Android, что открывает возможности для создания новых функций в различных приложениях: приложениях для отслеживания привычек, финансовых инструментах, сервисах доставки, приложениях для фитнеса, менеджерах задач и календарях.

Приложение для привычек может отображать сегодняшний прогресс без необходимости его запуска. Финансовое приложение может показывать краткую сводку бюджета с заголовком вроде этого:

Monthly Budget

а ниже — разбивку оставшейся суммы по категориям:

₹34,500 remainingFood        ₹8,200
Travel      ₹3,400
Shopping    ₹5,100

Менеджер задач может отображать три самые важные задачи дня непосредственно на главном экране.

В Android каждый виджет выполняет собственный пакет JavaScript на специальном движке Hermes, поддерживает взаимодействие с пользователем и может использовать цвета Material, чтобы гармонировать с темой системы. Стоит понимать принцип работы отдельного движка: виджет не делит память или состояние с запущенным приложением, поэтому данные к нему необходимо передавать явно, а не читать из внутреннего хранилища приложения. Для команд, работающих в кроссплатформенном формате, наличие виджетов на обеих платформах в экосистеме Expo устраняет ещё одну причину для поддержки отдельных нативных реализаций.

App Intents: Siri, Shortcuts и Spotlight

expo-app-intents соединяет приложения Expo с системой App Intents от Apple, которая является основой для нескольких системных интерфейсов:

• Siri
• Shortcuts
• Spotlight
• Apple Intelligence

Представьте себе менеджер задач. Обычно для выполнения задачи необходимо открыть приложение, найти соответствующий элемент и нажать на него. Когда предоставляется такая возможность, пользователь может просто попросить Siri:

"Завершите загрузку документов с идентификатором Upload ID."

Siri находит соответствующую задачу и запускает действие, объявленное вашим приложением. Ваш код на JavaScript получает этот сигнал и обновляет данные приложения. В примере Expo это происходит без вывода приложения на передний план.

Более широкие последствия заключаются в изменении структуры мобильного приложения. Иконка приложения больше не является единственной точкой входа. Некоторые действия выполняются через Siri, некоторые — через виджеты, некоторые — через поиск Spotlight, а некоторые — через автоматизацию Shortcuts пользователя. Приложение превращается в набор функций, которые операционная система может предоставить там, где они полезны, и это стоит учитывать при проектировании функционала.

Одно важное замечание: на момент написания expo-app-intents находится в стадии альфа-тестирования. Экспериментируйте с ним, но пока не используйте его для критически важных бизнес-процессов.

Expo UI приближается к SwiftUI и Jetpack Compose

Expo UI продолжает углублять свою интеграцию с SwiftUI и Jetpack Compose. В SDK 58 добавлены примитивы навигации SwiftUI для iOS:

NavigationStack
NavigationLink
NavigationDestination
Toolbar

Они соответствуют собственным элементам навигации SwiftUI, поэтому вы получаете нативную стековую навигацию и панели инструментов вместо их реализации на JavaScript. В этой версии также добавлено больше компонентов Jetpack Compose и улучшены существующие универсальные компоненты, работающие на всех платформах.

Ещё одно, казалось бы, незначительное улучшение оказывается очень полезным: теперь каждый компонент в документации Expo UI сопровождается визуальным примером. Без скриншотов выбор UI-компонента часто приводит к раздражающему циклу:

1. Найдите компонент, звучание которого вам нравится.
2. Ознакомьтесь с его параметрами.
3. Подключите его к экрану.
4. Запустите приложение.
5. Вы обнаружите, что оно совсем не похоже на то, что вы себе представляли.
6. Начните заново с другого компонента.

Видимость отрендеренного компонента рядом с его API прерывает этот цикл.

Device Hub и управление симулятором в браузере

Xcode 27 заменяет Simulator.app на Device Hub, и Expo CLI понимает новый рабочий процесс. Expo также тестирует отдельный пакет expo-device-hub, который предоставляет локальную панель управления в браузере для ваших симуляторов и эмуляторов.

С этой панели управления вы можете просматривать:

• живое отражение экрана устройства
• затраты CPU и памяти
• сетевой трафик
• варианты внешнего вида, такие как режим светлого и темного цвета
• опции доступности

Вы также можете нажимать, пролистывать и вводить текст на устройстве через браузер. Чтобы попробовать это, установите пакет и запустите сервер разработки:

npx expo install expo-device-hub
npx expo start

Если в вашей работе постоянно требуется переключаться между редактором, терминалом, эмулятором Android, симулятором iOS и отдельными инструментами анализа производительности, объединение части этих функций в одну вкладку браузера может значительно упростить процесс разработки.

Expo также работает над EAS Simulator, цель которого — предоставить аналогичный опыт с помощью симуляторов, размещенных в облаке, так что вам не потребуется устанавливать Xcode или Android Studio локально.

CLI, созданная для агентов кодирования

Это дополнение ясно показывает, куда движутся инструменты для разработчиков. Expo выпустила экспериментальный пакет:

@expo/agent-cli

Разработчикам бывает сложно решить, какой из нескольких инструментов использовать: Expo CLI, EAS CLI, expo-doctor и т. д., у каждого из которых свои флаги и формат вывода. CLI-инструмент объединяет их в единый унифицированный интерфейс. Настройка его для вашего проекта выглядит следующим образом:

npx @expo/agent-cli@latest agents:setup

Несколько команд этого инструмента иллюстрируют его принцип работы. Первая из них — это:

status

Она проверяет такие параметры, как совместимость с Expo Go, без запуска приложения. Следующая команда — это:

dev

Она запускает среду разработки и пытается найти самый быстрый способ запустить приложение. Последняя команда — это:

smoke

Она запускает приложение, делает скриншот и снова его останавливает.

Последняя команда наиболее интересна для автоматизированных рабочих процессов. Предположим, вы просите агента добавить экран настроек и проверить, продолжает ли приложение запускаться. Вместо того чтобы предполагать, что изменения сработали, агент может выполнить простую проверку и посмотреть результат. Это небольшой шаг от агентов-генераторов кода к агентам, способным проверять собственную работу, что и составляет основную практическую ценность таких агентов. Пакет находится в экспериментальной версии, поэтому ожидайте изменений в его командах.

Expo Router стабилизировал несколько функций

В SDK 58 произошло существенное обновление Expo Router. Несколько ранее экспериментальных функций теперь стали стабильными:

• загрузчики данных для получения информации о маршруте до отрисовки экрана
• отрисовка на стороне сервера для вывода в интернете
• мидлвары, выполняющиеся до того, как запрос достигнет маршрута
• нативные вкладки, поддерживаемые панелями вкладок платформы
• инструментальные строки

Внутри системы навигации также были внесены изменения, чтобы состояние навигации стало более детерминированным, то есть одна и та же последовательность действий всегда приводила к одинаковому состоянию. Большинство приложений не должны заметить разницы. Если вы создавали собственные навигаторы или импортировали код непосредственно с указанного пути, внимательно прочитайте руководство по миграции:

expo-router/react-navigation

В веб-приложениях теперь по умолчанию используются асинхронные маршруты. Каждый маршрут может быть разделен на отдельный JavaScript-фрагмент, который загружается при переходе пользователя на него, вместо того чтобы загружать код для каждого экрана сразу при первом открытии страницы. Для веб-приложений, построенных с использованием Expo Router, это разумный стандарт, поскольку именно время первоначальной загрузки обычно больше всего бросается в глаза пользователям. Имейте в виду, что это также означает, что маршрут может временно загружаться при первом посещении, поэтому состояния загрузки в веб-приложениях требуют тщательного рассмотрения.

Экспериментальный трансформатор на Rust для Metro

С технической точки зрения это, возможно, самое интересное изменение в этом обновлении, хотя оно является экспериментальным. Expo тестирует преобразователь JavaScript, написанный на Rust под названием Noxcturnal, созданный на основе инструментального набора oxc.

Значительная часть времени на генерацию «холодных» пакетов в Metro тратится на преобразования с помощью Babel: парсинг каждого файла, применение плагинов и генерация результата. Замена этого этапа на нативный код на Rust позволяет напрямую устранить самую трудоемкую часть процесса. В тестах Expo преобразование отдельных модулей происходило примерно в три раза быстрее, а генерация полных «холодных» пакетов — примерно в два раза быстрее. В одном крупном тестовом приложении из примерно 5 500 файлов время генерации сократилось с 5,26 секунд до 2,46 секунд.

Вы можете включить это функционал, установив соответствующий флаг экспериментов в своей конфигурации:

experiments: {
  noxcturnalTransformWorker: true
}

Узнайте ограничения перед включением этой функции. Проекты, которые используют пользовательские плагины Babel, настройки или специализированные преобразования, могут по-прежнему опираться на Babel, поэтому ускорение зависит от стандартизации вашей конфигурации. Поскольку эта функция является экспериментальной, её поведение и настройки могут меняться между версиями.

Этот подход соответствует тенденциям всей экосистемы, где инструменты для JavaScript с критическими требованиями к производительности уже несколько лет переходят с JavaScript на Rust. Expo сейчас исследует аналогичный путь для Metro.

Меньше ненужных пересборок нативного кода

По умолчанию в SDK 58 используется настройка balanced для генерации «отпечатков». «Отпечаток» — это хеш всех элементов, влияющих на сборку нативного кода; при его изменении инструменты Expo предполагают, что требуется новый нативный бинарник.

Это может показаться скучным, пока это не сэкономит вам необходимость пересборки нативного кода при изменениях, которые на самом деле не влияют на него. В зависимости от настроек раньше изменение такого параметра, как версия приложения в app.json, приводило к изменению «отпечатка» приложения. Балансировочный режим предназначен для игнорирования изменений, которые не оказывают существенного влияния на работу нативной среды выполнения. Практический результат прост: меньше случаев ненужной пересборки, а также меньше лишних сборок бинарных файлов, когда вы используете «отпечатки» для выбора между обновлением через сеть и новой версией из магазина. Никто не демонстрирует такую функцию, но все извлекают от неё пользу.

Более мелкие улучшения, о которых стоит знать

Помимо основных пунктов, в зависимости от вашего приложения могут оказаться полезными несколько обновлений модулей:

• expo-camera позволяет сканировать многосторонние документы, что полезно для сканеров квитанций, процессов загрузки документов, верификации личности (KYC) и управления расходами.
• expo-font поддерживает переменные шрифты на Android, iOS и в вебе.
• expo-audio получил функции управления экраном блокировки с учётом плейлиста и возможность записи в форматах WAV/PCM.
• expo-file-system дополняется новыми API для хеширования и поддержкой просмотра файлов нативно.
• expo-notifications вводит новые возможности, такие как отображение уведомлений в виде будильника на Android.
• Интеграция с PostHog позволяет прикреплять информацию о версии сборки EAS и её обновлениях к аналитическим событиям.

Ни один из этих элементов сам по себе не определяет версию продукта. Вместе они показывают, насколько расширилась сфера поддержки этой платформы.

Значимые изменения, которые необходимо рассмотреть перед обновлением

Обновления кажутся захватывающими до тех пор, пока приложение продолжает разрабатываться, поэтому не пропускайте этот этап. Прежде чем переводить реальный проект на SDK 58, проверьте следующее.

Глубокие импорты в React Native

Поищите в кодовой базе этот префикс пути:

react-native/Libraries/

Каждое совпадение — это импорт внутренних файлов React Native, который может быть отклонён строгой API TypeScript. Также проверьте папку node_modules или, по крайней мере, просмотрите несовместимые зависимости, поскольку библиотеки являются распространённым источником таких проблем.

Удалённые API React Native

Убедитесь, что ни ваше приложение, ни его зависимости не используют API, удалённые в версиях React Native 0.87 и 0.88, такие как InteractionManager.

Собственный код AppDelegate

Если проект для iOS содержит настройки жизненного цикла на нативном уровне, проверьте их с учётом жизненного цикла, основанного на сценах, требуемого iOS 27.

Собственная навигация в Expo Router

Персонализированные навигаторы и импорты из expo-router/react-navigation затронуты изменениями во внутренней структуре; следуйте руководству по миграции.

Запись в файловую систему

File.write() теперь является асинхронной функцией. Код, ожидающий наличия файла уже в следующем шаге, будет работать некорректно, если не будет ожидать завершения вызова. Если вам действительно нужна синхронная работа, переключитесь на:

File.writeSync()

Версия Node.js

Поддерживаемые Expo версии Node.js обновились. Проверьте свою локальную среду и образы CI, прежде чем считать сбой сборки ошибкой Expo.

Безопасный способ тестирования обновления

Не начинайте процесс на основной продакшн-ветке. Создайте специальную ветку для миграции и выполняйте обновление там:

npx expo install expo@next --fix

Тег expo@next устанавливает бета-версию, а параметр --fix синхронизирует ваши другие пакеты Expo с версиями, совместимыми с ней.

Сначала протестируйте менее значимые функции, ведь именно они бросаются в глаза пользователям при сбоях:

• Удается ли вообще запустить приложение?
• Работают ли процедуры входа и аутентификации?
• Могут ли пользователи перемещаться между основными экранами?
• Открываются ли глубокие ссылки в правильном месте?
• Приходят ли уведомления типа push?
• Могут ли пользователи загружать изображения и файлы?
• Удается ли завершить оплату?
• Удаётся ли собрать версию приложения для Android?
• Удаётся ли собрать версию приложения для iOS?

Только после того, как все эти аспекты будут работать корректно, стоит заняться новыми функциями. Новые API интересны для тестирования; регрессионное тестирование же помогает сохранить удовлетворённость пользователей.

Куда движется Expo

Если смотреть на SDK 58 в целом, направление развития важнее любой отдельной функции. Expo изначально был создан для того, чтобы сделать React Native более удобным в использовании, и постепенно превращается в полноценную платформу для разработки приложений:

• Expo Router для структуры приложения и навигации
• Expo Modules для работы с нативными API
• EAS Build для сборки приложений
• EAS Update для выпуска обновлений
• EAS Observe для мониторинга в производственной среде
• Expo UI для компонентов нативного интерфейса
• Виджеты и App Intents для интеграции с операционными системами
• Инструменты agent для разработки с использованием ИИ

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

Стоит ли обновляться сейчас?

Для производственного приложения сначала проведите тестирование, прежде чем делать коммиты. SDK 58 все еще находится в бета-версии, React Native 0.88 представлен как кандидат на выпуск, несколько новых API являются экспериментальными или альфа-версиями, и ожидается еще множество исправлений до стабильного выпуска.

Для побочного проекта, внутреннего инструмента или ветки миграции тестирование сейчас определенно стоит времени, особенно если вам нужна поддержка iOS 27 или хотите опередить изменения в React Native. Проблемы, обнаруженные во время бета-тестирования, все еще можно сообщить и исправить до стабильного выпуска, что гораздо проще, чем находить их после того, как все остальные уже обновились.

Единственная команда, которую нужно запомнить, — это та же, с которой вы начинаете:

npx expo install expo@next --fix

Запустите ее на ветке, а не в производственной среде.

Основные выводы

• Наиболее вероятно, что обновление нарушит работу в случае глубоких импортов, удаления таких API, как InteractionManager, пользовательского кода AppDelegate и пользовательских навигаторов Expo Router.
• Более быстрая сборка приложений для Android, более дешевые вызовы нативного кода и меньшее количество пересборок из-за изменений на устройстве предоставляются бесплатно с обновлением.
• Expo Modules 2.0, агент CLI, Device Hub и преобразователь Noxcturnal находятся в экспериментальной или бета-версии; оцените их, но пока не полагайтесь на них.
• expo-app-intents находится в альфа-версии, тогда как виджеты для Android делают возможными функции главного экрана для мультиплатформенных команд.
• Обновляйтесь на отдельной ветке, сначала протестируйте критически важные пользовательские процессы, а новые функции исследуйте только после того, как они пройдут проверку.