Почему мобильное приложение на 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 нашего тимлида Евгения Сатурова.

0
163 комментария
Написать комментарий...
Вадим Кулибаба

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

Ответить
Развернуть ветку
Daniel Martinez

Извините, но ваш комментарий выглядит как мнение человека далекого от мобильной разработки - на коленке собравшего приложение за 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 на лету. 

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

Ответить
Развернуть ветку
Артем Летюшев

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

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
160 комментариев
Раскрывать всегда