Разработка
Surf
19 904

Почему мобильное приложение на Flutter — хорошая идея для бизнеса в 2020 году

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

В закладки

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

В 2018 году команда Surf серьезно взялась за развитие кроссплатформенного направления. К лучшим практикам мы движемся все 9 лет, но именно в текущих условиях решением номер один для ритейла, финтеха и ecommerce стал Flutter.

Кроссплатформа бывает разной

Говоря простым языком, кроссплатформа — это набор инструментов (фреймворк), который позволяет создать приложение, подходящее сразу для iOS и Android. На первый взгляд звучит замечательно. На деле свои возможности и ограничения есть у каждого фреймворка. Их немало: React Native, Xamarin, PhoneGap, Titanium, Ionic, Flutter — самые популярные.

Идеальная кроссплатформа должна соответствовать двум требованиям:

  • быть экономичной с точки зрения разработки;
  • обеспечивать качественный пользовательский опыт.

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

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

Пользовательский опыт. Важно, чтобы пользователи воспринимали кроссплатформенное приложение как нативное — то есть как будто бы оно написано специально для этой платформы. Как минимум там должны быть плавные анимации, характерные для данной ОС элементы интерфейса, работа с жестами. И вот с этим плохо у всех, кроме Flutter.

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

Все это ухудшает пользовательский опыт, как следствие понижает оценки в сторах и retention (показатель возврата пользователей в приложение). Во Flutter такой проблемы нет, ровные анимации — его преимущество, можно без проблем использовать привычные и удобные для пользователя нативные элементы.

Перед тем как начать активно использовать Flutter, мы сравнили его с React Native. По итогу выяснилось, что последний в перспективе будет для нас проблемой. Сейчас позволить себе использовать этот фреймворк могут только такие гиганты, как Microsoft. Остальным же придется либо форкать и поддерживать свою версию React Native, либо участвовать в opensource-доработках. Малым и средним компаниям это не выгодно, поэтому мы как и многие другие (Airbnb, Uber, Udacity) отказались от него. Мы — в пользу Flutter.

Герман Сапрыкин, Grab
Senior Engineering Manager

Flutter — это свежий взгляд Google на кроссплатформу. При всей очевидности экономической выгоды даже для объемных задач технология относительно новая (2018 год), из-за чего многие разработчики не спешат ее использовать.

Однако в Surf не привыкли пасовать перед трудностями. Мы выбрали Flutter за его удобный инструментарий, простоту создания анимаций и компонентов UI, не уступающих нативным приложениям по скорости загрузки. Сама по себе технология будто специально создана для проработки микровзаимодействий, которые создают ощущение комфорта и обеспечивают качественный UX.

Конструктор, натив и кроссплатформа Flutter

Для тех, кому надо оперативно и антикризисно, уже придуманы конструкторы. Такой софт (Mobincube, Imshop.io и другие) позволяет сделать приложение быстро и дешево.

Но он не подходит для проектов, где важна гибкость, производительность, есть сложные интеграции и бизнес-процессы (например, 6–7 вариантов оформления заказа в мобильной аптеке «Ригла»), где планируются регулярные обновления.

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

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

Нативные приложения (написанные на родных языках ОС — Swift и Kotlin, для iOS и Android соответственно) не имеют серьезных минусов, но требуют значительных затрат на разработку и поддержку. Вам придется создавать бизнес-логику, верстку и интерфейс с учетом особенностей каждой платформы. Все это скажется на бюджете проекта.

Кроссплатформенное приложение на Flutter обладает достоинствами нативной разработки и позволяет переиспользовать большую часть кода между различными платформами, что позволит сэкономить, по нашим подсчетам, до 40% бюджета.

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

Особенно любимая программистами функция hot reload собирает приложение из виджетов буквально за секунды. В зависимости от сложности и самобытности проекта все это дает от 20 до 50% экономии времени, которое можно направить на разработку других полезных функций.

Flutter — идеальная платформа для прототипирования. Я как-то раз участвовал в марафоне, где участник (data scientist без опыта разработки) просто взял и собрал прототип простейшего приложения за несколько часов. На Android аналогичная разработка заняла бы на порядок больше времени.

Степан Гончаров, Lyft
Staff Software Engineer

Native vs мультиплатформа vs реальность

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

1. Быстрая разработка

  • Если сравнивать с двумя нативными приложениями, то разработка идет на 20–50% быстрее. Скорость зависит от сложности интерфейса и необходимых функций.
  • Если разработчик понимает, с какой стороны подступиться к задаче.
  • Если вам нужно не только срочно запустить приложение, но и ускорить дальнейшее развитие.

2. Выразительный и гибкий UI

  • Flutter позволяет реализовать нативный «look and feel», но прописывать UI-элементы придется вручную. Фреймворк сам настроит шрифты, физику скроллов жесты навигации и прочее.
  • Пользователи Apple находят небольшие отличия в UI (анимации, динамика).
  • Flutter идеально подходит для унифицированного UI/UX. Вы можете мимикрировать под нативные приложения и пользоваться привычными анимациями. Конечный пользователь не заметит разницы, если все виджеты будут настроены правильно.

3. Нативная производительность

  • Большинству современных приложений не требуется сложная логика. Запросы на сервер, работа с файлами и API платформы — все это во Flutter выполняется асинхронно и не ухудшает производительность приложения.
  • Команда Flutter заботится о быстродействии фреймворка. У него собственный графических движок, оптимизация в котором близка к нативной. Изображения меняются со скоростью до 60 кадров/с, что отлично воспринимается человеческим глазом.
  • На Flutter не получится сходу написать приложение, которое будет идеально работать на любом устройстве, любого года выпуска. Потребуются тесты, правки — все как на любом нативном фреймворке.

Почему разработка на Flutter дешевле

Чтобы было проще оценить преимущества Flutter перед нативом, приведем ход разработки проекта без платформозависимых функций. Например, небольшой магазин или программа лояльности с каталогом.

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

Трудоемкость считаем в идеальных днях. Разработка идет в два этапа:

  • запуск MVP (минимально жизнеспособного продукта) — 15–17 недель;
  • последующее развитие — 3 двухнедельных спринта.
Экономика проекта на Flutter. Ячейка — это неделя. Цифра в ячейке — ставка.
Во сколько обойдется запуск вашего приложения?

Получается, что Flutter в данном примере экономит нам 45,6% на разработке, 70,5% на QA с учетом использования автотестов в обеих командах, а также 33,3% на дизайне приложения.

Конечно, проекты бывают разные. Где-то Flutter может сберечь 15% бюджета, а где-то до 50%. Кроме того, возможно календарное преимущество при проектировании, так как вам не нужно синхронизировать логику между платформами. В Surf такие вещи обсуждаются до подписания, клиент заранее узнает преимущества и недостатки кроссплатформенных решений.

