I try to do the architecture for a bigger, production ready SwiftUI App. I am running all the time into the same problem which points to a major design flaw in SwiftUI.

Still nobody could give me a full working, production ready answer. 

**How to do reusable Views in `SwiftUI` which contain navigation?** 

As the `SwiftUI` `NavigationLink` is strongly bound to the view this is simply not possible in such a way that it scales also in bigger Apps. `NavigationLink` in those small sample Apps works, yes - but not as soon as you want to reuse many Views in one App. And maybe also reuse over module boundaries. (like: reusing View in iOS, WatchOS, etc...)

The design problem: NavigationLinks are hardcoded into the View.

    NavigationLink(destination: MyCustomView(item: item))

But if the view containing this `NavigationLink` should be reusable **I can not hardcode** the destination. There has to be a mechanism which provides the destination. I asked this here and got quite a good answer, but still not the full answer:

https://stackoverflow.com/questions/61188131/swiftui-mvvm-coordinator-router-navigationlink/61188788#61188788

The idea was to inject the Destination Links into the reusable view. Generally the idea works but unfortunately this does not scale to real Production Apps. As soon as I have multiple reusable screens I run into the logical problem that one reusable view (`ViewA`) needs a preconfigured view-destination (`ViewB`). But what if `ViewB` also needs a preconfigured view-destination `ViewC`? I would need to create `ViewB` already in such a way that `ViewC` is injected already in `ViewB` before I inject `ViewB` into `ViewA`. And so on.... but as the data which at that time has to be passed is not available the whole construct fails.

Another idea I had was to use the `Environment` as dependency injection mechanism to inject destinations for `NavigationLink`. But I think this should be considered more or less as a hack and not a scalable solution for large Apps. We would end up using the Environment basically for everything. But because Environment also can be used **only** inside View&#39;s (not in separate Coordinators or ViewModels) this would again create strange constructs in my opinion.

Like business logic (e.g. view model code) and view have to be separated also navigation and view have to be separated (e.g. the Coordinator pattern) In `UIKit` it&#39;s possible because we access to `UIViewController` and `UINavigationController` behind the view. `UIKit&#39;s` MVC already had the problem that it mashed up so many concepts that it become the fun-name &quot;Massive-View-Controller&quot; instead of &quot;Model-View-Controller&quot;. Now a similar problem continues in `SwiftUI` but even worse in my opinion. Navigation and Views are strongly coupled and can not be decoupled. Therefore it&#39;s not possible to do reusable views if they contain navigation. It was possible to solve this in `UIKit` but now I can&#39;t see a sane solution in `SwiftUI`. Unfortunately Apple did not provide us an explanation how to solve architectural issues like that. We got just some small sample Apps.

I would love to be proven wrong. Please show me a clean App design pattern which solves this for big production ready Apps. 

Thanks in advance.

------- 

Update: this bounty will end in a few minutes and unfortunately still nobody was able to provide a working example. But I will start a new bounty to solve this problem if I can&#39;t find any other solution and link it here. Thanks to all for their great Contribution!

--------
Update 18th June 2020:
I got an answer from Apple regarding this issue, proposing something like this to decouple views and models:


    enum Destination {
      case viewA
      case viewB 
      case viewC
    }
    
    struct Thing: Identifiable {
      var title: String
      var destination: Destination
      // … other stuff omitted …
    }
    
    struct ContentView {
      var things: [Thing]
    
      var body: some View {
        List(things) {
          NavigationLink($0.title, destination: destination(for: $0))
        }
      }
    
      @ViewBuilder
      func destination(for thing: Thing) -&gt; some View {
        switch thing.destination {
          case .viewA:
            return ViewA(thing)
          case .viewB:
            return ViewB(thing)
          case .viewC:
            return ViewC(thing)
        }
      }
    }


My response was:

&gt; Thanks for the feedback. But as you see you still have the strong
&gt; coupling in the View. Now &quot;ContentView&quot; needs to know all the views
&gt; (ViewA, ViewB, ViewC) it can navigate too. As I said, this works in
&gt; small sample Apps, but it does not scale to big production ready Apps.
&gt; 
&gt; 
&gt; Imagine that I create a custom View in a Project in GitHub. And then
&gt; import this view in my App. This custom View does not know anything
&gt; about the other views it can navigate too, because they are specific
&gt; to my App. 
&gt; 
&gt; I hope I explained the problem better.  
&gt; 
&gt; The only clean solution I see to this problem is to separate
&gt; Navigation and Views like in UIKit. (e.g. UINavigationController)
&gt; 
&gt; Thanks, Darko


So still no clean &amp; working solution for this problem. Looking forward to WWDC 2020. 

-------------

Update September 2021:
Using `AnyView` is not a good general solution for this problem. In big Apps basically all views have to be designed in a reusable way. This would mean that `AnyView` get&#39;s used _everywhere_. I had a session with two Apple developers and they clearly explained to me the `AnyView` creates a way worse performance then View and it should be only used in exceptional cases. The underlying reason for this is that the type of `AnyView` can&#39;t be resolved during compile time so it has to be allocated on the heap. 

All Swiftui Navigationlink Solutions on Gang of Coders

Total of 1 Swiftui Navigationlink Solutions

SwiftUI - how to avoid navigation hardcoded into the view?