Hello guys, is jetbrains working on multiplaform n...

# compose

[brabo-hi]

Hello guys, is jetbrains working on multiplaform navigation library?

[Hristijan]

Yes

[Stylianos Gakis]

I’ve seen a bulletpoint somewhere that they do want something to make happen there.
And there’s also an issue which tracks if/when androidx.navigation will manage to itself become multiplatform https://issuetracker.google.com/issues/214568825
These two things as may or may not be connected with each other, but in any case, JB has said that they want something to be done there.

[Konstantin Tskhovrebov]

Try https://github.com/adrielcafe/voyager 👍

[brabo-hi]

that's what we are currently using on some projects, my question was mostly to know jetbrain's roadmap regarding navigation and string resource management in KMM

[brabo-hi]

is there any plan to develop a native solution? or to use third party libraries

[Konstantin Tskhovrebov]

Why do you prefer one over other solutions?
Something is missing there?

[brabo-hi]

Nothing specifically, we are using it on other platforms except android where we still using jetpack navigation. Our decision is to see id we should migrate that part to use voyager instead and keep w single navigation.
One thing we haven’t tried with voyager is multiple modules navigation

[Pablichjenkov]

One thing Voyager lacks is platform lifecycles, onCreate/onStart/onStop/onDestroy. These are essentials to build an App. There is a way to integrate platform lifecycle in Voyager but it is not the nicest code.
I see many people using Voyager, they treat LaunchEffect as if it was onStart, and this is a big mistake.

[Pablichjenkov]

So far the closest to reality are Appyx and Decompose but then many complain about their complexity.
So at the end it seems people got used to jetpack navigation 🤷🏻‍♂️

[Pablichjenkov]

I do believe a navigation library is something should be provided first hand. All other UI declarative frameworks provide one solution, swift ui, flutter, react native, jetpack compose so compose multiplatform should offer an off the shelf solution too.

[Konstantin Tskhovrebov]

The voyager has own screenModel with a life cycle.

[Pablichjenkov]

Humm, interesting. Seems that I am outdated. Sounds good then.

[Hristijan]

I've been using

https://github.com/Tlaster/PreCompose

No issues, similar to Compose Navigation on Android

[Pablichjenkov]

I went through the Voyager code and I see it has some lifecycle stuff but as I mentioned this lifecycle by default is tied to the composable lifecycle. There is a sample for Android Integration for a custom lifecycle provider but there is nothing for iOS. And although the integration is not hard, the events don't match one to one.

[Pablichjenkov]

Yeah PreCompose is the closest you get to jetpack navigation and it has platform lifecycle integration, that is right.

[McEna]

Maybe it is covered by the efforts to make jetpack libraries compatible with KMM?

[Hristijan]

I think that'll be the case as I read somewhere that Google and Jetbrains will be collaborating for this solution

[McEna]

That's logical, otherwise, multiplatform kotlin and compose will compete with Jetpack patterns, and that's detrimental to both

[Joel Denke]

Also curious if JB and Androidx libs aligning, if we will see movement from Googles monorepo AOSP into JB open source or something new. That would make these roadmaps and commitment more transparent I guess.

For pure native navigation I recommend using https://slackhq.github.io/circuit/navigation/ for CMP projects. Best library so far I think. Hopefully Slack could help JB and Google, as seems using proper latest androidx APIs. Like predictive back gestures.

[brabo-hi]

@Joel Denke is Circuit multiplatform ?

[ribesg]

I'm also in the "how the hell do you actually do Compose multiplatform" limbo and kinda lost with Voyager, PreCompose, Decompose, Appyx, Circuit, Ballast… Do you just pick one and hope it doesn't die? Wouldn't they basically all die the moment there's a Jetbrains/Google lib?

[Stylianos Gakis]