Приложение DSR (Digital Successful Routine) — это аналитическая BPM-система для менеджеров и команды ресторанов сети KFC. Благодаря идее Surf сделать его на Flutter нам удалось в рамках бюджета реализовать больше функций: уже в первой версии в приложении сделали отдельный интерфейс для работы с аналитикой и задачами для группы ресторанов. Кроссплатформенная технология для нас новая, но мы не пожалели. UI и анимации реализованы на высоком уровне, пользователи не отличают наше Flutter-приложение от нативного, все работает быстро.

Евгений Никитчук, KFC
бизнес-партнер

Flutter продолжает приносить выгоду и на этапе развития: команда меньше, релизные циклы проще, скорость выхода на рынок (time-to-market) сокращается.

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

Написание бизнес-логики на Flutter занимает столько же времени, что и на нативе. Однако верстка UI во Flutter безумно быстрая! Ты можешь за пять минут собрать макет экрана из кубиков и сразу приступить к бизнес-логике. Плюс к этому добавляются возможности отладки (hot reload), которые ускоряют верстку экранов просто в разы. В итоге нам удалось ускорить производство фич на проекте «Таксометр» почти в 2 раза в сравнении с нативной разработкой.

Илья Вирник, «Яндекс.Такси»
Flutter/iOS разработчик

Этап развития

После релиза MVP начинается этап развития, на котором у Flutter-команды добавление новых функций, по нашим подсчетам, происходит на 20% быстрее. Достигается это преимущество за счет тестирования.

Плюсы:

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

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

Минус:

Потребуется больше устройств, но это незначительно отражается на бюджете.

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

Если разработка не замедлится слишком большим количеством ошибок, вы сможете сэкономить дополнительное время

С преимуществами разобрались, а что насчет областей применения?

Какие продукты можно реализовать на Flutter

Кратко — любые. Сейчас Flutter широко используется для создания приложений в Alibaba, «Яндекс», Airbnb, Uber и других крупных компаниях. Мы считаем, что фреймворк лучше всего подходит для среднего и крупного бизнеса.

(Малому бизнесу Flutter не противопоказан, но полноценное мобильное приложение — это значительный бюджет, поэтому тут скорее выберут дешевое коробочное решение.)

С помощью Flutter можно создать приложения для:

  • различного ритейла (программы лояльности, каталог, онлайн-магазин);
  • банков и финтеха (работа с малым бизнесом);
  • поставщиков и франчайзи;
  • крупного бизнеса (контакт-центры, контроль курьеров, организация внутренних процессов).

Поиски быстрых и выгодных решений привели во Flutter специалистов из разных сфер. Например, Медуза решила отказаться от натива в пользу кроссплатформы, чтобы было легче развивать приложения синхронно. Другие, как команда «Яндекс.Такси», нуждались в оперативном развитии одной из платформ.

У нас была цель — разработка UI за два с половиной месяца. C нуля. В таких жестких условиях главными для нас были: быстрая компиляция, хороший тулинг, скорость UI, легкость интеграции нативного кода и интеграция в нативный код. Все это есть во Flutter. Для нас он был новой технологией. Пришлось защищать проект перед начальством, так как у нас не было точных данных о скорости разработки, тестировании и стоимости поддержки. Но в итоге снятые в ходе разработки метрики полностью оправдали наш выбор.

Геннадий Евстратов, «Яндекс.Такси»
руководитель группы iOS-разработки

На данный момент у Surf в разработке пять приложений на Flutter для различных отраслей и целей. Мы опросили клиентов, приложения которых уже запущены или еще находятся в разработке. Первое недавно вышло в релиз — приложение для аптечной сети «Ригла».

У «Риглы» около 70% мобильных пользователей и три аптечных бренда с единым складом. Создавать шесть нативных приложений неразумно. Мы долго изучали особенности натива и Flutter. В итоге для наших целей выбрали кроссплатформу от Google. Surf привнесли в продукт свежие идеи, часть из которых мы сразу же реализовали в веб-версии интернет-магазина.

Анастасия Боева, аптечная сеть «Ригла»
директор по интернет-продажам

Вопросы и ответы

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

Почему Flutter, а не другая кроссплатформенная технология?

Flutter работает быстрее и стабильнее других фреймворков — на частоте 60 кадров в секунду. Это позволяет сделать анимации более плавными и запускать приложения даже на старых моделях смартфонов. Внешний вид и UX Flutter-приложений делают их неотличимыми для пользователя от нативных.

За счет чего экономится время разработки?

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

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

Насколько Flutter безопасен?

Отличий от нативной разработки не будет, так как используются нативные технологии самой платформы: Touch ID, Face ID или сканер отпечатка пальца. Кроме того, код приложения зашифрован таким образом, что его нельзя восстановить с помощью реверс-инжиниринга.

Что если Google забросит Flutter?

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

Почему все не перешли на Flutter, если он так хорош?

Flutter набирает популярность. По данным Stack Overflow за 2019 год, его назвали любимым фреймворком 75% опрошенных — а это 3 место. Но за нативные приложения можно не переживать, они никуда не денутся.

Заключение

Flutter — не волшебная палочка, но перспективный фреймворк по скорости внедрения и широте охвата. Мы убеждены, что на горизонте 3-х лет до трети среднего и крупного бизнеса перейдет на Flutter вслед за коллегами из Tencent, Alibaba, «Яндекс» и другими.

Если вы ищете вариант быстрой разработки приложения для iOS и Android с перспективами развития, без серьезных потерь в качестве и бюджете — дайте шанс Flutter уже сейчас, как это сделали Surf и наши клиенты.

Опытом мобильной разработки на Flutter делились клиенты Surf и гости Flutter Dev Podcast нашего тимлида Евгения Сатурова.

{ "author_name": "Surf", "author_type": "self", "tags": ["\u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f","flutter"], "comments": 154, "likes": 88, "favorites": 471, "is_advertisement": false, "subsite_label": "dev", "id": 131105, "is_wide": true, "is_ugc": true, "date": "Mon, 01 Jun 2020 13:21:54 +0300", "is_special": false }
0
154 комментария
Популярные
По порядку
Написать комментарий...
28

