React native

Когда речь заходит о разработке сразу для Android и iOS, начинаются холивары и гадания на кофейной гуще. Что перспективнее, Flutter или Kotlin Multiplatform? За этими технологиями будущее, или завтра их обе забудут?

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

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

Оглавление

• Web / PWA

• PhoneGap / Apache Cordova

• Qt

• Xamarin

• React Native

• Выводы

Web / PWA

В 2007-м, представляя разработчикам первый iPhone, Стив Джобс объяснял, что нативные приложения не нужны: В iPhone есть полный движок Safari. Так что можете писать потрясающие Web 2.0 и Ajax-приложения, которые выглядят и действуют на iPhone именно как приложения.

Android на тот момент ещё даже не был анонсирован. Но получается, что исторически первым единым решением для iOS и Android стал веб.

Вот только разработчики тогда не разделили энтузиазма Джобса (неудивительно, учитывая тогдашнее состояние мобильного интернета). И годом позже всё-таки появился App Store для нативных приложений. А его комиссия в 30% стала новым денежным потоком для компании. В итоге её позиция сменилась на противоположную: теперь Apple считает, что правильный подход это натив (и предпочитает не вспоминать, что там её лидер говорил в 2007-м, Океания всегда воевала с Остазией).

Однако идея веб-приложений не исчезла, а продолжила развиваться. И в 2015-м новое поколение таких приложений назвали Progressive Web Apps. Они могут хранить данные локально, работать в офлайне, а ещё их можно установить на домашний экран смартфона. Чем это тогда не настоящие мобильные приложения? Что ещё для счастья надо?

Ну, например, для счастья нужны push-уведомления. По состоянию на 2021-й iOS не поддерживает их у PWA, и это мощнейший стопор для распространения подхода. Получается, компания, которая первой хвалила веб-приложения, позже сама поставила главное препятствие на их пути. На change.org есть даже петиция, обращённая к Apple: мы всё понимаем, вы дорожите своими 30%, но эта ситуация должна измениться.

Что в итоге: подход жив, но не стал общепринятым во многом из-за ограничений Apple. В будущем что-то может измениться, стоит следить.

PhoneGap/Apache Cordova

Это решение тоже связано с вебом, но подход другой так называемый гибридный. Тут предложили использовать знакомую троицу HTML/CSS/JS, но результат не публиковать в виде сайта, а упаковать в контейнер нативного приложения. В таком случае не сталкиваешься с ограничениями веба и можешь реализовать те же push-уведомления.

PhoneGap появился в 2009-м благодаря компании Nitobi, а в 2011-м Adobe купила её и создала также опенсорсный вариант Apache Cordova. У проекта модульная архитектура, позволяющая подключать плагины. И в сочетании с опенсорсностью это означает, что если Cordova не умеет чего-то нужного (например, взаимодействовать с акселерометром смартфона), сообщество может научить. Вроде как прекрасно, да?

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

Почему так? Среди главных причин называют UX, уступающий нативным приложениям. Всё хуже и с производительностью, и с плавностью. Но основное отличие даже не измерить числами: пользователю попросту заметна разница между гибридным приложением и нативным, они производят разное впечатление. Для людей через WebView ощущения не те.

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

Интересно, что авторы проекта сами предвидели такое развитие событий и ещё в 2012-м написали, что итоговая цель PhoneGap прекратить своё существование. И недавно эта цель была достигнута: в 2020-м Adobe заявили о прекращении разработки, ссылаясь на то, что нишу закрыли PWA.

Что в итоге: разработка прекращена.

Qt

Проект Qt помогал людям заниматься кроссплатформенной разработкой ещё с 90-х, когда речь шла о десктопных ОС, а не мобильных. При этом он завязан на C++, который для Android и iOS не совсем чужой: даже нативные разработчики на этих платформах могут обращаться к плюсам. Так что, казалось бы, поддержка iOS/Android со стороны Qt просто напрашивалась.

