×Закрыть

Варианты кроссплатформенной разработки мобильных приложений

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

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

Давайте посмотрим, какие варианты кроссплатформенной разработки существуют и что они предлагают нам как создателям. Бизнес постучит со своими «хотелками», а выбор того, на чем писать, часто приходится делать именно разработчику.

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

Проблема архитектуры в кроссплатформах

В мире кроссплатформы все фреймворки примерно одинаковы по своей структуре. В основе всего — целевая платформа (iOS, Android, etc.), для которой ведется разработка, и слой абстракции, который обещают сделать быстро, дешево и красиво, а между ними мост, соединяющий эти две сущности. Слой абстракции в большинстве своем представлен связкой из JS и CSS (частично или полностью).

У такой архитектуры есть типичные проблемы.

Частично они обусловлены тем, что слой абстракции, условно говоря, пытается усидеть на двух стульях — с переменным успехом. Отсюда и сложности: на каждой отдельно взятой платформе приложение отображается и ведет себя по-разному. Иногда это не проблема, но бывают случаи, когда уникальный дизайн и поведение на обеих платформах являются дополнительным business value.

В пример можно привести приложение Reflectly. Изначально оно было написано на React Native, впервые вышло на iOS, а позже была попытка выйти на платформу Android.

React NativeFlutter

Запуск приложения в Android преподнес неприятный сюрприз. В итоге его полностью переписали на Flutter.

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

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

Работоспособность и поддержка плагинов. Кроссплатформа не так распространена, как классический фронтенд. Нередко плагин выпускается в Open Source, и практически сразу прекращается его поддержка, так как существующая версия решает проблемы разработчика, а за большее никто не будет платить. Еще хуже, когда прекращается не только поддержка, но и реагирование на pull requests...

Миф о том, что любого web-разработчика можно быстро переквалифицировать в мобильщика с помощью «магического фреймворка Х». Все выглядит похоже: на Web — CSS + JS, на кроссплатформе — то же самое. Должно работать. Но не учитывается факт, что к имеющимся знаниям требуется быстро прибавить понимание как минимум двух платформ (iOS и Android), с которыми разработчик раньше не сталкивался. Отдельным бонусом идет набивка руки в специфических тонкостях, связанных со взаимодействиями внутри всего этого зоопарка.

Из-за всех этих нюансов кроссплатформенную разработку троллят вот так:

Начнем знакомство с фреймворков, основанных на WebView.

Cordova

Одним из первых кроссплатформенных фреймворков стал Cordova (бывш. PhoneGap). Первый релиз состоялся в 2009 году. Изначально разрабатывался компанией Nitobi, купленной Adobe. В результате поглощения исходный код PhoneGap был передан Apache Foundation.

Из официальной архитектурной схемы видно, что основой рендеринга выступает обычный WebView — то есть обычный браузер. Несмотря на то что это самый давний фреймворк, предлагает он лишь джентльменский набор из плагинов и связки API для обеспечения их взаимодействия. Какого-то специфического набора инструментов у него нет. Есть перечень сервисов и библиотек, который предлагается на главной странице, например Onsen UI — UI-библиотека.

Developer experience довольно неоднозначный: фактически, как ты его себе организуешь, так и будет. Можно на jQuery все писать и обновлять страницу с F5, а можно собрать себе уютный и привычный набор библиотек и пользоваться уже существующими решениями для hot reload.

Дебаг происходит в консоли браузера. Дебаг на устройстве — через подключение из Safari к WebView, запущенном на iOS.

Также есть удобный механизм темплейтов, который позволяет генерить проект из готовых сторонних бойлерплейтов. Например, cordova-template-framework7-vue-webpack.

Ionic

На основе Cordova в 2013 году был выпущен Ionic. Со временем Cordova заменили Capacitor с сохранением совместимости API, чтобы осталась работоспособной вся существующая база компонентов.

Имеет свою базу UI-компонентов и позволяет реализовывать бизнес-логику на любом фреймворке из могучей тройки (до версии 4 была возможность использовать только Angular). Есть возможность оплатить энтерпрайз-поддержку. В остальном все сказанное о Cordova относится и к Ionic. Дебаг в консоли браузера, хот-релоад от фреймворка, работает внутри WebView.

Следующими рассмотрим фреймворки semi-native, которые предлагают писать на смеси CSS + JS (React Native, NativeScript, Appcelerator) или .NET (Xamarin), а на выходе получать приложение, практически не отличимое от нативного.