Спасибо за статью. Flutter действительно классная штука, и я считаю его лучшим мультиплатформанным решением сейчас, но позвольте добавить немного дегтя. Возможно, я сгущаю краски, но все же. Стоит понимать, что, как и любая мультиплатформа, flutter реализует штуки, которые до этого были реализованы нативными командами гугла и эппла. То есть в лучшем случае у вас будет возможность поддерживать все, что есть нового в этих платформах, но с определенной задержкой по времени. Это в лучшем. А в худшем часть функционала вообще не будет реализована или отдастся на откуп написателям плагинов.
     Продолжая предыдущий пункт. Совместимость с нативнми функциями реализуется с помощью плагинов. И эти плагины часто делаются обычными людьми, а не самой командой разработки флатера и могут косячить. И чем нетривиальнее ваша задача, тем больше вероятность, что вы упретесь в их некорректную работу. Например, я копался с флаттером в январе-феврале того года. И мне надо было реализовать логин во внутреннем браузере приложения. На тот момент существовало 2 плагина длля работы с встроенным браузером. 1 был откровенно плох (не помню то чно чем, но там был очень ограниченный набор функций). А во втором, который использовался массово, не работала клавиатура. То есть она не появлялась вообще, когда ты пытался заполнить текст в формах. Насколько я знаю, этот баг актуален до сих пор (спустя больше чем год).  То есть чем больше нетривиальных действий использует ваше приложение, тем больше вероятность встрять. А если ваше приложение не имеет серьезной логики, а нужно только для размазывания json по формам, то да, флаттер отличное решение. Только мобильная версия сайта в таком случае справится не хуже.
    Так же не забывайте, что флаттер разрабатывается командой гугла,а не эпла. Поэтому основной упор делается на элемента материал дезайна. Насколько я знаю, там есть и ios ui элементы, но их не так много. И ui вам скорее всего придется также разделять на 2 части, так как ваше приложение та же модерация эпла может завернуть из-за несоответствия гайдлайнам. То есть вы опять придете к 2 версиям ui и 2 версиям бизнеслогики. 
И ваш общий код будет просто нашпинован условиями if(IOS){} if(Android){}
Это то, с чем я столкнулся год назад. Возможно, сейчас это все решаемо

Ответить
5

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

Пройдусь по некоторым пунктам:
1) "А в худшем часть функционала вообще не будет реализована или отдастся на откуп написателям плагинов." - хороший Flutter-разработчик должен быть таким писателем плагинов потенциально для каждой из поддерживаемых платформ, это факт. Да, есть кейсы, который вы сами не решите, например, вы вряд ли напишете WebView. С каждым днём таких проблем всё меньше, а экосистема развивается.
2) "Только мобильная версия сайта в таком случае справится не хуже." - ну это не так, приложение остаётся приложением и даёт другой уровень UX и вовлечения. На чём бы ни было оно написано.
3) "То есть вы опять придете к 2 версиям ui и 2 версиям бизнеслогики." - а откуда берётся 2 версия бизнес-логики? Что касается дизайна, наши проекты (как и подавляющее большинство приложений из топов сторов) чаще всего имеют уникальный кастомный дизайн с оглядкой на бренд-гайды кастомера. И там да, есть место для платформенных адаптаций, но речь не идёт о двух принципиально различных дизайнах с нуля под две платформы никогда. Проблем с ревью в Apple никогда не было по этому критерию.
4) "ваш общий код будет просто нашпинован условиями if(IOS){} if(Android){}" - полез специально проверять, на 90к строк кода нашего проекта 20 таких условных проверок. Кажется не страшно.

Ответить
10

1)"хороший Flutter-разработчик должен быть таким писателем плагинов потенциально для каждой из поддерживаемых платформ" - ну вот это как раз тот момент, который стоит учитывать. Что вы все равно так или иначе будете искать людей с опытом нативной разработки (куда ж без него), готовых работать на новом стеке.
2) Впринципе, я с вами согласен. Только с развитием телефонов и скорости интернета вся эта разница между нативом, кросплатформой и вебом потихоньку нивилируется. Те же PWA могли хорошенько так занять нишу и, насколько я понимаю, затормозились они из-за эппла, которому терять выручку с девелопер аккаунтов особо не хочется.
3)Ну с бизнес логикой я тут погорячился. Тут больше про взаимодействие с самой системой. Как пример - запрос пермишенов. Тут все таки разный флоу, разные ссылки на настройки, разная обработка реакции пользователя. А бизнем логика - она общая, да.
По поводу UI - это скорее частный пример из просторов интернета. Несколько раз видел, что приложение IOS было отклонено как раз из-за гайдлайнов.
В целом, это не была попытка доказать, что flutter хрень и вы не шарите, а именно другая сторона медали. Чтоб люди, когда будут принимать решение, а не сделать ли нам кросплатформу, понимали, что у него есть не только плюсы.
 Если же вас устраивает текущая экосистема, то это клссно. Надеюсь, у вас все будет ок.

Ответить
0

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

А в остальном: Flutter - это инструмент. Кому-то он может не подойти, а кому-то наоборот. Понятное дело, что он имеет свои ограничения, как и любой другой. 

Ответить
1

 приложение остаётся приложением и даёт другой уровень UX и вовлечения. На чём бы ни было оно написано.

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

Ответить
1

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

а то что не пройдет в эппл по гайдлайнам это интересно, про такое я еще не слышал о флаттере

Ответить
2

Ну вон товарищ выше написал, что баг до сих пор не поправили. Правда он написал, что это только у 2-5% пользователей. У меня же тогда косячило на эмуляторе +2 андроид телефонах. До ios я так и не добрался

Ответить
1

Например, я копался с флаттером в январе-феврале того года. И мне надо было реализовать логин во внутреннем браузере приложения. На тот момент существовало 2 плагина длля работы с встроенным браузером.

Вести с полей — проблемы с внутренним браузером никуда не делись. У нас точно такая же задача (логин в сторонней системе через браузер) и ожидаем решения траблы с клавиатурой с октября 2019. Но справедливости ради, баг этот случается у примерно 2-5% аудитории.

Ответить
0

а не подскажете где посмотреть публичный трекер ошибок флаттера, на что еще пользователи завели тикеты, есть такой?
или по стековерфлоу жалобы собирать?

Ответить
1

В самом гитхабе как минимум https://github.com/flutter/flutter/issues
Возможно еще где

Ответить
0

не, больше нигде. только там

Ответить
20

Хорошая статья, по делу. Мы в Mad Brains тоже активно развиваем направление Flutter, пока опыт очень позитивный. Главная сложность — это специалисты. Приходится переучивать или учить с нуля. Для бизнеса это не особо критично, он получает результат, а вот для студий, желающих вступить на эту дорожку, может быть сложно.
Также в статье не хватает, как мне кажется, сравнения более развернутого с другими кросплатформенными решениями, например, с Kotlin Mutltiplatform. Уверен, подобный анализ будет полезным. Можем подготовить статью от нашей команды, если сообществу интересно

Ответить
5

Подготовьте пожалуйста статью)

Ответить
1

@Surf Как вы справляетесь с поиском специалистов?

Ответить
3

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

Ответить
1

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

Далее у нас есть вводный курс на начальном этапе работы у нас.

Ответить
0

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

По нашему опыту минимально рабочая команда для продукта, который обладает высокой сложностью (использование камеры, навигации, общение с устройствами посредством jack 3.5) необходим один ios и один android разработчик + QA + менеджмент.  

Ответить
1

Ну если дизайн  с вашей стороны, то еще нормального ui/ux (а не оставлять на выкуп менеджера). Тогда будет и нормальная анимация lottie/flare и компоненты и вообще user flow со всеми состояниями и фолл беками. Экспортируй из цеплин/фигма/avocado на загляденье.

Ответить
1

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

Ответить
0

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