Но поначалу дело осложнялось тем, что в 2008-м проект купила Nokia. Компания тогда делала ставку на Symbian и не горела желанием помогать конкурентам. В 2010-м возможностью запускать Qt-приложения на Android занимались энтузиасты, и на Хабре об этом писали:

В 2011-м Nokia отказалась от Symbian в пользу Windows Phone, а часть проекта Qt продала компании Digia. И тогда началась работа над поддержкой одновременно Windows 8, Android и iOS. Ну вот теперь-то счастье? Спустя 10 лет ясно, что тоже нет.

Вакансии по мобильной разработке на Qt сейчас единичные. Хабрапосты о ней появляются очень редко и не свидетельствуют об успехе: в одном причиной использования Qt стала ОС Аврора (экс-Sailfish), в другом попросту у меня уже был большой опыт с ним.

Что помешало? Я встречал жалобы на то, что недостаточно было использовать сам Qt и писать на С++/QML. Потому что средствами Qt многое было не реализовать, и приходилось-таки иметь дело с конкретной платформой (например, на Android работать с Java, увязывая это с плюсовой частью через JNI). Всё это очень неудобно и подрывает исходную идею бодренько запилим два приложения по цене одного.

При этом здесь пользователь тоже ощущает не-нативность. А к IDE Qt Creator есть нарекания, рантайм Qt увеличивает размер приложения, бесплатный вариант Qt подходит не всегда и может понадобиться недешёвый коммерческий. Кроме того, мне лично кажется, что ещё сказался язык. Кроссплатформенной разработке желательно быть такой, чтобы нативным разработчикам было попроще перекатиться туда, а с языком C++ слово попроще не ассоциируется.

И хотя случаи использования Qt встречаются до сих пор, это скорее исключения из правил, у которых могут быть какие-то особые исходные условия: например, хотим перетащить на телефоны с десктопа уже имеющуюся кодовую базу на C++.

Что в итоге: крайне нишевое решение, которое не умерло полностью, но используется очень узкой прослойкой.

Xamarin

Мигель де Икаса ещё в проекте Mono занимался тем, что притаскивал .NET на несвойственные ему платформы (начав с Linux). А когда в 2011-м он вместе со всей командой Mono попал под сокращение, основал новую компанию Xamarin, собрал прежних коллег там, и сосредоточился на мобильных платформах: мол, давайте писать мобильные приложения для них на C#, вот инструмент для этого.

Надо понимать контекст того времени. Годом ранее компания Microsoft выпустила Windows Phone и стремилась стать третьим большим игроком на мобильном рынке. И даже большая Windows лезла на мобильный рынок: готовилась к выходу Windows 8, оптимизированная для планшетов.

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

Но теперь задним числом мы знаем, что мобильные амбиции Microsoft заглохли. И это оставило Xamarin в странном положении: на рынке две живых платформы, а тут предлагают писать для обеих на языке умершей третьей. Ни айосеров, ни андроидоводов такое сильно не привлекает.

Ещё порой вызывали недовольство и то, что после появления новых фич в Android/iOS приходилось ждать их поддержки в Xamarin, и стоимость лицензии, и общее состояние экосистемы (документация, поддержка, библиотеки).

А тем временем компания Microsoft возлюбила опенсорс и сторонние платформы вроде Linux, так что идеи де Икасы оказались ей близки, и в итоге она купила Xamarin. Теперь его наработки вошли в .NET 5, и в прошлом году представили .NET MAUI (Multi-platform App UI) развитие тулкита Xamarin.Forms. В общем, не забросили купленное.

Что в итоге: пока всё остаётся в странноватом статусе, когда и масштабного взлёта не получилось, и полностью не прекращено.

React Native

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

Писать предлагается на JavaScript, поэтому кому-то может показаться, что это реинкарнация PhoneGap и его HTML-подхода, но нет. Когда-то Facebook действительно полагался для мобильных устройств на HTML, но ещё в 2012-м Цукерберг назвал это ошибкой. И у React Native идея не в том, чтобы с помощью HTML/CSS городить что хочешь, а в том, чтобы с помощью JSX использовать нативные элементы UI так что пользователь ощущал себя прямо как с нативным приложением.

