Shopify уходит с React Native: что это значит для Flutter
В 2020 году Shopify сделал полную ставку на React Native, в прошлом году закончил переводить свои приложения — а в сентябре 2026-го объявил, что возвращается к нативным Swift и Kotlin. Это не наш стек, но причина — кодовые агенты, а агенты меняют то, что вообще важно при выборе фреймворка. Я делаю фулстек-фреймворк на Dart и уже знаю, что приложения на нём буду писать не я: их будут писать агенты. Это меняет цену каждого технического решения, и Shopify — наглядный тому пример.
Что произошло
В 2020 году Shopify поставил на React Native: одна кодовая база, меньше издержек. В январе 2025-го их руководитель мобильной разработки писал, что у React Native светлое будущее. 10 сентября 2026 года тот же человек опубликовал Native is now the future of mobile at Shopify. Приложение Shop уже переписано и лежит в сторах; основное приложение Shopify — больше 300 экранов, виджеты, приложение для Apple Watch, Siri Shortcuts — выйдет позже в этом году.
Они не говорят, что React Native был ошибкой. Они говорят, что в 2020 году это был правильный выбор, а условия изменились.
Что дал нативный код
Из поста о миграции приложения Shop:
| React Native | Нативно | Изменение | |
|---|---|---|---|
| Холодный старт, Android | 4433 мс | 2233 мс | −50% |
| Холодный старт, iOS | 3200 мс | 2466 мс | −23% |
| Размер приложения, Android | 293 МБ | 184 МБ | −37% |
| Размер приложения, iOS | +1 МБ | ||
| Сессии без падений | 99,5% | 99,95% | в 10 раз меньше падающих сессий |
| Время release-сборки под Android | −75% |
Шесть основных инженеров, двенадцать недель от прототипа до сторов. Сам прототип занял у одного инженера одну неделю.
Преимущества нативного кода были известны всегда. Просто они всегда выглядели мелочью — чуть быстрее запуск, чуть меньше сборка, на пару платформенных багов меньше — на фоне стоимости того, чтобы делать всё дважды.
Почему именно сейчас
Держать две кодовые базы раньше означало держать две полноценные команды разработки. Теперь большую часть кода пишут агенты, и они же могут взять на себя обслуживающую работу: проверить, что фича ведёт себя одинаково на обеих платформах, сравнить, верифицировать. Shopify формулирует это так:
Native still means building and maintaining software on two platforms, that cost has not disappeared. What changed is that agents can now do enough of the implementation, translation, testing, and review work that it's no longer the deciding factor it was in 2020.
То же самое происходит везде. С агентами можно перенести почти любую библиотеку на свой стек или переписать целый фреймворк — и сделать это быстро. Это меняет то, что считается хорошим или плохим техническим решением.
Как они это сделали
Интересно не само решение, а то, как доверить переписывание такого масштаба агентам в компании, где любая ошибка стоит реальных денег. Они не просто сказали модели переписать приложение. Они построили конвейер.
Логика отделена от UI. Бизнес-логику отделили от интерфейса настолько чисто, что она работает headless, на десктопной машине. Агенты тестировали её через CLI и консольные тесты — посмотреть состояние приложения, перейти куда-то, выполнить действие — за миллисекунды, не поднимая эмулятор. UI проверяли отдельно: новые экраны сравнивали по скриншотам с работающим React Native-приложением в тех же контрольных точках. Их инструмент для этого, Tardis, ещё и собирал события аналитики в обоих приложениях, чтобы агенты могли сравнить названия событий, их количество и полезную нагрузку.
Маленькие чекпойнты. Их система Helix режет экран на маленькие упорядоченные куски, каждый из которых можно отревьюить за минуты. Каждый кусок должен подтвердить своё поведение тестами, совпасть с работающим приложением на визуальном ревью, пройти двух состязательных код-ревьюеров и получить одобрение человека — и только тогда попадает в коммит. Замечания с ревью запоминаются, так что по ходу миграции циклу нужно всё меньше помощи.
Где агенты не справились. Даже внутри такого конвейера сгенерированный код приносил дублирование, архитектурный дрейф и проблемы с производительностью. Shopify прямо говорит, что нативная экспертиза осталась необходимой — всё это сработало только потому, что код ревьюила команда нативных экспертов.
Что остаётся за цифрами
Несколько вещей в видео не поместились:
- Сравнение идёт со старой архитектурой React Native. В комментариях отметили, что никто не знает, какие были бы цифры у New Architecture — а переход на неё был крупным рефакторингом, который Shopify всё равно предстоял.
- Это был перенос, а не новый продукт. У агентов было работающее приложение, которое можно читать и с которым можно сравнивать. Shopify говорит, что агенты работали лучше всего именно там, где была готовая реализация; разработка чего-то нового так не ускоряется.
- Две платформы теперь навсегда. Паритет функциональности «всё время», два ревью, два релиза — и никаких обновлений по воздуху в обход стора.
Стоит ли беспокоиться Flutter-разработчикам?
Думаю, нет — я в этом вполне уверен.
Это ещё один пример того, как агенты делают возможным чуть больше. Крупнейшие техкомпании всегда писали нативно, с параллельными командами под каждую платформу, и в кроссплатформу не уходили. Shopify — большая компания, но не настолько; агенты позволили ей работать по стандартам компаний с более сильными командами разработки. Это тот же сдвиг, что и возможность небольшого бизнеса сделать своё приложение, на которое раньше нужна была средняя компания. Стоимость достижения того же результата падает — на каждом уровне.
И переписывание — это боль в любом случае. Большинству компаний оно просто не стоит того: гораздо лучше вложить силы в продукт — новые фичи, более высокое качество, — чем гоняться за последним процентом багов и выжимать мегабайты из сборки. Выигрыш, который получил Shopify, для большинства команд значит куда меньше.
Так что я не ожидаю, что это заметно сдвинет рынок труда, а Flutter — и того меньше. На мой взгляд Flutter сильно впереди React Native, поэтому от таких трендов страдает меньше.
Что я из этого забираю — тот же урок, который изменил мою собственную работу: недавно я довольно радикально переписал свой фреймворк именно потому, что стал доверять агентам очень большие задачи за короткое время. Говорит ли кто-то вокруг вас о переходе с одного стека на другой с помощью агентов?
Видеоверсия, на русском, — на YouTube.