Но в целом котлин приятен.

Ответить
1

Да, к сожалению пока только добираемся до Kotlin MPP. Ну и пока он еще в experimental статусе.

Но ниже в коментах я уже указал, что МПП - это тема для команд от двух, а лучше трех разработчиков и проектов заточенных под гайды платформы.

Ответить
0

Kotlin Mutltiplatform и Flutter не взаимозаменяемые технологии, а наоборот, взаимодополняющие. На Kotlin MPP писать общею бизнес логику, а на Flutter UI часть.

Ответить
2

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

Ответить
0

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

Ответить
0

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

Ответить
11

Flutter это инициатива Google, с бизнес-целью продвинуть свой Dart, которым они хотели заменить JS (им не нравится перспектива зависеть от JetBrains и их Kotlin) Flutter это практически нейтив на Android, но на iOS примерно такие же проблемы как ReactNative. В больших городах типа Москвы около 50% владельцев, айфонов. Если вашему бизнесу не помешают страдания iOS пользователей, то можете использовать Flutter,  иначе будет как с Медузой: оценка хочет упасть ниже 3 звезд, лагает даже на топовых в айфонах, рандомные креши, ненативное поведение.

Кроссплатформа всегда была и будет низкокачественной, разумная альтернатива Kotlin Multiplatform тогда UI на обеих платформах остается нативным, а бизнес логика пишется один раз.

Ответить
7

По поводу оценок. 
Приложение написанное на Flutter в AppStore с 4.7 (https://apps.apple.com/ru/app/%D1%80%D0%B8%D0%B3%D0%BB%D0%B0-%D0%B0%D0%BF%D1%82%D0%B5%D1%87%D0%BD%D0%B0%D1%8F-%D1%81%D0%B5%D1%82%D1%8C/id1505062873 )

Приложение, которое бывало в топах апп стора: https://apps.apple.com/ru/app/reflectly-self-care-journal/id1241229134

Качество часто зависит от рук разработчиков. И натив - это не панацея от оценки в три звезды.

Ответить
8

Первое приложение тормозит на 11 Pro и в некоторых местах выглядит довольно плохо

Ответить
5

Потыкал это приложение, ну пиздец же просто. На десятке фризы при переходе в любую вкладку.

Наверно разработчики хуёвые тоже. :)

Ответить
–3

Разработчики выпускали первую версию в достаточно короткие сроки(не факт, что натив бы успел в такие).  Это часто важно для бизнеса.
Да и видимо аудиторию приложения устраивает производительность на данный момент.

И, думаю, сейчас ведутся работы по его улучшению.

Ответить
12

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

Ответить
9

1. Делаешь новостное приложение на Flutter.
2. Тратишь на это больше года (?).
3. Рассказываешь в своём блоге о том, как вы тестировали его с кучей ребят.
4. В том же блоге оправдываешься, почему именно Flutter.
5. На выходе получаешь кусок говна с оценкой 3.
6. Profit. 👍

Ответить
0

Добрый день! А можете проверить как наше приложение будет работать на вашем устройстве?
https://apps.apple.com/RU/app/id1486121900/id1486121900
Только выберите магазин Метро (там фото быстрее грузятся) и укажите любой адрес в Калужской области, мы пока не вышли на МО.

Ответить
0

Я тестировал ваше приложение почему-то изображения продукта не загружается)

Ответить
2

Новая Медуза это боль.

Ответить
1

Свежий выпуск подкаста Flutter-разработчиков Surf с техдиректором Медузы про их новое приложение: https://t.me/flutterdevpodcast_news/49 

В сторах уже 50 тысяч Flutter-приложений, но не каждое из них может похвастаться 100-тысячной метрикой daily active users. Ребята из Meduza с 2014 года прошли долгий путь от mobile-first концепции, через возврат к web-истокам и прокачку сайта до идеала обратно в мобайл. Переп...
В сторах уже 50 тысяч Flutter-приложений, но не каждое из них может похвастаться 100-тысячной метрикой daily active users. Ребята из Meduza с 2014 года прошли долгий путь от mobile-first концепции, через возврат к web-истокам и прокачку сайта до идеала обратно в мобайл. Перепробовав, возможно, все технологии на свете, они знали на что делать ставки - новое приложение Meduza написано на Flutter с нуля. У нас в гостях CTO Meduza Борис Горячев - человек-оркестр, который писал, кажется, на всём, что умеет хоть как-то исполняться. В эпизоде Борис рассказывает про непростые отношения с нативными разработчиками, удивительный мир медиа-разработки, игры со шрифтами, тяготах работы с WebView и Backend Driven UI, а также отвечает на претензии Артемия Лебедева.

https://soundcloud.com/flutterdevpodcast/16-meduza

У микрофона: Евгений Сатуров (Surf), Александр Денисов (Epam), Артём Зайцев (Surf), Евгений Кот (Wrike), Кирилл Адещенко (Tennesibet), Борис Горячев (Meduza).

Главное по выпуску:
❗️https://habr.com/ru/company/meduza/blog/501786/
❗️https://meduza.io/cards/meduza-god-delala-novoe-mobilnoe-prilozhenie-i-nakonets-vypustila-ego-zachem

События:
💥Flutter Day (25 июня) https://medium.com/flutter/save-the-date-flutter-day-june-25-2020-8e9f5fd03248
💥Flutterhack (27-28 июня) https://flutterhackathon.com/#/
💥🇷🇺❗️Mobius Питер (22-25 июня) - скидка от подкаста 13% по ссылке https://bit.ly/3cya65q или по промокоду Flutter2020pc

Интересное
:
💥Результаты опроса разработчиков Q1 2020: https://link.medium.com/1fey7J8fN6
💥Стартовал опрос Q2 2020: https://google.qualtrics.com/jfe/form/SV_5oNFjVJWGRECS3z
💥Про последние апдейты плагинов и инфраструктуры: https://medium.com/flutter/flutter-package-ecosystem-update-d50645f2d7bc
💥Что нового во Flutter 1.17: https://medium.com/flutter/announcing-flutter-1-17-4182d8af7f8e
💥Всё что нужно знать про поддержку Metal в iOS: https://github.com/flutter/flutter/wiki/Metal-on-iOS-FAQ
💥Adobe XD плагин в раннем доступе: https://medium.com/flutter/announcing-adobe-xd-support-for-flutter-4b3dd55ff40e
💥MWWM - архитектурный пакет от Surf в бете: https://pub.dev/packages/mwwm (чат: https://t.me/surf_flutter_team)

Официальный канал подкаста: t.me/flutterdevpodcast_news
Официальный чат подкаста: t.me/flutterdevpodcast
Ответить
1