Appcelerator наименее известен (0 упоминаний в вакансиях на DOU), использует свой собственный фреймворк Alloy. Существует также версия с поддержкой Angular, но она все еще в бете, а движение в репозитории остановилось в 2108 году... Знать о нем можно, а изучать практического смысла нет :)

Xamarin

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

В отличие от JS-фреймворков код на C# компилируется, и это позволяет ему работать чуть быстрее. Также у него есть два варианта архитектуры.

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

Xamarin Forms

Продолжение развития Xamarin, но уже с покрытием UI, не требующим написания по отдельности.

Доступны наборы инструментов для разработки на любой вкус. Есть бесплатная Visual Studio Community Edition и платная версия Visual Studio Professional по подписке за 45 $ в месяц.

Дебагер, хот-релоад (только для верстки), лейаут-эдитор — все имеется в наличии. Однако язык разработки и относительная дороговизна инструментов разработки делает Xamarin малораспространенным за пределами экосистемы Microsoft.

NativeScript

Фреймворк выпущен в 2014 году. На данный момент из коробки предлагается писать на Angular или Vue. За долгие годы развития накопил достаточно большой арсенал инструментов разработчика: готовый набор UI-компонентов, собственную песочницу, маркетплейс компонентов, приложение для быстрого запуска превью написанного кода на устройстве, приложение, где можно увидеть вживую работу компонентов. Для дебага можно использовать или консоль браузера, или предоставляемый разработчиками плагин для VS Code.

Имеет интересную архитектуру — API платформы через рефлексию пробрасываются на сторону JavaScript.

На практике работа с API-платформы выглядит так, как будто вы пишете, например, на Java, только через призму JS. В повседневной же работе используется набор встроенных layout-компонентов и CSS-подобный синтаксис для раскраски. При изменении стилей достаточно неплохо работает hot reload.

На выходе имеем бандл JS-кода, выполненный в JSCore (iOS) или V8 (Android) и работающий через мост с платформой.

React Native

Первый релиз состоялся в 2015 году. Практически единственный из кроссплатформенных фреймворков JS, который не дает нам выбора и предлагает только React как фреймворк для разработки. Его появление подтверждает, что React можно скормить любой движок для рендеринга виртуального дома дерева. Первая имплементация этого подхода была результатом хакатона и в итоге продолжила свое развитие в Open Source. На данный момент очень популярен не в последнюю очередь благодаря «Реакту» для Web.

Общая архитектура очень похожа на NativeScript, только мост на 100 метров выше по реке. Нативные плагины пишутся на стороне платформы, а через мост передаются лишь параметры. В промежутке между JS и платформой находится Yoga — кроссплатформенный движок, который реализует flex-box layout на целевой платформе.

Технически React Native очень похож на то, что frontend-разработчики привыкли видеть на Web.

Фреймворк активно развивается: релизы появляются каждые 3–6 месяцев. В версии 0.61.0 обновили механизм hot reload, который позволяет работать более производительно. Не так давно была выпущена версия 0.62.0, которая добавила интеграцию fbflipper из коробки. Надеюсь, эта инициатива получит достойное продолжение, так как до сих пор арсенал инструментов разработчика был похож на лоскутное одеяло. Изначально предлагается только консоль браузера, можно использовать также react-native-debugger или reactotron, которые дают дополнительные инструменты при разработке (инспекция Redux, MobX, Apollo Cache).

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

Последними рассмотрим фреймворки native-like. Отличает их то, что они совсем не используют встроенных виджетов. Вместо этого рисуют все своими силами. Одним из новичков в этой категории является Flutter. В процессе подготовки статьи я с удивлением обнаружил, что с 2011 года на Python развивается аналогичный фреймворк, реализующий такую же концепцию, — Kyvi. Увы, но этому фреймворку не хватает финансирования и комьюнити. Например, имплементация Material UI уже 3 года не развивается, а инициатива была перехвачена нашим соотечественником.

Flutter

Первый релиз состоялся в конце 2018 года. Платформа достаточно молодая, но она активно развивается: ежеквартальные релизы, активное развитие языка Dart, богатый инструментарий разработчика, изумительный hot reload, онлайн-редактор для анимации, специализированная CI/CD — все это было доступно с первого дня релиза версии 1.0.

