Shopify повертається до нативного коду: чому React Native поступився AI-агентам

У 2020-му Shopify публічно оголосив all-in на React Native — і це був один із найвідоміших кейсів великої компанії на крос-платформній розробці. У вересні 2026-го та сама компанія оголосила зворотний хід: усі мобільні додатки — Shop, Shopify, Point of Sale, Inbox — мігрують на нативні Swift і Kotlin. І головна причина не в якості фреймворку, а в тому, що LLM-агенти знецінили основний аргумент за спільну кодову базу.

Чому в 2020 обрали React Native

Три причини: не писати ту саму фічу двічі, дозволити розробникам працювати через увесь стек і не гнатися вічно за паритетом платформ. React Native це справді дав — інженери без мобільного бекграунду контрибутили в додатки, а Shopify перестав хронічно відставати на одній із платформ. Ще у січні 2025-го компанія писала, що майбутнє React Native «яскраве» — і це була щира позиція на той момент.

Що змінилося? Моделі для коду стали суттєво кращими. Shopify перевірив це практикою: перебудував кілька ключових частин найбільших додатків у Swift і Kotlin за допомогою агентів — і був здивований, наскільки це працює. Агенти реалізовували фічу на Android, маючи за референс iOS-версію, і навпаки; допомагали розробникам швидко вкатуватись у чужий стек; різко здешевили підтримку паритету через спільні специфікації, тести й ревʼю-чекпоінти.

Нативна розробка досі означає підтримку двох платформ — ця ціна нікуди не зникла. Але агенти тепер роблять достатньо багато реалізації, перекладу, тестування й ревʼю, щоб вона більше не була вирішальним фактором, як у 2020-му.

Важливий нюанс, який часто втрачається в переказах: Shopify не каже, що React Native поганий. «React Native-додатки можуть бути швидкими. Наші — швидкі». Рішення суто про зміну балансу trade-offʼів: переваги спільної реалізації зменшились, а переваги нативної розробки нікуди не дінись — близькість до платформених можливостей, first-party тулкінг, менше шарів між кодом і платформою.

Що буде з відкритими бібліотеками

У Shopify одні з найпопулярніших бібліотек екосистеми React Native, і компанія детально розписала їхню долю:

• React Native Skia — спонсорство до кінця 2026-го, далі William Candillon продовжить роботу: форкне репозиторій і видаватиме бібліотеку під новою назвою. Оригінальний репозиторій архівують.
• FlashList (~2 млн завантажень на тиждень) — Shopify продовжить фіксити критичні issues, що ламають сумісність, і зараз шукає компанію для довгострокового опікунства.
• Restyle — репозиторій архівують; підтримка до кінця 2026-го, далі форк на розсуд спільноти.

Greenfield замість brownfield

Класична мудрість міграцій — не переписувати з нуля, а переїжджати поступово. Минулого разу Shopify саме так і робив. Цього разу переміг greenfield — повний rebuild, і знову ж через агентів: їм добре дається будувати фічі в Swift і Kotlin, маючи React Native-версію за референс; чистий аркуш дозволяє перебудувати додаток без старих обмежень; прототипи показали, що з агентами rebuild суттєво швидший, ніж будь-коли раніше.

Першим переїхав Shop app — регулярний топ шопінг-категорії в сторах. Від proof of concept до повністю нативного додатка в сторах команда пройшла за 12 тижнів. Міграція найбільшого додатка Shopify (300+ екранів, віджети home/lockscreen, Apple Watch, Siri Shortcuts) вже триває й вийде цього року.

Що дала міграція Shop: цифри

Нативна версія Shop проти React Native-попередника:

Холодний старт на iOS швидший на 23%, на Android — на 50%. Розмір Android-білда впав на 109 МБ (−37%), на iOS — практично без змін (+1 МБ). Android release-білди збираються на ~75% швидше. Найвражаюча цифра — стабільність: історичні 99.5%+ session stability зросли до 99.95%+, тобто крашів сесій стало у 10 разів менше. А Android-версія досягає 120 FPS при скролі фіду — і це, за словами команди, «мінімум оптимізацій».

Helix: як не дати агентам генерувати сміття

Найцікавіша частина посту — чесне визнання, що підхід «покажи LLM кодову базу й one-shot перепиши» не працює: навіть із замороженими спеками виходить величезна кількість коду, який неможливо вичерпати. Натомість Shopify побудував систему Helix із поступовим підходом. Розробник вказує на екран, Helix читає React Native код і пропонує послідовність маленьких чекпоинтів, які можна відревʼювати за хвилини. Кожен чекпоинт мусить довести поведінку тестами, збігтися з робочим додатком на візуальному ревʼю, пережити двох adversarial ревʼюверів-агентів і отримати згоду людини — лише тоді він комітиться і починається наступний. Фідбек з кожного ревʼю запамʼятається, тож цикл стає автономнішим із часом.

Головний інженерний урок: швидкі фідбек-лупи

Друга велика тема — агенти генерують код за секунди, але тестують його хвилинами: симулятори повільні й крихкі через залежність від accessibility tree і скріншоти. Shopify вирішив це архітектурно: бізнес-логіка повністю відʼєднана від UI і здатна запускатись headlessly на десктопі. Агенти працюють із нею через CLI, який дозволяє інспектувати стан додатка, навігувати між секціями і виконувати дії за мілісекунди — без симуляторів. Коли потрібна взаємодія з UI, CLI підключається до симулятора в remote-режимі й керує ним командами, без парсингу дерева доступності. Результат — агенти автономно працюють годинами.

Що це означає для екосистеми

Shopify — компанія, чия публікація 2020-го була головним аргументом «React Native — серйозна технологія для enterprise». Тепер та сама компанія фактично каже: спільна кодова база — це оптимізація дефіциту інженерних годин, а коли агенти здешевили реалізацію, оптимізувати вже нічого. Це не «React Native помер» — фреймворк залишився хорошим, а Shopify продовжує підтримувати критичні бібліотеки. Але це перший гучний сигнал, що розрахунок «build once, run everywhere» змінився під впливом агентів, і інші компанії точно перераховуватимуть свої trade-offʼи так само.