Чего?
"Flutter это инициатива Google, с бизнес-целью продвинуть свой Dart, которым они хотели заменить JS (им не нравится перспектива зависеть от JetBrains и их Kotlin)"
Кажется, у Вас все смешалось в голове) Dart как замена js на вебе провалился уже очень давно и сейчас в основном используется для мобильных приложений и не рассматривалась как попытка заменить java/kotlin до 2017, пока они не доделали flutter, который также изначально был не гугловским и использовался для совершенно других целей. 
Нативный/достаточно близкий к нативному UI можно писать и на флаттере, нужно только его сделать максимально близким к нативу, практически все виджеты для этого есть и нужно только заморочиться с тем, чтобы сделать 2 UI на разные платформы (впрочем, как и в котлин MPP никто этим не заморачивается и не будет).
Flutter это исключительно флеймворк для отображения виджетов на экране, который никак не завязан на логику - вся логика - это dart, который по скорости будет примерно равен JS. Ни о каком "практически нейтив на Android" и речи не идет - просто виджеты гугл делает (что тоже логично) в основном похожие на свои платформы и заточенные под материал дизайн.
Плюс всегда во флаттере можно прокинуть часть логики в нативный код, что еще сильнее увеличивает преимущество над остальными платформами. Не считая Kotlin MPP, но он пока сыроват для прод проектов + под него все еще мало сообщества и плагинов, что также увеличивает время разработки. Ну и да, бизнес логику в дарте писать также один раз)
Вы хотя бы изучите вопрос прежде чем хэйтить платформу) Ну и да, медуза за прошедший месяц выкинула несколько обновлений, которые дали хороший + в производительности + ios часть флаттера перешла недавно на metal, что даст еще меньше лагов приложеньке. Так что ждем развития платформы, чего уж

Ответить
0

А в чём нейтив на Android? Что на Android, что на iOS всё устроено плюс-минус одинаково. И ни там, ни там, почти ничего нативного нет.

Ответить
0

это тоже обобщение, у моего приложения достаточно хороший рейтинг, а написать работу с плеером на Kotlin Multiplatform у вас не получится :D -  так что это тоже не панацея, да и в целом судя по отзывам Kotlin Multiplatform для интеграции в код не фонтан, лучше уж как это сделано во Flutter)

Ответить
0

а вот для MVP подойдет Flutter? Ваше мнение хочу узнать

Ответить
0

Субъективно на 2020 год лучше инструмента для MVP нет. 

Ответить
10

У меня скорее негативный опыт, с Flutter. Первое впечатление крайне положительное, разочарование приходит со временем.  Основное - крайне низкое качество системы в целом. Речь не о том что большинство плагинов тяп ляп собранные на коленке несовместимые ни между собой ни между версиями флатер ни между другими плагинами поделия. Речь о качестве самих библиотек разрабатываемых гуглом. Такое чувство что пишут их на коленке, даже в гугле, причем что странно не зная андроид. Например плагин запуска сервиса, начал запускаться после рестарта версии к восьмой. GRPC плагин выжирал батарею и постоянно терял коннект. Сыпал рандомными ошибками. Периодически гугл перевыпускает плагин, сразу прыгая на версию 2.0 например. И если потерянные коннекты пропали - жор батареи - нет. На айос рендеринг картинок "глитчит" при скроллинге. И жор жор жор батареи. Просто стыдно, открываешь приложение, которое не делает ничего, и оно жрет процентов 10 даже в спящем режиме. Сам флаттер работает совсем по разному в дебаг режиме и в скомпилированном режиме. В дебаг режиме просто ад, в скомпилированном получше. Естественно в скомпилированном режиме дебажить нельзя и тут здраствуй PHP стайл дебага с виджетом потребления ресурсов и тп. Постоянные обновления - приносят постоянную несовместимость и постоянные новые ошибки. Те обновление закрывает одну проблему но создает две новых. Гугл не мелочится и меняет версию дарт с 1.0 на 2.0 - превращая в мусор все что было написано на 1.0. Это сейчас неактуально но характеризует подход. Все будет постоянно ломаться, совместимость теряться и тп. БОльшей части библиотек нет от слова совсем. Работы с сокетами - нет. Работы с чтением почтового протокала - нет. Те сам дарт никому из нормальных разработчиков не вперся и библиотек под него не пишут. Фича с автообновлением (Hot Reload) -отваливается через день. Как только проект становится чуть больше hello world - все ломается и глючит - и отлаживать придется по старинке. Плюс в дебаг режиме все работает по другому - смысла в нем дебажить нет. Ну разве что UI. 

Ответить
8

Не влезло:
Сам язык - напоминает набор заклинаний. Это не язык, в нем нет продуманной системы классов как в яве или продуманной системы библиотек как в Go. Dart это миллион несовместимых между собой "синтаксических сахарков". В каждом виджете, в каждом методе -он свой. Те каждый разработчик делал каждую часть - по своему - без единной логики - и все что вам остается - это выучить этот набор заклинаний. Работа с комьюнити - на уровне - удалить тикет. Те вы пишите ишью - команда флатер просто его удаляет. На одну и ту же проблему - сотни идентичных тикетов висят годами. На все пишут единообразные заклинания -типа проблема с айос, проблема в симуляторе айос, проблема в настройках симулятора айос - или просто удаляют, закрывают и тп. Пилит фреймворк команда хрома. Чувствуется по массивности подхода. Простые решение - это не для нас. Просто берут мегабайтный кусок кода и втыкают в проблему чтоб ее заткнуть (ну, по ощущениям). В итоге, проект я доделал - но выкладывать его стыдно. Он жрет батарею. Глитчит на айос. Единственное что в нем хорошо - он визуально нарядный. В итоге из плея удалил, и в флатер больше не ногой. Пруф

Ответить
10

ну и объективности ради. Делал сложное приложение. С каналами как в телеграм, асинхронной подгрузкой и всем таким. На флатере я не видел ничего подобного. Ну 100 и один человек - начинают и пытаются написать мессенджер на флаттер но ни у кого ничего нормального не получилось. А какой то простой проект сделать на флатер - легко. И он будет наверное лучше реакт найтив. Но однозначно хуже нэйтив. Вобщем, в кроссплатформенной разработке, как выбирали 10 лет назад между кактусами - так и все и осталось.

Ответить
1

Извините, но ваш комментарий выглядит как мнение человека далекого от мобильной разработки - на коленке собравшего приложение за 2 часа пробежавшись по верхам и сложив субъективную негативную оценку. Если приложите пруфы про "удаление тикетов", и "мегабайтные куски кода для затыкания проблемы" буду благодарен.

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

Ну а теперь по пунктам.

1. Про собранные гуглом на коленке комментарий опущу, вы видно не привыкли читать хороший код, если есть примеры гавнокода - welcome. 

2.  "Сам флаттер работает совсем по разному в дебаг режиме и в скомпилированном режиме. В дебаг режиме просто ад, в скомпилированном получше. " 
" Плюс в дебаг режиме все работает по другому - смысла в нем дебажить нет. Ну разве что UI. " 
две реплики некомпетентного человека. 