Особенностью архитектуры Flutter является то, что он сам рисует каждый пиксель, контролирует жесты и анимацию. Он не использует ОЕМ-виджеты, как это делает React Native. Вместо этого команда Flutter создала два набора виджетов для основных мобильных платформ: Material для Android и Cupertino для iOS. Таким образом, они заново отрисовали все UI-компоненты с обеих мобильных платформ, полностью повторив их поведение. Непосредственно с мобильной платформой (геолокация, звук, Bluetooth) взаимодействие происходит через Platform Channels.

Благодаря такой архитектуре заявлена поддержка «всего что угодно», в теории. На практике хорошо поддерживаются iOS и Android. Активно развивается Web. Фактически успех на web-поприще определит дальнейшую популярность фреймворка во всем мире. На данный момент есть поддержка Web в бета-версии, и с каждым днем она становится все лучше. Одной из проблем является производительность. С флагом FLUTTER_WEB_USE_SKIA=true производительность существенно возрастает. Более подробный обзор Flutter доступен в моей предыдущей статье.

Относительная «молодость» платформы и широкий перечень поддерживаемых платформ, бывает, преподносит баги в неожиданных местах. Благодаря быстро растущему комьюнити на многие из них есть ишьюс на GitHub, в которых часто можно найти вариант обходного решения проблемы.

Qt

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

Тренды

Для полноты картины приведу тренды на Stack Overflow:

Вакансии (Djinni):

  • React Native — 45.
  • Flutter — 19.
  • Xamarin — 4.
  • Cordova/Ionic — 1.
  • NativeScript — 0.

Муки выбора

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

Например, если у вас десктоп-решение на .NET, ваш выбор, скорее всего, падет на Xamarin, что позволит эффективно заново использовать имеющиеся наработки и компетенции.

Если вам нужно простейшее решение, чтобы текущий web-продукт поддержать мобильной платформой, вам подойдут PWA или Ioinc (с дистрибуцией через магазины).

Если вы только за Angular либо за React, а все остальное — «фу-фу-фу», если нет времени или желания разбираться, а нужно приложение на вчера, вы, скорее всего, остановите выбор на NativeScript в первом случае или на React Native во втором.

Стартапам придется выбирать между React Native и Flutter из-за их популярности и поддержки большими компаниями. Первый — это зрелый фреймворк с устоявшимися практиками разработки, богатством библиотек и большим комьюнити. Второй — молодой, быстрый и перспективный с богатым набором встроенных UI-компонентов и крутым developer experience.

Начинающим разработчикам или желающим попробовать что-то новое стоит обратить внимание на Flutter.

Конкурс

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

ArtFlutter Meetup #1

21 мая 2020 в 18:00 мы проведем первый митап, посвященный Flutter, на нашем YouTube-канале.

Темы докладов:

  • Flutter/Web: adaptive and responsive UI.
  • Integrating C/C++ code into your Flutter application.

Подписывайтесь и следите за обновлениями!

LinkedIn

70 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Супер!)
Всем будет работа ;-)

Не в последнюю очередь потому что после ReactNative — Flutter просто агонь) Ну и Гугл тоже добавляет копеечку и засылает докладчиков)

Dart Развивается слабо — по сравнению с чем?
Каких фичей языка не хватает?

1) Xamarin можна спокійно викорстовувати з Community версіями VS для Win та Mac . Що більшість і робить. Платна версія VS має Xamarin Profiler та Inspector.
2) Зараз активно розвивається Xamarin.Shell та Xamarin.Material для одинакового UI на обидвох платформах та спрощеної структури самої апки.
3) Перевагою Xamarin також є те, що можна використовувати усі сторонні компоненти написані на (objective-c/swift та java/kotlin),
для яких біндінги робляться в напів-автоматичному режимі. Тобто не потрібні знання тих самих (objective-c/swift та java/kotlin).
3.1) 100 % API Coverage, усі останні апішки обох платформ (легко)доступні
4) Доступні усі останні performance build фічі для обох платформ (R8, D8, AOT, AAB, Native Handlers, Aapt2 і так далі )
5) Для фанатів UI code з версії 4.6.0 стане доступним CSharpForMarkup і можна буде писати UI в коді замість Xaml
6) Бекенд платформи iOS, Android, UWP, Mac OS (official support), WPF та GTK(community), Tizen (Samsung), Web (поки що PoC)
7) з версі VS 16.5.5 стане доступний partial Hot-Reload (зараз в Preview) де оновлюється безпосередньо сам контрол, а не вся сторінка. Тобто не обривається контекст та швидше працює
Є ще всякі фічі типу чудової інтеграції з Azure, Xamarin.Essentials та уніфікація в .NET 5 , але то вже на окрему статтю потягне ))

