Thank you Azam for elaborating your views much appreciate it.

MVVM does not promote creating multiple viewModels per screen because of the possible downsides mentioned below

While there might be situations where multiple ViewModels could work, it's crucial to weigh the advantages against potential drawbacks. Here are a few factors to consider:

1. Code duplication.

2. Architectural purity.

3. Complex data flows .

4. High Memory Consumption due to multiple VMs .

5. Code clutter.

6. Maintenance Challenges.

Here's a version of how I propose to do the decoupling and maintain SOC and SRP just adding one more reference for the developers to choose from

https://gist.github.com/codecat15/68b88fa96f928d22eba9e586618ddaab

In the context of your example, it's interesting to observe that the "StoreModel" essentially functions as a ViewModel.

I'm curious if there's a particular rationale behind labeling it as a "Model" instead of a "ViewModel."

In iOS app development, the term "Model" typically denotes a data representation entity, and introducing functions that manage API and database interactions in a file labelled as "Model" can lead to semantic confusion.

We don't use such semantics in other declarative frameworks, and there are precise sevices, repositories, DAOs, utilities for low level abstraction than using a "Model"

Therefore, wouldn't it be more precise to designate it as a ViewModel?

Could you kindly elaborate on the criteria or scenarios that guide one's decision to use a "StoreModel" as opposed to a more conventional "StoreViewModel"?

This differentiation could provide valuable insights into the separation of concerns and architectural decisions within your codebase.

OR if they are the same then why not use the standard naming convention and avoid confusion?