Shopify возвращается с React Native на нативный код: LLM изменили всё

Модели стали намного лучше генерировать нативные iOS-приложения. Основная привлекательность RN была в возможности задействовать ваших веб-разработчиков для мобильной разработки. Именно так я делал в своей последней компании. И для стартапа это нормально, но в конце концов вы захотите выделенных нативных инженеров, потому что каждая платформа действительно заслуживает своих технических мастеров, которые могут оптимизировать под неё.

Но теперь, когда весь код генерируется, мало смысла иметь RN-приложение... просто начинайте с нативного. Ваши разработчики всё равно почти не будут писать код.

Мы сделали то же самое — 90% было готово за ночь. Потом потратили несколько дней на фоне на доработку для полировки.

Наше приложение меньше, в нём около 15-20 экранов. Я начал примерно в 12:30 ночи, дал codex цель, и он провёл инвентаризацию каждого экрана на основе кода React Native, затем создал директории android и iOS, использовал maestro (я уже настроил этот инструментарий для предыдущей сборки личного приложения за несколько недель до этого), и к утру всё работало на android и iOS. Ушло около 6 часов, пока я спал.

Приложение гораздо меньше, запускается мгновенно, а android-приложение (якобы) выглядит нативно. Говорю «якобы», потому что я не пользуюсь android-телефонами. Но там используется Jetpack Compose и Kotlin.

И я не знаю Swift или Kotlin. Честно говоря, я больше не вижу смысла в React Native. Я знаю, что Expo делает очень крутые агентные штуки, но я просто не уверен, зачем мне всё это, когда я могу написать нативное приложение.

Я сижу здесь за столом с видом на Cordova Street. Улицу, в честь которой назван Apache Cordova. Я наблюдаю этот спор уже почти два десятилетия.

Команды прыгают на новейший кросс-платформенный фреймворк, предполагая, что это снизит затраты на персонал за счёт получения приложения по самому низкому общему знаменателю на каждой платформе.

Последнее верно, но первое — нет.

В итоге происходит следующее: команды начинают с 20 iOS-инженеров и 20 Android-инженеров. Они внедряют что-то вроде React Native. Затем у вас получается команда из 20 продуктовых инженеров и 20 инженеров по инструментам и фреймворкам.

Я видел это бесчисленное количество раз за последние два десятилетия.

Мы не держимся за решение только потому, что оно было успешным в то время. Когда ключевое предположение меняется, мы готовы вернуться и спросить, остаётся ли это правильным выбором. LLM изменили одно из ключевых предположений, лежавших в основе нашего решения 2020 года, поэтому мы пересмотрели наш мобильный стек с первых принципов.

То, что мы обнаружили, привело нас обратно к нативному коду.

Я согласен с советом людям уходить с React Native, хотя я думаю, что история о том, что «LLM позволили рассмотреть миграцию, которая иначе была бы слишком дорогой», неверна.

Я говорю это, потому что я был частью миграции с React Native-приложения среднего размера на нативное приложение на Swift/Kotlin. Я выполнил большую часть технической работы над этим. Большая часть работы была проделана до января 2026 года и без помощи LLM в написании кода, хотя более поздние функции в приложении определённо использовали некоторые из них.

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

Всё это к тому, что это решение стоит рассматривать даже без учёта помощи LLM.

Вчера, прямо перед сном, я направил Astra на наше Electron-приложение для десктопа и попросил написать мне нативное Swift-приложение для iOS.

В Electron-приложении 750 юнит-тестов и около 50 интеграционных тестов. У него также был доступ к Electron-приложению через mcp, и он мог кликать и осматривать его. Я также дал Astra доступ только для чтения к коду бэкенда.

Он работал 3 часа и выдал почти полностью функциональный порт. Сегодня я при ручном тестировании нашёл 3 бага и 1 проблему с производительностью, все из которых он затем исправил. Чтобы исправить проблему с производительностью, он сделал несколько разных сборок и профилировал их с помощью Xcode.

Примерно в 12:30 у меня был полный нативный порт нашего продукта на iPhone и iPad, и я мог показать его своей команде. Он даже правильно сделал портретную и ландшафтную ориентацию!

Излишне говорить, что я был ошеломлён. С одной стороны, мне это нравится, теперь я могу создавать все эти классные штуки, но с другой стороны, это полное обесценивание моего ремесла. Я как-то говорю себе, что всё равно именно я настраивал для него подходящее окружение и что не каждый может это сделать. Но это самоуспокоение. Чёртово самоуспокоение… и я это знаю.

А я просто сижу здесь, смотрю на десктопное приложение Codex для Mac и задаюсь вопросом, почему список, окно чата и текстовое поле требуют загрузки в 579 МБ (сжатых) и 4 ГБ оперативной памяти.

Я не совсем понимаю часть про симулятор(ы), вероятно, потому что я никогда на самом деле не занимался мобильной разработкой.

> Когда требуется взаимодействие с симулятором, CLI может подключаться к ним через удалённый режим и управлять UI с помощью команд, без необходимости инспектировать макет или дерево доступности. Это обеспечивает молниеносную производительность и E2E-тесты.

Кажется, я не улавливаю. Разве вам всё ещё не нужно тестировать дерево доступности и макет на том самом слое, с которым будет взаимодействовать пользователь?

Отказаться от React и вернуться к чистому JavaScript следующим?

Я всё ещё оплакиваю GitHub до React. Может, это розовые очки, но им было так приятно пользоваться.