Почему уход Shopify от React Native не представляет угрозы для Expo
Объясняется, почему переход Shopify с React Native на нативные языки Swift и Kotlin не означает конца разработки в среде Expo для большинства команд.
10 сентября 2026 года Shopify объявила о том, что собирается перестать использовать React Native для своих основных мобильных приложений и переписать их с нуля с использованием языков Swift и Kotlin. В течение нескольких часов форумы разработчиков заполнились догадками. В социальных сетях велись дискуссии о том, означает ли это конец React Native. Некоторые блог-посты даже утверждали, что разработка мобильных приложений для нескольких платформ завершилась.
Если вы разрабатываете с использованием Expo, всё это не должно вас беспокоить.
Что на самом деле сделала Shopify — и почему
Обоснование, приведённое Shopify, было довольно простым: помощники для кодирования на основе ИИ существенно снизили затраты на поддержку двух отдельных нативных кодовых баз для iOS и Android. Изначальным преимуществом React Native была экономия времени инженеров за счёт общего использования кода на разных платформах. Однако, когда инструменты ИИ могут быстро генерировать код на языках Swift и Kotlin, расчёты для компании такого масштаба, как Shopify, меняются.
Ключевой момент заключается в «организации такого размера, как Shopify».
Shopify разрабатывает одно из самых сложных мобильных приложений в мире: здесь работают сотни инженеров, миллионы продавцов, а требования к производительности ставят под серьезную проверку любую платформу. Когда Shopify утверждает, что искусственный интеллект сделал разработку нативного кода более доступной, она говорит от имени компании, способной одновременно обслуживать две крупные и сложные базы кода.
Большинство разработчиков Expo не находятся в таком положении, как и типичные команды, создающие приложения сегодня.
Expo и Shopify решают разные проблемы
Для Shopify React Native в первую очередь служил способом сокращения расходов в крупной инженерной организации. Для разработчиков Expo React Native — это инструмент, позволяющий отдельному разработчику или небольшой команде выпускать полноценное, отлаженное приложение как для iOS, так и для Android, без необходимости быть специалистом по какой-либо из нативных платформ.
У этих двух сценариев использования практически нет ничего общего.
У Expo есть отдельная основная команда, которая годами совершенствует один из лучших опытов разработки в мобильной сфере. Недавно выпущенный SDK 57 принес дальнейшее улучшение производительности, инструментов сборки и удобства работы разработчиков в повседневной деятельности. Библиотеки, такие как NativeWind, Reanimated и Expo Router, стали более стабильными и готовыми к использованию в производственных условиях, чем когда-либо ранее.
Все это не изменится только потому, что один крупный ритейлер решил перейти на другой инструмент.
Цифры говорят о другом
Пока комментаторы занимались тем, что объявляли о завершении разработки React Native, данные об использовании показывали совсем другое.
NativeWind — решение для стилизации в стиле Tailwind CSS для React Native — достигло 1,3 миллиона еженедельных загрузок в 2026 году и продолжает расти. Expo по-прежнему активно упоминается в сообществах разработчиков и обсуждениях. Появились новые библиотеки для стилизации, такие как Uniwind, которые за несколько месяцев набрали сотни тысяч еженедельных загрузок.
Эти цифры не свидетельствуют о сокращении экосистемы. Они указывают на то, что она всё ещё созревает.
Те, кто бросил React Native сразу после объявления Shopify, скорее всего, были теми же людьми, которые в любом случае нашли бы какое-то другое оправдание для ухода в следующем месяце. Разработчики, которые действительно создают реальные продукты с помощью Expo, не собираются что-либо менять.
Искусственный интеллект ускоряет разработку с Expo, а не делает её устаревшей
В аргументе о том, что искусственный интеллект уничтожил React Native, кроется настоящая ирония: инструменты на основе ИИ на самом деле существенно улучшили процесс разработки с Expo, а не ухудшили его.
Помощники вроде Claude, Cursor и GitHub Copilot хорошо разбираются в экосистеме Expo. Если у вас есть хорошо организованный файл CLAUDE.md, в котором описаны правила формирования компонентов и архитектурные паттерны, один из этих помощников может добавлять новые экраны, разрабатывать функции и рефакторить существующий код, сохраняя соответствие остальной части кодовой базы.
Люди, которые получают наибольшую пользу от этого рабочего процесса, иногда называемые «кодерами настроения», поскольку они описывают желаемый результат и позволяют ассистенту заниматься реализацией, всё равно нуждаются в надежной стартовой структуре. ИИ-инструменты отлично справляются с написанием кода, но гораздо менее надежны при принятии архитектурных решений, проектировании навигационных потоков, создании систем тем или формировании единого набора общих компонентов с нуля.
Именно этот пробел и заполняет хорошо спроектированный шаблон старта для Expo. Речь не идет о коде, который ИИ-ассистент мог бы сгенерировать по запросу — речь идет о базовой структуре, которая делает кодирование с использованием ИИ действительно продуктивным.
Шаблоны — это основной уровень для разработки с помощью ИИ
Когда разработчик открывает Cursor или Claude, чтобы начать работу над новым приложением, первый важный вопрос заключается в том, с какой кодовой базы он будет начинать.
Начинать с чистого результата команды create-expo-app означает провести первые часы на настройке навигации, добавлении поддержки темного режима, создании базовых компонентов интерфейса и утверждении стандартов. ИИ может помочь с частью этой работы, но всё равно требуется принятие решений человеком, настройки и многократные корректировки, прежде чем появится пригодная для использования основа.
Если же начать с готового к использованию шаблона, то подготовительные работы уже выполнены. Вы открываете редактор с поддержкой ИИ, описываете следующую функцию, которая вам нужна, и ассистент уже имеет структурированную и упорядоченную базу кода для дальнейшего развития.
Именно поэтому сегодня шаблоны, разработанные с учётом рабочих процессов с использованием ИИ — с подробной документацией в формате CLAUDE.md, чёткими примечаниями к компонентам и последовательными шаблонами — важнее, чем два года назад, а не менее.
Разработчики, которым действительно стоит беспокоиться
Если кого-то и должен беспокоить шаг Shopify, так это разработчиков, создающих простые приложения на React Native вне экосистемы Expo, которые напрямую используют React Native CLI и ориентируются на крупных клиентов, у которых достаточно инженеров для полноценной разработки нативных приложений.
Это описывает довольно узкий круг среди всех, кто использует React Native.
Если же вы независимый разработчик, фрилансер, маленькая студия или человек, создающий своё первое приложение, в основном описывая его для ИИ-ассистента, то Expo по-прежнему остаётся самым быстрым способом превратить идею в готовое приложение для обеих основных мобильных платформ. Решение Shopify ничего не меняет в этой ситуации.
Что это значит для вас
Продолжайте разрабатывать с Expo. Продолжайте выпускать приложения с помощью Expo. Экосистема находится в хорошем состоянии, инструменты постоянно совершенствуются с каждым новым релизом, а сообщество вокруг неё не исчезает.
Если вы начинаете новый проект на React Native, начните с готовой к использованию шаблона, а не с пустого проекта, и позвольте ИИ-ассистентам заниматься деталями реализации на этой основе. Такое сочетание позволяет выпускать приложения быстрее, чем это возможно при работе с нуля.
Некоторые разработчики в ближайшие недели будут читать спорные мнения и сомневаться в своих технологических выборах из-за объявления одной компании. Другие же просто будут продолжать выпускать свои приложения.
Стремитесь быть во второй группе.
Связанные статьи
- Nitro Modules: Как статические связи превосходят React Native TurboModules — Объясняется, как Nitro Modules используют заранее скомпилированные статические связи вместо динамического поиска, что позволяет им значительно превзойти TurboModules и Expo Modules в React Native.
- React Native, Flutter и другие: кроссплатформенные мобильные приложения в 2026 году — Сравнительный анализ React Native, Flutter, Kotlin Multiplatform, Ionic, NativeScript и PWA с точки зрения производительности, опыта разработчика и уровня зрелости экосистемы.