Чому відхід Shopify від React Native не становить загрози для Expo
Пояснює, чому перехід Shopify від React Native до нативних мов Swift та Kotlin не означає кінець розробки в мультиплатформному середовищі Expo для більшості команд.
10 вересня 2026 року Shopify оголосила, що виймає свої основні мобільні додатки з React Native та перебудовує їх нативно за допомогою Swift та Kotlin. Протягом кількох годин форуми розробників заповнилися припущеннями. У тредах у соціальних мережах велися дискусії щодо того, чи означає це кінець React Native. Деякі блог-пости навіть стверджували, що розробка мобільних додатків для кількох платформ завершилась.
Якщо ви розробляєте за допомогою Expo, усе це не повинно вас турбувати.
Що насправді зробила Shopify — та чому
Обґрунтування Shopify було досить простим: асистенти з кодування на основі ШІ значно скоротили витрати на підтримку двох окремих нативних кодових баз для iOS та Android. Початковою перевагою React Native була економія часу інженерів завдяки спільному використанню коду між платформами. Однак коли інструменти ШІ можуть швидко генерувати нативний код на Swift та Kotlin, цей підхід втрачає актуальність для організації такого розміру, як Shopify.
Ключовою деталлю є «організація такого розміру, як Shopify».
Shopify використовує одне з найскладніших мобільних додатків у світі — з сотнями інженерів, мільйонами продавців та вимогами до продуктивності, які ставлять під сумнів будь-яку фреймворк-систему. Коли Shopify стверджує, що штучний інтелект зробив розробку нативного коду доступнішою, вона говорить з позиції компанії, яка може одночасно керувати двома великими, складними кодовими базами.
Більшість розробників Expo не знаходяться в такій ситуації, як і звичайні команди, які сьогодні створюють додатки.
Expo та Shopify вирішують різні проблеми
Для Shopify React Native був насамперед способом скоротити витрати у величезній інженерній організації. Для розробників Expo цей інструмент дозволяє окремому розробнику чи невеликій команді створювати повноцінний, досконалий додаток як для iOS, так і для Android, не потребуючи спеціалізації на жодній з нативних платформ.
У цих двох сценаріях використання майже немає спільного.
У Expo є окрема основна команда, яка роками працює над вдосконаленням одного з найкращих досвідів розробки для мобільних пристроїв. Нещодавно випущений SDK 57 приніс ще більше покращень у продуктивності, інструментах для створення додатків та зручності роботи розробників щодня. Бібліотеки на кшталт NativeWind, Reanimated та Expo Router стали більш стабільними та готовими до використання у реальних проектах, ніж будь-коли раніше.
Усе це не зміниться лише через те, що один великий ритейлер вирішив перейти на інший інструмент.
Цифри розповідають іншу історію
Поки коментатори займалися тим, що оголошували про завершення розвитку React Native, дані щодо його використання показували протилежне.
NativeWind – інструмент стилю у стилі Tailwind CSS для React Native – у 2026 році досяг 1,3 мільйона щотижневих завантажень та продовжував зростати. Expo залишається активним у спільнотах розробників та обговореннях. Нові бібліотеки стилю, такі як Uniwind, з’явилися та за кілька місяців набрали сотні тисяч щотижневих завантажень.
Ці цифри не свідчать про скорочення екосистеми. Вони показують, що вона все ще розвивається.
Ті, хто покинули React Native одразу після оголошення Shopify, ймовірно, були тими самими людьми, які все одно знайшли б якусь іншу причину для відходу наступного місяця. Розробники, які справді створюють продукти за допомогою Expo, не збираються щось переглядати.
Штучний інтелект прискорює розробку в Expo, а не робить її застарілою
У твердженні про те, що штучний інтелект знищив React Native, криється справжня іронія: інструменти на основі штучного інтелекту насправді значно покращили процес розробки з використанням Expo, а не погіршили його.
Асистенти на кшталт Claude, Cursor та GitHub Copilot добре розуміють екосистему Expo. Якщо у вас є добре організований файл CLAUDE.md, який описує конвенції компонентів та архітектурні патерни, один із цих асистентів може додавати нові екрани, розробляти функції та переробляти існуючий код, залишаючись у злагоді з рештою вашої кодової бази.
Люди, які отримують найбільшу користь від цього робочого процесу, який іноді називають „кодувальниками атмосфери“, оскільки вони описують бажаний результат та дозволяють асистенту займатися реалізацією, все одно потребують міцної початкової структури. Інструменти ШІ чудово справляються з написанням коду. Проте вони значно менш надійні у прийнятті архітектурних рішень, проєктуванні логіки навігації, створенні систем тем або формуванні послідовного набору спільних компонентів з нуля.
Саме цю прогалину заповнює добре створений початковий шаблон Expo. Йдеться не про код, який асистент ШІ міг би генерувати за запитом, — а про основну структуру, яка робить кодування за допомогою ШІ справді продуктивним.
Шаблони — це базовий рівень для розробки за допомогою ШІ
Коли розробник відкриває Cursor або Claude, щоб створити новий додаток, перше справжнє питання — з якої кодової бази він починає роботу.
Початок роботи з порожнього результату команди create-expo-app означає, що ви будете перші кілька годин присвячувати налаштуванню навігації, додаванню підтримки темного режиму, створенню базових компонентів інтерфейсу та визначенню стандартів. Штучний інтелект може допомогти з частиною цієї роботи, але все одно потрібні людські рішення, налаштування та постійна корекція, перш ніж у вас з’явиться придатна основа.
Якщо ж починати з готового шаблону для продакшну, то підготовча робота вже завершена. Ви відкриваєте редактор на основі ШІ, описуєте функцію, яку хочете додати, і асистент має послідовну, добре організовану базу коду для розширення.
Саме тому сьогодні шаблони, розроблені з урахуванням робочих процесів за допомогою ШІ — з детальною документацією у форматі CLAUDE.md, чіткими примітками до компонентів та послідовними шаблонами — мають ще більше значення, ніж два роки тому, а не менше.
Розробники, яким справді варто хвилюватися
Якщо щось і має налякати користувачів Shopify, то це розробники, які створюють прості додатки на React Native поза екосистемою Expo, спираючись безпосередньо на React Native CLI, та орієнтуються на клієнтів великого масштабу, у яких є достатньо інженерів для фінансування повноцінного розроблення нативних додатків.
Це стосується досить вузької групи серед усіх, хто використовує React Native.
Якщо ж ви — фрілансер, невелика студія чи хтось, хто створює свій перший додаток, переважно описуючи його для AI-асистента, то Expo залишається найшвидшим шляхом від ідеї до готового додатку на обох основних мобільних платформах. Рішення Shopify нічого не змінює в цьому.
Що це означає для вас
Продовжуйте розробляти з Expo. Продовжуйте випускати продукти за допомогою Expo. Екосистема знаходиться у гарній формі, інструменти постійно вдосконалюються з кожним новим випуском, а спільнота навколо неї не зникає.
Якщо ви починаєте новий проект React Native, почніть з готової до використання шаблонної структури, а не з порожнього проекту, і дозвольте AI-асистентам займатися деталями реалізації на цій основі. Таке поєднання дозволяє випускати продукти швидше, ніж це можливо при розробці з нуля.
Деякі розробники протягом наступних тижнів будуть читати суперечливі думки та переосмислювати свої технологічні вибори через оголошення однієї компанії. Інші ж просто продовжуватимуть випускати свої додатки.
Прагніть належати до другої групи.
Пов’язана література
- Nitro Modules: Як статичні зв’язки перевершують React Native TurboModules — Пояснює, як Nitro Modules використовують заздалегідь скомпільовані статичні зв’язки замість динамічних пошуків, що дозволяє значно перевершувати TurboModules та Expo Modules у React Native.
- React Native, Flutter та інші: мобільні додатки крос-платформного типу у 2026 році — Порівняльний аналіз React Native, Flutter, Kotlin Multiplatform, Ionic, NativeScript та PWA з точки зору продуктивності, досвіду розробника та зрілості екосистеми.