Кодовая база для разных режимов абсолютно одинаковая (кроме отличий обоснованных build flavors либо CI), приложение работает абсолютно идентично за исключением: 
 * в дебаг режиме возможно пользоваться хот релод, из-за этого есть органичение на количество кадров рендера + расширенное логгирование + отсутствие минификации и обфускации
* для отладки релизного сборки приложения можно воспользоваться как минимум 3 методами 
 - использовать build mode https://flutter.dev/docs/testing/build-modes
 - профайлить приложение на ios девайсе предварительно скомпилировав dart code, а потом запустить через xcode в profile режиме
 - воспользоваться DartDevTools

3. Работы с сокетами - нет.  
 Абсолютное заблуждение, существуют как решения из коробки, так и от крупных вендоров/компаний 
https://flutter.dev/docs/cookbook/networking/web-sockets
* signalR - https://pub.dev/packages/signalr_client
https://pub.dev/packages/websocket_manager

4. "Работы с чтением почтового протокала - нет."
Заблуждение, для дарт существует большое количество пакетов, которые позволяют работать полноценно с актуальными почтовыми протоколами, для флаттер есть решение, оно в альфе но базовые вещи работают стабильно:
* https://pub.dev/packages/imap_client

5. "Фича с автообновлением (Hot Reload) -отваливается через день. Как только проект становится чуть больше hello world - все ломается и глючит - и отлаживать придется по старинке" - конечно, когда вы добавляете новые файлы, меняете структуру проекта или работаете с кодогенерацией, хотрелод не будет работать, про все эти моменты также написано в оф. документации. 
Задача хотрелоад позволять сокращать время разработки за счет моментально внесения изменений в определенном контексте, причем работает даже в DEBUG режиме, что позволяет менять не только UI, и видеть его ребилд, а также и вносить изменения в business logic на лету. 

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

Ответить
0

Ура, адекватный образованный человек!

Ответить
8

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

Ответить
10

Никто не хочет терять аудиторию из-за низкого качества (кроме Рокета и Медузы)

Ответить
2

Да бизнес вроде как не понимает зачем ему кросплатформенные приложения года так с 2010, когда я только начинал мобильной разработкой заниматься. Был и ReactNative, и Xamarin, и PhoneGap. Ну можно еще раз с новым фреймворком попробовать...

Ответить
0

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

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

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

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

Ответить
0

Мы предполагаем, что бизнес сейчас будет точнее считать расходы. 

Ответить
2

Что значит "сейчас" и почему он этого не делал раньше?

Ответить
2

Считают всегда, но в кризис вопросы бюджета и сроков обостряются. И потом, Flutter довольно молодая технология, многие еще открывают его для себя.

Ответить
1

Многие понимают, что найти специалиста по Dart намного сложнее чем по swift/kotlin, да и сам процесс декларативного программирования отличается от императивного.

Ответить
10

Действующий разработчик на Flutter (примерно полтора года стажа после восьми лет на iOS) – кстати готов к предложениям по работе. Могу попробовать ответить на какие-то конкретные вопросы. Несколько заметок к статье:

– Шаг вперед для Андроид. Техническая скорость разработки (да то же время компиляции и отзывчивость эмулятора) + возможность относительно простой реализации анимации играют очень большую роль. Возможно, наконец-то приложения на Андроид перестанут выглядеть бедными родственниками по сравнению с сборкой на iOS одного и того же проекта.

– Полшага назад для iOS. Халявы нет. Анимации делать руками, интерфейс сделанный по официальным гайдлайнам будет (слегка) притормаживать. К тому же это делал Google, а не Apple. Я не про техническую компетенцию, я про школы. Вплоть даже до того, что стандартные animation curves реализованы по-разному. Опытный пользователь iOS сразу почувствует "что-то не то, не могу понять что – но какой-то неуловимый нюанс". Все решаемо, но надо будет приложить усилия.

– Про плагины уже и без меня написали. Переходный период, устаканится. Есть серьезнее проблема - система разделения визуального компонента на публичный  Widget + приватный State. Если коротко - то слегка модифицировать компонент наследованием не получится. Или пиши свой или занимайся копипастой в тысячи строк.  

– Flutter хорош для энтерпрайзных/банковских/"серьезных" приложений. Там где нужно делом заниматься, а не лайки ставить геймпадом. Серьезные вычисления нативно, не через плагины, тоже пока не потянет (Dart это-таки JS, если  не вдаваться слишком глубоко в тех подробности).  Но в своей нише он действительно хорош, а будет еще лучше. Развивается прямо на глазах. Попробуйте его, особенно если ваш бюджет пока не позволяет держать армию ну очень недешевых  нативных разработчиков на один проект.

Ответить
0

Добрый день! Подскажите, пожалуйста, приложение такого плана можно сделать? 
https://play.google.com/store/apps/details?id=ru.egeapp2020.egeapp2020

Ответить
0

Здравствуйте, да, вполне, во всяком случае на первый взгляд непреодолимых сложностей не видно. Но, кажется, это Ваше приложение? Чем не устраивает текущее?  

Ответить
0

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

Ответить
0

Понятно. Да, вполне имеет смысл так и попробовать сделать.

Ответить
0

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

Ответить
0

А вы можете сориентировать по стоимости разработки? 

Ответить
0

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

Ответить
0

Просто по скриншотам по тз вам оценят очень грубо. Лично я в зависимости от требований предположительно просил бы от $5 до $10 тыс.

Ответить
0

можете отправить заявку с ТЗ на hello@surfstudio.ru 

Ответить
0

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

Стоимость зависит от количества времени, а время — от сложности проекта. Обычно есть 4 части проекта:

— перевод дизайна в код (2 часа на каждый уникальный виджет)
— разработка моделей данных (по 4 часа на модель)
— интеграция с API (по 4 часа на каждый вызов)
— тестирование и исправления (50% от времени)

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

Виджет — это один визуальный элемент, такой, как кнопка, картинка, иконка, надпись и так далее.

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

Цифры выше взяты из реальных проектов, хотя от проекта к проекту могут отличаться. Хотя в большинстве случаев, честно говоря, какую бы оценку не брать, ошибаешься в худшую сторону.

К примеру, приложение из 15 экранов по 7 виджетов и 10 функций API:

— перевод дизайна в код — 15 экранов x 7 виджетов x 2 часа = 210 часов
— разработка моделей данных — 3 модели (пользователь, товар, заказ) x 4 часа = 12 часов
— интеграция с 10 функциями API x 4 часа = 40 часов
— тестирование и исправления (50% времени) = 262 часа

Итого: 524 часа. Для стоимости в рублях нужно умножить на часовую ставку ваших программистов (обычно от 1 до 3 тыс. ₽).

Ответить
0

 Полшага назад для iOS. Халявы нет. Анимации делать руками

Нет ли каких-то готовых библиотек компонентов от сообщества, которые бы реализовывали анимации так, чтобы они выглядели родными для iOS?

Ответить
0

Я не могу встречал таких.

Ответить
10

