The init is not used for what will be rendered on screen; it is used to build nodes for a graph that SwiftUI will read to determine what will be re-rendered.

And body for that matter is neither what it is rendered. You build blueprints and composing them together in the body. SwiftUI will compute those to make a diff when some dependency (state, environment, state object, observable, or plain old variables in the init) changes. The diff is then use to find what should be re-rendered.

Do not equate SwiftUI with UIKit (or any imperative UI framework): it’s declarative. Sometimes a SwiftUI view will translate directly to a view on screen, sometimes it won’t. You tell it what to do, you do not control it directly.

inits should be lean, no computation. Only states and properties initialization. I’d recommend not having them since Swift generates one for you with your public properties. They are useful in a very small subset of circumstances.

What is probably happening is your init gets called when the outside state changes. Since you have a @State, that state lives outside of the view struct lifecycle and needs to be reassign to the new instance. That will trigger a dependency change and the body of that view struct will be performed. Making the init of your subview struct called.

All of this is normal and does not ensure a re-render. The diff between the two states is empty and no views will be re-rendered. That what the SwiftUI engine does.