MVC Swift vs MVVM on iOS: Key Differences With

Examples
Model-View-Controller (MVC) and Model-View-View Model (MVVM) are common software
patterns to help Swift developers build diverse, useful mobile applications. Learning the key
differences between the systems can help you find a better fit for your next project.

During the development of a modern iOS app, you need to select the proper architectural
pattern for the project and end user. The choice should be based on many factors, such as
expected app complexity, the experience of the team working on it, or the deadline for
implementation.

Before you choose a pattern, you’ll need to understand how they work, as well as what
problems they address and, in some cases, create. We can start by comparing two of the
most common mobile architectural patterns in the iOS environment: the
Model-View-Controller (MVC) pattern used by Apple together with third-party developers and
the Model-View-View Model (MVVM) originating from Microsoft's ecosystem.

What is the Model View Controller Pattern?

MVC stands for Model-View-Controller – an architectural pattern separating an application
into three main logical components, each of which is assigned to handle specific aspects of
the application.

The MVC pattern divides the responsibilities of an iOS application into different sectors that
serve their purpose. The MVC separates the business and operations side of the application
from the presentation layer while taking a middleman, known as the controller object, to
facilitate interactions between the Model and View, including retrieving data from the
database, manipulating it and either sending it back to the database or using it for rendering.

MVC Pattern
First of all, let’s take a look at the three layers that organize code in the
Model-View-Controller pattern:

●​ Model – is responsible for storing the data but should not manipulate it for the View’s
needs, as it is not aware in any way of the View. The model data is crucial as it is
used to create views that accurately represent the output to the user, including
various customer views with UI components.​

●​ View – has two responsibilities: it takes care of presenting the data to the user and
receives the actions made by the user. It is not aware in any way of the Model – it is
updated with processed data by its owner. Because of this characteristic, View
should be devoid of any business logic.​
 ●​ Controller – owns and communicates with the View and Model layers. It’s responsible
for updating the Model and the View with processed data from the Model. In the
simplest setup, Controller is usually set as a delegate to the View or it sets up proper
callbacks for the View to be able to update the Model and View based on user
actions.

Relationships between main MVC Components

MVC Advantages
The MVC design pattern provides the following advantages:

●​ Simplicity and ease of use. Due to the small count of simply defined components, it
is hard to find a pattern that would be more straightforward to introduce and maintain
than MVC.
●​ Clear separation of concerns. It is obvious what should be part of either the View or
Model.
●​ Reusability. Both View and Model are not tightly coupled with other components, so
it is easy to reuse them.
●​ Vast Learning Resources. It is one of the most common patterns. It was the most
frequently used in the early days of iOS development. It is widely understood by iOS
developers, and many learning resources regarding its usage are easily accessible.

MVC Disadvantages
While having strong arguments for implementation, the MVC pattern could also cause the
following issues during the development process:
 ●​ Controller is kind of a catch-all object here. If a given task does not belong to the
View or the Model, it usually ends up being implemented in the Controller, causing it
to become a large and complex object. This problem is frequently referred to as
Massive View Controller or Fat View Controller.​

●​ To ensure the quality of the code, at least the business logic should be covered with
unit tests. In this pattern, this logic is placed in Controller – a complicated object
tightly coupled with both View and Model. This complexity significantly hinders
effective unit testing, making it very hard to write proper tests that can ensure code
reliability and performance.​

●​ Direct result of those two drawbacks is reduced testability of this pattern. As the
Controllers grow in size and complexity, they cause difficulty in covering the app with
sufficient unit tests, along with problems in both maintaining and developing the
application.​

MVVM Pattern
MVVM, short for Model-View-ViewModel (MVVM), is an architecture pattern that enhances
the separation of the graphical user interface from the business logic or back-end logic.
Similarly to MVC, this pattern divides the application into the model and view components.
However, unlike MVC where the controller mediates between the view and model, in MVVM,
this role is fulfilled by the ViewModel.

This leads to a cleaner separation of concerns, with the ViewModel acting as the mediator
and housing the business logic code that is separated from the view. The MVVM design
pattern offers several advantages over other patterns, such as MVC and MVVM, by
providing a more efficient way to build interactive applications.

MVVM Pattern
To address the problems mentioned above, MVVM introduces one additional layer to the
MVC setup. It is called View Model, and it replaces C with VM in the MVVM (even though
Controllers are still present in this pattern). Please note that the Model and the View have
the same responsibilities as in MVC.

