Hey, is there a way to use K/N and Flutter togethe...

# multiplatform

[Anastasia Finogenova]

Hey, is there a way to use K/N and Flutter together in my cross platform app at the moment?

[gildor]

You probably can call K/N exposed as C bindings using dart:ffi

[kpgalligan]

Well, you can also use it like any other interop with Flutter, which means hand-writing the translation layer with channels

[Kurt Renzo Acosta]

Have you checked this out?

“Fast Prototypes with Flutter + Kotlin/Native” by JB Lorenzo https://link.medium.com/K7UDeCSDx1

[kpgalligan]

Yes. I’ve talked to “JB” about this in particular. “Fast” is relative. Flutter’s interop story is bad, which is the strength of Kotlin. There really needs to be a project that facilitates the interop. Without that, it’ll always be kind of a painful slog

[kpgalligan]

If you’re building a prototype of something with Flutter, essentially it doesn’t make a whole lot of sense to also call out to Kotlin code, unless you have existing code (which is a whole different problem)

[Anastasia Finogenova]

I am looking to find a production suitable approach for larger scale enterprise apps ( so no not a prototype ) but with the resource constraints we decided to look at Flutter and K/N which seem to be the two pieces for a "compete" cross platform solution but from what I read online it doesn't look like there is a solid way to "productionize" it, so I am looking to understand what are those limitations cause if you can have an Android module for example in a Flutter project what prevents you to have it not in Android - Kotlin but in K/N other that some compile / interop issues

[Anastasia Finogenova]

So trying to find out what are those

[kpgalligan]

Those are big topics. Why would you expect Flutter to require less resources for these apps? Or KN?

[kpgalligan]

I know that sounds like a dumb question, but a lot is taken on faith

[Anastasia Finogenova]

We have two teams Android and iOS devs and we want to join them for a project so double the resources

[Anastasia Finogenova]

Yeah, it does seem like there is no production data as these technologies are fairy new so someone has to be first to try 🤷

[gildor]

In this case an approach with common Kotlin MPP business logic and native UI looks as a lot more safe and efficient solution, than Frankenstein Flutter+K/N

[kpgalligan]

Ah. So, if you have a lot of local code (db, logic, etc), KMP can make a lot of sense. The Android and iOS teams can still focus with their tools and skillsets. The iOS team can use Swift UI and keep them “happy”. I think it kind of depends what you’re doing, though

[Kurt Renzo Acosta]

I think Flutter is better for now if you just want to merge your resources. But of course, multiplatform is a much better investment (I think). Check out KotlinConf 2019, seems like there's someone who already used multiplatform in production

[kpgalligan]

For Flutter, everybody has to retrain, and then you need to make sure whatever you’re doing is supported. I would not recommend trying to merge KMP and Flutter without a good reason, though

[Anastasia Finogenova]

But it will not be a "run anywhere" type of project. There will be still some native platform code. Is it even realistic to create this kind of solution at all? (Not taking about hybrid approaches here)

[kpgalligan]

“For Flutter, everybody has to retrain” by that I mean all of the devs have to retrain for Dart/Flutter. That is risky both in time and retention. Get buy in first.

[gildor]

if you just want to merge resources

Before merge resources, you have to retrain both teams, switch paradigm and toolset completely for both of them

[Kurt Renzo Acosta]

Oh yeah, that's the cost

[kpgalligan]

“Is it even realistic to create this kind of solution at all?” Kotlin, yes. The interop is great. Flutter, it’ll work, but interop is not a focus of that framework.

[Anastasia Finogenova]

I mean it is marketed as a UI toolkit so that is suspicious right away that people try to create "all flutter" solutions

[kpgalligan]

In summary, Flutter is more risky as the team/project grows. Double that if you have engineers with existing mobile experience (which is why few mid-size to larger teams seriously consider Flutter)

[Anastasia Finogenova]

Sounds like it is not what it was designed to do

[darkmoon_uk]

I'm currently positioning my company & their product to go down K/MP path - it's not trivial to set up but I can see it being hugely productive once we reach cruising altitude. Just yesterday got the macos Build Agent VM's set up and integrated with CI; first K/MP builds going through, exciting.

[kpgalligan]

Flutter is a portable UI, but the devrel/marketing are pushing it to be more than that. It wasn’t really designed as a “cross platform” framework, in my opinion, but whatever.

[Anastasia Finogenova]

Do you know where it is marketed as cross platform? Cause first thing I see when going to their website it "UI toolkit" so it doesn't make sense to limit the marketing on the website if it was designed to do more...my logic at least

[gildor]

I also want to say that if you want to use Flutter for UI, just use Flutter, no need to add K/N, I hardly see how it may be beneficial, except cases when you already have some relatively large piece of business logic written on pure Kotlin without platform dependant libraries (and if you have it, probably use native UI is also good solution, at least interop will be a lot better)

[Anastasia Finogenova]

@Kurt Renzo Acosta thanks I will check out the conference

[kpgalligan]

If you’ve ever been to a Google road show type of event, where they have different teams pushing their “products”, it’s pretty funny. The Flutter team will tell you everything is flutter in the future, the Chrome team will tell you native is dead, the Android team will show you crazy UI stuff, etc. Talk to Flutter marketing people. They’ll definitely tell you that Flutter will solve your mobile problems.

[Kurt Renzo Acosta]

Same comment as above. You might wanna rethink why you need it and why you were trying to merge Flutter and K/N and ask do you really need to merge it or choose one of them. (go multiplatform)

[kpgalligan]

That was what I was trying to say about the blog post. Merging flutter and KN for a smaller app is a waste of time. If doing flutter, just do all flutter.

[gildor]

