Earlier quoted context omitted.
I find that in larger GUI apps the best thing to have is a layered architecture where visual and non-visual parts are separated globally, not on a view-by-view basis. One advantage of this is that you can slice off your visual part and have something like a "headless browser" variant of your app. Among other things this is good for writing integration tests if you also have a backend. Same trick is impossible or very…
> visual and non-visual parts are separated globally, not on a view-by-view basis Yes, yes, and YES! This is something that confused me greatly over the last years: teams/companies I was in contact with were really struggling getting MVC to work (never mind MV*) and I wasn't...but I wasn't doing anything special, at least not that I could tell. I would implement my model, TDD-style, put minimal views on top, possible…
> Exactly. Do this.
> The app is an object. It has an API. It knows how to coordinate its pieces. The local I/O, the remote I/O, any timing stuff. All of it. Then you plonk the UI on > top of that. You can have sub-parts, but you need one piece that ties it all together, on the model side.
This is exactly what I did with all projects I've worked on. It helped that I had to target both, iOS and macOS where sharing "business logic" was crucial, so you were kinda "forced" to think about that.
To put it simply, there is one question I'm asking myself, can I delete UI and then rewrite it from scratch without updating non UIView/NSView code (just calling MyClasses i.e. my APIs)? Let's just say, if I have to write NSSortDescriptor again, that means there is an architectural issue with my code, which has to be fixed.