●​ Model – is responsible for storing the data but should not manipulate it for the View’s
needs as it is not in any way aware of the View.​

●​ View – has only two responsibilities: takes care of presenting the data to the user and
receives the actions made by the user. It is not aware in any way of the Model – it is
updated with processed data by its owner. Because of this characteristic, View
should be devoid of any business logic.​

●​ View Model – is a new layer between the Model and the Controller. It owns the Model
and takes care of manipulating its data in a way that makes it ready to be displayed
 by a simplified View. Additionally, it enables data binding, which facilitates two-way
communication between the view and the model, automating the propagation of
modifications and ensuring a clean separation of concerns.​

●​ Controller – retains the responsibilities of setting up and coordinating the components

it owns. Controller role is simplified in comparison to MVC because the business
logic related to manipulating the Model’s data is moved to the View Model layer. The
second difference is that it owns View Model instead of owning Model directly.​

Relationships between main MVVM Components

MVVM Advantages
Considering the introduction of the View Model layer, here are the advantages of the MVVM
pattern.

●​ Clear separation of concerns. It is obvious what should be part of View or Model.

●​ Reusability. Neither View nor Model is tightly coupled with other components, which
makes it easy to reuse them.
●​ Popularity. In the iOS world, MVVM is a newer pattern than MVC. Even so, it has
become frequently used in recent years and many learning resources are within easy
reach.
 ●​ Improved testability. In contrast to MVC, business logic is moved to the View
Model, which makes it easy to test by mocking Model's data and checking View
Model's properties and methods.
●​ Improved scalability and reduced complexity. MVVM increases scalability, which
means that – with the growing size of the app as well as the count of the features and
user flows – the complexity of its internal structure stays at a reasonable level longer
than in the MVC pattern. This is especially true when taking into account the flexibility
in choosing the way of communication with the View Model, depending on the case
we can use the Delegate pattern, bindings, or callbacks. This scalability could be
increased even further by introducing Coordinators to extract the app's navigation
logic from Controllers. We would then call this new pattern MVVM-C.

Example of implementation in MVC and MVVM

Now, let’s consider a simple component in a to-do app that displays one task on some
screen with a list of tasks to see the difference between MVC and MVVM. In both MVC and
MVVM architectural patterns, the user interface plays a crucial role in transforming model
objects into graphical components like HTML, CSS, and jQuery, making data accessible and
interactive for the user.

Common parts in MVC and MVVM implementations

Here are: Task (Model), TaskView, and TaskViewDelegate – those will be exactly the
same in both implementations. In the View, we are skipping the implementation of the init
and setting up the tap action handling. Note that this step is not related to or affected by the
architectural differences of the MVC or MVVM patterns.

struct Task {
​ var text: String
​ var isChecked: Bool
}

protocol TaskViewDelegate {
​ func didTap()
}

