Фанат нативной разработки выбрал Flutter для новых приложений Plussios — так можно описать меня вчера вечером.

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

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

Резюме (Executive Summary)

React Native отклонил, так как для него нужно много сторонних библиотек, которые часто забрасывают. Он не даёт существенных преимуществ перед Flutter.

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

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

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

Требования

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

Соответственно, необходим доступ ко следующим возможностям устройств:

  • Геолокация.
  • Хранилище для оффлайн-данных.
  • Работа в фоне для обновления данных и отправки изменений в режиме оффлайн.
  • Оплата и подписки в приложении.

Ключевые бизнес-требования для выбора платформы по убыванию важности:

  1. Быстрый запуск приложения и ввод транзакции (см. требование по скорости).
  2. Минимальный срок разработки базовой версии.
  3. Минимальные затраты на разработку и дальнейшее развитие приложений.
  4. Минимальный состав команды разработки.
  5. Разработчиков должно быть достаточно просто найти.

Сравнение технологий

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

Фактор Нативная разработка Flutter React Native
Нужно разработчиков 2 1 0
Сложность поиска разработчиков Низкая Высокая Средняя
Размер приложения (Android), Мб 0,54 7,5 7,0
Поддержка WatchOS1 Есть Нужно разрабатывать отдельно Нужно разрабатывать отдельно
Поддержка Crashlytics2 Есть Есть Есть
Поддержка Amplitude3 Есть Есть Есть
Accessibility4 Есть Что-то есть Что-то есть
Работа в фоне Есть Что-то есть Сложно
Оффлайн-хранилище Есть SQLite, файлы, ключ-значение Сложно
Пуш-уведомления Есть Есть Что-то есть

Нативная разработка - наилучший вариант с точки зрения доступа к возможностям системы и производительности. Но она требует 2 отдельных разработчиков или двойной бюджет. При самостоятельной разработке, с учётом обучения, для нативных версий суммарно потребуется в 1,5 раза больше времени, чем для кросс-платформенной.

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

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

В отношении Flutter есть неопределённость в плане фоновой работы и оффлайн-хранилища. Документация есть, но нужно проверить, насколько оно хорошо работает. Также есть опасения о скорости работы - это тоже нужно проверять.

И таблица с моим любимым SWOT-анализом:

Нативная разработка Flutter React Native
👍 Плюсы + Наилучшая производительность и наименьший размер приложений.
+ Доступ ко всем возможностям каждой системы.
+ Нужен только один дополнительный разработчик.
+ Единый вид на всех версиях устройств — меньше проблем с поддержкой старых версий ОС.
+ Быстрые итерации разработки.
+ Может разрабатывать фронтендер, не нужно дополнительных людей.
+ Стабильность: более 5 лет на рынке, использована в крупных приложениях (FB, Tesla).
+ Быстрые итерации разработки.
👎 Минусы - Нужны два отдельных разработчика.
- Дорогая начальная разработка.
- Не поддерживает 3D-touch.
- Зависимость от Google для всего фронтенда.
- Много путей для решения одной задачи. Нужно тратить время, чтобы разобраться.
- Зависимость от библиотек, многие из которых заброшены.
- Мало готовых элементов, адаптированных под iOS и Android. Нужно писать свои.
- Медленно исправляют ошибки в платформе (отсюда).
💡 Возможности + Можно оптимизировать внешний вид и поведение под каждую платформу. + Можно сделать веб-приложение тем же кодом и заменить JS-разработчика.
💣 Угрозы - Сложно исправляемые креши.
- Блокировки от Apple.
- Сложно исправляемые креши. - Блокировки от Apple.
- Обновления OS могут сломать приложение.
- Может потребоваться оптимизация под каждую платформу.

Доступность разработчиков

Собрал статистику о вакансиях и резюме по данным сайта headhunter.ru на 18.08.2021. По каждому запросу из таблицы искали в разделах Вакансии и Резюме. Установлен фильтр по региону “Россия”, остальные фильтры оставлены по умолчанию.

Запрос Вакансии Соискатели Индекс5 Нижняя отсечка зарплаты
Flutter 446 1 248 2,80 До 65 000 (103 резюме)
React Native 752 2 136 2,84 До 100 000 (270 резюме)
Android разработчик 3 467 22 490 6,49 До 75 000 (2 640 резюме)
iOS разработчик 3 199 14 466 4,52 До 85 000 (1 347 резюме)

Нативных разработчиков на порядок больше, чем кросс-платформенных. Тем не менее, найти разработчика на Flutter, для которого сильно меньше резюме, выглядит вполне подъёмной задачей.

Минимальные запрашиваемые зарплаты выше всего у разработчиков на React Native. Самые низкие - у разработчиков на Flutter.

Размер приложений

Нашёл два сравнения размеров приложений: одно для Android, другое для iOS. В последнем не рассматривали React Native. В обоих случаях делали простейшее приложение с одной кнопкой. Итоговые размеры приложений в мегабайтах по данным из статей привожу в таблице.

Сравнение Нативное приложение Flutter React Native
Android 0,54 7,50 7,00
iOS, только нативное и Flutter 23,20 52,40

Заметка на полях: при определении размера приложения, нужно учитывать, что после загрузки на устройство, размер уменьшается. Например, в этом вопросе на SO размер app-файла был 475Мб, а при загрузке на устройство стал 29Мб.

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

Выводы

React Native отклонил из-за сложностей с библиотеками. По поводу Flutter не смог найти известных существенных проблем и аргументированных опасностей, хотя потратил на поиски часа три.

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

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


  1. Если захотим разрабатывать расширение для умных часов. ↩︎

  2. Crashlytics — система сбора и анализа событий непредвиденного завершения работы приложения. Или проще, анализ креш-логов. ↩︎

  3. Amplitude — система сбора статистики поведения пользователей в приложениях. ↩︎

  4. Accessibiliy — инструменты, повышающие доступность приложений для людей с плохим зрением. Позволяют устройствам зачитывать название и назначения элементов интерфейса. Эта функция как-то работает без дополнительных усилий разработчика. Чтобы она заработала корректно и удобно, разработчик должен указывать дополнительные свойства для некоторых элементов. В таблице сравнил, насколько это возможно в каждом из вариантов. ↩︎

  5. Индекс — соотношение количества соискателей к количеству вакансий. Чем выше индекс, тем выше конкурс на место, и тем проще должно быть подобрать сотрудника. Считаем, что при индексе меньше 1 найти сотрудника будет крайне затруднительно. ↩︎