Почему вам не нужен Kotlin Multiplatform

[@AndroidBroadcast]

🔗 Платная подписка на Boosty abdev.by/oroS 🔗 Платная подписка в Telegram abdev.by/lrpW 🔗 Telegram Android Broadcast t.me/+y-LPEB3R5-9mNmRi 🔗 База знаний Android разработчика abdev.by/graa

[@frezycode]

Ну хоть кто-то не стал орать про убийство Flutter а рассказал непредвзято про KMP . Кирилл, спасибо большое за конкретику! Искренне желаю KMP развития с такими специалистами

[@alsh2887]

Он как раз рассказывет предвзято. Половина его рассказа - нежелание андроидщика изучать новую технологию.

[@AndroidBroadcast]

Flutter сейчас для протитов и простых приложений более жизнеспособная технология, но я очень жду 2025 и там будет много сделано для улучшения опыта разработчиков в KMP

[@sb-dor]

​@@AndroidBroadcastНемножко недопонимания. Для каких простых приложений ? Типо add to cart приложения ? Или на котлине все проги написаны для Rocket science?!

[@maudau-bz7dl]

Тут такое дело, что если послушать, что говорят представители команды KMP из Jetbrains, то можно понять, что простота внедрения и использования, вообще не входит в список приоритетов. Цель стоит сделать узконаправленную технологию "для избранных"

[@mmiro]

​​@@AndroidBroadcastбанковское приложение, или видеоплеер я бы нашем не писал, но для всего остального Flutter уже вполне подходит, даже небольших 2D игр(Flame)

[@evgeniy9248]

в заключении не хватает вставки "Флаттер выглядит сейчас стабильней" )))) Хотите мультиплатформу)) попробуйте флаттер и dart ))

[@AndroidBroadcast]

Flutter - хороший продукт для своего спектра задач

[@Symbi0x7]

На фоне compose/kotlin ваш flutter выглядит как набор костылей. Да, он стабильнее, но это его единственный плюс который нивелируется со временем.

[@EVAVoit-d5y]

@@evgeniy9248 так и запишем. Потом поговорим, когда-нибудь, на эту тему.

[@alekseyblekot119]

Я использовал стек Decompose, MVI Kotlin, Jetbrains Compose, Ktor, Moko resources, kmm settings И все хорошо) приложение - аудиоплеер с подгоузкой контента с бекенда. Вся логика, навигация, авторизация, настройки, сеть, обработка ошибок, UI - в общем коде. Нативные только: сам аудио плеер, billing, мелкие функции типа отправить имейл, пошарить приложение. Но конечно рискованная затея для бизнеса) Согласен, что это не для джунов. На стадии настройки гредл или XCode можно потерять энтузиазм и забросить затею

[@DrZupan]

общий посыл - для КММ нужна соответствующая квалификация

[@AndroidBroadcast]

Верно!

[@user-not_defined]

в связи с этим KMM может утерять популярность и смысл при наличии flatter, бизнесу нужны решения которые может поддерживать и развивать специалист хотя-бы среднего звена, а KKM - только для тех кто уже нахавался с андроидом более 5 лет и понимает все под капотом в том числе и под IOS

[@captainsustain]

@@user-not_defined на KMM можно будет мигрировать любое крупное приложение, не переписывая всё с нуля, сохраняя все платформенные возможности и особенности. И в итоге убрать процесс, когда параллельно несколько команд тупо делают одно и то же.

[@comachine]

@@user-not_defined да с флаттером тоже как-то не понятно всё, недавно гугл сократил дарт, флаттер отдел. проблемы с desktop-поддержкой у флаттера тоже имеются до сих пор незакрытые насколько я правильно помню. поэтому мне на самом деле неизвестно насчет наличия реально стабильного игрока на рынке мультиплатформенной разработки (да что уж там, банально быстрой-развёртки-friendly до сих пор для одного только desktop'а стабильного не особо то и видно, хотя насколько я знаю чистый десктоп реально вымирает потихоньку, все переходят на мультиплатформу либо на веб)

[@ruvirta]

Работал с Compose MP, всё достаточно просто если ты хороший инженер

[@netdeveloper740]

Все просто только надо пилить свои плагины потому что их почти нет 😅

[@agidel2012]

В свое время выбрал развиваться как флаттер-разработчик, за 3.5 года крупных проектов проблем не было. И с каждым годом все лучше и проще становится. КММ пройдет свой путь, пофиксятся "детские" болячки, набьют руку разработчики - и займет свою нишу.

[@AndroidBroadcast]

Да, однозначно. Просто Flutter все начала на порядок раньше чем KMP + Compose

[@programmerc1178]

Годная и конструктивная критика, хорошее видео. Обязательно при просмотре нужно понимать, что речь тут идет в основном про enterprise разработку, тк KMP как раз и создан для ускорения этой самой разработки. Если вы делаете свой PET проект или что-то подобное, не бойтесь юзать KMP, все ваши копания в коде окупятся и перейдут в "боевой опыт". Откатиться в native в своем проекте вы всегда успеете :)

