KMP vs Flutter: 4 сценария, когда нужно сделать ставку на Kotlin Multiplatform, а не Flutter

Кроссплатформенные инструменты помогают бизнесу не писать код два раза под iOS и Android, а переиспользовать его на обеих платформах. В статье — о том, чем Kotlin Multiplatform отличается от Flutter и в каких случаях он переигрывает и уничтожает Flutter.

KMP vs Flutter: 4 сценария, когда нужно сделать ставку на Kotlin Multiplatform, а не Flutter
9.2K9.2K показов
4.2K4.2K открытий
11 репост

Честно, прям сильно не понял про невероятный Bluetooth, и проблемы с ним.
Мы используем сканеры Zebra, Honeywell, Urovo, в том числе с SDK от Honeywell, и всё отлично заводится и сканирует.
Доступ к нативной части приложения так же - не немыслимая вещь, ведь существуют MethodChannel.
Да, тут надо покопаться, если есть потребность идти в натив. Но, опять же, это необходимо чуть ли не единоразово для подключения и настройки. Далее - логика работы с данными, и тут уже вечеринка, с бизнес-требованиями и блэк джеком.

В плане ui - тоже не понял проблемы.
Вроде того, что кому-то надо на андроиде видеть стандартные виджет андроида, а на iOS - айосные?
Чё ж там с дизайнерами происходит? И почему бы не дать всем один внешний вид продукта, исходя от требований бизнеса, бренда, фирменного стиля, а не платформы?
Но тут, опять же, у всех свои потребности.
(Ну и не стоит забывать, что стандартные виджеты что Андрюши, что ИОС - лежат в самом флаттере в базе)

В плане того, что можно с Kotlin пильнуть приложку так же, и под ios, дорисовав интерфейс - клёво.

Но рассказывать про то, что flutter - не для бизнеса, тут не убедил.

p.s. На хакатоне вполне себе отлично заносили пакет Яндекса для работы с их картами. Да, там есть ограничения, в веб версии отказался заводиться.

Ответить

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

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

Для примеров можно открыть тысячи issue платформ ios и android (https://github.com/flutter/flutter/issues?q=is%3Aopen+label%3Aplatform-ios%2Cplatform-android+). Некоторые из проблем кажутся незначительными. Но есть и глобальные, например: 1(https://github.com/flutter/flutter/issues/82906), 2(https://www.reddit.com/r/FlutterDev/comments/yywx66/attn_all_your_vote_is_needed_to_fix_critical/), 3(https://www.reddit.com/r/FlutterDev/comments/1140pdv/two_years_later_flutters_biggest_problem/) .

Ответить

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

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

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

Ответить