Всем привет!
С командой планируем запускать мобильное приложение, что-то типа интернет-магазина.
Уже наваяли прототип на мобильной платформе 1С + HTML+CSS+JS (частично просто на формочках). Бэкенд, ессно, тоже есть.
Но этого мало.
Хотим выходить малыми оборотами в продакшен.
И тут приходит понимание, что с таким интерфейсом от 1С мы, как ни крути, далеко не уедем.
Стали думать уже писать на нативе, но тут наткнулись на Flutter.
Поизучали, штука вроде приличная.
Понятно, что сейчас уровень прототипа мы там запилим без проблем, тем более на готовом стеке HTML+CSS+JS на webview. И оно будет работать на всём.
Но, заглядывая вперед, приходит четкое понимание, что от этого стека придется уходить.
И чем дальше в лес, тем сложнее будут интерфейсы.

Соответственно, появляется вопрос: действительно ли возможности Flutter могут покрыть нативные? И действительно ли это будет дешевле в реализации?

Если вы не боитесь скобочек, то flutter вам зайдёт :)
Ну а так - Dart это альтернативный взгляд на "правильный JavaScript" от Гугла.
Под iOS я его собирать не пробовал, не начем, да и незачем. На андроидах работает весело.
Соберите пару экранов по туториалам. Зайдёт - берите.
Нет, ну есть ещё Native Script.

(1)
А что писал на нем?)

(0) Все плюсы флаттера и прочих подобных технологий убиваются одним огромным минусом.

Батарейка сцуко быстро садится...

(4) + Вот я тоже не понимаю нафига нужно приложение, я например никогда не ставлю приложения, если есть возможность посмотреть на сайте.
(0) Нафига нужно приложение, чем оно будет лучше сайта?

(4) Смотря какой магазин. Если часто пользоваться - то нужно приложение, ибо это быстрее и удобнее в разы. Если редко - то и просто веб-версия сайта сойдет.
Flutter - хорошее решение для начала, особенно если экономите ресурсы на команде. 1С-мобильное приложение в мусорку, конечно. React Native даже не рассматривайте.

(6) Все зависит от частоты использования магазина. На один-два раза смысла в приложении нет. А при частых закупках - приложение тупо быстрее работает, отсутствуют лаги (ну, должны, при грамотной аснхронщине), удобнее авторизация (по тому же отпечатку и т.д.), простая работа с геопозицией (для некоторых магазинов-сетей актуально). С точки зрения маркетинга - приложение привязывает пользователя к магазину, но тут важна красота и продуманный UX - пользователю должно хотеться пользоваться таким приложением.

(0) если есть специалисты, то почему бы и да. Ещё из той же оперы есть Xamarin от мелкософта, тоже кросплатформенные МП можно писать, но уже на C#. Такие фреймворки намного лучше ограниченной МП 1С. Но всё же, когда речь заходит о большой масштабируемости (миллионы разношерстных устройств), они уступают родным средствам: Java/Kotlin под Android, Swift под Apple

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

(8)  это для магазинов уровня Беру или iHerb

(11) Мы не знаем что там у автора. Может что-то узкопрофилированное для определенного круга людей, которые будут пользоваться этим постоянно. Да и требований к функционалу тоже не вижу, поэтому рассуждаем крайне абстрактно в контексте вопроса "а зачем вообще приложение?"

(8) Ну может быть конечно и есть какой то смысл, но я его все равное не очень вижу. Плюс каждую неделю потом еще нужно будет обновлять это приложение. Которое будет требовать доступа к камере, файлам, контактам и т.д.

(10) Меня безопасность этих манипуляций и в приложении отпугивает.

Хотел бы попробовать, но пока не знаю что на нём создать.

(14) Имиджборду пиши.

(9)
Да, рассматривали и xamarin, и React Native

(8)
Всё верно.
Но в нашем случае был еще один фактор: мы одинэсники. Поэтому запрототипировали на том, на чем могли это сделать максимально быстро ;-)
Ну и еще есть пара причин.

(7)
У тебя есть конкретный опыт?

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

(5)
Первый раз такое слышу)

kotlin  не рассматривали ?

(20) Любой не нативный относительно оси способ это всегда повышенная прожорливость ибо ресурсов больше тратится.

Flutter сам рисует UI, не используя имеющиеся контролы.

Это по сути как взять например https://github.com/golang/go/wiki/Mobile и на OpenGL самому контролы рисовать или использовать некую OpenGL либу.
Как в примере https://github.com/golang/mobile/blob/master/example/basic/main.go

(21)
Вот kotlin - только под android. Рассматриваем в том числе.
Но сейчас прорабатываем вариант одного приложения сразу под обе платформы. Для этого пытаемся разобраться, подходит ли Flutter в полной мере.

(8) >> при частых закупках - приложение тупо быстрее работает, отсутствуют лаги
Нагрузка на процессор у магазина небольшая хоть в приложении хоть в браузере. И не факт что в браузере будет медленнее чем в Flutter, скорее даже наоборот.

>> удобнее авторизация (по тому же отпечатку и т.д.),
Чем авторизация по отпечатку в браузере удобнее авторизации по отпечатку в приложении? Я не вижу разницы.

>> простая работа с геопозицией (для некоторых магазинов-сетей актуально).
Аналогично. Чем удобнее? Есть готовые библиотеки для веб, и такие же для приложения. Удобство для программиста почти одинаковое, для пользователя вообще нет разницы.