[@AndroidBroadcast]

Полностью поддерживаю. Инвестировать в изучение стоит, тянуть в прод - пока осторожно!

[@abd3d2fKm-s]

Заменить в вышесказанном KMP => Xamarin и утверждения заиграют новыми красками ) Где сейчас Xamarin?

[@romanpavliuk2301]

Для больших стабильных продуктов переход на Flutter/React/etc ещё большая проблема. Главным плюсом KMP есть возможность перенести какую-то часть логики в common модуль, при этом всё остальное будет работать как и работало. По сути только это всех и цепляет. Это уже выгодно бизнесу так как не нужно ждать 6-9 месяцев переписывания всего продукта на другую кросс-платформу чтобы увидеть результат. Ещё нужно же потом глянуть метрики, если что-то просело, то всё это время выкинуто "в трубу". Выходит КМР не лучшее кросс-платформенное решение на рынке и понятно что оно сырое, но оно открывает немного другие возможности чем существующие решения

[@AndroidBroadcast]

Согласен

[@EVAVoit-d5y]

Красиво рисуешь😮❤

[@truefalsemary]

На flutter тоже можно переписать часть продукта

[@romanpavliuk2301]

@@truefalsemary может подскажешь куда копнуть? Потому что я с таким не сталкивался, но после Swift cross-platform всё возможно :)

[@user-not_defined]

начал делать проект на kmm, с общим UI, осталось разобраться как поделить на модули и подмодули и внедрить DI на это вce. Начать сложно в KMM - готов подтвердить. А дальше по идее легче. К сожалению из под коробки решений практически нет. Работа с ресурсами, тот же DI - боль да. Но дальше должно быть легче. C документацией - как должно быть так-же

[@AndroidBroadcast]

Да, когда отработает все подходы начнете получать выгоду.

[@arctan-k]

Работаю на KMP довольно давно (с 2022) и радуюсь

[@AndroidBroadcast]

Какой путь был в начале? Либо его за вас прошли другие и вы пришли на готовый проект?

[@mmiro]

Ну это не странно, есть же любители БДСМ)

[@denior162]

На данный момент KPM звучит как идеальное решение, если нужно из хорошего, адаптированного для планшетов, Android приложения сделать приложение для компьютера

[@AndroidBroadcast]

Поддерживаю

[@nightscream3687]

Поддерживаю Кирилла, в течении года пробовали КМР по разному, сейчас проще писать на нативке.

[@dunkin_donuts_tagger]

Для тех кому лень смотреть 20 минут видео: все видео чел рассказывает что у него не получалось писать код на KMP и из-за этого он считает что никакой экономии времени нет. Ну так может быть ты скажешь, что KMP это просто абсолютно другой подход к разработке и его надо тоже изучать? Когда я только начал изучать разработку под Android я тоже очень долго не мог сделать какие-то базовые штуки, там сходить в сеть или послать уведомление. С опытом ты начинаешь делать это быстрее, и если у тебя конкретно не получается что-то делать это значит что у тебя недостаточно опыта. Это как будто ты всю жизнь писал под андроид, потом сел попробовать писать на iOs и потом записываешь видео "Почему писать под iOs себе же у ущерб" обосновывая это тем что у тебя нихуя не получается и разработка будет вестись долго потому что надо будет со всем разбираться ну камон

[@gorbachew5598]

Только думал садиться и активно изучать\творить в KMP. Спасибо, подожду еще годик)

[@AndroidBroadcast]