Задолбали рекламить flutter как волшебную панацею в мире мобильной разработки, ну потыкайте вы новое приложение медузы или риглы. Они тормозят на iPhone 11 (на данный момент один из самых производительных телефонов), вызывает абсолютное отторжение, как это может заменить native?? Вы за деньги самих клиентов делаете их бета-тестировщиками сырого продукта от Гугл.

Ответить
8

после «Остальным же придется либо форкать и поддерживать свою версию React Native, либо участвовать в opensource-доработках.» желание читать отпало. явно не разобрались в вопросе, такие голословные заявления не понятно зачем делать, RN прекрасно работает, не надо ничего форкать, надо было такое написать вообще... майкрософт еще приплели сюда зачем-то. Зашел про флаттер прочитать называется)

Ответить
3

Много общих слов ни о чем.
Какие возможности для рисования графиков и диаграмм? Какая поддержка SVG / WebGL? Какие возможности для асинхронного REST и т.п.

Ответить
0

 Статья для бизнеса

Что? )) Бизнесу-то это зачем? Флаттер - инструмент для разработчиков.

Ответить
8

А заказывает разработчиков кто?) Клиент должен понимать, что он покупает, как его приложение будет работать долгие годы, как быстро будет сделано и сколько будет стоить в MVP и дальше. В тексте есть цитаты представителей Риглы и KFC — они тоже когда-то не знали о Flutter.

Ответить
1

Флаттер поддерживает canvas, для запросов есть официальный плагин http. Остальное, увы, не знаю.

Ответить
0

Ну, хоть что-то.

Ответить
0

Есть куча библиотек для графиков и диаграмм.
Есть либы для svg.

Так же полный аналог Retrofit для REST, реализация для GRPC,  уже готовые решения для БД и тд.

Ответить
0

Все что вы перечислили присутствует, причем количество альтернатив поражает. 
1. SVG - https://github.com/dnfield/flutter_svg
2. Async requests, для REST рекомендую https://github.com/flutterchina/dio, даже если используете из коробки http, решается все просто - https://stackoverflow.com/questions/50027632/optimal-way-to-make-multiple-independent-requests-to-server-in-dart

Ответить
4

Сейчас Flutter широко используется для создания приложений в Alibaba, «Яндекс», Airbnb, Uber и других крупных компаниях.

А можно вот тут сразу ссылки на конкретные приложения, лучше сразу под обе платформы? А то про Uber раньше говорили, что там есть RN, а на практике это был экспериментальный вспомогательный экран в приложении Uber.Eats для ресторанов.

Ответить
4

Читаю комментарии нативных разработчиков и в легком недоумении. Мы в itis.team пишем на Flutter с первого дня бета релиза. Все рассказывают про какие-то провисы, проблемы с ui, canvas/svg/step animation. Такое впечатление, что большинство дальше main.dart не заглядывало. Господа диванные эксперты, технологии почти 3 года. Библиотек море, многое оптимизировано ещё на бета релизе.

Ответить
0

Дико поддерживаю, использовал флаттер с первой альфы в пет-проджекте, в дальнейшем использовали флаттер уже в основном проекте, который содержит в себе работу и с WebSocket, и с навигацией, и OCR, активно пишем платформенный код, контрибьютим во многие пакеты, а также боремся с некоторыми незакрытыми проблемами, но стоит отметить, что альтернатив Flutter в данный момент нет. 

Ответить
0

Согласен полностью. Мы вообще с командой читали комментарии к статье под пиво. Набралось половину нативнщиков-неандартальцев, которые толком даже MVVM не понимают и пытаются использовать костыли во flutter, как привыкли. Здесь не работает императивный подход хера-стековерфлоу-херак - 1200 строк 1 класс и все, работает.

Ответить
0

Естественно с таким недоподходом у них провисает фпс и вообще в логике что-то не то.

Ответить
0

И на iOS всё корректно работает? Сам просто планирую изучить Dart и Flutter

Ответить
0

Конечно, это же кроссплатформ.

Ответить
3

Flutter хорош. Субъективно, сильно быстрее ReactNative и, конечно, Cordova. Как в работе, так и в разработке. О стабильности я вообще молчу.

Даже без знания Dart (до этого писал только на JS, PHP и немного Python) за неделю разобрался, а ещё за несколько вечеров написал приложение. Работает, скачивается, пользователям нравится. То есть порог входа сильно ниже, чем у тех же Swift и Kotlin. Это относительный плюс, конечно, но всё же.

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

Ответить
1

Удобство разработчика важная вещь, но нужно так же оценивать качество приложения получаемое на Flutter

Ответить
2

Флаттер покрывает почти все задачи для формочек и табличек, а именно такие задачи решает автор статьи, судя по бюджетам. Кстати, почему на нативе было  по 3 разраба, а на флаттере 4?

Ответить
3

Потому что необходимость писать платформенный код всё-таки не уходит совсем.

Ответить
3

Опа, приехали )

Ответить
0

Надо уточнить, что наличие такого "платформенного" кода крайне мало и далеко не всегда есть. Скорее есть некоторые платформенные настройки и конфигурации.

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

Ответить
1

Фигасе, отдельный верстальщик... Остальные, видимо, верстать не умеют? Что за команда с ограниченными способностями.

Ответить
0

Дополнительный, а не отдельный.

Ответить
0

Тем более )

Ответить
0

А какая кроссплатформа иные возможности предоставляет? Хотите делать что-то сложнее кнопок и списков - с этим придётся столкнуться в любом случае.

Ответить
0

Кроссплатформа - это кроссплатформа, она обязана предоставлять полный кроссплатформенный интерфейс. Иначе это не кроссплатформа, а фигня.

Ответить
0

что вы подразумеваете под кроссплатформенным интерфейсом? UI? 

Ответить
0

Так в этом и прелесть - если гугл/эпл выпустят обновление системы и там добавят какую то фичу нативно (например поддержку нового кодека или энергоэффективный протокол связи по BT или еще что либо) - не нужно ничего костылить на дарте и придумывать что то новое - нужно всего лишь прокинуть один вызов в нативный код, который уже все сделает адекватно. + в таком случае переносить уже существующее приложение бывает довольно удобно 

Ответить
3

за решения в виде конструкторов Mobincube, Imshop.io отдельная благодарочка

Ответить
2

Разве Airbnb и Uber используют Flutter?

Ответить
2

Они использовали React какое-то время и отказались.

Ответить
4

Это известно, но при чем тут Flutter?

Цитата:
Сейчас Flutter широко используется для создания приложений в Alibaba, «Яндекс», Airbnb, Uber и других крупных компаниях.

Ответить
2

Code Push есть в Flutter?

Ответить
0

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

Ответить
4

Ну тогда зачем он, этот Flutter? Если RN позволяет то же самое (кроссплатформенность) + еще и кодпуш?
И да, почему у вас в случае натива дизайнер работает на 2 недели дольше? Ему в обоих случаях надо нарисовать оба дизайна - для ios и для android, ему-то все равно как вы дизайн реализовывать будете