No why would they die? It’s not like everyone uses androidx.navigation on Android itself even. Many people might just not like the solution JB brings out for navigation.
Just pick one and use it, that’s what you should do. After you’ve successfully used one of them you will have a much stronger point to start off of, and you can much better assess what your next one will be, if you are happy with what you chose or if you want to try something else.
Before you even pick one of them to use, then all you can do is either guess or hear other people’s opinion about them. But as you can see everyone has their own favorite, there is no “de-facto” nav library because they are all a bit different in various ways.
If you really struggle to even just pick one at random, just do something silly like pick the one with the most stars. Or go to previous discussions around them and just hear what people have to say about them.

[Joel Denke]

Even if library deprecated can fork it yourself. Apparently no one likes existing nav solutions and keep adding more 😁

[ribesg]

I'm talking more about risk management here. In my case picking the less likely to die lib is more important than picking the coolest or the most user friendly or whatever. It's for an app rewrite, with one strong argument for the rewrite being the current/previous technology isn't future proof… I can't just pick any random lib

[ribesg]

Important questions would be, which one would be the easiest to migrate from? Or, assuming a potential "official" lib would most likely match android navigation, which of those lib is the closest to android navigation already?

If I had to choose based on personal preference I would pick something that more heavily relies on functions rather than classes, but I'm not sure it matters in my case

[Hristijan]

Precompose is currently the easier to migrate from, same API surface as the Compose Navigation Component by Google

[Stylianos Gakis]

If you are not confident in that if things change that the migration path to the new lib won’t be easy, or that the pick you make won’t be sufficient for use then don’t do it in production until you are confident enough. Do it in a sample project which you are ok with experimenting.
Or do exactly that, see which one of the solutions is the least intrusive, aka the one that does not leak everywhere (DI, presenters, inside your UI code etc), so that you know if you need to migrate it’s gonna be easy to do so.
PreCompose is indeed the closest one to the androidx API, but that is assuming that you will be migrating to that when it eventually becomes KMP compatible. And that you are willing to wait until that happens. For all we know that could be in 2026, or it could be next month, there’s absolutely no timeline shared with us around this at least as of right now. And we don’t know for sure either that JB will be basically providing androidx.navigation as a KMP lib. It may be that they are only getting inspiration from it but they might provide a completely different API 🤷 It’s all speculation at this point imo.

[Arkadii Ivanov]

Noone can predict when a library will become deprecated. Even Google deprecates things and replaces with newer ones. Of course there will be a replacement and migration guides, but still the API may be completely different.

So I would pick one of the libs, or try multiple in a sample project, and then use one. Then maybe migrate to an official one if you find that better.

[Joel Denke]

Make sure decouple your navigation with custom navhost/controller interface. Then doesnt matter if switch. By using that I was able migrate between androidx navigation, circuit, Voyager and decompose very fast. In my case evaluating which one best in my opinion.
Impossible evaluate risk. Reduce risk by decouple your code from Android, iOS and library SDKs with good interfaces and architecture and youre fine :)

[Ian Lake]

FWIW, in Jetbrains recent roadmap blog post, they did say they are working on a solution for multiplatform navigation: https://blog.jetbrains.com/kotlin/2023/11/kotlin-multiplatform-development-roadmap-for-2024/

And that work has included us (the androidx.navigation team) talking with them directly, as mentioned here: https://twitter.com/ianhlake/status/1725225989943464234

[Pablichjenkov]

Not to say that the 3rd parties aren't great. Indeed they are but as a comment mentioned above, other things like maintainability, licencing, support are to consider. And nothing better for that than a first hand solution.

[Ian Lake]

You'll want to +1 the official issue in the issue tracker for multiplatform support in Navigation Compose if that's something you're interested in: https://issuetracker.google.com/issues/281774647

[Pablichjenkov]

+1 Did it in the past already yeup

[Ian Lake]

But yes, lots of choice. There's absolutely no requirement to use any particular navigation library - that's one reason why it is part of androidx.navigation and not hosted directly as part of androidx.compose itself - it is just one of my totally valid choices to choose from 🙂

[McEna]

Are those blockers dependencies on external teams, or is it just a bandwith/priority issue? Also, would you take contributions for those?

[brabo-hi]

I think android compose navigation is the best way to go, it will be easy to migrate web based app. However it needs to review the way it handles argument type, deep linking, the code could be more simpler