Question about navigation stacks and nested child stacks in Decompose

[benMohamed]

Hello,

I’m currently integrating the Decompose SDK into a KMM project. Since my background is mainly iOS development, I’m trying to clearly understand how navigation in Decompose maps to concepts I already know from iOS.

On iOS with SwiftUI, we typically use a single NavigationStack that manages a stack of views, and it’s generally discouraged to push a NavigationStack inside another one. The idea is to have one navigation container responsible for the entire navigation flow.

If I understand Decompose’s architecture correctly, it seems that it is possible (and maybe common) to have a Child Stack pushed inside another Child Stack — essentially nesting navigation stacks via child components.

My question is:
Is this approach considered normal and recommended in Decompose? Or should navigation ideally be centralized in a single stack, similar to best practices on iOS?

Thank you in advance for your guidance.

[arkivanov]

Great question, also see #525

In general, Decompose encourages nested tree-structured architecture. It's common to have sub-stacks for separate flows (e.g. login/registration flow can be a separate stack). This works particularly with Jetpack Compose, because each screen can have its own top app bar and navigation gestures are handled at the parent/host level.

This however doesn't work great with SwiftUI. Though, there were some workarounds in the wild. If you are going to use SwiftUI, it should be ok to constrain your architecture to one global stack. You will probably need one big sealed interface for screen arguments.

Cc @AJIEKCX, in case you have an update on this. I remember you mentioned a workaround.

[benMohamed]

Thank you @arkivanov for your response.

I checked the workaround suggested by @AJIEKCX . It may work for a small app, but it doesn’t scale well for a large project—especially when integrating an iOS TabView with a bottom or top bar.

I think we are facing two main points here. First, the way Decompose works fits Android projects very well, but it’s not as straightforward on iOS. Second, the idea of using a single global stack might work, but it would reduce the project’s structure and overall cleanliness.

I believe we need to go deeper and find a better solution. I have a few ideas that require some work and testing, and I’ll keep you updated if I find something solid.

[arkivanov]

Yes, please share, if you find anything useful!

Second, the idea of using a single global stack might work, but it would reduce the project’s structure and overall cleanliness. We could incorporate that in the sample and/or docs.

Indeed. But to be honest this looks more like a limitation from SwiftUI.