>> С точки зрения маркетинга - приложение привязывает пользователя к магазину, но тут важна красота и продуманный UX - пользователю должно хотеться пользоваться таким приложением.
Если только он установит его. Если установит, а потом удалит, то маленькая вероятность что потом снова установит.
На сайт может зайти в любой момент без всяких сомнений. Выйдет если не понравится. Потом снова зайдет если передумает.
Внешний вид сайта и приложения обычно совпадает полностью, так что с красотой разницы тоже нет.
Итого, приложение не нужно.

(10) >>  Например, через мобильный сайт ты не купишь с помощью платежного аккаунта гугл/эппл
Что мешает? Я покупал много раз.

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

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

>> по отпечатку в браузере
Как это там реализовано? Не откроется сайт без подтверждения отпечатка? Или после открытия надо нажимать "авторизоваться" и потом только входишь в личный кабинет? И каждый раз выходить из кабинета при окончании сеанса? В приложении ставишь блокировку перед его стартом и все - открытие только по отпечатку.

>> Внешний вид сайта и приложения обычно совпадает полностью, так что с красотой разницы тоже нет.
Совершенно не согласен. Анимация в приложениях на совершенно другом уровне. Красивые переходы между контроллерами, нормальные fps, моментальные отклик на действия пользователей и т.д. Повторюсь - кому-то на это совершенно плевать, но для большей части пользователей положительный UX является приоритетом, не просто так в это вкладывают столько денег.

(18) Есть определенный опыт, в iOS правда. Под вашу задачу (запустить в минимальные сроки и бюджет MVP) Flutter должен подойти, сейчас много на нем пилится. Он, конечно, вроде как однопоточный, но в любом случае быстрее, чем React Native. Наличие macOS обязательно для Flutter, если планируете сборку под iOS делать. Но лучше нативные kotlin + swift под две платформы, благо языки во многом схожи, а интернет пестрит мануалами и примерами.

(27)
"Но лучше нативные kotlin + swift под две платформы"
Почему лучше, на твой взгляд?

(26) браузер давно умеет все что ты описал

(29) Из точки А в точку Б можно доехать на большинстве машин. Так почему один седан стоит 500к, а другой 5500к?

(28) Потому что если будешь делать что-то более сложное, чем просто витрина магазина на Flutter, то все равно придется делать какую-то интеграцию с нативными инструментами. А значит надо один фиг углубляться в ту сторону. Отсюда - может уж лучше сразу на нативе писать? У Flutter немало библиотек, но все равно платформа очень молодая, в то время, как для Android или iOS на том же гитхабе есть решения на любые случаи жизни. Ну и в остальном не знаю даже как описать чем родное лучше сторонних платформ))
Все вообще зависит от задачи. Как я понимаю, Flutter сейчас - отличный инструмент для быстрого старта, особенно если на нем пишут люди, уже имеющий опыт в нативной разработке. Но говорить, что на нем тратится ровно в 2 раза меньше человекочасов, т.к. один проект на две платформы - преувеличение. Ну и чисто мне Dart вообще не зашел, но это субъективщина)

то что на хтмл сложнее - это однозначно

Вчера попробовали сделать Hello World.
Пришел к выводу, что пора менять комп) или хотя бы добавить ОЗУ) 8 гигов явно впритык

а мы еще на 1С ругаемся))

(26) >> Веб-страница, даже адаптированная для мобильного телефона, так или иначе тяжелее работает, чем то же в приложении.
Откуда у тебя такие мысли? Конечно нет. Представь что приложение - это браузер + веб страница два в одном. А сайт - это только веб страница, так как браузер уже есть на телефоне. Так будет проще осознать что веб страница гораздо легче чем приложение по весу, а работает так же, а иногда даже быстрее.

(26) >> она каждую страницу подгружает целиком при любом переходе.

Значит они неправильно сделали сайт. Просто не делайте так.

(26) >> Как это там реализовано? Не откроется сайт без подтверждения отпечатка? Или после открытия надо нажимать "авторизоваться" и потом только входишь в личный кабинет?

Вот как я бы это сделал:
Открывается сайт, нажимаешь кнопку "Залогиниться" или "Вход в личный кабинет" или как тебе больше нравится ее назвать. Появляется окно логина, где в первый раз нужно заполнить свои данные, и чтобы повторно их не заполнять - поставить галочку "запомнить меня на этом устройстве". Если не поставишь эту галку, и хочешь логиниться при каждом открытии сайта, то логин и пароль телефон сам предложит запомнить и будет их вводить в следующий раз после того как ты приложишь свой палец.

(9) Только не Xamarin, это жуткая вещь.

Я сравнивал Флаттер с React Native и решил не уходить с реакта. Если не нужен сайт, то можно и флаттер попробовать.

(26) >> Анимация в приложениях на совершенно другом уровне. Красивые переходы между контроллерами, нормальные fps, моментальные отклик на действия пользователей и т.д.
Все зависит от желания заказчика и как это реализует программист. Кто запрещает сделать красивые переходы на веб? Браузер поддерживает 60 fps, этого разве недостаточно? Моментальный отклик такой же как в приложении, никакой разницы глазом не заметишь, так как счет идет на миллисекунды, и в браузере бывает даже быстрее.