Однозначно стоит пробовать и смотреть. Команда много всего сделала и улучшила за годы и в следующем году будет ещё лучше на порядок

[@Symbi0x7]

Изучать уже давно можно. Я уже пару своих пет-проектов на кмп создал и особых проблем вообще не заметил. Правда, я пока под ios не адаптировал, т.к. нет макбука и айфона, но не думаю, что с этим будет большая проблема. В кмп основной принцип это создавать ui и бизнес логику в общем модуле (commonMain), т.е., для ios нужно только вьюху написать на swiftui, а вьюмодели и весь остальной код будет на котлине. Swiftui не сильно отличается от того же compose, поэтому опять же не должно быть больших проблем.

[@DenisYukhnovets]

мне сложно оценить, но звучит как достаточно логичные мысли. Спасибо за озвученое мнение, я узнал несколько новых вещей о KMP

[@yet300]

Сейчас много странных багов ошибок, тот же compose resources толком не работают на других платформах, у меня почему то для desktop генерирует ресурсы которых даже нет у меня

[@ВиталийСорокин-с2с]

Очень классный видос! Нравится подход к съемке и содержание)

[@alonealone6368]

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

[@AndroidBroadcast]

Не соглашусь. Переиспользование кода может помочь сэкономить мелким компаниям которые ограничены в бюджете и времени

[@ЕвгенийАндреевич-з5р]

спасибо за твой опыт который ты делишься с нами! ❤

[@AndroidBroadcast]

Пожалуйста

[@СергейНесергей]

Дважды участвовал плотно в работе с кмп. Один раз на внутреннем проекте аутсор компании, который с момента моего увольнения всё ещё не вышел из лаборатории сумрачного гения. И второй раз на оч крупном и известном проекте, его сначала запиливали, потом выпиливали. Лол. Из реальных плюсов КМП могу заметить только один, он выкручивает кокошки разрабам и заставляет их блюсти +- нормальную архитектуру.

[@AndroidBroadcast]

Без хорошей архитектуры в любом большом проекте никуда

[@ttahat]

Да здравствует flutter ❤

[@potatoechannel2760]

Я понимаю ваши чувства, неоправданные ожидания - это всегда неприятно. Но тем не менее хочу указать на некоторые моменты. Хорошо поддерживаемый код характеризуется низкой связанностью.,одна часть программы мало чего знает о других: никакая сущность не должна расползаться по всему проекту. Для хорошо спроектированного кода замена одного класса другим - зачастую задача очень простая и естественная. Поддерживаемый код по определению готов к любым внешним изменениям. Увы, андроид сам по себе спроектирован плохо. Много статики, контекстов, которые проникают везде. Базовые классы, как вы привели пример даты, спроектированы плохо. Мульти платформа правда вызовет много боли у любителей быстрого и высоко связанного кода, так как она требует кода более высокого качества.

[@ArtiomXendrik]

@@potatoechannel2760 это как раз плюс, как мне кажется. Например, я так включал KMP с Android-only таргетом в части модулей, потому что это не давало там использовать платформенный код и повышало таким образом качество.

[@nablunatel]

Те кто решил описанные проблемы уже давно забирает горы плюсов от KMP

[@AndroidBroadcast]

Да, так и есть! Только хотелось бы чтобы не приходилось им решать каждой компании/проекту, а уже из коробки было

[@dmitrychernozubov6722]

Звучит как база, да. Вообще ситуация не нова. Почти тоже самое было с compose, когда люди с двух ног запрыгивали в него, еще на этапе лютой альфы, а потом у них везде всё глючило и появились всякие жесткие практики скрещивания бегемота с крокодилом (Recycler view + compose)

[@AndroidBroadcast]

Ну когда висит плашка Альфа то ты сам явно берешь риски

[@jaloliddingulomov3635]

Я вспомнил как я мучился с Room на KMP не давно

[@AndroidBroadcast]

Он еще в альфе, так что пока рано судить

[@evgeniy9248]

"нахрен не кому не нужны"

[@anonym1548]

Всё так и есть. У меня тоже жопа чуть не сгорела, когда начал в этом разбираться.

[@AndroidBroadcast]

Было непросто мне, но я люблю вызовы

[@sergey30027]

В принципе давольно справедливо сказано. Слишком много чего не хватает.

[@DmytroZaitsev]

