Как стать автором
Обновить

Комментарии 15

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

У вас пункт 3 пропущен.
Спасибо, поправили.
Не совсем понятно зачем использовать ReactNative(RN), если уже есть приложения написанные на native стеке и вы от них не собираетесь отказываться. Использование большого «зоопарка» в технологиях всегда сопряжено с усложнением кода и его поддержкой.

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

Про переход на 64Bit версию Android тоже не совсем верно. Поддержка появилась в версии 0.59 и переход на неё не был сколько-нибудь сложным, в отличии от перехода на версии 0.60+.

В общем я соглашусь с вами в том, что использовать RN, когда уже есть native, не совсем целесообразно. Но не могу согласиться с выводом, что на RN можно писать только простые приложения аля витрина магазина. Можно посмотреть к примеру сюда.
Слежу краем глаза за флаттер чатиком и с выводами статьи в целом согласен. Пока дело касается разработки UI и применения готовых плагинов — вроде проблем особых у людей нет. Как только нужно подправить библиотеку или написать свою, интегрировать с нативным кодом, разобраться с ошибкой в нативной части и подобное — тут у тех кто понадеялся на наличие готовых решений начинаются проблемы.
Спасибо за комментарий!

Абсолютно согласен, что при наличии полностью нативного приложения внедрение кроссплатформенной составляющей добавляет проблем в поддержке.

Да, библиотеки, возможно, есть, но тогда встает вопрос поддержки и кастомизации того, что написано другим разработчиком. А самое главное — скорость обновления библиотек. Если, например, в Google API изменится логика работы с оплатами, а разработчик, который ее поддерживал, не внес изменения, а вы об этом не знаете, так как надеетесь на библиотеку, то можете получить дополнительные проблемы.

У нас была сравнительно старая версия React Native в проекте 0.43, и переход с нее на 0.59 оказался довольно болезненым.

С примерами можно согласиться, но Airbnb в итоге отказался от использования кроссплатформенности, Facebook-приложения, в том числе Instagram, используют свой стэк по сути (React Native все-таки разработка Facebook, было бы странно, если бы они использовали что-то другое). Walmart, по сути, является интернет-магазином.

С остальным спорить не буду: каждый выбирает то, что ему удобнее. Остается вопрос, сколько проблем они готовы решать для того, чтобы использование React Native в их приложениях оправдался. Не могу судить о том, сколько у них уходит усилий на то, чтобы обработать ту или иную особенность платформ. Для меня кейс Airbnb является наиболее показательным.
Для начала, стоит вообще серьёзно засесть за пиво стол и честно глядя друг другу в глаза спросить: а нафига нам эти платформы?! КТО и где будет приносить нам деньги? И насколько приложение вообще будет привлекательно, чтобы за него кто-то вообще платил.
И сразу обнаружится, что 99% приложений вообще не нуждаются ни в каких «кросс-платформенностях». У смузихлёбов это просто бзик, хайп в заднем проходе — «кроссплатформенность». И только потом, профукав время и деньги заказчиков/себя, начинается прозрение.

Забавно, но кроссплатформенность — она не нужна юзерам — она нужна разработчикам! Очень ленивым/жадным разработчикам, которые в 21 веке думают, что можно «экономить на коде». Реальность показывает, что скупой не просто «платит дважды», а вообще вылетает из бизнеса.

«Нэйтив» — это чудовищный «подводный слой» функциональности и поведения, над которым работали годами профессионалы. Таскбар, трэй, меню, уведомления, жесты, тени, шрифты, отточенные контролы… да надо быть глупцом, чтобы думать, что всё это можно прикрыть фúговым листиком жабоскрипта и сверху нафигачить «кроссплатформенных кнопок»! Чудики, ей богу!
Справедливости ради, хоть RN я терпеть не могу — он использует нативные UI элементы через мост, а не сам рисует. Тем что вы описали страдает флаттер, дарт в котором компилируется aot в машинный код рисует через skia на канвасе напрямую, используя opengl/metal, как игровые движки.
Я нативщик, но в целом флаттер мне видится лучшей альтернативой чем засилье RN, электронов и подобного.
Этого мало, я же описал ЧТО ИМЕННО в системе (помимо внешнего вида) помогает юзерам:

Таскбар, трэй, меню, уведомления, жесты, тени, шрифты, отточенные контролы


Любой, кто сидит хотя бы год в своих иОСиках, Вендах и Линупсах, мгновенно просекает, когда «что-то не то». Когда приложение — лишь нашлёпка над очередной «кроссплатформенной муетой», а не родная программа.

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

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

Опять же, если один черт бизнес будет экономить и разрабатывать кроссплатформу — я бы предпочел видеть у себя на мобилке или на десктопе флаттер, чем электрон, кордову, реакт нейтив и другие веб штуки. А бизнес будет экономить, даже зная о минусах кроссплатформы.
Такая реализация приводит и к минусам.
Пришлось недавно начать пользоваться одним приложением на флаттере (под андроид)(вообще это клиент одного вебсайта):
— навигация совершенно нелогичная (догадаться логически куда системная наэкранная кнопка назад переведет или даже встроенная кнопка назад у приложения — невозможно)
— логин — если через штатные логин-пароль то нет даже попытки имитировать нормальные контролы (в результате не то что автозаполнялка — не работает, даже вставить руками скопированный пароль не выходит).
— авторизация через Facebook — берем открываем вебвью (при том что на устройстве есть приложение Facebook'а и вменяемые приложения — им пользуются).
— пополнение внутреннего счета (там через яндекскассу) — разумеется ТОЖЕ через вебвью а не открытием браузера, и при любой ошибке от яндекс кассы — не прочитать потому что сразу закрывается экран.

А это известная проблема. Разработка кроссплатформы (нормальной) требует квалификации выше чем разработка только под одну платформу. На флаттере можно и нормально сделать, но это надо знать как флаттер, так и натив.

Все так, но история ничему не учит. Swing против SWT, QT или wxWidgets. Желание сэкономить будет порождать обертки вроде RN и SWT и рендеры вроде Flutter и QT с одним и тем же результатом — все это оседает в нишах, тортовые продукты делаются на нативном UI.

Вы не ответили на этот комментарий под предыдущей статьёй, ну да может он просто потерялся. Может ответите тут. Что думаете насчёт этого?
https://twitter.com/SanSYS/status/1299657221085835264


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

Добрый день! Мы проверили ситуацию, описанную пользователем в этом треде. Указанные им факты не подтвердились.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.