And for bigger apps using Flutter also questionable (but probably Flutter people will disagree)

[kpgalligan]

Not that there shouldn’t be a Flutter/Kotlin library. I want to make it, and call it Klutter.

[darkmoon_uk]

The K/MP strategy I'm betting on is 'plain' Model/View/Presenter (Passive View), where Presenters and Contracts are defined in common. This will be cemented in place by a couple of libraries multi-mvp and coroutines-ui to provide some conventional, common ways to deal with the MVP pattern, concurrency and presenting UI interactions as Flow sources/sinks.
Platforms implement their own native View layers.
Platforms will be Android/iOS/JavaFX Desktop.
iOS will be written completely in Kotlin, not Swift/ObjC.
After evaluation JavaFX won't use TornadoFX; it's good but too opinionated for MP.

[kpgalligan]

I’ve been saying that for a while. I take no credit for the name. Good name.

[Anastasia Finogenova]

@gildor we wanted to explore of there is a right once and compile on every platform solution, so sounds like a good idea -> share UI in flutter and then share logic in KMP

[gildor]

So, it's not K/N, it's Kotlin Multiplatform if you compiler for each platform

[gildor]

I'm still not convinced that it so much better than pure Flutter solution, at least no problems with interop, it's the same language on every platform

[darkmoon_uk]

Being in Kotlin, we can also offer shared code with back-end further down the road-map. Almost every project has some model files shared between Client and Server. In our product there is also some business logic that's maintained at cost across Kotlin/.NET.

[kpgalligan]

If native UI isn’t critical, a hybrid web app is a better option than Flutter, by a wide margin. If native UI/interface is important and/or low risk, a native app is a better option than Flutter. At least in my biased worldview

[Anastasia Finogenova]

@gildor why is using Flutter for bigger apps questionable?

[Anastasia Finogenova]

That's actually what I think from the scalability perspective
..like there is no dicent networking libraries yet as far as I see, no di yet etc etc so if you want to build something to scale, tests and maintain I have concerns 🤔 and also most flutter plugins are 3rd party (not that it is bad) it is just I am used using libraries that have been tested by years and production and there is nothing like that in Fluter (of course because I wasn't tested by production itself )😅

[Dmitri Sh]

if your teams are native iOS and Android developers, wouldn't KMP be a better learning curve? for iOS devs, Kotlin is intuitive

[Jonas Bark]

@Anastasia Finogenova check out Dio regarding networking - has everything you'd expect.

At our company our main focus is now Flutter for mobile apps for our medium sized customers that need B2B apps. It's a great solution for them to save costs and our developers love developing in Flutter.
On the other hand we're also working with KMP for larger scale B2C apps that cannot be rewritten in Flutter that easily - but should still share Business logic between iOS & Android.
So yeah, we went down the Flutter path and didn't notice any blockers (yet?)

[Anastasia Finogenova]

@Jonas Bark thanks how long have you been on Flutter?

[Jonas Bark]

my company does apps for approx 16 months now and I have experience with it for over two years

[kpgalligan]

For KMP, decent networking would be ktor, although I think myself and others would like an alternate that runs synchronous calls (long story). For DI, there will be a Koin version soon-ish. I have a fork published, but chatted with the maintainer and we need to do some under the hood redesign. Not a great answer for today, but still. That’s the status on KMP.

[Sam]

I’m wrapping up a Flutter project and would echo the above by Jonas. Dart is a capable language but no one will fall in love with it with better alternatives like Swift and Kotlin. Flutter is a nice well thought out ui framework. It is what Compose is taking inspiration from. I liked the experience well enough that I would repeat it.

That said it isn’t a perfect replica of what an iOS experience is not perfect. It’s very good but not 100%. The Android experience to my eye (iPhone user here) is spot on. Plus not having to deal with activities and fragments and version incompatibilities is priceless.

My thought is pure Dart/Flutter for any size B2B and small-medium B2C apps. I would only do B2C apps in Flutter where resources are a constraint and where it’s okay to not present a fully native ui. If the app is going to work with hardware it should be native. If the app is your face to the customer it should be native. Also if the app is going to need some kind of 3D visuals (CAD) it will need to be native.

[Jonas Bark]

I absolutely agree on the hardware + 3D point - same for complex data management.
I do not, however, agree on the visual native part. Us devs and UI / UX designers will notice a difference but I highly doubt the casual users will notice and if they do - do they really care? 🙂

[kpgalligan]

My longer term concern with Flutter kind of weaves into that answer. I’m not surprised that the ios experience is not perfect, first of all. There’s not a huge incentive to make it so. I’m primarily an iphone user in a mostly Android dev world, so I’ve tried a few flutter apps, and often out of the box the experience is just kind of odd, and the iPhone experience needs more work. For B2B, I can understand the argument that it’s not critical. However, I think a lot of that world has been and will continue to be hybrid web apps. As SwiftUI and Compose mature, they will service more of the native space. Flutter might be huge in cross platform, but it also might get king of caught in the middle. That’s the long term thinking, but predicting the future is hard.

[Sam]

I think React Native has overthrown hybrid apps in the B2B world. I’m all for any solution that isn’t JavaScript. I have no love for that language. Plus R/N is not without many issues since it tries to meld two worlds.

[kpgalligan]

I’m not a fan of JS either. Just saying for apps where native ux is less of an issue, I think Flutter will have trouble seriously competing in that space. Maybe it’ll be huge. Very hard to tell. github stars don’t mean much. I would actually guess RN has not had anywhere near the impact of just react and hybrid apps. I think native developers see less of it, but htmi mobile apps, as crappy as they can be, are pervasive in the “not-consumer” world. This is all conjecture, though.