Спасибо за развернутое дополнение)
В рамках стека МС полезные нововведения

В стек МС входить: backend, mobile, cloud, desktop, AI та IOT. Не такий вже і маленький стек)

8) забув добавити SkiaSharp на якому можна писати супер кастомні контроли з анімацією, які легко добавляються в апки і працюють на всіх платформах (ios, android, uwp, wpf, mac, tizen, linux(GTK)) і виглядають однаково . Це той самий engine на якому працює Flutter)

в списку «всі платформи» пропущено саму головну — web :)

Web також є. Поки це реалізували в UNO Platform через Blazor.
Тут готова демка з можливостями SkiaSharp
https://platform.uno/blog/skiasharp-support-for-webassembly-via-uno-platform

Також є Web бекенд від Xamarin — поки що PoC
github.com/...​in.Forms.Platforms.Blazor
А також можливість розробляти Native апки для тих в кого є знання web через MobileBlazorBindings
docs.microsoft.com/...​s/mobile-blazor-bindings

простіше повіситись, якщо чесно.

Мне кажется в лого Xamarin чего-то все время не дорисовывют — tppr.me/GoYq4
А то все вроде бы есть, но что-то мешает чтобы быть востребованным в значимых масштабах)

В залежності чим міряти масштаби. В порівнянні з масштабом React Native і Flutter не дуже виглядає, але ви та інші компанії його використовуєте і статтю написали. І він до тогож активно розвивається (судячи по кількості PR та багів на Github ).

9) Ще забув про ReactorUI. Для любителів Rx UI підходу (Flutter та React Native) є сторонні розробки, що працють за принципом Component Based UI з Hot-Reload. Ось стаття про це
medium.com/...​ent-based-ui-56a9bd861078

0. спочатку 3 дні угадуєш, яку саме версію .NET треба поставити: Core, .NET Framework, ще купа якихось свістелок. Ну і працює лише в студії.

.NET Framework — це десктоп, під вінду. .NET Core кросс платформа, поки в основному бекенд. Швидше за все мається на увазі Runtime, бо Xamarin працює через Mono — поки що.
Платформа ставиться/вибирається автоматом при установці студіїї. Треба просто поставити галочку навпроти mobile ) . Не тільки VS студія, також є Rider)

щось так складно, що краще флатер :) ще і вінду ставити для .NET цього...

Взагалі то є Visual Studio for Mac. На якому я в основному і працюю. Там ще простіше.
Windows в основному потрбіне для UWP та WPF. Ну і я б не сказав, що установка Flutter прям така проста порівняно зі студією, де все ставиться з коробки при виборі відповідних галочок.
medium.com/...​ions-with-it-81b4bbe739f8

Мабуть ми з вами на різних берегах знаходимось) Треба бути трохи фанатом платформи .Net, тоді все стає зрозуміло і з’являється можливість побачити, куди взагалі рухається Microsoft — від .Net framework і нормальної підтримки лише desktop на початку нульових до дикої кростплатформеності і відкритого коду зараз (.Net 5). Спробуйте знайти якусь статтю по динаміці розвитку .Net за 15 років — думаю вам сподобається.

нормальної підтримки лише desktop на початку нульових

Они поддерживали всё, не только desktop, web, mobile, silverlight, mono еще в 2007* (точный год не помню) умел запускать простые win form кросс-платформенно, то чего .net core не может или не хочет.

WinForm кроссплатформенно? Может вы путаете с другим фреймворком, типа Gtk? Потому что WinForms (а потом и WPF) были и есть только под Windows. Сейчас есть проект Uno для кроссплатформ разработки под все существующие ОС+web.

чего .net core не может или не хочет

насчет этого — думаю это довольно таки сложно вместить поддержку UI для Windows+MacOS+Linux в одну либу. Не буду говорить за Microsoft, но мне кажется это или очень сложно/невыполнимо, или невыгодно с точки зрения бизнеса, или над этим уже работают)

ИМХО это и не нужно, так как есть .NET Standart модуль, в котором вместится вся бизнес-логика, а способы визуализации под каждую платформу свои

www.mono-project.com/...​ng-winforms-applications

Это не только выполнимо, а уже давно выполнено и забыто.

Я это сам пробовал в 2008 году на OpenSuse, брал WinForm проект, билдил в Windows, потом запускал в линукс через

