You would just use some architecture pattern. I would say the most natural one for SwiftUI is MVVM so the logic would go to viewModel.

Do I understand it correct when the UI then calls methods or functions on a model layer?

> Your Delphi setup isolates business logic from UI. Which may seem "overly complex" in trivial demoes, but will help you the very moment you write the first test or add some business logic.

So basically, the same as Cocoa/obj-C?

> It's also why I see so many React apps spiral into an unmaintainable mess within days after their "git init".

This is true for any library/framework/architecture, and the same problem is very prominent in Svelte/Vue/React/Backbone/Angular and everything else.

> and everything else.

No. It's true for any library or framework that lack isolation or decoupling concepts.

In react (and many of the ones you mention) there is nothing on place that guides you into decoupling. It has nothing, not even conventions, that help a junior to put stuff in the right place (or to prohibit or make it difficult to put stuff in the wrong place).

Part of that is due to how in TS/JS everything can grope around in everything else. But the bigger part is lacking conventions, primitives and structure in the libs and frameworks.

Sure, a library (which react is) doesn't provide structure (it's a distinguishing trait from frameworks). But the many frameworks on top of React don't do a good job either. They either become some Enterprise Ready amalgamation of saga's, redux, message-bus, setups, or they offer too little guidance. And in all situations, it's still possible to just fire a fetch() or put data transforms or business logic within the UI. Only discipline keeps people from taking this "much easier" route.

And when only discipline stands between us and "the easier way for now", that "easier way for now" will be chosen, and pain in future will be felt.

>They either become some Enterprise Ready amalgamation of saga's, redux, message-bus, setups, or they offer too little guidance

At least Redux provides a semblance of immediately grokable data flow, this all gets worse with mobx which gives you all the flour you need to make spaghetti for the whole village. Worked on a codebase where you might have to chase down references across all sorts of files you wouldn't expect because everything is 'observable' so people, working 2-week sprints, just stop thinking about any kind of coherent structure cause it works anyway.

TBC. I don't mean that "redux == bad" just that it's often part of a large swath of systems that somewhat work together. And then still does not prohibit developers or libraries or mui or whatever from also keeping their own state in some `useEffect()` or `useState()`.

I've seen too many react projects that employ all sorts of enterprise patterns (amongst which redux) yet also wrangling-spagetti of useEffect and useState, often intermixed. There's one thing worse than having to unknot a mess of useStates: thats having to unknot a mess of useStates that is sometimes synced to and sometimes from and sometimes both, a redux global state.