Мобильное приложение на Flutter. Стоимость, сроки, подводные камни. Часть 1

Flutter — бесплатный набор средств разработки (SDK) c открытым исходным кодом, разработанный Google для создания мобильных приложений. Другими словами, при помощи Flutter можно создать мобильное приложение для двух платформ (iOS и Android), используя один язык и общий код.

Flutter сегодня

В 2019 году в рунете стали популярны статьи о Flutter. Уже тогда обсуждалось, как быстро он исчерпает себя. Основной причиной такого внимания стало то, что это кроссплатформенный фреймворк для разработки мобильных приложений от Google, которому принадлежит платформа Android. Тогда все обратили на него внимание, кто-то попробовал, но, как часто бывает с новой технологией, быстро забыли.

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

Критерии выбора технологий

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

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

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

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

Сколько стоит разработка приложения?

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

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

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

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

Разработка для двух платформ. iOS и Android — это абсолютно независимые операционные системы, поэтому если нужно сделать приложение для обеих, по факту придется разработать два продукта с идентичным функционалом и стоимость разработки пропорционально увеличится вдвое. Представьте, что сайт может открываться на одном браузере, но чтобы он работал на втором, необходимо было бы делать новый. Возможно, это покажется диким и абсурдным, но таковы реалии в mobile dev.

Универсальные решения

Очевидно, что мысли об универсальном решении возникали у многих и не один раз. Было много попыток. Самые известные — Cordova, Ionic, Xamarin, React Native. Последний даже смог добиться неплохих успехов и на нем было написано несколько крупных приложений. Но тут тоже не все так гладко. Давайте вспомним AirBnB, которые подняли шум своей статьей с объяснением отказа от React Native.

Есть и противоположный пример, который выбивается из этого списка по многим параметрам, но отлично справляется с этой задачей: Unity — игровой движок, который работает с iOS, Android, PC, PlayStation, Xbox и даже в браузерах.

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

В чем же преимущества Flutter для бизнеса

Стоимость разработки. Выше мы написали, что при нативной разработке по факту оплата происходит за два отдельных приложения. Кроссплатформенное решение позволяет создать общую кодовую базу для двух платформ с последующей трансляцией кода на операционную систему через специальную прослойку. Это позволяет сэкономить от 30% до 50% на разработке приложения для iOS и Android.

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

Применимость фреймворка. Наш опыт работы с Flutter показал, что с его помощью можно закрыть потребности большинства запросов на мобильную разработку. Функционал и проработанность технологии позволяют использовать ее для многих сфер. А некоторые вообще лучше делать исключительно на кроссплатформе, например, приложения для интернет-СМИ, таких как Meduza.

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

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

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

  • натив Android — 6 часов
  • натив iOS — 5 часов
  • Flutter — 5 часов

Вроде бы никакой разницы, но есть один важный нюанс — приложение на Flutter запускается сразу на iOS и на Android. То есть, получается 11 часов против 5 часов. Это лишь одна задача, а в мобильном приложении таких много. Именно так появляется существенная экономия при разработке.

Большинство современных мобильных приложений — тонкие клиенты, которые просто получают данные с сервера и отображают в красивом формате. Качественное кросплатформенное решение, такое как Flutter, отлично справляется с этой задачей. То есть, около 90% современных мобильных приложений могут быть успешно реализованы на Flutter. Исключение составляют приложения, очень близкие к платформе с обязательным использованием стандартных компонентов, либо приложения со сложной технической составляющей — использование аппаратных средств девайса напрямую, соединение внешними устройствами, подключение легаси библиотек и тп. Но нерешаемых с помощью Flutter задач становится все меньше.

Анатолий Пешков, Технический директор Mad Brains

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

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

0
21 комментарий
Написать комментарий...
Ware Wow
Мобильная разработка — это дорого

Было. Как раньше с сайтами.
Хотя наверно студии и сейчас впаривают.

Ответить
Развернуть ветку
Олег Чебулаев

Да, рынок готовых и универсальных решений в мобайле отстает лет на 10.

Ответить
Развернуть ветку
Pavel Sherer

Окей, жду остальных частей с нетерпением. Особенно интересно, можно ли как-то сделать общие библиотеки на Flutter. Есть идея собрать плагин для Figma, который из макетов сам бы собирал базовые элементы для web и Flutter.

Ответить
Развернуть ветку
Antol Peshkov

Общие библиотеки в каком понимании? По плагину для Figma - хорошая идея! Можно пока присмотреться к вот этой штуке, что у них получилось https://medium.com/flutter/announcing-adobe-xd-support-for-flutter-4b3dd55ff40e

Ответить
Развернуть ветку
Pavel Sherer