mono form.exe

Сейчас можно и девелопить под линухом, только начихуахуа?)

Ну это не совсем .Net — это Mono. Пути у Mono и .Net идут немного раздельно. Когда получится унифицировать рантаймы — тогда и о кроссплатформ UI сразу от Microsoft наверное можно говорить. Думаю что это просто не столь ценно для бизнеса, тем более сейчас — в тренде веб и мобайл, на десктоп сравнительно мало пишут.

P.S.

www.mono-project.com/...​ng-winforms-applications

Очень похоже на Gtk. Приходилось на GtkSharp писать GUI десктоп приложение под Windows и MacOS. На первый взгляд подход точно такой же.

Есть Avalonia. А MS не собираются делать WPF кроссплатформенным, это слишком затратно.

WinForm кроссплатформенно?

Да. Лично пробовал, когда нужно было кровь из носу запустить программку извлечения данных из бэкапа телефонов Nokia на Linux, написанную на обычном .NET.

А кто что скажет про Kivy?

Денег у них нет, пусть держатся)

Прочитал статью — неплохо написано про Xamarin, автор знает о чем пишет (за другие фреймворки не скажу, сам не сталкивался). Только вот непонятно — почему такая низкая популярность платформы Xamarin? Даже минусов как таковых серьезных нет.

Однако язык разработки и относительная дороговизна инструментов разработки делает Xamarin малораспространенным за пределами экосистемы Microsoft.

То есть выучить новый язык для флатера не проблема (которому два года), и работать с сыроватой платформой, которая еще в результате и не дает native ui — это интересно, а Xamarin с его возможностями и преимуществами — нет. Интересно получается) Может просто маркетинг хромает у Xamarin?

Спасибо) Я хорошо гуглю :-)

По поводу популярности

На счет ЖС фреймворков вопросов не возникает, надеюсь?
По поводу Flatter — очень похож на React/ReactNative, хороший PR и Dart особо не нужно учить чтобы говнять :-) Контейнер в паддинг завернул, стейтом приправил и го в прод)

«Dart особо не нужно учить чтобы говнять»
По ксамарину допустим, все довольно понятно, опыта у вас нет, но эта фраза тоже спорная, зависит от сложности компонента который от вас потребует заказчик и набора фич апки, флаттер все еще сырой для серьезных апок с частыми релизами. Более простые апки достаточно легко реализуются на всех фреймворка из списка. А по выбору стека у компании чаще всего решает пулл доступной экспертизы разработчиков внутри самой компании или хайп над самим инструментом.

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

Тем не менее не стоит воспринимать ее буквально. К тому времени как заказчику захочется вундервафлю и понимание дарта подтянется)

Я думаю що так + ком’юніті не таке велике як у RN для прикладу. Не один рік використовую Xamarin в проді, досить стабільно себе показує.

почему такая низкая популярность платформы Xamarin? Даже минусов как таковых серьезных нет.

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

А маркетинг у Xamarin в твиттере очень даже активный. Тут, скорее, может быть неприятие из серии «фу-фу-фу, это от Microsoft, которые сами не смогли в мобайл, так теперь лезут на другие платформы со своим дотнетиком»

Думаю у нас сейчас будет просто спор об «ощущениях» от использования той или иной технологии. У каждого свое субъективное мнение, тем более что многие из нас кодят только на одной технологии, поэтому тяжело спорить о преимуществах или недостатках других. Я пишу на Xamarin с 2015 года, и могу сказать, что Xamarin тогда — это велосипед, а сейчас — ракета) Ну а всем любителям мыслить категориями и шаблонами (e.g. я не люблю «дотнетик» и все что с ним связано) я пожелаю удачи :)

К сожалению Flutter еще достаточно молод и это порождает неожиданные трудности: нет поддержки Lottie, не native password autofill, нет поддержки TV платформ, Bluetooth плагин очень сырой. Возможно часть этих проблем уже как-то решена но год назад была пичаль.

На счет остального — прогресс есть, деталями не владею)

Lottie

уже есть.

native password autofill

особенности кроссплатформы.

Bluetooth плагин очень сырой

Уже получше

React Native — це останній виродок Web Dark Age.

Флатер, слава богу, відкрив нову епоху розробки:

www.gladimdim.org/...​ck899axp700aq9as1vjd1ip26

Тема избитая уже, react native примененяется массово и будет пока флаттер не превзойдет его в вебе, а если это и произойдёт то на это нужно время. Так что на данный момент и на ближайшее время react/react native или полный native или pwa.

