Flutter Heroes

New post on /r/flutterdev subreddit:

Flutter vs Kotlin Multiplatform Mobile (not a holywar)
TL;DR: huge topic, but hope former native devs will found it interestingMy case is that i'm experienced dev/arch and i was pushed to build mobile App for one startup.I specifically decided to ask question in FlutterDev channel rather than in Android/iOS Native ones.At work i used and use a bunch of languages, so Dart vs Kotlin doesn't matter for me.I'm completely green in mobile direction, so wanted to ask experienced Mobile Devs to confirm or deny my concerns in choosing right stack.As always in this question it was:UI:- found Compose and SwiftUI pretty similar and less boilerplate (little difference) than Flutter itself - it's less LOC/capacity of code to write native visually complex widget for specific platform than crossplatform widget in Flutter (I also take into account UI branching in Flutter, such that Spinner should be different in iOS and Android).- found Compose and SwiftUI much more boilerplate than Flutter for visually simple but interactively complex widgets. For example - Horizontal Pager with custom paddings, layouts and different widget positions on different horizontal lines (with different gestures) within single Pager (it was realworld case).Backend/Repository layer:- found Flutter graphql is way ahead , even almost mature as Apollo for JS. apollo-kotlin is several miles behind, a lot of issues, absolutely inconvenient usage after graphql-flutterLibraries (my most huge concerns):- Didn't find specific benchmarks for Hybrid Composition, but found a lot of issues on Github where people complain about performance in some specific cases (even on Android 10+)- 3D graphics, i used filament in KMM and it was outstanding, didn't find bindings or similar pub- Company was forced to use specific Vector Maps backend (but i think it is true for any other) and packages in Flutter are in a very early stage for this problem. I have choice to write Hybrid Composition for both platforms since Vector Maps provider deliver Android and iOS client libraries or to go hard way and impl the client library itself.- ML: i have a prototype using tflite_flutter_plugin but it was a huge mistake, used workarounds several times hitting segfaults and other memory usage issues (it's very risky to use it in production on hundred of different devices). Ended up with Flutter Channels for platform specific clients.At the end:Currently i have KMM in production, but besides all listed above - SwiftUI -> KMM shared module interaction is a pain.I'm building second mobile APP using Flutter (it's like a duo app project for different roles, first is already implemented in KMM) and it's like a fighting question in my head - was it better to choose KMM or to stick with Flutter, since every stack has very contradictory pros and cons:KMM: writing and copying SwiftUI style from Compose and fighting with Swift -> KMM shared module interaction.Flutter: Hybrid Composition and Channels are huge boilerplates. Also even i'm working in enterprise world constantly with five-six-seven+ different languages (but each of them for specific domain, purpose, high-level task) - it's very very very annoying to build Client application using three languages at the same time with boilerplate to glue them.When i'm thinking about this two technologies i'm asking myself - is copying and writing SwiftUI was easier for iOS than writing Hybrid Composition / Channels for both ? Am i missing something ?

January 24, 2022 at 12:03PM by kitsen_battousai
https://ift.tt/3Iwji9P

GitHub

GitHub - apollographql/apollo-kotlin: :rocket: A strongly-typed, caching GraphQL client for the JVM, Android, and Kotlin multiplatform.

:rocket: A strongly-typed, caching GraphQL client for the JVM, Android, and Kotlin multiplatform. - apollographql/apollo-kotlin

1.0K views11:14