Насколько это получилось? Шероховатости и срезанные углы существуют с ними сталкиваются и разработчики, и пользователи. Для кого-то они оказываются критичными: особенно нашумел пост Airbnb, где после React Native решили вернуться к нативной разработке. Но какие-то другие компании (вроде самой Facebook) эти ограничения не остановили, использование в индустрии есть.

Поскольку нативной отполированности не достичь, это решение часто рекомендуют для случаев, где она и не требуется. Если пользователь залипает в приложении часами (как в соцсетях), то любая неаккуратная мелочь будет бросаться ему в глаза но вот если юзкейс приложения такой, что его включают на минуту в неделю, то эти мелочи просто никто не заметит.

Если зайти на HeadHunter и сравнить число вакансий по React Native с нативной разработкой, то их немного. Но вот если сравнивать с Qt/Xamarin/PhoneGap то вакансий окажется больше, чем у них всех, вместе взятых, это наиболее успешный вариант.

Что в итоге: React Native не стал так успешен, как его фронтендовый старший брат, но определённую нишу занял.

Выводы

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

• Победит и умрёт не единственные варианты. Есть ситуации, когда технология занимает небольшой сегмент рынка и не претендует на мировое господство, но приносит кому-то пользу.

• Кроссплатформа это всегда компромисс. Выдержать планку качества, заданную нативом, не получалось нигде. Везде что-то вытарчивает и пользователи могут заметить разницу, и разработчикам приходится возиться со сложностями. И далеко не для всего кроссплатформа годится одинаково хорошо: если бизнес-логика между платформами шарится хорошо, то с UI всё сложнее.

• Но качество ниже нативного не означает, что кроссплатформа плоха и не нужна. Кому-то на этот компромисс вполне стоит идти (например, стартапу, где вся жизнь один сплошной компромисс). В каждом проекте надо взвешивать свои за и против, и результаты в разных случаях будут различаться.

И всё это приводит меня к такому выводу про Flutter: вместо обсуждений выиграет он или проиграет надо обсуждать в каких конкретно юзкейсах он выигрывает. По-моему, он хорош для определённой ниши, поэтому вряд ли угрожает будущему всей нативной разработки, но закрепиться в этой нише вполне может. Вопрос в том, каковы её размеры и попадает ли в неё ваш проект.

А вот про Kotlin Multiplatform сделать выводы по прошлому у меня не получилось, потому что у него нетипичная ситуация, отличающаяся от предшественников. Во-первых, идея кроссплатформа годится не для всего тут заложена прямо в фундамент: а мы и не предлагаем объединять всё, реализуйте общую бизнес-логику, а остальное на Android и iOS делайте раздельно. А во-вторых, тут играет на руку родной для Android язык: он уже знаком половине мобильных разработчиков, и такого в кроссплатформе раньше не возникало. Так что опыт предыдущих технологий тут непоказателен остаётся смотреть, что покажет время.

На последнем Mobius было сразу несколько кроссплатформенных докладов (три про Flutter, один про Kotlin Multiplatform) мы уже выложили все видеозаписи конференции на YouTube, так что можете сами их посмотреть. А мы тем временем вовсю работаем над следующим Mobius: он пройдёт 13-16 апреля в онлайне, и там без освещения кроссплатформы тоже не обойдётся. Так что, если вас заинтересовал этот пост, то вам будет интересно и там.

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

Мы попросили лидера мобильной разработки Артёма Рыжкина (phoenix_rav) рассказать о том, откуда в нативных приложениях Lingualeo появились модули на React Native, какие они вызывали проблемы и когда вообще имеет смысл делать кроссплатформенные приложения.

Как в приложении Lingualeo появились кроссплатформенные элементы

Приложение Lingualeo появилось в русских сторах в 2012 году. Тогда ещё не было кроссплатформенных технологий, приложение для iOS написали на Objective-C, а для Android на Java. Их поддерживали и развивали две отдельные команды.

