Мысли о React Native и Shopify

Если вы всю последнюю неделю жили под камнем, то могли пропустить пост Shopify, в котором компания объявила, что переводит свои приложения с React Native обратно на нативную разработку. Такие публикации обычно привлекают много внимания, потому что почти всегда вызывают споры.

Суть поста в том, что Shopify использует ИИ-агентов для программирования, чтобы помочь перенести приложения с React Native на нативные версии для iOS и Android.

Прежде чем углубляться в тему, полезно немного рассказать о моём опыте мобильного разработчика. В 2016 году я работал .NET-разработчиком. В свободное от основной работы время я писал iOS-приложения, а затем получил предложение стать iOS-архитектором в небольшой компании по разработке ПО во Флориде. Тогда мы создавали приложения нативно: на Objective-C для iOS и Java для Android. В то время мы изучили React Native и решили, что как кроссплатформенный фреймворк он ещё недостаточно зрел для наших приложений.

Вскоре после этого, в 2017 году, Airbnb опубликовала серию постов о том, почему компания отказывается от React Native в пользу нативных приложений. Airbnb была одним из крупнейших спонсоров React Native, и эти публикации вызвали настолько сильную реакцию, что сообщество React Native фактически занялось переработкой архитектуры фреймворка. В течение следующих пяти лет появились new architecture, среда выполнения JavaScript Hermes и Fabric. Если не углубляться в детали, это были огромные улучшения, заметно повысившие производительность приложений на React Native.

Примерно в 2022 году компания, в которой я работал, начала рассматривать React Native как способ писать отдельные части нашего приложения кроссплатформенно, оставляя при этом большую часть приложений полностью нативной — на Swift и Kotlin. Пока я изучал, как это организовать, я записал видео о том, как добавить React Native в существующее нативное приложение.

После публикации этого видео мне предложили работу в компании из Кремниевой долины, где нужно было помогать интегрировать React Native в нативные приложения. Хотя большую часть карьеры мобильного разработчика я занимался именно нативными приложениями, меня начали воспринимать как React Native-разработчика.

В большинстве крупных организаций, занимающихся мобильной разработкой, обычно есть отдельные команды разработчиков мобильных приложений. Когда я работал в мобильной разработке, я, как правило, был либо в iOS-команде, либо в Android-команде. В одной компании у нас была отдельная команда React Native, которая занималась кроссплатформенным приложением, а все остальные работали в командах под конкретную операционную систему.

После 2022 года рекрутеры, глядя на моё резюме, часто автоматически считали меня React Native-разработчиком, хотя большую часть своей мобильной карьеры я работал именно с нативными приложениями.

Преимущества React Native

Прежде чем слишком глубоко погружаться в React Native, хочу сразу сказать: я большой поклонник React. Большую часть своей карьеры я работал либо над серверными приложениями, либо над веб-приложениями. Я также очень люблю JavaScript и TypeScript. Но React Native — совсем другой зверь. В нём возникают технические проблемы, которых обычно нет при работе только с React или Next.js.

React Native особенно хорош в нескольких областях. Если у вас есть разработчики, знакомые с React, им очень легко подключиться к работе над приложением на React Native.

Ещё одна сильная сторона React Native — быстрая разработка кроссплатформенных прототипов. Одна команда может создать одно приложение, которое работает и на iOS, и на Android. Многие стартапы делают свои первые прототипы именно на React Native.

Ещё одна возможность, которая когда-то привлекла меня в React Native, — обновления «по воздуху». Можно обновить JavaScript-пакет и доставить его пользователям без необходимости отправлять новую версию приложения в магазин. И Google, и Apple используют процесс проверки приложений перед публикацией нативных обновлений. В одной компании, где я работал, мы иногда выкатывали по три обновления «по воздуху» в день, что, если честно, не всегда было хорошей идеей.

