Dart хороша мова, і на мою суб’єктивну думку, Flutter найкращий фреймворк для для мультиплатформенної розробки, але не під усі задачі.

Порівнювати C і Dart — недоречно. Це зовсім різні мови, абсолютно для різних цілей.

З контексту, певно малося на увазі Objective C

Мати KMM i намагатись додати Dart — виглядає дуже сумнівним рішенням і, швидше за все, не виправданим. Я б назвав це 🩼

Дякую за відповідь.

ось і вся справа, я не люблю продукцію мікрософта, а особливо сварюся коли постійно вилогінює з тімса :) слек так не робить :)

перепрошую що втрутився, додам коментар в + до Flutter. В Flutter SDK є потужний річ текст який дозволяє додавати навіть віджети (вюхт) між текстом

І ще... вище лишили сніпет з кодом чекбокса, там є прикольний online-compiler — це теж плюс.

Рекомендую спробувати побавитись з анімаціями на Flutter, має сподобатись. Їх реалізація в рази легша і приємніша ніж на нейтіві. Це теж важливий аргумент.

IMHO:
Зробити фенсі-Figma UI на Flutter — значно простіше ніж на за(кса)маріні.
so-шка двигунця флатера важить, якщо не помиляюсь 6 чи 12МБ (для андроїд). Це означає, що в принципі додатки можна робити відносно не вел. розміру. Для мене ред флег коли апка важить якісь сотні мегабайтів. В мене питання що туди можна було напхати....

Чесно кажучи я не розумію для яких потреб кса(за)марін ще використовується. Поясніть, будь ласка, дуже цікаво почути вашу думку.

Поясню свою думку. Потрібно це було відразу написати. Отже я вважаю, що:

1. Найкраще — це нативна розробка. Досвідчений Android або iOS девелопер знає багато нюансів фреймворка, його компонентів і взаємодії з ними, лайфсайклу, налаштування білд системи, оптимазації коду та аутпут файлів, оперування мовою програмування тощо. Для нього є зрозумілим динаміка, актуальність і напрям розвитку фреймворка. Наприклад Google має потужні гайдлайни щодо побудови вдалої/правильної клієнт-серверної (і не тільки) архітектури додатків. Для мене є зрозумілим що додатки на нейтіві будуть існувати завжди допоки існує ОС.

2. Flutter — безумовно крутий фреймворк особливо для клієнт-серверних додатків. Для ходіння в інтернет і парсання джейсонів — це ідеальне рішення. В його SDK вже неймовірна к-ть графічних Матіріал/Купертіно віджетів, які подекуди навіть на нейтіві реалізувати важче. Зрозуміла деревовидна структура написання коду, хот релоад, інспектор віджетів — це все топ. Свій двигунець для відмальовування графіки.

Я впевнений що додаток написаний рівними руками по перформенсу і всяких fps-ах виграє інші короспатформенні солюшини. Наприклад за 10-15хв можна запрототипити застосунок з Google картами чи OSM відразу на Android/iOS/Windows/MacOS i Web.
В мене особисто є багато запитань до 3rd-party бібліотек, якість яких не завжди найкраща (можливо тому, що їх пишуть не девелопери які «шарять» нейтів, деталі які я згадував вище, а саме флатеристи).

IMHO як AOSP/Android SE:
ReactNative/Xamarin/Ionic/апки на WebView i оте все — це пратично мертві штуки, які вистрілюють на кілька років до тих пір поки щось не зявиться краще (flutter наприклад). Хайлевел фреймворк — це завжди біль з лібами і резолванням їх версій, білд системою тощо.
+ купа враперів, бріджів, мостів, костилів щоб зробити чекбокс з текстом
+ мене особисто трігерить додатки які важать багато за рахунок *.so-шок які треба/не треба але напхані в APK/AAR-ки.
+ поріг входження в «Flutter» — думаю «трошки» швидший ніж в Xamarin чи ReactNative. Якось пробував швидко щось скомпілити на реакті а до того на за(кса)маріні — не вийшло бо нічого не понятно.

Не чув що якийсь крутий софт написаний на за(кса)маріні. Якщо такій апці 3-4 роки то — скоріш за все такий додаток вже переписали на нейтів чи флатер через «не можливість супортити такий продукт бо якась ліба вже не існує/підтримується».

Давайте візьмемо наприклад Інстаграм — він на реакт нейтіві, але виглядає він убого, купа багів.Чому він важить так багато? На скільки там оптимальний код?

краще написати апку на найтіві java/kotlin або flutter ніж на цьому костилі

1. я в загальному процитував твердження про «достатнє бажання». Інколи лише бажання не достатньо.
2. якщо щось десь лежить не в не сильно захищеному місці — то це погане секюріті.

...Маючи достатньо бажання, можна обійти будь-яку систему безпеки...

— при всьому бажанні обійти AES256 треба буде мільярди років N-ГВт елктроенергії.

..але те саме працює з розумними ... датчиками, лампами, камерами...

в дійсно «розумних сенсорах» викоритосвується екрипшин.

Робота подібних систем за допомогою «JS-онів» — це свідчить про те що систему розробляли:
1. Розробники які не знають, що таке секюріті || НЕ інженери, а швидше ІТ-шніки
2. Спеціально — щоб експоузнути «АПІ» з можливістю використати в інших застосунках