После RN — Flutter как песня)
Если текущая аппа на RN бросаться переписывать не вариант. Или штат уже есть RN разрабочтиков которые не хотят/не нравится(ключевые слова) Flutter. В ином случае — если вы стартуете новый проект с активной командой не уверен что RN лучший выбор.

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

Если что, про material widgets / cupertino widgets я в курсе, но насколько они подстраиваются в плане внешнего вида под конкретную версию мобильной ОС, и насколько оперативно обновляются под look & feel самых свежих версий iOS и Android?

Под версию ОС они не подстраиваются. Кому-то плюс — аппа выглядит одинаково везде-везде. Кому-то — минус, так как хочется чтобы именно синхронизировалось с версией ОС.

Если у вас есть пример зачем выглядеть «супер нативно» относительно версии ОС — будет интересно почитать ваш кейс.

Под лук энд фил обновляются. Не в тот же день, но в целом соответствуют. Предполагаю что это ишью даст больше инфы github.com/...​tter/flutter/issues/43041

Если у вас есть пример зачем выглядеть «супер нативно» относительно версии ОС — будет интересно почитать ваш кейс.

Примера, увы, нет ☹ Но это тот контр-аргумент, который я очень часто слышу от native mobile разработчиков: мол, сразу видно, что аппа не нативная. Правда, тут хороший вопрос — волнует ли это кого-то, кроме самих разработчиков?

Соглашусь) Аргумент жиденький. До тех пор пока этот аргумент не отобразить в прибыли/убыли для бизнеса он, увы, пустой звук)

Строго ИМХО:

Несколько лет назад на рынке iOS приложений присутствовал определённый снобизм: если приложение не выглядело и не вело себя так, как предписано Apple, то такое приложение не имело шансов получить высокий рейтинг и популярность в App Store.

Но, потом, такие крупные игроки, как Facebook и Uber, переломили этот тренд, и сейчас нестандартно выглядящие приложения не вызывают отторжения у большинства владельцев iPhone / iPad.

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

Такой кейс имел место быть)

флаттер знає яка ОС крутиться і під неї можна підлаштовуватись. Є деякі системні компоненти, які самі підлаштовуються, інші треба вручну вибирати, але це не важко.

а що, реакт нейтів уже вміє в веб компіляться?

Есть react-native-web. На костылях и webpack позволяет собирать сабсет RN для браузера

ааа. самоделкіни. таке не зараховується :(

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

Таки да) В 2017 году было бы странным выбрать Flutter ;-)

www.youtube.com/...​39lLO-U&feature=emb_title

а точно. я ж забув що на РН все що можна зробити, це ліст вью і текстове поле. щось більш складніше і все...

Ну expo умеет с одной кодовой базы компилить и под веб в том числе. Но не все библиотеки поддерживают веб. Например влепил expo-sqlite — попрощался с компиляцией веб-версии, потому что там баг уже почти год как. Но если сильно-сильно надо, то можно получить и веб. Просто где-то придется более тщательно подобрать библиотеку, что-то напильником подогнать

Пришлось выпиливать Expo из проекта, чтобы нормально подключать все доступные библиотеки. Удовольствие еще то.

Я только начал изучать react-native (больше на всякий случай «для общего развития», чем с целью на нем работать) и документация советует для тех кто не занимался мобильной разработкой expo-cli. Для простых мобильных CRUD-приложений expo должно хватить, имхо.

Круто! Но лучше все таки флаттер. Перспективнее)

Может быть. Но всё в мире не поизучаешь 😅

Да, для очень простых приложений подойдет. Но лучше все же чистый RN, а еще лучше Flutter сразу начинать, как написали ниже.

expo це таке убожество, що я не знаю, ким треба бути, щоб затягнути його в проект. хоча, якщо проект чи продукт чужий для розробника, то можна. ще одна серд паті поделка.

Qt прекрасно працює у нашому випадку — десктоп під вінду і лінукс, і андроїд.

С++ дозволяє вкомпільовувати ту саму логіку як на гуї, на і на бекенді, і не думати про різні мови.

Qt останій раз 9 років тому бачив, здається вони також самі промальовують UI як і флатер. Але складність с++, складність ліцензування і його ціна (зараз ніби ж ліцензія за 500 для малих вендоров) а також оріентованість на «продати один раз за багато бабла» вбивали той фреймворк на мобілках.

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