final class TaskView: UIView {

​ weak var delegate: TaskViewDelegate?

​ private let imageView: UIImageView

​ private let label: UILabel

​ // Skipping init and setting up of the tap action that triggers didTap delegate method

​ func update(with image: UIImage?, and attributedText: NSAttributedString) {

​ ​ imageView.image = image
​ ​ label.attributedText = attributedText
​ }

Example of Controller in MVC implementation

Here is the implementation of MVC's controller. In this example, the controller is responsible
for owning the Model and transforming data into properties consumable by the TaskView.
This time, we are skipping the setting up of the view, as well as triggering the initial update;
this part will be the same in both architectural approaches.

final class TaskViewController: UIViewController {

​ private let taskView: TaskView
​ private let attributes = [NSAttributedString.Key: Any]() // Empty, for demo purposes
only
​ private var task: Task

​ // Skipping setting up the view and triggering initial update

​ func didTap() {
​ ​ task.isChecked.toggle()
​ ​ updateView()
​ }

​ func updateView() {
​ ​ let image = UIImage(named: task.isChecked ? "checkedTaskIcon" :
"taskIcon")
​ ​ let attributedText = NSAttributedString(string: task.text, attributes: attributes)
​ ​ taskView.update(with: image, and: attributedText)
​ }
}

Example of View Model in MVVM implementation

Now, let's see how we could implement a View Model that would own the Model, toggle its
isChecked value, and expose properties to the View that would be computed from Model's
data.

struct TaskViewModel {
var image: UIImage? {
UIImage(named: task.isChecked ? "checkedTaskIcon" : "taskIcon")
​ }
​
​ var attributedText: NSAttributedString {
​ ​ NSAttributedString(string: task.text, attributes: attributes)
​ }
​
​ private let attributes = [NSAttributedString.Key: Any]() // Empty, for demo purposes
only
​ private var task: Task

​ init(task: Task) {
​ ​ self.task = task
​ }

​ func toggleTask() {
​ ​ task.isChecked.toggle()
​ }
}

Note that even though moving the business logic to the View Model increases the code-line
count, the result appears more readable since TaskViewModel has very obvious and
limited responsibilities. In addition to that, writing unit tests for it is simple. For example, this
is how a method testing the image property could look:

func testImage() {
// given
let task = Task(text: "Fixture Text", isChecked: true)
let sut = TaskViewModel(task: task)

// then
XCTAssertEqual(sut.image, UIImage(named: "checkedTaskIcon"))
}

Finally, let’s see how introducing the View Model will change the Controller in an MVVM
implementation.

final class TaskViewController: UIViewController, TaskViewDelegate {

private var viewModel: TaskViewModel

// Skipping setting up the view and triggering initial update

func didTap() {
viewModel.toggle()
updateView()
}

func updateView() {
taskView.update(with: viewModel.image, and: viewModel.attributedText)
}
}

Conclusion from MVC and MVVM implementations

From the code above, we can see that adding View Model layer streamlined the controller
visibly. The removed code is now encapsulated inside a well-defined struct. Take special
attention to how much easier it is to test the MVVM approach because we can directly
access the results of manipulating mocked data provided to the View Model. In MVC’s case,
we would need to either:

●​ Test the TaskView object to check the logic placed in the Controller. Since we would
be checking a system of two objects, this would actually be an integration test
instead of a unit test. A drawback here would be that to test all possible
configurations of view (n) and controller (m) we would need to write n*m instead of
n+m tests. It is easy to see that, in this scenario, the cost of maintaining tests grows
quickly alongside complexity.
●​ Change the implementation of the Controller by putting the data manipulation code
into two non-private properties. This would mean sacrificing the readability of the
class for the sake of its testability. While this practice may be acceptable in an easy
case, with growing complexity, it would be an increasingly difficult problem to cope
with.

Summary
While selecting the architecture pattern is one of the most important responsibilities of a
developer working on a mobile app, this decision has to be made considering the project's
specific needs.

It is impossible to name a universally applicable pattern for software development, as all

patterns have benefits and disadvantages that will fit some use cases better than others. If
you are working on a simple project that you don’t plan to make more complicated in the
future, MVC is an easy-to-implement pattern suited for your use case.

On the other hand, if you want your app to be a little easier to expand and maintain when it
is getting more complicated, we have provided an example where MVVM streamlines the
testing process and divides the responsibilities. MVVM could be a good choice for your app
if you would like to avoid overgrown controller classes or facilitate the process of writing unit
tests.
Understanding the Differences: MVC vs. MVVM
When it comes to software architecture, choosing the right pattern is crucial for building
scalable, maintainable, and testable applications. Two popular patterns,
Model-View-Controller (MVC) and Model-View-View Model (MVVM), provide structure and
separation of concerns.

I will explore the differences between MVC and MVVM, highlighting their unique
characteristics, advantages, and use cases.

Differences Between MVC and MVVM

The main differences between MVC and MVVM are, as follows:

Separation of Concerns

MVC separates the application into three main components:

●​ Model: Represents the data and business logic of the application.

●​ View: Handles the presentation layer and user interface.
●​ Controller: Manages the interaction between the Model and the View.
MVVM also emphasize separation of concerns, but with three different components:

●​ Model: Represents the data and business logic, similar to MVC.

●​ View: Handles the UI and presentation layer, akin to MVC.
●​ ViewModel: Acts as an intermediary between the View and the Model, exposing data
and commands for data binding.

View-Model Communication

In MVC, the View communicates directly with the Controller to handle user interactions and
updates. The Controller then interacts with the Model to retrieve or update data. The View
does not directly reference the Model.

In MVVM, the View communicates with the ViewModel through data binding. The ViewModel
exposes properties and commands that the View binds to. The ViewModel, in turn, interacts
with the Model to retrieve or update.

Data Binding
MVC typically does not have built-in data binding capabilities. The View relies on the
Controller to retrieve data from the Model and update the UI manually.

MVVM introduces powerful data binding capabilities. Data binding establishes a connection
between the View and the ViewModel, allowing automatic synchronisation of data between
them. When data changes in the ViewModel, the View is automatically updated, and user
interactions trigger commands in the ViewModel.

In Flutter, there are several popular state management frameworks that provide data binding
capabilities:

●​ Provider. Provider is a lightweight and flexible state management solution in Flutter.

It allows you to manage and share data across different parts of your application
using a provider pattern. It supports data binding by providing the ChangeNotifier
class, which can be extended to create observable models. Widgets can then listen
to changes in these models and update their UI accordingly.
●​ Riverpod. A state management library built on top of Provider, Riverpod offers a
more refined and simplified API for managing state and sharing data in Flutter
applications. It supports data binding by utilising the StateNotifier and
StateNotifierProvider classes. With Riverpod, you can easily expose data as streams
or providers that can be consumed by widgets for UI updates.
●​ MobX. MobX is a popular state management library in the Flutter ecosystem. It
leverages the concept of observable data and reactions to automatically update the
UI when data changes. MobX uses a reactive programming approach, where
changes in the data trigger the re-computation of dependent values and automatic UI
updates. It provides annotations and observables that facilitate data binding between
the ViewModel and the View.
Testability
MVC provides good testability, particularly with unit testing the Model and Controller
components. However, testing the View can be challenging due to its tight coupling with the
Controller.

MVVM enhances testability with better separation of concerns. The ViewModel can be
tested independently of the View and the Model, as it does not have direct dependencies on
them. Unit testing the ViewModel becomes more manageable, resulting in more
comprehensive and focused tests.

Flexibility and Extensibility

MVC offers flexibility, allowing for different View and Controller implementations. This
flexibility can be useful when adapting the application to changing requirements or
integrating with various UI frameworks.

MVVM provides enhanced flexibility through the use of data binding. The separation of the
View and ViewModel enables easier UI customization and reusability. Different Views can be
bound to the same ViewModel, or multiple ViewModels can be used with a single View.

Conclusion
MVC and MVVM are both effective architectural patterns that promote separation of
concerns. MVC provides a straightforward and widely adopted approach, while MVVM
introduces data binding and a clearer separation between the View and ViewModel.

The choice between MVC and MVVM depends on the specific requirements of the project,
the complexity of the UI, and the need for testability and flexibility. Understanding the
differences between these patterns helps developers make informed decisions and create
well-structured, maintainable applications. This blog will help you make the right decision.

MVC, MVVM, and MVP design patterns in

Swift

# MVC stands for Model-View-Controller

The MVC architecture is straightforward to understand and quite easy to implement in UIKit.
All architectures are created to make it easy, effective, flexible, and fast to develop our app
and prevent many mistakes that developers can make without architecture.

Let’s dive into the MVC architecture and gain a deeper understanding of how it works 🔥
# M — Model​
The “Model” is responsible for business logic, network calls, parse data, and so on. The
“Model” does not need to know about the UI if you in the “Model” use UI attributes it means
your architecture goes wrong.

# V — View​
The ‘View’ is responsible for representing UI elements such as UILabel, UIView, UITextView,
and so on. It should not have knowledge of the ‘Model.’ Including business logic and
network calls within the ‘View’ indicates a problem in your architecture.

# C — Controller​
The “Controller” acts as an intermediary between the “Model” and the “View”. It handles

🤷‍♂️
user input, communicates with the “Model” to fetch or update data, and updates the “View”
accordingly. You can see the above image

# The real example of MVC architecture in UIKit 🥶

You can check out my GitHub repository at the following link: 👉 TodoListApp. The
‘TodoListApp’ is built using the MVC architecture.

For the “Model” check out this page.​

For the “View” check out this page.​
For the “Controller” check out this page.
# MVVM stands for Model-View-ViewModel

The MVVM architecture is quite similar to the MVC design pattern. While it shares many
similarities with MVC, MVVM is widely used in SwiftUI, and it’s especially beneficial when
working with the Combine framework.

# M — Model​
The “Model” in MVVM is similar to the “Model” in MVC. It represents the data and business
logic of the application. It defines how data is structured and manipulated. In Swift, the
“Model” can be implemented using classes, structs, or enums.

# V — View​
The “View” in MVVM is also similar to the “View” in MVC. It represents the only UI elements
and the “View” should only display data, and handle user interactions, without containing
application logic(business logic).

# VM — View-Model​
The “ViewModel” acts as a mediator between the “Model” and the “View”. The “ViewModel”
is responsible for preparing and formatting data from the “Model” for presentation in the
“View”. “ViewModels” also handles user input and interactions. They contain the business
logic needed for specific views.

# The real example of MVVM architecture in UIKit 🥶

# Model

struct Task {

var title: String