Со временем приоритеты в компании несколько раз менялись. После 2015 в Lingualeo сделали упор на веб: в мобильной команде осталось всего несколько разработчиков. В основном они поддерживали и актуализировали версии библиотек, и редко добавляли новое.

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

В 2016 году в Lingualeo родилась идея игровых тренировок комплексов заданий, которые помогают пользователям учить язык. Часть была платная, часть бесплатная. Всего их придумали шесть.

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

Для работы выбрали React Native. Помимо него рассматривали несколько других кроссплатформенных технологий, например, подключаемые библиотеки, игровые движки и Webview. Все варианты оценили по скорости, удобству и качеству разработки, и в итоге выбрали React Native.

К тому же в тот момент веб переезжал на React. В Lingualeo была сильная веб-команда, и на это сделали ставку: решили, что разработчикам, знакомым с React, будет комфортнее и быстрее разобраться с React Native, чем с другой технологией. Шесть игровых тренировок сначала сделали на вебе, потом портировали в приложения.

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

Почему кроссплатформенные элементы в нативных приложениях это проблема?

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

React Native не позволяет полностью отказаться от нативного кода, заменив его кроссплатформенным. Для некоторых функций, например, проигрывания музыки, обращения к сенсорам устройства или к локальному хранилищу придётся писать так называемые bridge-классы.

Другой вариант подключать сторонние node модули, реализующие необходимую функциональность. Но может сложиться ситуация, что библиотеку всё равно придётся доработать под нужды вашего приложения. К тому же команда, разработавшая модуль, со временем может перестать его поддерживать.

У нас использовались bridge-классы код на двух нативных языках: Java/Kotlin для Android и Objective-C/Swift для iOS. Мы написали их для обращения к медиаплееру, к аналитическим системам, локальному хранилищу и логике авторизации.

Например, вот как bridge-класс запускает Intent Service в Android:

public class LLMergeBridgeModule extends ReactContextBaseJavaModule {

protected static final String MODULENAME = "LLMergeBridgeModule";

@Override

public String getName() {

return LLMergeBridgeModule.MODULENAME;

}

public LLMergeBridgeModule(ReactApplicationContext reactContext) {

super(reactContext);

}

@ReactMethod

public void merge() {

ReactApplicationContext context = getReactApplicationContext();

SyncService.startServiceForceSync(context);

}

}

У разработчика также могут возникнуть проблемы, если на кроссплатформенном фреймворке необходимо реализовать кастомную логику обработки жизненного цикла экрана Activity в Android или ViewController в iOS.

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

Сложно искать разработчиков: нужен дорогой универсальный специалист или несколько разработчиков разного профиля. Если вы хотите создать приложение на React Native, можно найти разработчика, который знает одновременно iOS, Android и React Native.

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

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

Например, на момент внедрения React Native у нас уже было два проекта для локализации строк в системе переводов. Один работал для приложения на Android, другой для iOS. Каждый из проектов учитывал особенности своей платформы.

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

С августа 2019 все приложения Google Play должны обязательно поддерживать 64-битную архитектуру. Если для нативного приложения такая поддержка включалась парой строчек кода, то для React Native пришлось мигрировать на последнюю версию. Нативный разработчик несколько недель разбирался в коде, чтобы адаптировать его под новую версию.

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

Как мы вернулись к полностью нативным приложениям

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

Работа шла дольше, чем мы предполагали. Аутсорс-команда отдавала нам сборку, которую нужно было проверить, поэтому у нас выросла нагрузка на QA. Мы проверяли сборку, давали комментарии, их брали в работу, но процесс шёл медленно. Миграция одной тренировки в среднем занимала 3 месяца от получения ТЗ до отправки в прод.

Для ускорения процесса мы решили взяться за миграцию тренировок самостоятельно. Версии для iOS закончили аутсорсеры, а Android мы взяли сами. Начали с одной тренировки в экспериментальном режиме: получилось быстрее и дешевле, чем на аутсорсе.