Не хочу показаться занудой, но, судя по комментариям, многие сравнивают KMP (особенно в связке с Compose Multiplatform) и Flutter, что, на мой взгляд, некорректно. Это разные технологии, предназначенные для решения разных задач. KMP - это мультиплатформенное решение, Flutter - кросс-платформенное. Сравнивать их напрямую неправильно, так как они решают разные задачи, применяются в разных контекстах и в общем случае не взаимозаменяемые.

[@antaki93]

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

[@maks24102]

Так Flutter как раз позиционирует себя как мультиплатформу - он работает стабильно на всех шести (android, ios, web, windows, macos, linux).

[@AndroidBroadcast]

Полностью согласен. Всех интересует как сэкономить на разработке Android + iOS а оба решения это предлагают

[@de.mirgorod]

@@AndroidBroadcast если писать shared код (domain и data layer), а UI нативный оставлять для iOS и Android - это экономия на разработке?

[@DeliOZzz]

Интересно, но довольно однобоко. По сути обсуждался опыт только в контексте мобильной разработки. А для десктопа то все +- норм работает. Если нет желания писать на джаве приложули с красивым и современным UI/UX, то KMP - вполне себе выход.

[@lynx6511]

Пока что флаттер и реакт нейтив лидеры в этом плане. Для себя отмечаю во флаттере большой плюс - это одинаковый UI на обеих платформах. Т.к. у нас в основном проекты не отличаются дизайном на платформах. А если еще и завезут макросов в дарт, то вообще будет то, что надо. Но увы дарт пока очень слабенький язык в плане функционала

[@BOOMvrn]

По моему опыту: На простых B2B проектах, без сложного интерфейса, логики и т.д. выигрыш по времени может достигать 30% (не в 2 раза точно). На крупных проектов процентов 10 экономия максимум, а то и вообще никакой.

[@ruslan622]

как раз вчера на Хабре увидел статью про PWA, как там красиво рассказывается, что натив нужен только для узкого круга приложений, а остальным лучше PWA.

[@AndroidBroadcast]

Зависит какие возможности используется. В целом PWA более простой и дешевле вариант для старта

[@denisk3852]

Сложно для входа

[@AndroidBroadcast]

KMP сегодня точно не для входа в разработку технология

[@АртёмПатрин-д4ц]

Kmm - это 20% на написание продуктовой фичи, 80% разобраться как подключить фраемворк на iOS, чтоб он не ломал сборку

[@AndroidBroadcast]

И еще как вызвать Kotlin код из iOS

[@alsh2887]

Это полная чушь.

[@RockRider2k]

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

[@AndroidBroadcast]

Flutter ушел вперед т.к. раньше начал и зашел дальше

[@katerinashepel2914]

Вижу боль Кирилла )))) спасибо за мнение!

[@AndroidBroadcast]

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

[@handleftman]

хорошо, что я на год отошёл от новинок Андройда, а тут особых движений нет, всё еще не "моё" как и год назад )

[@qw453et]

На базовом m1 air 8 gb озу вполне сносно можно работать в мультиплатформе (Xcode + Android studio). Как минимум на небольших и среднего уровня проектах

[@AndroidBroadcast]

Ну там однозначно есть уход в SWAP и то что начинается деградация SSD больше Эмулятор Android + симулятор запускаете?

[@qw453et]

@@AndroidBroadcast пользуюсь таким ноутом больше трёх лет в довольно суровом режиме, пока проблем с SSD выявлено не было - такая система в свопе буквально сразу даже без дополнительных программ при запуске системы. Понятно что с Xcode и studio своп будет ещё больше. Да, пользуюсь симуляторами и андроид и iOS и даже иногда запущено все одновременно и ide и симуляторы. Своп может достигать порядка 5 и 8 и более гб. Это не то что бы самое лучшее решение - но даже такая сборка все ещё позволяет на допустимом уровне заниматься разработкой. Деградация SSD действительно будет быстрее, но даже на системах с 16 озу и более - в своп так же быстро можно уйти. Моя основная мысль, что казалось бы, самый простой вариант вполне переваривает довольно сложные технологии на базовом уровне

[@zull474]

Ощущение немного похожее на "дал заднюю", а может просто выгорание.

[@tractorist1]

лучший

[@jahongirzokirov3453]