 var completed: Bool

# ViewModel

class TaskListViewModel {

private var tasks: [Task] = [

Task(title: "Buy groceries", completed: false),

Task(title: "Read a book", completed: true),

Task(title: "Exercise", completed: false)

var taskCount: Int {

return tasks.count

func task(at index: Int) -> Task {

return tasks[index]

func addTask(title: String) {

let newTask = Task(title: title, completed: false)

tasks.append(newTask)

func toggleTask(at index: Int) {

tasks[index].completed.toggle()

}
}

# View

import UIKit

class TaskListViewController: UIViewController {

@IBOutlet private var tableView: UITableView!

@IBOutlet private var taskTextField: UITextField!

private var viewModel = TaskListViewModel()

override func viewDidLoad() {

super.viewDidLoad()

tableView.dataSource = self

@IBAction private func addButtonTapped() {

guard let taskTitle = taskTextField.text, !taskTitle.isEmpty else { return }

viewModel.addTask(title: taskTitle)

taskTextField.text = ""

tableView.reloadData()

extension TaskListViewController: UITableViewDataSource {

func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {

return viewModel.taskCount
 }

func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) ->

UITableViewCell {

let cell = tableView.dequeueReusableCell(withIdentifier: "TaskCell", for: indexPath)

let task = viewModel.task(at: indexPath.row)

cell.textLabel?.text = task.title

cell.accessoryType = task.completed ? .checkmark : .none

return cell

1.​ Task represents the “Model”, which defines the structure of a task.
2.​ TaskListViewModel is the “ViewModel”, responsible for managing tasks, adding
tasks, and updating their completion status.
3.​ TaskListViewController is the “View”, which displays the list of tasks in a table view
and allows the user to add new tasks. It communicates with the ViewModel to
perform these tasks.

# MVP stands for Model-View-Presenter

The MVP architecture is also similar to MVC architecture the same “Model” layer, “View”
layer, and additional “Presenter”. However, the MVP design pattern has one difference from
the MVC design pattern. Now the ViewController(Controller layer) is considered as a
view. which means it will include only the view-related code, nothing more and all logic will
be implemented in the presenter.

●​ View: The “View” includes both view and view controllers, taking care of setting up
the user interface and handling user interactions and all events.
●​ Presenter: The “Presenter” handles all the logic, such as responding to user actions
and updating the UI through the Protocols and Delegates. An important aspect is that
our presenter is UIKit-independent, making it well-isolated and easily testable.
●​ Model: The “Model” role will be exactly the same in MVC architecture.

# The real example of MVP architecture in UIKit 🥶

# Model

// Model: Represents a task

struct Task {

var title: String

var description: String

# View

// View: Displays task information

class TaskViewController: UIViewController {

@IBOutlet private var titleLabel: UILabel!

@IBOutlet private var descriptionLabel: UILabel!

private var presenter: TaskPresenterProtocol!

convenience init(presenter: TaskPresenterProtocol) {

self.init()

self.presenter = presenter

override func viewDidLoad() {

 super.viewDidLoad()

configureView()

private func configureView() {

let task = presenter.fetchTask()

titleLabel.text = task.title

descriptionLabel.text = task.description

@IBAction private func completeButtonTapped() {

presenter.taskCompleted()

# Presenter

// Presenter: Manages the interaction between Model and View

protocol TaskPresenterProtocol {

func fetchTask() -> Task

func taskCompleted()

class TaskPresenter: TaskPresenterProtocol {

private var task: Task

init(task: Task) {

self.task = task
 }

func fetchTask() -> Task {

return task

func taskCompleted() {

// Perform logic to mark the task as completed

●​ Task: The task represents the “Model”, which defines the structure of a task.
●​ TaskPresenter: The TaskPresenter is the “Presenter”, which manages the
interaction between the “Model” and the “View”. It provides methods to fetch task
data and mark tasks as completed.
●​ TaskViewController: The TaskViewController is the “View”, which displays the task
information and handles user interactions. It receives a TaskPresenterProtocol
instance and uses it to fetch and update task data.

Thank you for your attention while reading this article and I will be very happy if you
share your opinions about this article.

I hope to see you soon with your suggestions and problems please write to me on LinkedIn.

What’s new in UIKit — https://medium.com/@knoo/whats-new-in-uikit-bc8a98090cfc

I published(submitted) my first app to the App Store(MoveItem & GuessPicture) —🚀🔥

https://medium.com/@knoo/i-published-submitted-my-first-app-to-the-app-store-moveitem-g
uesspicture-2a744403a66f

iOS Interview Questions —

https://medium.com/@knoo/ios-interview-questions-2023-7fd56079f363

ViewController Life Cycle in iOS —

https://medium.com/@knoo/viewcontroller-life-cycle-in-ios-29f7da4acfc7

Application Life Cycle in iOS —

https://medium.com/@knoo/application-life-cycle-in-ios-dd9e1f5c9053
GCD — Grand Central Dispatch in iOS —
https://medium.com/@knoo/gcd-grand-central-dispatch-in-ios-b2dd665cabd5

ARC —
https://medium.com/@knoo/arc-automatic-reference-counting-in-swift-e7ac473229cc

SOLID — https://medium.com/@knoo/solid-principles-in-swift-2324df4a814c

Linkedin — https://www.linkedin.com/in/knyaz-harutyunyan-1a3672235/

GitHub — https://github.com/Kno777

MVC,MVVM architecture in swift

There are many design patterns are used in development.

In this article I am trying to show you some basics about MVC and MVVM architecture with
example.

First let me start with MVC design pattern.

1.​ Model (M)

M stands for Model and in design architecture Model is used to just represent
the data.

2. View (V)
 V stands for View. View is used to display the data (received from Model or
ViewModel). So basically XIB,Storyboard acts as a View.

3. Controller (C)

C stands for Controller. Controller is mediator between View and

Model/ViewModel, it receives structured data form the Model/ViewModel and
passes that data to View to display it on screen.

Now let’s see it by very simple example.

In this example,

1.​ We are getting some data from our web server

2.​ Then pass that data (received from web server) to our model class
3.​ Then display that data (User’s list) using tableview

UserViewController.swift — Controller_image1
UserViewController.swift — Controller_image2

We are receiving some data from web server ( see Controller_image2) in Controller class
and passes those data to our Model class ( see below Model_image3). And Model sends
structured data back to controller.

UserInfo.swift- Model_image3

Then In tableview’s delegate method “cellForRowAt” we are passing particular userInfo

object with its indexPath to display it to tableView’s cell. So here Controller is passing data
to View to display it on screen.
UserInfoTbaleViewCell.swift — View_image4

UserInfoTableViewCell.swift class acts as a View in our project (see View_image4).

So we can see that in Controller class, we are receiving data from server and then pass
that response to Model class and then Model class sends structured data to Controller
class back. Then Controller class sends that structured data to View class to display it. So
we can say that Controller acts as mediator between Model and View class.

Another thing you might be noticed in MVC, View class is not just
responsible to display data. it also performs some logic over the data and
then display it. See below highlighted code implemented in
UserInfoTbaleViewCell.swift — View_image4

var userInfo : UserInfo! { didSet { self.labelFname.text = userInfo.firstName ?? ""

self.labelLname.text = userInfo.lastName ?? "" self.contentView.backgroundColor =
(userInfo.isAdmin) ? UIColor.red : UIColor.green }}

you can see in above code, it first performs some logic (checking wether isAdmin property of
userInfo is true or false ) for contentView’s background color and then accordingly it sets the
background color.

So this is the main difference between MVC and MVVM, in MVVM “View
class” is responsible for just displaying the data, it never performs any
operation over data. To perform logic over data VM (View Model) class is
there.

Now let’s see same example with MVVM Design pattern.

MVVM
In MVVM architecture, Model and Controller class are as same as in MVC.

While in MVVM one new class ViewModel is there, and there is a little change in View
class.

Let’s see sequence of operations in MVVM

1.​ Controller class passes data (received from server) to Model class.
2.​ Model class returns structured data to Controller class.
3.​ Controller class passes structured data to ViewModel class.
4.​ ViewModel class performs logic over that data if needed and then sends back that
final data to Controller class.
5.​ Controller class passes final data to View class and finally View class displays that
data on the screen.

UserVIewModel.swift — ViewModel_image5
UserViewController.swift — Controller_image6

UserViewController.swift — Controller_image7
UserInfoTableViewCell.swift — View_image8

So this is the difference between MVC and MVVM. The example which I have used is so
simple, in real you can have complex project. But in this article I have tried to demonstrate
the difference between MVC and MVVM in a very simple way.

Each pattern has some pros and cons. So it is up to you which pattern you need to use as
per requirement.