Thanks for sharing. I want to know more about user interactions in MVVM pattern.

The best way to think about a View Model is that it describes UI using your own domain classes, not UIKit classes.

For instance, you can have a Greeting Screen View Model describing data which has to be then bound to corresponding Greeting View Controller. When you want to present UIAlert create a Dialog View Model in the Greeting View Model and ask the View Controller to present it (use delegation, or block callback). In case of block it can look like self.presentDialog(self.dialogVM()).

Than its View Controller’s responsibility to create UIAlertController and map data and actions from the Dialog View Model.

Same approach can be used for presenting next View Controllers, you get a new VM from current VM, then the current VC injects it into a new VC and presents it.

The whole idea that your VC is only responsible for displaying UI and all business decisions are taken in VM.

If you didn’t import UKit into a VM you have guaranty that you are not relying on UIKit objects with some undefined state inside. For instance you don’t worry about current state of navigation stack.