когда речь пошла про то что 16 гб не хватит - начался пиздеж))) у меня макбук на 16 гб на м1 про и все работает норм)

[@alsh2887]

Аналогично Макбук М3 с 18Гб, всё работает. Правда я далеко не всегда вместе запускаю хКод и Андроид студию.

[@AndroidBroadcast]

Мне приходилось работать с XCode + Android Studio + Android эмлуятор + iPhone симулятор. При этом естественно открыты вкладки браузера и другой софт в фоне. Можно и с 8 ГБ оперативы все делать и работать в SWAP постоянно. У всех разный уровень комфорта работы и требования к скоростям сборки и отзвычивости

[@ArtiomXendrik]

М3 с 18Гб даже для Android-only не всегда комфортно, увы. SWAP'ается время от времени, когда активно используешь эмулятор и другие тулы

[@QashqaiQueshi-rq2mk]

M3 pro + 18 GB ОЗУ, запускаю fleet + AS + xCode, полет нормальный даже с эмуляторами, но пока только на не больших проектах

[@rus_travel]

​@@AndroidBroadcastкак вас понимаю. Сижу на линуксе и всегда открыто 4-5 проектов в студии и по 2 эмулятора, а ещё браузер с фигмами и т.д. Раньше было 32gb ram, начал использоваться swap, пришлось добавить до 64. Проц i9 12900h переваривает все отлично. Пытался закрывать не используемое, но всегда то тут, то там дернут...

[@БорисШумай]

Такой кейс 1. Проект с нуля писался на KMM + Compose Multiplatform 2. Жестких требований к UI нет 3. Платформозависимости мало (локали, уведомления, вебвью и т.п.) 4. Один разраб пришедший из Андроида middle -, сменивший middle +, который все это ставил Паниковать после просмотра видео или похер пляшем?

[@qw453et]

Мое мнение, что может быть все ок. Для меня основной нюанс для входа в kmp - что нужны будут знания и iOS / swift, ну и однозначно Android / Kotlin Если нет желания ввязываться и в изучение swift / iOS - то KMP будет не очень решением

[@alsh2887]

Не надо паниковать. Вполне оно рабочее. Большая часть претензий высосана из пальца.

[@alsh2887]

@@qw453et Я сделал проект на КМП вообще без знания Свифта. Но пришлось по ходу, конечно немного нативного кода сделать. Но благо есть Интернет.

[@AndroidBroadcast]

Если вы уже начали это делать, то надо оценить с чем уже сталкивались и что есть. Если у вас мало специфики платформенной то будет намного проще

[@Lonkly6669]

Kmp крут, а джуномидлы и во вьюмоделях не разберутся, не говоря уж про multiplatform.

[@rndofpipowe]

Ну вот. А я только плагин в Студию установил.

[@AndroidBroadcast]

Правильно делаешь. Изучать и пробовать стоит, а в от тянуть в прод - острожно и неспешно

[@BorzdeG]

Почему противовесом мультиплатформе на Kotlin ставится только раздельный нативный кодинг и не упоминается тот же Flutter для мультиплатформы?

[@dmitrychernozubov6722]

Хех в целом да, но канва такая. Kotlin -> KMP. Канал то базово про android ))

[@AndroidBroadcast]

На Flutter есть свои подводные камни, я не эксперт чтобы давать им оценку или говорить что берите Flutter

[@BorzdeG]

@@AndroidBroadcast но можно было не так аппеляционно говорит "либо KMP либо нативная разработка", а сослаться, что кроме KMP есть и другие мультиплатформы и не только Flutter, но и всякие React Native, которые возможно лучше, возможно хуже

[@jamjam3337]

😎

[@АлексейОвсянников-д7ч]

Только начал смотреть, а уже сложилось впечатление, что речь не про КМП, а про жб композ :)

[@AndroidBroadcast]

Мало кому интересен в мобилке KMP безе переиспользования UI под Android и iOS

[@АлексейОвсянников-д7ч]

@@AndroidBroadcast В мобилке согласен, но КМП - не про мобилку, он про шаринг кода и бизнес алгоритмов между платформами :) помимо iOS существует как минимум еще три платформы (JVM, JS, Android) и мир KMP не ограничивается мобилками или UI :) С этой точки зрения, то есть если писать бизнес логику в коммоне и шарить её между платформами (в том числе шарить между на серверами и клиентами) - получаем реальную пользу KMP :)

