There is a .NET Core project under the Run folder called VM, and which is compiled into VM.exe.

This project has a reference to the following shared projects:

• App.Domain
• ViewModel

Unlike the UI based runtimes (UWP, Android and iOS) this runtime does not reference the View.UI project, making it a simple and pure runtime to develop and test your app's view model, domain, integrations, etc. It also encourages you to maintain a strict separation of concerns, with a ViewModel that is clean from any UI framework dependencies.

This has several benefits:

• Rapid compile-run-feedback cycle: During the development process you can press F5 to instantly compile and run a console app.
• Architecturally pure: Not even having access to the Views is a good restriction, leading to an elegance separation of concerns.
• C# Skills only: This can be developed by any C# backend developer who either doesn't have Zebble skills, or does not want to doing UI.
• No threading hassle: There is no notion of UI Thread / Threadpool to worry about. You just can't block the UI thread or make the app freeze.
• Easier testing: The abstract view model can be tested using standard unit testing tools without worrying about the UI.
• Better performance: The Zebble MVVM framework automatically manages the View lifecycle and uses various optimization techniques such as caching,  eager template instantiation.
• Easier UI development: The Zebble UI developers can focus on implementing one page at a time simply from the pre-defined ViewModel schema without worrying about the application flow, database, etc.

Command line interface

When starting your app using VM.exe, the StartUp logic is executed and your first page is established.

At this point, in the command prompt, you will see something like the following:

It shows you:

• The current state (view model page)
• Its bindable properties and their current values
• Actions that can be invoked

Compare that with a real user interface, where you would see the page, the data, and a button for each action that you can take. From there, the user is expecetd to tap a button (or another gesture) to go from that page (state) to another.

Similarly, in the VM.exe mode, you will see an option to choose to invoke, for each action (method) on the view model. Every time that you select an action, the method will be invoked, in which case either the page state (bindable properties) will be changed, or you will move to another page. This creates an infinite loop, whereby you can interact with the app using simple command selections and simulate a full workflow.

In the above example, if you type the button number (1) and press enter, the following will happen:

Basically, the console is showing you that the current page is now "LoginPage". Its bindable properties of Email and Password are both holding the current value of NULL. And you have 2 action choices.

In addition, at every step, you will be able to change the value of the bindable properties (Email and Password in the above example) using the following:

Email=hello@test.com

Of course in the real app UI, you will have data input controls for this purpose.