The viewStore is created in the init, although it is an ObservedObject. From what I understand, @ObservedObject should be injected and not created by the view because when init is called again (that can happen anytime) then the viewStore is created again. I thought that @StateObject was the way to go when we want the view to own the lifecycle of the created objects.
officially supported by Apple but discouraged in their documentation.
If you know what are the consequences of doing like this (meaning that the ViewStore will only be instantiated once for the lifetime of the View), it will work as expected, and this is the only way to instantiate a StateObject from an init. But this "gotcha" is why this is not publicized a lot by Apple, even if they confirmed it would work fine in some SwiftUI lounge.
As for the rest of the discussion, iOS 13 support is indeed the only thing preventing to make WithViewStore use a @StateObject, but a few related performance improvements are already in preparation and can be released in the upcoming weeks if they don't have adverse effects.
As soon as TCA ends official support for iOS 13 (in one way or another), WithViewStore will be able to switch to @StateObject, provided this construct still makes sense at this moment.
While it is true that observable objects are typically passed in from the parent rather than instantiated from inside, in this case it is ok. This is because the actual source of truth for the view is from the store, which is passed into the view.
And as @tgrapperon we do plan on using @StateObject inside WithViewStore, but more for performance reasons than correctness reasons. We won't do that until 1.0 probably where we will drop iOS 13 support.