[@АлексейОвсянников-д7ч]

@@AndroidBroadcast Я продолжаю смотреть и лишний раз просто убеждаюсь в своей мысли: бизнес-логика должна быть общей, а вот UI и другие платформенные вещи - на платформах, желательно в нативном окружении. Поэтому же я не сильно сейчас поддерживаю движуху вокруг композа - они развивают тему "Один UI на все платформы", но как вы верно говорите в видео, проще нанять пару миддлов на каждую из платформ для вёрстки.

[@AndroidBroadcast]

Да, но в моих реалиях всем интереснее шарить UI код который забирает много времени, чем бизнес логику

[@AndroidBroadcast]

Скорее всего Compose появился именно чтобы на Desktop сделать удобный фреймворк, а там пошло и дальше

[@netdeveloper740]

Еще недавно адепты котлина рассказывали что он победил флаттер

[@AndroidBroadcast]

Было соревнование?

[@netdeveloper740]

@@AndroidBroadcast еще какое, записи доклада можно посмотреть у Яндекса

[@denislopatkin6996]

Спасибо за трезвый адекватный разбор!

[@SmoukingMouse]

Аххаха, поворачиваем диван в другую сторону, KMP не нужен, KMP дорого и плохо.

[@mikhailshirokov8464]

Очень полезное видео.

[@SlothHuntOnYou]

почему до сих пор никто не использует Unity для кроссплатформенного мобильного приложения? все нативные фичи платформы вызываются из c# через таргетированные либы(которых уже много в ассетСторе) P.s у меня приложение на unity c большими листами галери - работает всё отлично, приложение запускается за 4 секунды, минимальный размер для апк 6 мб, портировано на ios/mac/win - хватит сидеть на котлине=))

[@АлександрБеспалов-ц3щ]

Запускается 4 секунды???

[@SlothHuntOnYou]

@@АлександрБеспалов-ц3щ всмысле на устройстве билд il2cpp(64bit) - приложение запускается за 4 секунды(т,е через 4 секунды приложение уже в работе, не отличить от нативных апплетов), раньше под моно запускалось 8 секунд(т,е ты смотрел на loadScreen 8 секунд)

[@AndroidBroadcast]

Unity - это про игровые движки и поэтому не обращают внимания. Мне бы было интересно обсудить твой опыт, может даже снять интервью. Если готов - пиши t.me/kirill_broadcast

[@AndroidBroadcast]

В нативной разработке на среднем устрйостве 1 секунда считается так себе

[@Mike_x64]

tl;dr всё придётся делать самому или искать решения на просторах опенсорса. То есть ВООБЩЕ НИЧЕГО в сравнении с нативным андроидом не изменится. Передаю привет с проекта на Compose Multiplatform. Могу признать, что навигации нормальной нет. Как нет и в нативе.

[@macherdrones]

Ох как с grpc на kmp говна поел в прошлом году, флэшбэки налетели

[@AndroidBroadcast]

😮😮😮

[@begalisydykov6404]

СMP + KMM значительно сокращает время разработки приложения, если вы опытный разработчик. Не надо жаловаться, а наоборот мы должны помочь им развиваться. Надо уметь использовать технологию. Честно говоря я не вижу больших препятствий.

[@AndroidBroadcast]

Именно "если вы опытный разработчик". Таких немного и бизнесу они обходятся недешево

[@AK-zq7bg]

Работал над огромным известным проектом на полторы ляма строк кода. Также поверили и два года шли в кмп. В итоге пришли к тому что крутые iOS разрабы с 10+ годами опыта, молили забить и пойти написать уже этот кусок второй раз на андройде, потому что уже зайтишейпились внехочу, а ковырять какахи и витьеватости кмп задолбало. Подписываюсь под каждым словом автора кровью команды в 60ят человек. PS. Еще учтите что идя в кмп, вы нивелируете сильные стороны своих айосеров, и даже андройдеров, потому что это отдельный мир со своими правилами. PPS. Уже говорил джетам, но это какая отладка мвп об энд юзера, что в 2019ом что в 2022ом что в 2024ом, еще 3и года и будет зашибись. Может хватит хватать все подряд и сделаем что-то одно (замену c++) хорошо?

