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

Expo SDK 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 керував усім додатком: одне вікно, один набір функцій запуску та обробки подій у першому плані. Модель сцен розділяє ці обов’язки, тож кожна інстанція UI (сцена) має власний цикл життя, яким керує делегат сцени. Обов’язки, які раніше були у делегаті додатку — наприклад, реакція на активування додатку чи обробка надісланих 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 пропускає більшу частину цього кроку.

У середовищі 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 виконує відповідне завдання та ініціює дію, оголошену вашим додатком. Ваш код на 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 супроводжується візуальним прикладом. Без скріншотів вибір компонента інтерфейсу часто призводить до фруструючого циклу:

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, які може відхилити Strict TypeScript API. Також перевірте папку 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

Версії Node.js, які підтримує Expo, оновилися. Перевірте своє локальне середовище та образи 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 для компонентів нативного інтерфейсу
• widgets та 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, користувацький код та власні навігатори Expo Router.
• Швидше створення проектів для Android, дешевші виклики нативних функцій та менше перезапусків після змін у системі входу надаються безкоштовно разом із оновленням.
• Expo Modules 2.0, агент CLI, Device Hub та Noxcturnal transformer є експериментальними або бета-версіями; оцініть їх, але поки що не покладайтеся на них.
• expo-app-intents знаходиться у стадії альфа, тоді як віджети для Android роблять функції головного екрана придатними для команд, що працюють у крос-платформеному середовищі.
• Оновлюйтесь у спеціальній гілці, спочатку протестуйте критичні сценарії використання, а нові функції досліджуйте лише після їх перевірки.