Shopify вернулся на native: агенты изменили цену второй кодовой базы

10 сентября 2026 года Shopify опубликовал пост «Native is now the future of mobile at Shopify»: компания уходит с React Native обратно на отдельные кодовые базы на Swift и Kotlin. Тред на Hacker News собрал 1262 очка за сутки — во многом потому, что это редкий жанр. Обычно публично объявляют выбор, а не его отмену.

Причина отмены названа прямо: изменилось одно допущение, на котором стояло решение 2020 года. Не язык стал лучше, не фреймворк испортился — подешевела работа, которой этот выбор избегал.

Но самое ценное в посте лежит не там, где его читали чаще всего. Shopify описал, как именно они заставили агентов писать код, который можно отправить в стор, — и начал с того, что наивный способ не работает.

Что именно отменили

В 2020 году Shopify перешёл на React Native по трём причинам, и в посте они перечислены без переписывания истории: не строить одну фичу дважды, дать разработчикам без мобильного опыта работать в мобильных приложениях, меньше времени тратить на догонку паритета между платформами. В январе 2025 года компания писала, что будущее React Native светлое и она продолжит в него вкладываться.

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

Хронология в посте своя, не задним числом: LLM в разработке у них с 2021 года — сначала фичи, баги и ревью; к концу 2025 года модели дошли до уровня, на котором вопрос «а правда ли писать дважды означает двойную работу» стал осмысленным. Прототипы на Swift и Kotlin показали, что агент реализует фичу на Android по iOS-версии как по образцу и обратно.

«Одним прогоном» не работает — это их слова

Дальше место, ради которого пост стоит читать целиком. Соблазн очевиден: направить модель на существующий React Native-код и попросить повторить те же экраны на Swift и Kotlin. Shopify сформулировал результат прямо: так не работает. И уточнил, что не работает даже усиленный вариант — попросить собрать максимум контекста заранее, заморозить его в спеки и файлы задач, и потом реализовывать. На выходе «огромное количество неподдерживаемого кода, который нельзя отправить».

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

Что вместо этого: воротца на каждом шаге

Система называется Helix и устроена как цикл, который не пропускает несовершенный результат дальше, пока он не станет хорошим.

Разработчик показывает Helix экран. Система читает код React Native и предлагает последовательность чекпойнтов — маленьких упорядоченных ломтей работы, каждый из которых проверяется за минуты. Дальше по одному чекпойнту: каждый обязан доказать поведение тестами, совпасть с работающим приложением в визуальном ревью, пережить двух состязательных ревьюеров кода и получить кивок человека — и только после этого коммитится, а цикл переходит к следующему. Замечания всех ревью запоминаются, поэтому по ходу миграции цикл становится автономнее.

Обратите внимание на порядок: ворота стоят до коммита, а человек — последним, а не первым. Автономность здесь не выдана авансом, а накапливается из зафиксированных замечаний.

Узкое место оказалось не в модели

Вторая половина поста — про скорость обратной связи, и это самая переносимая его часть. Агентное управление симуляторами было у них горлышком: инструменты читают состояние приложения через дерево доступности или скриншоты, и это медленно и хрупко. Формулировка Shopify: агент меняет код за секунды, а на проверку результата уходят минуты. Вывод, который они из этого сделали, стоит выписать целиком — «неважно, насколько хороша модель, если она не может быстро проверить свою работу».

Лечили это архитектурой, а не моделью. Принцип: бизнес-логика полностью отделена от UI и запускается headless на десктопе. Дальше она отдаётся агентам через CLI, который позволяет смотреть состояние приложения, переходить между разделами и выполнять действия, не касаясь интерфейса, — миллисекунды вместо минут. По их словам, после этого агенты работают автономно часами. Когда симулятор всё-таки нужен, тот же CLI подключается к нему в удалённом режиме и управляет UI командами, без разбора вёрстки и дерева доступности.

Чего в посте нет

Цифр почти нет — и это честно оговаривать. Единственная измеримая: приложение Shop прошло путь от proof of concept до полностью переписанного native-приложения, опубликованного в сторах, за 12 недель. Главное приложение Shopify — 300+ экранов, виджеты, приложение для Apple Watch, комплики, Siri Shortcuts — в работе и выйдет позже в этом году; миграцию выбрали greenfield, а не постепенную, хотя в 2020-м на React Native переезжали как раз постепенно.

Успех обещают измерять потом: скоростью продукта, качеством приложений и долей работы, которую агенты делают автономно. То есть заявление о выигрыше пока не подкреплено замером — подкреплён только факт, что они на это решились после прототипов.

В треде на Hacker News автор поста ответил на вопрос о переучивании: команды на native подтягивали заранее, до того как идти всё-ин. Это стоит держать как реплику в треде, а не как часть публикации. Там же звучит и разумное возражение: у маленькой команды расчёт другой — выбор стоит не между одной и двумя кодовыми базами, а между кросс-платформой и отсутствием приложения вообще. Shopify описывает свой расчёт, а не универсальный.

Что из этого забрать

• Перепроверять решения, у которых сменилось допущение, а не те, которые надоели. Shopify отменил успешное решение, назвав ровно один изменившийся вход.
• Не планировать миграцию как один прогон агента. Их вывод: даже с замороженными спеками получается неотправляемый код.
• Ставить ворота до коммита и человека последним. Тесты, визуальное сравнение с работающей версией, состязательное ревью, кивок — и только потом следующий ломоть.
• Мерить задержку обратной связи агента так же серьёзно, как качество модели. Если проверка идёт минуты, дорогая модель не поможет.
• Делать бизнес-логику запускаемой без UI. Это единственный пункт списка, который меняет архитектуру, — и именно он у них превратил минуты в миллисекунды.