I am also interested in this! My use case being: we have internal frameworks that we link to our main app target, and that gets deployed via a CI server. (Github actions and Fastlane). I'd like to include test coverage of these frameworks in the overall test coverage report, since those frameworks are more heavily tested than the app target. It would be nice if it could just be run in one go, without having to do much else with the CI server's configuration. Otherwise, is there a way to make use of a test coverage report that can be saved in our repo, as these frameworks don't change much, but would have a coverage report we can make use of?

First of all, thank you for taking the time to post all of this detailed discussion. I have to admit, I started scanning, perhaps because I'm not sure if this resonated with me entirely. I like the separation between what a view can do and how a view model responds to actions and is responsible for changing state that the view is ultimately binding. The view model adapts all of the data it manages to a format the View needs. So I dunno; whether one is using UIKit or SwiftUI, one can take a similar approach. You could argue this is over-enginering; I consider it a separation of concerns. I personally believe a View should be vapid and vain: as dumb as possible and only interested in how it should look. So, if somebody interacts with it, it just notifies its view model. View Model does the heavy lifting then changes state as required, and the View binds properties that are required for it to look good / right.