[@alonealone6368]

Гайз, как разраб с опытом нескольких лет работы под android native и перешедший на fluttter могу сказать, вы избавитесь от такого кол-ва головной боли, усталости и нервотрепки, что жизнь для вас вновь заиграет красками). И разработка вновь начнет приносить удовольствие

[@Symbi0x7]

Ты из какого android native перешел? Из времен динозавтров? Уже год работаю с флаттером и после compose/kotlin это одна сплошная пытка.

[@AndroidBroadcast]

Я слежу за Android разработкой с 2011 года и она кажды пару лет делала большие шаги в удобстве и возможностях. Так что полностью НЕ согласен с тем что во Flutter все настолько удобнее и лучше

[@mmiro]

​​@@AndroidBroadcastпочти во всем. Согласен с автором, чуть больше полугода работаю только с флатером, до этого год было и то и другое одновременно. Вот тогда я осознал, насколько Флатер удобнее почти во всем, и после этого на натив вообще не хочется возвращаться .

[@sanek1985t]

​@@AndroidBroadcastа какие удобства? Те, что надо постоянно переписывать код на новые парадигмы? То что раньше во фрагментах надо было мучиться с состоянием экрана когда с него уходишь , кучей гугловых либ и по навигации тоже (кривых либ). То что потом объявили Compose, который лагает и в нем по дефолту нету нужны вещей и надо юзать Accompanist? Это не удобства - это гвозди в жопу разработчикам чтобы они мучились всю жизнь, разрабатывая на андроид... Поэтому я и ушёл вообще с нативной разработки так как посто заеб**ся это терпеть

[@sladkoko]

Весь спич про интероп kotlin/swift показывает красильщика кнопок

[@sladkoko]

Остальные поинты не лучше. И нет это не значит что kmp это сейчас самое лучшее и там нет проблем, но конкретное видео плохое

[@AndroidBroadcast]

Я только рад буду обсудить где и в чём я не прав

[@sladkoko]

@@AndroidBroadcast Не хотел обидеть По поводу интеропа можно начать с простых вопросов: 1. Зачем? То есть буквально зачем? Это имеет смысл для определенных юзкейсов, но глобально для апп разработки в соотношение это не приносит большой выгоды, улучшит dx но при этом трудозатраты огромные 2. Можно поинтересоваться, почему большинство высокоуровневых языков общаются через С? 3. На youtrack можно почитать ишью, там только односторонний interop, тоже можно подумать почему

[@ymusclecode]

Зачем они столько сил тратят на кмр

[@AndroidBroadcast]

Они точно видят в этом смысл и сами пользуют. Технология совершила большой прогресс за 5 лет из года в год стабильно, собрала сообщество и большие компании с проектами на KMP

[@sanek1985t]

​@@AndroidBroadcastя думаю они просто хотят подсадить плотно разрабов на свою технологию, это просто бизнес в конечном счёте..

[@Symbi0x7]

Лучше уйти из профессии, чем работать на Flutter. Этот фреймворк может и не назовешь абсолютно плохим, но по-сравнению с KMP (который по большей части включает compose/kotlin) это самый настоящий набор костылей и один большой бойлерплейт. Крайне не рекомендую переходить на этого франкенштейна. К тому же, довольно показательно, что Гугл решили официально поддерживать KMP.

[@AndroidBroadcast]

Команда Android поддерживает KMP, а не то чтобы позиция Google. Они вкладывают в разные технологии и пробуют подходы которые конкурируют чтобы найти лучшее

[@mmiro]

Гугл захоронил не один сервис хороший, но родил Gemini) поэтому то что делает Google не показатель что это хорошо или плохо вообще😂 По моему это КМР это один сплошной костыль и паяльник в Ж, либо натив либо Flutter

[@sanek1985t]

Ну тогда лучше вообще уйти из андройд разработки.... Compose? Тормозит, постоянно в какой то недоделанной бете. Нету многих вещей - юзай Accompanist. Потом ещё постоянно депрекейтят технологии и подходы . Куча ExperimentalApi декораторов . Это чё за херня, а?? Разработчик не может столько времени тратить на наладку инструментов!!!

[@sanek1985t]

​​@@AndroidBroadcastв итоге потонут оба, скриньте!