В React также есть функция HMR (Hot Module Replacement, горячая замена модулей), которая автоматически обновляет компоненты во время редактирования кода разработчиком. Это может значительно ускорять разработку.

Теперь о недостатках

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

Есть и хорошие примеры компаний, которые качественно поддерживают сторонние компоненты. Expo, например, отлично работает с нативными возможностями вроде камеры.

Обновления самого фреймворка — ещё один источник раздражения. React Native получает новую минорную версию примерно каждые 51 день. На первый взгляд это может показаться не так уж часто, но даже спустя 10 лет React Native всё ещё не дошёл до версии 1.0. На момент написания статьи актуальная версия — 0.87.

За обновлениями React Native приходится постоянно следить, иначе приложение в какой-то момент просто перестанет собираться. Хорошая практика — обновлять фреймворк примерно раз в три месяца. Если отложить обновление больше чем на год, перейти на последнюю версию проекта становится почти невозможно. Нативные части фреймворка используют Gradle на Android и CocoaPods на iOS. Поддержка CocoaPods будет прекращена 2 декабря этого года. React Native пока всё ещё зависит от CocoaPods. Сейчас ведётся работа над переносом поддержки iOS в React Native на Swift Package Manager. Экспериментальная поддержка SPM появилась в React Native 0.87.

Когда я обновляю React Native, обычно у меня уходит около недели только на то, чтобы снова получить рабочую сборку для iOS и Android. И очень часто во время обновления выясняется, что какие-то компоненты больше не поддерживаются, и приходится искать им замену — если такая вообще существует.

Реальность кроссплатформенной разработки

Salesforce проводила исследования поддержки мобильных приложений и пришла к выводу, что для прототипов или разработки нового приложения с нуля React Native действительно позволяет сделать всё быстрее. Но когда речь заходит о поддержке уже существующего мобильного приложения, нативное приложение обходится дешевле в сопровождении, чем приложение на React Native. При этом большая часть разработки приложений — это именно работа с уже существующими продуктами. Около 80% разработки связано с поддержкой текущих приложений, в том числе и в мобильной сфере.

Реальность мобильной разработки такова: поддерживать нативное приложение дешевле, чем приложение на React Native.

Правильное ли решение принимает Shopify?

После прочтения поста Shopify мне кажется, что компания, возможно, принимает правильное решение. Полное переписывание приложения с нуля исторически часто заканчивается неудачей. За свою карьеру я видел много программных проектов, которые пытались переписать приложение полностью и проваливались. Хорошая новость для Shopify в том, что у компании очень сильная инженерная команда, и я уверен, что они справятся.

Я сам экспериментировал с ИИ-агентами для программирования, пытаясь переписывать приложения с одного языка на другой. Anthropic недавно сделала что-то похожее с Bun, переписав среду выполнения с Zig на Rust.

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

Статистика использования React Native

По данным Appfigures, около 6,7% Android-приложений написаны на React Native. Среди 10 000 самых популярных неигровых приложений в App Store примерно 13,5% используют React Native. Существуют и другие кроссплатформенные фреймворки, такие как Flutter и Unity, однако подавляющее большинство приложений и в Google Play, и в Apple App Store остаются нативными.

Хорошая новость в том, что если вам нужны нативные iOS- или Android-разработчики, то на рынке сейчас хватает опытных специалистов, которые ищут работу в мобильной разработке.

Итог

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

Тем не менее React Native не был бы моим первым выбором для мобильной разработки. Использование нативных SDK даёт разработчикам полный доступ ко всем API платформы без ненадёжных абстракций, которые иногда сложно реализовывать и ещё сложнее поддерживать.

Если посмотреть на современные приложения на SwiftUI и Android Compose, видно, что они заимствовали многие идеи из React. И SwiftUI, и Compose, как и React, построены на компонентах. В некоторых случаях изменения можно видеть в реальном времени прямо на холсте в Xcode или Android Studio. И Apple, и Google переняли множество удачных идей, которые когда-то появились в React.

Источник