Да, спасибо, это для XD, но суть, думаю, схожая, изучу. Касаемо общих библиотек – хотелось бы сделать единый набор компонентов, которые можно переиспользовать в разных приложениях. Может быть, пакетом отдельным, типа как Material у Flutter'а сейчас. Чтобы изменить пакет – и просто пересобрать приложения. Это частый кейс у корпоративных клиентов, когда им нужно несколько относительно простых внутренних приложений в едином стиле. Поддерживать такие сложно и нудно.

Общая схема в идеале была бы такая: 
1. Набор компонентов в Figma, собранных по определённым правилам.
2. Плагин для Figma, который проходится по всем компонентам и собирает из них готовые компоненты для Flutter и веба.
3. Какой-нибудь воркер, который по результатам работы плагина обновляет пакет для Flutter и библиотеку для веба.
4. В случае изменений разработчики просто обновляют зависимости приложений (веб и мобильных), пересобирают их.
5. Клиенту прилетают обновления. 

Ответить
Развернуть ветку
Antol Peshkov

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

Ответить
Развернуть ветку
Anton Smets

Гугл ещё в начале 2019 выделил отдельную команду, или она изначально была, никак не вчера она появилась.
На Флаттер очень сильно повлияет судьба Фуксии, если говорить про будущее...

Ответить
Развернуть ветку
Antol Peshkov

Если быть точнее, то трудиться над Flutter начали еще в 2014 или 2015 году (первая превьюшка была представлена в 2015-ом). Здесь же речь шла об отдельной команде для подготовки видео на YouTube, она начала выкладывать видео как раз в начале 2019-го
Fuchsia бесспорно повлияет на будущее всей мобильной разработки, но будущее Flutter уже сейчас вполне себе безоблачно

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

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

Ответить
Развернуть ветку
Antol Peshkov

Dart - главная боль и основной тормоз принятия Flutter. Вот если бы они Kotlin взяли за основу... Но их понять тоже можно, Dart с его виртуальной машиной, изолятами и сборщиком мусора - очень интересный язык. Осталось подтянуть синтаксис и удобство использования. Вон уже null safety почти завезли, останется от ';' избавиться - тогда заживем!

Ответить
Развернуть ветку
true iBegginer
> на голову выше других кроссплатформенных решений.

В каких местах RN на голову ниже flutter-а?

Ответить
Развернуть ветку
Alex K

Спасибо за статью. Если у вас есть опыт в разработке PWA с использованием Flutter - прошу поделиться :) да, это пока бета, но результат даже на бете я считаю очень хорошим.
Спасибо!

Ответить
Развернуть ветку
Antol Peshkov

Смотрели, экспериментировали, но много времени пока не уделяли, так как все может сильно поменяться. В будущем планируем уделить больше времени как только web устаканится

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

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

Ответить
Развернуть ветку
Antol Peshkov

А поделитесь ссылкой если веб-приложение вышло в релиз, каждый такой кейс интересен. 
Хорошо подмеченные минусы, часть из них просто болезни роста, но некоторые осознанный выбор команды разработчиков, как тот же отдельный стейт. По крайней мере это очевиднее чем то, что творится в SwiftUI (хоспаде-прости)
К вложенности тоже долго привыкали, IDE и плагины к ним немного упрощают жизнь. Но местами если не декомпозитовать ужасаешься пирамидам, так что по старой схеме "Разделяй и властвуй" ;)

Ответить
Развернуть ветку
Игорь Кравченко
Ответить
Развернуть ветку
Antol Peshkov

Спасибо, красивые картинки

Ответить
Развернуть ветку
Алексей Кметик

Все-таки он лучший, но не панацея. Производительность высокая даже на старых устройствах, код пишется быстро, слегка подбешивает dart(приватные поля ×#%#),но на фоне js это отличный яп. Все-таки требует знание платформы и kotlin/swift. За пару лет отберёт много хлеба и обесценит рынок мобильной разработки.

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

Ответить
Развернуть ветку
Antol Peshkov

Да, не панацея, с этим соглашусь полностью. Вот со знанием kotlin/swift - пока обязательно, иначе больно будет. Но мне кажется при должном развитии это может свестись к верхнему уровню понимания, как например раньше обязательно было понимание ASM для оптимизации программ, сейчас же большинство программистов знает о нем лишь по байкам дедов
Сырость некоторых вещей, детские болезни - да, есть такое. Тут только понять и простить, или помочь

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

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

Ответить
Развернуть ветку
Mad Brains
Автор

Алярм! 
Продолжение статьи тут — https://vc.ru/dev/143489-mobilnoe-prilozhenie-na-flutter-stoimost-sroki-podvodnye-kamni-chast-2

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