Первую тренировку мы перенесли за полтора месяца, вторую и третью тоже. Дальше механики тренировок начали повторяться, поэтому последние три мы закрыли за месяц. Сейчас мы тестируем тренировки и включим их в следующий релиз.

Дополнительный плюс от перехода на полностью нативные приложения оказался в том, что размер архива приложения уменьшился на 28 Мб. Также сократилось время сборки: раньше билд релиза Android-приложения на Mac mini занимал до 20 минут на холодном старте, а сейчас 2.

Получается, что в Lingualeo сначала появились кроссплатформенные элементы, а затем мы переписали их в нативных языках. В нашем случае поддерживать кроссплатформенность было накладнее, чем вести полностью нативные приложения.

В каких случаях выгодно делать кроссплатформенное приложение?

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

1. Это простое приложение. Такое приложение не требует реализации сложной бизнес-логики и сложной UI-логики. Например, витрина интернет-магазина: приложение должно просто отобразить список товаров, дать возможность положить товар в корзину и оплатить покупку.

2. Это приложение должно быть одинаковым на каждой платформе. Если ваше приложение выглядит и построено так, что не будет отличаться в зависимости от платформы, используйте React Native. В таком случае получится сэкономить деньги бизнеса и время разработчиков за счёт унификации кода.

4. Это приложение не работает с медиафайлами, сенсорами и навигацией. React Native удобная технология для мобильных приложений, которым не требуется работать с медиафайлами и множеством сенсоров смартфона.

5. Вам важно быстро запуститься и вносить изменения на лету. Кроссплатформенные технологии отличный вариант для быстрого запуска. React Native будет выгодно использовать, например, стартапам. Скорее всего, кроссплатформенная разработка потребует меньше человеко-часов и предприниматель быстрее получит продукт. Его можно тестировать, показывать инвесторам и при необходимости менять код на лету без пересборки проекта, используя механизм code push.

6. У вас пока нет нативных приложений. Добавление кроссплатформенности в нативные приложения приведёт к дублированию сетевого слоя, логики работы UI, локализации, также появятся проблемы с настройками проекта.

Когда кроссплатформенные решения не выигрывают у нативных?

Есть кейсы, когда React Native точно не будет выгоднее, чем нативное приложение. Вот несколько таких:

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

В Lingualeo такие механики как раз есть в игровых тренировках. Например, в аудиотренировке текст сначала проигрывается до конца, затем разбивается на фрагменты. Пользователь может воспроизводить их и перетаскивать при помощи drag and drop.

Приложение будет много обращаться к сенсорам. Чтобы обратиться, например, к GPS, Bluetooth, акселерометрам, датчику лица или микрофону, коду на React Native также нужны bridge-классы.

В приложении будут встроенные покупки. Внутренние покупки очень важная и чувствительная для пользователей фича в приложении. При её реализации лучше обращаться к нативным библиотекам Google и Apple, чтобы, например, чётко понимать, какие проблемы возникли на этапе покупки и верно обрабатывать состояния. Придётся внедрять в приложение нативный код, который будет обращаться к сторам, и для каждой платформы эти модули будут разными.

Фичеринг приложения и следование гайдлайнам. Если вы хотите активно получать фичеринг от Google Play и Apple Store, то, скорее всего, от команды разработчиков потребуется внедрение новой функциональности, специфичной для каждой из двух платформ. Поддержка подобных фичей в React Native потребует времени со стороны разработчиков, а сторонний node module может появиться с заметным опозданием.

Выводы

React Native мощная, удобная и во многом универсальная технология, но лучше всего она подойдёт для приложений, которые:

• не имеют нативной кодовой базы: то есть, сразу создаются как кроссплатформенные;

• основаны на простой логике: им не нужен доступ к медиафайлам и датчикам;

• не имеют встроенных покупок, например, платного премиум-доступа или игровой валюты;

• должны запуститься быстро и экономно: например, чтобы показать MVP инвесторам.