Comments 10
Ох, так это же такой же "чупачупс" как у нас на бекенде микросервисы! Вот мы ща как сделаем, как будет нам хорошо, как настанет на проекте рай! А потом - так это все вы, инженеры бездарные, запороли такие идеи!
Так что, Flutter надо было?
Возникнет вопрос, почему не Flutter? И у меня есть ответ: look and feel нативных приложений.
А что мешает его получить?
Несмотря на все успехи KMP и Flutter, они всё ещё уступают нативным решениям по скорости
Есть подтверждающие это метрики? За КМР не скажу, не пользовался, но у флаттера нет проблем со скоростью – благо он компилится в нативный код.
и интеграции с платформенными API.
Конкретно, с какими?
Работаю в большом интеграторе западном, делали проекты для правительства uae и автомоутив для одного немецкого концерна. Исследования в области декларативных ui провалились как по скорости разработки и поддержки, так и качеству и гибкости работы над самой визуальной составляющей, да и скорость работы компоуз интерфейсов вызвала вопросы, и заметно подросшие ресурсы. Для приложения доставки пиццы это рабочий кейс. Для серьёзных вещей - неудобно и медленно. Да, разработка под андроид aaos и aosp. Разработка архитектур систем всегда должна отталкиваться от бизнес и продуктового мышления, а не от слепого следования вещам типа Паттерны банды 4х, тотального ООП, или clean architecture.
Статья, мне кажется, немного не соответствует заголовку.
В ней как будто есть подтекст: говорится об абстрактных проблемах, но в основном - о том, что разработчик должен уметь адаптироваться и иногда брать на себя функции менеджера. Мультиплатформенность - это хорошо, но важно глубоко знать платформенное API.
Здесь есть классическое противоречие. Создается ощущение, что между строк звучит мысль: "Быть программистом-арестром это хорошо".
Но вот проблема: такой разработчик вряд ли сможет в совершенстве овладеть конкретной технологией.
Велосипеды изобретать будут всегда. Некоторые библиотеки забрасываются, быстро устаревают, а найти им надежную замену не всегда получается. Вот и приходится писать свое решение.
Мне кажется, вы очень много требуете от мультиплатформенных решений. Да и многие из описанных проблем уже не актуальны.
Все перечисленные проблемы из-за сжатых сроков разработки и отсутствии исследований перед её началом (спросить у сообщества CMP существующие проблемы, какие кейсы позволяет закрыть библиотека, а какие нет).
Решение: определили стек технологий, определили границы решений, согласовали с бизнесом, собрали MVP.
P.S. Я не представляю какой SuperApp требуется поручить команде (не одному человеку, а именно команде профессиональных разработчиков), чтобы не хватило 3 месяца на реализацию MVP.
P.P.S. В статье не приведен временной промежуток, когда шла разработка. Одно дело собирать проект в 2023 году, когда таргет под iOS только вышел, а другое - 2024/2025, когда KMP & CMP в stable, а в библиотеки завезли мультиплатформу / написали новые.
Интересная статья, но во многом не согласен. Мы сейчас как раз пишем приложение на KMP + CMP, и у нас все выходит без каких-либо проблем. На поддержку iOS мы потратили всего пару дней, так как надо было реализовать работу с кастомной камерой, пермишенами. Все остальное перенеслось без доработок
Мы не поддерживали нативный look and feel, так как от нас этого не требовали, но реализовать его тоже не проблема, есть даже либа.
C Preview в Compose как мне кажется всегда была боль и разрабы их часто не пишут так как привыкли верстать в голове. Cейчас в последних IDEA (Начиная с IntelliJ IDEA 2025.1 EAP) preview в commonMain тоже завели (ждем в android studio), для desktop вообще hot reload появился. В любом случае никто не мешает вам в android target preview завести, не очень удобно конечно, но все таки возможно
У нас в проекте был Compose Multiplatform, но снова я бы так не делал