Shopify возвращается от React Native к отдельным приложениям на Swift и Kotlin не потому, что кроссплатформенный фреймворк оказался неудачным. Компания утверждает обратное: React Native был хорошим выбором в течение шести лет. Изменилось другое — стоимость поддержки двух платформ перестала быть главным ограничением, потому что coding agents теперь могут брать на себя заметную часть реализации, переноса логики, тестирования и ревью.
Это важный поворот в разговоре о мобильной разработке. Обычно выбор между native и кроссплатформенным стеком описывают как спор о производительности интерфейса, размере команды или скорости выпуска. В случае Shopify главный аргумент находится на другом уровне: меняется не мобильная платформа, а цена инженерной координации вокруг неё.
В 2020 году компания выбрала React Native по трём причинам: не писать одинаковые функции дважды, дать разработчикам возможность работать на разных участках стека и тратить меньше времени на выравнивание возможностей iOS и Android. В 2026 году эти причины не исчезли. Но, по оценке Shopify, часть работы, ради которой требовалась единая кодовая база, теперь можно делегировать агентам.
Это не доказательство того, что native снова станет универсальным будущим мобильной разработки. Скорее, это сигнал: при достаточно большой кодовой базе и зрелом процессе AI отдельные платформенные приложения могут стать дешевле и гибче, чем единый слой абстракции.
Что именно меняет Shopify
Компания намерена перейти от React Native к двум нативным кодовым базам: Swift для iOS и Kotlin для Android. Важно не перепутать этот шаг с полным отказом от общей логики или общих продуктов. Из имеющихся материалов следует более узкий вывод: Shopify меняет основной способ создания нативных приложений и снова принимает расходы, связанные с поддержкой двух платформ.
Эти расходы никуда не исчезают. Их перечисление довольно прозаично:
- одну функцию нужно спроектировать с учётом двух платформ;
- поведение интерфейса требуется реализовать и проверить отдельно;
- ошибки могут возникать только на iOS или только на Android;
- разработчикам приходится поддерживать два набора тестов и инструментов;
- продуктовая команда должна следить за тем, чтобы версии функций не расходились.
В 2020 году именно эта цена делала React Native привлекательным. Общий JavaScript-слой позволял уменьшить дублирование и быстрее доставлять одинаковые возможности пользователям двух платформ.
Теперь Shopify считает, что coding agents способны сократить часть ручной работы. Агент может помочь реализовать функцию на одной платформе, перевести её на другую, написать тесты, найти расхождения и подготовить изменения к проверке. Это не превращает Swift и Kotlin в один язык. Но уменьшает объём механического труда, который раньше был главным аргументом за общий слой.
Здесь есть принципиальная оговорка: Shopify не говорит, что агенты устранили стоимость двух приложений. Компания прямо признаёт, что native по-прежнему означает разработку и поддержку программного обеспечения для двух платформ. Изменился не сам объект затрат, а его доля в общей экономике проекта.
React Native не проиграл технологическую войну
Самая слабая интерпретация новости — объявить её поражением React Native. Она противоречит исходному тезису Shopify. Компания описывает фреймворк как удачный для периода, когда его использовала, а переход объясняет изменившимися инструментами разработки.
Это различие важно для архитектурных решений. Технология может быть правильной в 2020 году и перестать быть оптимальной в 2026-м без того, чтобы за это время стать плохой. У React Native остаются очевидные преимущества:
- общий слой для значительной части продуктовой логики;
- возможность быстрее синхронизировать функциональность;
- более низкий порог перехода между веб-разработкой и мобильной;
- развитая экосистема библиотек;
- меньшая вероятность, что базовая функция появится на одной платформе значительно раньше другой.
Но у общей кодовой базы есть и обратная сторона. Она не устраняет различия между операционными системами, а часто переносит их в слой интеграций и исключений. Чем сложнее приложение, тем больше команда должна понимать границы абстракции: навигацию, фоновые задачи, системные разрешения, платежи, производительность списков, доступность и особенности жизненного цикла приложения.
Native-разработка, напротив, делает различия явными. Команда платит за дублирование, но получает прямой доступ к платформенным API и может проектировать интерфейс в соответствии с правилами iOS и Android, а не искать общий компромисс.
Поэтому вопрос не в том, какая технология «лучше вообще». Вопрос звучит иначе: где сейчас находится самая дорогая часть работы — в написании двух реализаций или в обслуживании абстракции, которая должна удерживать две платформы в синхронном состоянии?
Новая экономика дублирования
Полезно разложить аргумент Shopify на простую модель. Пусть функцию нужно выпустить на iOS и Android.
При React Native затраты выглядят примерно так:
общая реализация;
адаптеры к платформенным возможностям;
3. тестирование на обеих системах;
4. исправление платформенных расхождений;
5. поддержка библиотек и версии фреймворка.
При native-подходе список меняется:
реализация на Swift;
реализация на Kotlin;
3. два набора тестов;
4. отдельное исправление ошибок;
5. синхронизация продуктового поведения;
6. поддержка двух стеков.
В 2020 году второй список был очевидно тяжелее для многих команд. В 2026 году coding agents могут уменьшить расходы в пунктах 2–4: подготовить вторую реализацию по образцу первой, сгенерировать типовые тесты и найти часть несовпадений.
Редакционный расчёт здесь не является измерением Shopify, а показывает, почему изменение может быть экономически рациональным. Предположим, ручная реализация функции на двух платформах требует 100 условных инженерных единиц: 55 на первую платформу, 35 на вторую и 10 на синхронизацию и проверку. Если агент сокращает только механическую часть второй реализации и подготовки тестов на 40%, общая экономия составит не 40% проекта, а примерно 14% от исходной работы. Основная архитектурная и продуктовая сложность останется.
Это одновременно объясняет и потенциал, и ограничения подхода. Агент не делает две платформы одной платформой. Он уменьшает цену повторяемых операций. Чем больше в задаче стандартного кода и чем лучше описаны требования, тем выше выигрыш. Чем больше продукт зависит от нестандартного поведения, тем важнее человеческая экспертиза и реальные устройства.
Для крупного бизнеса даже небольшое сокращение повторяемой работы может быть значимым. Но переносить этот вывод на небольшую команду без расчёта нельзя. Если приложение состоит из нескольких экранов и редко меняется, дополнительная native-реализация может не окупиться. Если же команда годами поддерживает сложный продукт, а общий слой регулярно сталкивается с платформенными исключениями, баланс может быть другим.
Главный риск — не генерация, а проверка
В описании Shopify агенты участвуют не только в написании кода, но и в реализации, переводе, тестировании и ревью. Именно последние два пункта определяют, станет ли новая схема надёжнее.
Сгенерировать похожий экран на Swift после реализации на Kotlin сравнительно просто. Доказать, что он ведёт себя одинаково во всех важных сценариях, значительно сложнее. Сюда входят:
- восстановление состояния после выгрузки приложения;
- работа без сети и повторная отправка данных;
- разные размеры экранов и системные шрифты;
- жесты, клавиатура и системная навигация;
- доступность;
- разрешения и ограничения фоновой работы;
- ошибки оплаты или синхронизации;
- миграции данных между версиями.
Coding agent может предложить тесты, но качество результата зависит от того, насколько хорошо команда описала ожидаемое поведение. Если спецификация неполна, агент обычно воспроизводит неявные предположения из существующего кода. В итоге две реализации могут быть синтаксически корректными и даже покрыты тестами, но расходиться в редких сценариях.
Именно поэтому переход к native требует не просто доступа к модели, а инженерного «обвеса»: единых контрактов, тестовых фикстур, снимков интерфейса, проверок на реальных устройствах, автоматического сравнения поведения и понятного процесса ревью. В подборке материалов об agent harness этот слой описывается как инфраструктура вокруг агента: доставка контекста, интерфейсы инструментов, артефакты планирования, циклы верификации, память и песочницы.
Для мобильной разработки это означает практическое правило: агент должен получать не только задачу «перепиши экран на Kotlin», но и контракт — состояния, ограничения, события, ошибки, требования доступности и критерии готовности. Без этого автоматизация ускорит появление кода, но не обязательно ускорит выпуск работающей функции.
Что происходит с экосистемой React Native
Переход Shopify затрагивает не только внутренние приложения. Компания была сопровождающей стороной для трёх заметных библиотек React Native: react-native-skia, FlashList и Restyle.
По сообщению из исходного материала, у первых двух библиотек появятся новые владельцы. Restyle планируется архивировать в конце 2026 года, поскольку у него меньше пользователей, чем у других проектов Shopify.
Это важная деталь по двум причинам.
Во-первых, крупная компания может перестать быть естественным центром поддержки библиотеки даже тогда, когда сама технология продолжает существовать. Пользователи получают не мгновенный отказ, а необходимость проверить, кто будет принимать исправления, выпускать обновления и реагировать на изменения платформ.
Во-вторых, судьба библиотек показывает разницу между выбором архитектуры приложения и ответственностью за инфраструктуру сообщества. Shopify может перейти на Swift и Kotlin, но последствия почувствуют команды, которые используют её React Native-компоненты. Передача проектов новым владельцам снижает риск резкого обрыва, однако не гарантирует прежний уровень финансирования и скорости разработки.
Для пользователей этих библиотек практический план должен быть консервативным: зафиксировать версии, проверить активность новых сопровождающих, оценить совместимость с актуальными версиями iOS, Android и React Native, а затем решить, нужен ли план миграции. Архивирование Restyle особенно важно учитывать в долгоживущих продуктах: отсутствие немедленной поломки не означает, что зависимость безопасна на горизонте нескольких лет.
Что это означает для команд
Решение Shopify нельзя превращать в универсальную рекомендацию «переходите на native». Оно скорее даёт набор вопросов для собственной оценки.
Первый вопрос — где находится уникальная сложность продукта. Если основная ценность — сложные мобильные взаимодействия, глубокая интеграция с операционной системой, производительность и точное соответствие платформенным паттернам, native может дать больше контроля.
Второй — насколько дорого расхождение между платформами. Для приложения, где iOS и Android должны выглядеть и работать почти одинаково, общий слой остаётся привлекательным. Для продукта, который сознательно использует разные модели навигации и системные возможности, попытка удержать полное единообразие может быть искусственным ограничением.
Третий — готова ли команда проверять работу агентов. Если нет единого набора сценариев, автоматических тестов и владельцев платформ, переход просто заменит одну форму сложности другой.
Четвёртый — какова цена ожидания. React Native позволяет быстрее доставить общую функцию, но команда может дольше разбираться с платформенными углами. Native требует больше первоначальной координации, зато разработчики получают прямые инструменты платформы.
Наконец, следует оценить не только стоимость разработки, но и стоимость найма, обучения и удержания специалистов. Swift и Kotlin — не взаимозаменяемые навыки. Команда, которая сегодня эффективно работает в JavaScript-стеке, может не получить обещанный выигрыш сразу после миграции.
Что могло бы опровергнуть вывод Shopify
Пока это убедительная инженерная гипотеза крупной компании, а не независимое сравнение двух подходов. В доступном материале нет чисел о скорости выпуска, количестве дефектов, размере команд или стоимости миграции. Нет и опубликованного контролируемого сравнения: сколько времени занимает одинаковая функция до и после перехода, сколько ошибок находят агенты и сколько из них обнаруживается на реальных устройствах.
Поэтому вывод можно будет проверить по нескольким признакам.
Если после перехода Shopify действительно будет выпускать функции быстрее без роста платформенных расхождений, это станет сильным подтверждением. Важны также стабильность приложения, скорость исправления ошибок, доля кода, который требует ручной переработки после генерации, и нагрузка на команды ревью.
Обратный результат тоже возможен. Если две кодовые базы начнут расходиться, агенты будут создавать больше ложного ощущения готовности, а время ревью вырастет, React Native снова окажется рациональнее. Особенно если стоимость синхронизации требований окажется выше экономии на механической реализации.
Переход Shopify показывает не конец кроссплатформенной разработки, а смену точки сравнения. Раньше единый код был способом избежать повторения работы. Теперь часть повторения можно автоматизировать, и в некоторых больших продуктах прямой доступ к двум платформам начинает стоить меньше, чем поддержка общей абстракции.
Но решающим фактором будет не наличие агента, а качество инженерной системы вокруг него. Native становится будущим не тогда, когда модель научилась писать Swift и Kotlin, а тогда, когда команда умеет доказать, что две сгенерированные реализации действительно делают одно и то же — там, где это требуется продукту, и по-разному там, где этого требуют iOS и Android.