Ответить
5

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

Ответить
4

1. Пользователю неважно на чем написано приложение. Совсем.
Неважно сколько рисовал дизайнер и сколько компания искала разработчика.
Пользователю важны только целесообразность установки приложения, его удобство и его скорость.
Да, у RN есть кодпуш - это классная фича, но не та, из-за которой бросаем все и пишем на React Native.

RN проигрывает в скорости. Это я замечал в FPS и в ощущениях от приложения.

Есть статья про сравнение:
https://habr.com/ru/post/491832/

2. Flutter делает тоже самое только на бумаге.
У них совершенно разные подходы.

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

3. Дизайнер не просто рисует дизайн, а дальше выкручиваетесь как хотите. Он как часть команды, решает задачу. И не обязательно рисовать на 2 платформы. Дизайн может быть один на обе и, если нужно, в чем-то отличаться.

Интересно, а что вы делаете когда прилага большая и гоняется много данных? У моих знакомы в RN до сих пор головная боль - постепенное замедление приложения из-за этого.

Ответить
3

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

И отсюда вытекает следующий пункт:
Flutter обновляется регулярно и весомо. В RN как-то с этим медленнее.

Ответить
1

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

Ответить
0

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

Ответить
1

Принципиальных разниц - несколько.

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

Но флаттер - это скомпилированное приложение, которое работает в скомпилированном виде. В RN есть пресловутый js bridge, который нужно задействовать при необходимости связывания нативных элементов и кода приложения. Для многих частей это норм, для анимации придумывали костыль (условно годный), а вот списки будут тупить. Пока решение этой проблемы в фэйсбуке не особо придумали и не внедрили, но думают (файбер?).

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

Ответить
0

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

Ответить
2

Это не новый подход - он имеет знакомые грабли. Погуглите про Delphi FMX (FireMonkey) - там много критики. Ну и Qt - почти то же самое. 

Рисовать свой GUI здорово подходит для приложений, которые и не планировали использовать нативный GUI: игры, визуализация всякая или оригинальный интерфейс. 

Для "стандартных" приложений пользователи ожидают на месте похожих на стандартные элементы управления увидеть стандартные элементы управления, которые ведут себя знакомым образом. Например, - типа с iOS 13 уметь менять тему на ночную. А если вы эмулировали GUI - вы как будете делать? Если приложение использует iOS 13, то включать ночной стиль, а если запустилось на старой iOS - то не включать? Два разных компонента включите в свое приложение - для старой iOS и для новой?  В общем, проблема когда управляющие элементы в разных версиях ОС ведут себя по-разному - она плохо решается при эмуляции этих элементов.

Ответить
1

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

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

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

Ответить
1

Интересно посмотреть на отзывы про Медузу в App Store. Рейтинг - 3 из 5. Жалуются на лаги и странное поведение. И это - закономерно

Ответить
0

Производительность React ниже, подробнее про технические аспекты есть наша статья: https://apptractor.ru/info/articles/flutter-buisnes.html 

Также готовим статью на Хабр про сравнение RN и Flutter.

Ответить
0

Пользователи Медузы на iOS посредственно оценивают производительность flutter

Ответить
0

CodePush не запрещен, однако запрещена подмена одного бандла другим, это понятно, читерить это плохо, "хитрожопых никто не любит" (с)

Однако, CodePush не панацея в читерстве сторов, а именно у вас всегда есть возможность подменить логику, через API. Допустим, вы один стартап, который продает приложения для рисования и медитации, этакая раскраска, и вы на этапе ревью отключаете на экране покупки режим, в котором весь экран становится кнопкой (да да весь, хрен ткнешь мимо), но когда ревью проходит, апп в сторе, вы идете в CRM и включаете все, что вам нужно. 

Удивительно, как их еще не забанили. 

Ответить
0

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

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

Ответить
0

  мы вряд ли перейдем на Flutter ближайшие лет 5

Ничего себе. Через 5 лет Flutter устареет, а RN вообще отойдет в древнюю историю.

Ответить
11

Выйдет новая хайповая кроссплатформа и все побегут костылить на нее как прошедшие 10 лет: PhoneGap/Cordova > ReactNative > Flutter. Профессиональные мобайл разработчики смотрят на это как на цирк т.к. кроссплатформеры приходят с незнанием UI/UX мобайла и гайдов(HIG/Material), и тянут веб подход с кастомными компонентами, в итоге оценка приложения падает ниже 3, а пользователи ноют, что невозможно пользоваться.

Ответить
3

До Flutter смотрел на кроссплатформу как на цирк.

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

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

По поводу гайдов: сейчас часто наблюдаю даже нативные приложения, которые отходят от гайдов конкретной платформы. Есть много brand first design приложений. Здесь Flutter также позволит уменьшить стоимость разработки.

Ответить
0

Какой там хоть ЯП? Жаваскрипт?

Ответить
0

Dart. Не JavaScript. Формально похож, но это другой язык.

Ответить
1

Dart. И плагин к нему - Vader. И темная тема. Ок

Ответить
0

Flutter можно смело заменить на React Native и ничего не изменится 

Ответить
3

Здесь видимо нужно пояснить.
Любая кроссплатформа преследует свои цели, например, вы пишите первую версию на RN, потому что дешево, далее решаете, окупается продукт или нет (мы ведь тут с вами собрались не ради холивара RN vc Flutter, мы тут про деньги прямо или косвенно). 

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

Да любая кроссплатформа это больно, а любой нэйтив на старте проекта - дорого, да еще и два раза. 

Ответить
1

Если бы натив под платформы был удобоварим, им бы пользовались все. Но увы...

Ответить
0

Когда только пришел из RN - писал медленнее, потом все стало ок.
RN тоже не форкал.

Ответить
0

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

Ответить
3

В отличии от многих продуктов Гугла Flutter - это опенсорс. Убить его в привычном смысле невозможно.
Так же если посмотреть на слухи о той же Фуксии - она должна поддерживать Флаттер из коробки, а это уже кажется долгоиграющей песней.

Ответить
1

Chromium OS также казался долгоиграющей. Под него даже ноуты выпускали. И тоже опенсорс. Убить невозможно, просто все будут смотреть в сторону какой нибудь Фуксии. 

Ответить
1

React Native тикай с городу.

Ответить
1

сравнение только с React Native, а что насчёт Xamarin.Forms?

Ответить
1

Хороший вопрос, раз уж речь идет о кроссплатформах я бы еще спросил про Monogame, Unity и Unreal и послушал каково это делать продукт под все платформы нативно, вместо использования кросс решений. Тот же Bastion отлично себя чувствует и написан на Monogame для почти всех платформ.

Ответить
0

В данном случае: потому что Xamarin не настолько популярен. Все же основная война - между Flutter и RN.

Плюс, насколько я знаю даже майки используют тот же RN вместо Xamarin в своих проектах(пример Скайп).

Ответить