DEV Community: Vijesh KR

React Native Rendering: Understanding What Happens Between React Code and the Screen

Vijesh KR — Sun, 27 Sep 2026 07:59:37 +0000

When I first started using React Native, I understood the code I was writing.

I knew what this meant:

<View>
  <Text>Hello</Text>
</View>

I knew that View was something like a container and Text displayed text.

But I had never really asked a deeper question:

What actually happens between my React code and the pixels I see on the screen?

The code looks simple.

The result looks simple.

But there is a lot happening in between.

React Native has to take the React components we write in JavaScript, understand their structure, calculate where everything should appear, figure out what actually changed, and finally update the real native views on Android or iOS.

This is where concepts like Reconciliation, Fabric, Shadow Tree, Yoga, Commit, and Mount start to make sense.

Instead of learning these as separate terms, I found it much easier to understand them as different parts of the same journey.

So let's follow that journey.

The Code We Write

Let's start with something very simple.

function Welcome() {
  return (
    <View>
      <Text>Hello</Text>
    </View>
  );
}

At the React level, this is just a component.

React sees something like:

Welcome
   ↓
<View>
   ↓
<Text>Hello</Text>

But Android and iOS don't understand React components.

Android doesn't have a native component called <View> in the React sense.

iOS doesn't know what <Text> means.

The operating system understands native UI objects.

So there is an important gap:

React Code
    ↓
    ?
    ↓
Native Views
    ↓
  Pixels

What happens in that ?

That is the rendering system.

/ and actual Android/iOS native views." width="800" height="533">

Why Does React Native Need a Rendering System?

If React already knows what the UI should look like, why can't React just directly create the native views?

Because there is more to rendering a UI than creating views.

Consider this:

<View style={{ flex: 1 }}>
  <Text>Hello</Text>
</View>

Before Android or iOS can display this correctly, React Native needs to know things like:

What is the parent-child structure?
What size should the View have?
Where should the Text be positioned?
How much space is available?
What happens if the screen size changes?
What changed if state updates?
Which native views actually need to be created?
Which existing views can simply be updated?

React Native therefore needs an intermediate representation and a rendering process.

This is one of the most important ideas to understand:

React describes what the UI should look like. React Native's renderer figures out how that description becomes native UI.

And in the New Architecture, that renderer is called Fabric.

But before getting to Fabric, there is another React concept we need to understand.

Reconciliation: What Actually Changed?

Imagine we have a counter.

function Counter() {
  const [count, setCount] = useState(0);

  return (
    <View>
      <Text>{count}</Text>

      <Button
        title="Increase"
        onPress={() => setCount(count + 1)}
      />
    </View>
  );
}

Initially:

After pressing the button:

React doesn't need to throw away the entire UI and build everything again.

It needs to understand what changed.

Conceptually:

Previous UI

<View>
  <Text>0</Text>
  <Button />
</View>


New UI

<View>
  <Text>1</Text>
  <Button />
</View>

The structure is mostly the same.

Only the text changed.

This process of React determining what the updated UI should look like is part of what we commonly call reconciliation.

The important idea is:

A React update does not mean every native view must be recreated.

The renderer can compare the previous and next representations and eventually apply only the necessary native changes.

This becomes especially important when an application becomes large.

Imagine a screen with:

Header
Profile
Statistics
Charts
Transactions
Buttons
Footer

If one transaction amount changes, we don't want to rebuild everything.

We want the renderer to understand the difference.

This is where Fabric becomes important.

Introducing Fabric

Fabric is React Native's new rendering system.

It is not a completely separate UI framework.

It is the rendering system that connects React's world with the native platform.

The architecture was redesigned around a shared C++ core, better interoperability with native platforms, and capabilities needed for modern React Native.

A simplified mental model looks like this:

React Components
       ↓
React Reconciliation
       ↓
   Fabric Renderer
       ↓
    Shadow Tree
       ↓
  Layout Calculation
       ↓
      Commit
       ↓
      Mount
       ↓
      Screen

But there is something important hiding inside this diagram.

Fabric doesn't immediately create native views when React renders.

Instead, it builds an intermediate representation.

This is the React Shadow Tree.

The Shadow Tree

When I first heard the term "Shadow Tree", I thought it was something complicated.

The basic idea is actually quite simple.

Suppose we write:

<View>
  <Text>Hello</Text>
</View>

Conceptually, React has a tree:

View
 └── Text

Fabric creates a corresponding tree of Shadow Nodes.

ViewShadowNode
      │
      └── TextShadowNode

A React Shadow Tree is created by Fabric and consists of React Shadow Nodes.

These nodes represent the React UI and contain information needed by the renderer, including props and layout information.

So instead of immediately saying:

"Create an Android View."

Fabric first builds a structured representation of what needs to exist.

This gives the renderer a place to reason about the UI before touching the actual native views.

Think of it like a plan.

React Code

<View>
  <Text>Hello</Text>
</View>

       ↓

Shadow Tree

ViewShadowNode
      │
      └── TextShadowNode

       ↓

Native Views

Android / iOS Views

This separation is extremely useful.

Because now React Native can calculate, compare, and prepare changes before applying them to the actual UI.

But Where Does Layout Come From?

We now know that the Shadow Tree represents the UI.

But it still doesn't answer an important question.

Where exactly should each component appear?

For example:

<View
  style={{
    flex: 1,
    justifyContent: 'center',
    alignItems: 'center',
  }}
>
  <Text>Hello</Text>
</View>

How does React Native decide:

View:
x = 0
y = 0
width = 390
height = 844

Text:
x = ...
y = ...
width = ...
height = ...

This is where Yoga comes in.

Yoga and Layout Calculation

React Native uses Yoga as its layout engine for calculating layout information.

You can think of Yoga as the part responsible for answering:

"Given these styles and these available constraints, where should everything go?"

For example:

<View
  style={{
    flex: 1,
    justifyContent: 'center',
    alignItems: 'center',
  }}
>
  <Text>Hello</Text>
</View>

Yoga helps calculate the position and size of the elements.

Conceptually:

Available screen
      ↓
Parent constraints
      ↓
    Styles
      ↓
     Yoga
      ↓
x / y / width / height

The result becomes layout information associated with the Shadow Tree.

It might conceptually look like:

View
x: 0
y: 0
width: 390
height: 844

   └── Text
       x: 160
       y: 400
       width: 70
       height: 25

The exact values obviously depend on the device and content.

The important part is the responsibility.

Yoga calculates layout. Fabric uses that layout information as part of turning the Shadow Tree into native UI.

Render, Commit, Mount

At this point, we have enough context to understand the three words that appear again and again in React Native's rendering architecture:

Render.

Commit.

Mount.

These are not three unrelated concepts.

They are three phases of the rendering pipeline.

React Native's rendering pipeline can be understood as:

Render → Commit → Mount

Let's understand each one.

1. Render

Suppose we write:

<View>
  <Text>Hello</Text>
</View>

React executes our application logic and produces the React Element Tree in JavaScript.

Conceptually:

React Component
      ↓
React Element Tree

Fabric then creates the corresponding React Shadow Tree.

React Element Tree
      ↓
React Shadow Tree

So the Render phase is essentially about constructing the next representation of the UI.

A simplified mental model is:

JavaScript / React
        ↓
  React Elements
        ↓
   Shadow Nodes
        ↓
    Shadow Tree

The Shadow Tree is immutable.

That means React Native does not simply mutate the existing tree whenever something changes.

Instead, it creates a new version of the tree, while using structural sharing so unchanged portions don't need to be duplicated unnecessarily.

That sounds complicated, but the reason is important.

It makes the rendering system easier to reason about and allows different versions of UI state to be handled safely.

2. Commit

Once the new Shadow Tree has been created, React Native needs to prepare it for mounting.

This is the Commit phase.

Two important things happen here:

Layout calculation
Preparing the next tree for mounting

Yoga calculates the layout of the Shadow Tree using the available constraints and styles.

Then the newly prepared tree becomes the next tree that can be mounted.

Conceptually:

Shadow Tree
     ↓
    Yoga
     ↓
Layout information
     ↓
  Next Tree

So after Commit, React Native has something much closer to:

"This is the UI tree we want to display, and this is where everything should be."

But we still haven't actually updated the native views.

That happens next.

3. Mount

Now we finally reach the native UI.

The Mount phase takes the Shadow Tree, including its calculated layout, and turns it into the native Host View Tree.

This is where actual native views are created, updated, removed, or rearranged.

For example:

Shadow Node
     ↓
Native View

For Android, this can result in native Android views.

For iOS, corresponding UIKit views are used.

The renderer also compares the previously rendered tree with the next tree and produces the required mutations.

Conceptually:

Previous Tree
      +
  Next Tree
      ↓
   Tree Diff
      ↓
create / update / remove
      ↓
  Native Views

Finally:

Native Views
      ↓
    Screen

Following One Example From Start to Finish

Let's put everything together.

Suppose we have:

function Greeting() {
  return (
    <View>
      <Text>Hello</Text>
    </View>
  );
}

What happens?

Step 1 — React

React executes the component.

Greeting
   ↓
<View>
   ↓
<Text>Hello</Text>

React creates the React Element Tree.

Step 2 — Fabric

Fabric creates the corresponding Shadow Tree.

ViewShadowNode
      │
      └── TextShadowNode

Step 3 — Layout

Yoga calculates the layout.

View
 ├── x
 ├── y
 ├── width
 └── height

Text
 ├── x
 ├── y
 ├── width
 └── height

Step 4 — Commit

The newly prepared tree becomes the next tree to be mounted.

Step 5 — Mount

The renderer determines the required native operations.

Conceptually:

Create View
Create Text
Set Text = "Hello"
Add Text to View

Step 6 — Screen

The native platform displays the result.

Hello

That's the entire journey.

React Component
      ↓
React Element Tree
      ↓
Reconciliation
      ↓
Shadow Tree
      ↓
Yoga Layout
      ↓
Commit
      ↓
Mount
      ↓
Native Views
      ↓
    Screen

Hello example from React component → Element Tree → Shadow Tree → Yoga → Commit → Mount → Native View → Screen." width="800" height="533">

What Happens When State Changes?

The initial render is only half the story.

The more interesting case is an update.

Consider:

function Counter() {
  const [count, setCount] = useState(0);

  return (
    <View>
      <Text>{count}</Text>

      <Button
        title="Increase"
        onPress={() => setCount(count + 1)}
      />
    </View>
  );
}

Initially:

The user taps the button.

Now:

What happens?

First: React Updates

The state changes.

count: 0
      ↓
count: 1

React produces a new version of the React Element Tree.

Conceptually:

Previous

<View>
  <Text>0</Text>
  <Button />
</View>


Next

<View>
  <Text>1</Text>
  <Button />
</View>

The important thing is that React doesn't need to recreate everything conceptually from scratch.

The unchanged parts can be shared between the old and new trees.

Then: Shadow Tree Update

Fabric creates the updated Shadow Tree.

Conceptually:

Old Shadow Tree

View
 ├── Text("0")
 └── Button


New Shadow Tree

View
 ├── Text("1")
 └── Button

Notice something.

The View didn't disappear.

The Button didn't disappear.

The important change is the text.

Then: Commit

Yoga/layout work happens as needed.

The new tree becomes the next tree.

Finally: Mount

The renderer compares the previous rendered tree and the new tree.

Conceptually:

Previous
   ↓
Text = "0"

Next
   ↓
Text = "1"

Diff
   ↓
Update Text

So the native UI can perform a small update rather than rebuilding the entire screen.

This is one of the most important ideas to remember:

React re-rendering does not mean the entire native UI is recreated.

The renderer determines what native mutations are actually necessary.

Where Can Performance Problems Appear?

Understanding the rendering pipeline changes how I think about React Native performance.

Before learning this, it is easy to think:

"React Native performance means making JavaScript faster."

But that is only one part of the story.

There are multiple places where work can become expensive.

1. Too Much JavaScript Work

If your component logic is expensive, React may take longer to produce the next UI representation.

For example:

Large computation
     ↓
Slow render
     ↓
Delayed UI update

This is why things like unnecessary calculations, unnecessary component updates, and poorly structured state can matter.

2. Too Much UI

Imagine rendering hundreds or thousands of complex components.

Even if your JavaScript is reasonable, the renderer still has more UI to reason about.

Large lists are a classic example.

This is why list virtualization and careful component design matter.

3. Complex Layout

A complicated UI can require significant layout calculation.

For example:

Nested containers
      ↓
Many layout constraints
      ↓
   More work

Yoga is efficient, but it still has work to do.

4. Too Many Native Mutations

Eventually, changes have to reach native views.

If an update causes a large number of native operations:

createView
updateView
removeView
insertView
...

that work can become expensive.

So performance isn't just about:

"How fast is my JavaScript?"

It is also about:

"How much work is required across the entire rendering pipeline?"

The Old Architecture vs The New Architecture

This is where many React Native discussions become confusing.

People often say:

"Old Architecture was Bridge and New Architecture is Fabric."

That's useful as a starting point, but it isn't the complete picture.

The New Architecture changed several major pieces of React Native's internals.

In the old architecture, React Native relied heavily on an asynchronous Bridge to serialize and enqueue communication between JavaScript and native code.

The New Architecture removes that dependency and introduces a new renderer, new native module/component systems, and better support for modern React capabilities.

A simplified comparison looks like this:

Area	Legacy Architecture	New Architecture
Renderer	Legacy renderer	Fabric
JS ↔ Native communication	Asynchronous Bridge	JSI-based interoperability
Rendering model	Legacy rendering model	Modern renderer
Native modules	Legacy Native Modules	New Native Module system
Native components	Legacy system	New Native Component system
React capabilities	More limited by architecture	Better support for modern React features
Core rendering logic	More platform-specific	More shared C++ logic

Starting with React Native 0.76, the New Architecture became enabled by default and was declared ready for production use.

But there is an important detail.

The New Architecture is not a magic switch that automatically makes every application fast.

Your application can still have:

Bad state management
      ↓
Unnecessary renders
      ↓
Heavy computations
      ↓
Huge lists
      ↓
Expensive UI

Changing the architecture does not remove application-level bottlenecks.

The architecture gives React Native better foundations and capabilities.

We still have to build our applications carefully.

What About Threads?

This is another area where React Native rendering can become confusing.

You may hear things like:

JavaScript Thread
UI Thread
Background Thread

And then try to memorize:

"Render always happens here, Commit always happens there, Mount always happens there."

That is not a good mental model.

The actual implementation and scheduling can vary.

React Native's rendering architecture involves JavaScript and C++ work, layout/commit work, and native UI work, with scheduling depending on the situation and platform.

So instead of memorizing:

Render = Thread X
Commit = Thread Y
Mount = Thread Z

I prefer to remember the responsibility:

Render
→ What should the UI tree look like?

Commit
→ Prepare the next tree and calculate its layout.

Mount
→ Apply the necessary changes to native UI.

That mental model survives implementation details much better.

Why Does the Shadow Tree Matter?

At this point, we can understand why the Shadow Tree exists.

Without an intermediate representation, the renderer would have to reason directly about platform-specific native views.

Instead, Fabric can work with a platform-independent representation:

React
  ↓
Shadow Tree
  ↓
Layout
  ↓
Diff
  ↓
Native Views

This creates an important separation.

React doesn't need to know whether the final platform is:

Android

or:

iOS

The renderer and host platform implementation handle that part.

This is also one reason Fabric's shared C++ core is important.

More rendering logic can be shared across platforms instead of being duplicated in completely separate implementations.

Why Does Mounting Use a Diff?

Imagine an application with this UI:

Screen
 ├── Header
 ├── Profile
 ├── Transactions
 │    ├── Transaction 1
 │    ├── Transaction 2
 │    └── Transaction 3
 └── Footer

Now imagine one transaction changes.

We don't want to blindly do:

Delete everything
Create everything again

Instead:

Previous Tree
      +
  Next Tree
      ↓
   Compare
      ↓
  Find changes
      ↓
Apply mutations

Maybe the result is simply:

Update Transaction 2

The Mount phase turns the difference between trees into the required native mutations.

This is one of the places where the architecture connects directly to something we care about as developers:

efficient UI updates.

The Complete Mental Model

Let's zoom out.

We started with:

<View>
  <Text>Hello</Text>
</View>

But now we can see the bigger picture.

React Code
     │
     ▼
React Element Tree
     │
     ▼
Reconciliation
     │
     ▼
Fabric Renderer
     │
     ▼
Shadow Tree
     │
     ▼
Yoga Layout
     │
     ▼
   Commit
     │
     ▼
Previous Tree + Next Tree
     │
     ▼
    Diff
     │
     ▼
   Mount
     │
     ▼
Native Views
     │
     ▼
   Screen

And the three phases can be remembered very simply:

RENDER

"What should the UI look like?"

COMMIT

"Prepare the next tree and calculate its layout."

MOUNT

"Apply the necessary changes to native UI."

The Bigger Picture

When I first started working with React Native, I mostly thought about components.

<View />
<Text />
<FlatList />
<Pressable />

Then I learned about state.

Then performance.

Then architecture.

But understanding the rendering pipeline added another layer to the picture.

A React Native application is not simply:

JavaScript → Screen

There is a rendering system between those two worlds.

JavaScript
    ↓
  React
    ↓
  Fabric
    ↓
Shadow Tree
    ↓
  Layout
    ↓
  Commit
    ↓
  Mount
    ↓
Native UI

And suddenly terms that initially sounded unrelated start to connect.

Reconciliation helps determine the new React result.

Fabric is the rendering system.

Shadow Tree represents the UI before it becomes native views.

Yoga calculates layout.

Commit prepares the next tree.

Mount applies the necessary changes to the native UI.

These aren't separate topics.

They are different parts of one process.

One Simple Way to Remember It

If I had to explain the entire rendering system in an interview without going too deep into implementation details, I would say:

"React Native takes the React component tree produced by JavaScript and uses its renderer, Fabric, to build a Shadow Tree. During the render phase, React and the renderer create the next UI representation. During commit, layout is calculated using Yoga and the new tree is prepared. During mount, React Native diffs the trees and applies the required mutations to the native views."

That explanation is much more useful than memorizing a list of terms.

Because now every term has a responsibility.

React
→ describes the UI

Reconciliation
→ determines the new React result

Fabric
→ rendering system

Shadow Tree
→ intermediate representation

Yoga
→ layout calculation

Commit
→ prepare the next tree

Mount
→ update native UI

Final Thoughts

The interesting part of React Native is that the code we write is often much simpler than the system executing it.

When we write:

<View>
  <Text>Hello</Text>
</View>

we don't normally need to think about:

React Element Tree
Shadow Nodes
Shadow Tree
Yoga
Commit
Tree Diffing
Mount
Native Views

And that's exactly what a good abstraction should do.

We can build applications without understanding every internal detail.

But when we start working on performance, debugging difficult rendering problems, building native components, or simply trying to understand why React Native works the way it does, these concepts become extremely useful.

For me, the biggest takeaway is not memorizing the names.

It is understanding the journey:

React describes the UI. Fabric builds a representation of that UI. Yoga calculates its layout. Commit prepares the next tree. Mount turns the result into native UI.

Once that mental model is clear, React Native rendering stops feeling like a collection of mysterious internal terms.

It becomes one connected system.

And that is the part worth remembering.

MVVM and Clean Architecture: Understanding Where Our Code Actually Belongs

Vijesh KR — Tue, 22 Sep 2026 13:05:44 +0000

When I first started learning software architecture, I thought it was mostly about remembering names:

MVC.
MVP.
MVVM.
Clean Architecture.
Repository.
Use Case.
Domain.
Data.

But after working with real applications, I realized that architecture is not really about memorizing these names.

The more important question is:

When an application grows, where should each piece of logic actually live?

That question is what helped me understand MVVM and Clean Architecture more clearly.

This article is my attempt to explain both concepts in a practical way, without treating them as complicated rules or a collection of folders.

When a Simple Application Starts Becoming Complicated

Imagine we start with a simple expense-tracking application.

At first, the application might only need:

A screen to enter an expense
A button to save it
A list showing expenses

Everything feels simple.

But then the application grows.

Now we need:

Input validation
Different expense categories
API communication
Local database storage
Loading and error states
Authentication
Business rules
Offline support
Data synchronization
Reporting
Notifications
Analytics

Suddenly, the screen that originally handled a few things is now responsible for many completely different concerns.

The UI knows about the API.

The API logic knows about the UI.

Business rules are mixed with button-click logic.

Database code appears inside presentation code.

Changing one thing starts affecting several unrelated parts of the application.

This is where architecture becomes important.

Architecture Is About Responsibility

One of the biggest things I learned is that architecture is not primarily about creating folders.

You can create folders called:

components
services
models
repositories
utils
screens

and still have a badly structured application.

Architecture is really about responsibilities and boundaries.

Every part of the application should have a clear answer to questions like:

What is this part responsible for?
What should it know about?
What should it not know about?
Who should it communicate with?
What happens if the API changes?
What happens if the database changes?
Can this business logic be tested without the UI?

Once I started looking at architecture this way, MVVM became much easier to understand.

MVVM: Separating What We See From What We Do

MVVM stands for:

Model - View - ViewModel

The basic idea is simple.

Instead of putting everything inside the UI, we separate the presentation responsibilities.

Think about a screen that displays a list of expenses.

The screen needs to:

Display the expenses
Show loading information
Display errors
React to user actions

But does the screen itself need to know how the data is fetched?

Not necessarily.

That is where the ViewModel becomes useful.

View

The View is what the user interacts with.

Its responsibility is mainly presentation.

For example:

Screens
UI components
Buttons
Forms
Lists
Loading indicators
Error messages

The View should focus on:

What should the user see?

It should not become the place where every application decision is made.

ViewModel

The ViewModel sits between the View and the rest of the application.

It manages things such as:

UI state
User actions
Presentation logic
Loading state
Error state
Preparing data for the View

For example, when a user taps Save Expense, the View does not need to understand everything involved in saving that expense.

The View can simply communicate the action.

The ViewModel can then coordinate what needs to happen.

This gives us a useful separation:

View = What the user sees

ViewModel = What the UI needs to know and what should happen from a UI action

Model

The Model represents the data and concepts used by the application.

Depending on how the application is designed, this can include things such as:

Data objects
Entities
Data structures
Related data concepts

The exact meaning of "Model" can vary between different implementations of MVVM.

That is important because MVVM itself does not define every detail of the entire application's architecture.

And this leads to an important point.

MVVM Is Not the Entire Architecture

MVVM is mainly a presentation pattern.

It helps us organize how the UI communicates with presentation logic.

But what happens after the ViewModel needs to perform an actual business operation?

For example:

"Create this expense."

Should the ViewModel directly call the database?

Should it directly call an API?

Should it contain all the business rules?

As applications become larger, putting everything inside the ViewModel can simply create another problem:

A giant ViewModel.

This is where a broader architectural approach becomes useful.

That is where Clean Architecture comes in.

Clean Architecture: Separating the Core From External Details

Clean Architecture is broader than MVVM.

The main idea is to keep the important business logic of an application independent from external technologies and implementation details.

External details can include things like:

UI frameworks
APIs
Databases
Network libraries
Storage systems
Third-party services

The business logic should not become tightly coupled to these things.

A common way to understand Clean Architecture is through three major areas:

Presentation
Domain
Data

These are not simply folders.

They represent different responsibilities and boundaries.

Presentation Layer

The Presentation layer is responsible for interacting with the user.

This is where things such as:

Views
ViewModels
UI state
User interactions

usually live.

This is also where MVVM can fit naturally.

So instead of thinking:

MVVM vs Clean Architecture

it is more useful to think:

MVVM can organize the Presentation layer inside a Clean Architecture application.

Domain Layer

The Domain layer is the heart of the application.

This is where we keep the important business concepts and rules.

The Domain layer should not need to know whether the application is using:

REST API
GraphQL
PostgreSQL
MongoDB
SQLite
A particular UI framework
A particular network library

The business rules should remain independent.

Entities

Entities represent important concepts in the application's business domain.

For an expense application, an entity might represent an:

Expense

For a shopping application:

Order

For a banking application:

Account

These concepts exist regardless of which UI framework or database the application uses.

Use Cases

A Use Case represents something the application does.

For example:

Add Expense
Delete Expense
Create Order
Cancel Order
Generate Report
Update Profile

Instead of thinking about Use Cases as another complicated architectural term, I find it easier to think:

A Use Case represents an application action or business operation.

This gives the application a clear place for business logic.

Repository Interfaces

The Domain layer may need data, but it should not need to know exactly where that data comes from.

For example, an Add Expense use case may need to save an expense.

The Domain layer can depend on an abstraction such as a repository interface.

It does not need to know whether the repository eventually saves the data to:

A remote API
A local database
Local storage
A cache
Some other data source

That implementation detail belongs outside the Domain layer.

Data Layer

The Data layer deals with external data sources.

This can include:

APIs
Databases
Local storage
Files
Caches
Repository implementations
Data source implementations

For example, the Domain layer might say:

"I need to save an expense."

The Data layer handles how that actually happens.

This separation becomes powerful when external technologies change.

Suppose an application initially uses one database and later moves to another.

If the business logic is tightly coupled to the original database, the change can become painful.

But if the business logic communicates through abstractions, the implementation can change without forcing the business rules to understand the new technology.

The Most Important Idea: Dependency Direction

This is one of the most important ideas behind Clean Architecture.

It is not enough to separate the application into Presentation, Domain, and Data.

We also need to think about which layer depends on which.

The important principle is:

The core business logic should not depend directly on external implementation details.

Think about a restaurant.

The customer should not need to know:

Which supplier delivered the vegetables
Which brand of cooking oil was used
Which kitchen equipment was used
Where the restaurant purchased its ingredients

The customer cares about the result.

The restaurant's internal processes can change without changing what the customer expects.

In a similar way, our business logic should not become tightly connected to external details.

The database can change.

The API can change.

The UI technology can change.

The core business rules should remain relatively stable.

MVVM and Clean Architecture Together

This is where the two concepts finally connect.

They are not competing architectures.

They solve problems at different levels.

MVVM helps organize the presentation side.

Clean Architecture helps structure the broader application and control dependencies between different parts.

A simplified structure can look like this:

Presentation
│
├── View
│
└── ViewModel
        │
        ▼
     Domain
        │
        ├── Entities
        ├── Use Cases
        └── Repository Interfaces
                    │
                    ▼
                  Data
                    │
                    ├── Repository Implementations
                    └── Data Sources
                           │
                           ├── API
                           ├── Database
                           └── Local Storage

The important thing is not memorizing this diagram.

The important thing is understanding why the separation exists.

Following One Action Through the Application

Let's follow a simple example.

A user wants to add an expense.

1. User interacts with the View

The user enters an amount and taps Save.

The View captures the interaction.

2. View communicates with the ViewModel

The ViewModel receives the action.

It can update UI state, handle presentation concerns, and coordinate the next step.

3. ViewModel calls a Use Case

Instead of putting the actual business operation inside the ViewModel, it delegates the operation to the appropriate Use Case.

For example:

Add Expense Use Case

4. Use Case applies business rules

The Use Case determines what needs to happen according to the application's rules.

It may validate the information or coordinate the required operation.

5. Use Case communicates through a Repository abstraction

The Use Case does not need to know whether the data comes from an API, database, or local storage.

It communicates through the repository abstraction.

6. Repository implementation handles the data

The Data layer provides the actual repository implementation.

That implementation knows how to communicate with the required data source.

7. Data Source performs the actual operation

The data may finally reach:

An API
A database
Local storage
Another external system

The result then travels back through the layers.

So conceptually:

User
  ↓
View
  ↓
ViewModel
  ↓
Use Case
  ↓
Repository Interface
  ↓
Repository Implementation
  ↓
Data Source

And the result comes back in the opposite direction toward the UI.

This gives every part of the application a clear responsibility.

Why This Separation Is Useful

The biggest benefit is not simply that the project has more folders.

The real benefit is that changes become easier to manage.

Imagine the API changes.

The View should not need to change just because the API response changed.

Imagine the database changes.

The business rules should not suddenly need to understand the new database.

Imagine the UI changes.

The core business logic should not need to change just because the design changed.

Imagine we want to test a business rule.

We should be able to test that rule without launching the entire application.

This is where good boundaries become valuable.

Testing Becomes Easier

Separation also makes testing more focused.

Instead of testing the entire application every time, different responsibilities can be tested independently.

For example:

View

Can the UI display the correct state?

ViewModel

Does the correct UI state appear after an action?

Use Case

Does the business rule behave correctly?

Repository

Does the data operation work as expected?

Data Source

Does the API or database communication work correctly?

The more independent these responsibilities are, the easier it becomes to identify where a problem actually exists.

What Happens When Technology Changes?

One of the reasons I find Clean Architecture useful is that software technology constantly changes.

Today we may use one API library.

Tomorrow we may replace it.

Today we may use one database.

Later we may migrate to another.

The UI framework may change.

A third-party library may be removed.

These changes are much easier to handle when our business logic is not directly dependent on every external technology.

The goal is not to prevent change.

The goal is to contain the impact of change.

Benefits of Combining MVVM and Clean Architecture

When used appropriately, this combination can provide several benefits.

Clear separation of responsibilities

Each part of the application has a specific job.

Better maintainability

Changes can remain localized instead of spreading throughout the application.

Better testability

Business logic can be tested independently from UI and external systems.

Reduced coupling

The core logic does not need to know the implementation details of external technologies.

Easier scaling

As an application grows, clearly defined boundaries make the codebase easier to understand and extend.

Easier replacement of technologies

APIs, databases, libraries, and other external tools can potentially be replaced with less impact on the core business logic.

But There Is a Trade-Off

Architecture is not free.

A well-structured architecture usually means:

More files
More abstractions
More interfaces
More layers
More concepts to understand
More initial setup

For a very small application, creating a Use Case, Repository Interface, Repository Implementation, Data Source, ViewModel, and several other abstractions for a single screen may be unnecessary.

That can become overengineering.

The goal of architecture is not to create the maximum number of layers.

The goal is to create useful boundaries for the complexity that actually exists.

A small application may need a simple structure.

A large application with complicated business rules and multiple data sources may benefit from stronger architectural boundaries.

Architecture Is Not About Following a Folder Structure

This is another lesson I find important.

Someone can create a project like this:

presentation/
domain/
data/

and still have poor architecture.

Why?

Because the folder names themselves do not create separation.

If the View directly accesses the database, the boundaries are already being broken.

If the Domain layer directly imports a specific API library, it becomes coupled to that external technology.

If all the business logic still lives inside one giant ViewModel, simply calling the project "MVVM" does not solve the problem.

Architecture is about:

Responsibilities.

Boundaries.

Dependencies.

Communication between those boundaries.

The folder structure is only one way of representing those decisions.

MVVM vs Clean Architecture

It becomes much easier to understand the difference when we look at their purpose.

MVVM	Clean Architecture
Presentation pattern	Broader architectural approach
Focuses mainly on UI and presentation logic	Focuses on the structure of the whole application
Separates View and ViewModel responsibilities	Separates application concerns and controls dependencies
Helps organize presentation code	Helps protect core business logic
Can be used inside Clean Architecture	Can use MVVM in its Presentation layer

So instead of asking:

Which one should I use?

A better question is:

How can they work together to solve different architectural problems?

A Simple Mental Model

When looking at a piece of code, I try to ask four simple questions.

What does the user see?

View

What does the UI need to know or respond to?

ViewModel

What does the application actually do?

Use Case / Domain

Where does the data come from?

Repository / Data

This mental model is much easier to remember than trying to memorize a long list of architectural definitions.

The Bigger Picture

When I started learning architecture, the different terms felt disconnected.

MVVM felt like one topic.

Clean Architecture felt like another.

Repository felt like another.

Use Cases felt like another.

But once I started looking at them through responsibilities and dependencies, they started fitting together.

MVVM helps answer:

How should presentation logic be organized?

Clean Architecture helps answer:

How should the application be structured so that core logic stays independent from external details?

Repository helps answer:

How can the application communicate with data without tightly coupling business logic to the data source?

Use Cases help answer:

Where should an application action or business operation live?

Together, these ideas create a much clearer mental model of where code should belong.

Final Thoughts

Good architecture is not about making software complicated.

It is about making responsibilities clear.

When an application grows, complexity is inevitable.

The goal of architecture is not to eliminate complexity completely.

The goal is to organize that complexity so that it remains understandable and changeable.

MVVM helps separate what the user sees from the logic that supports the UI.

Clean Architecture helps separate the core business logic from external implementation details.

When these ideas are used together thoughtfully, the result is not simply a project with more folders.

It is a system where:

UI has a responsibility.

Presentation logic has a responsibility.

Business logic has a responsibility.

Data access has a responsibility.

And most importantly, the boundaries between them are intentional.

That, for me, is the real purpose of software architecture:

Not just deciding where code goes, but understanding why it belongs there.

Building a Lightweight Biometric Authentication Library for React Native with Kotlin

Vijesh KR — Sat, 19 Sep 2026 14:30:22 +0000

Hello developers!

Today, I want to share a quick story about a common challenge I faced while working with React Native: securing app access with biometric authentication, and why I decided to build and open-source my own library:

@vijeshkr/react-native-biometric-auth

The Spark: Why Another Biometric Library?

While working on a mobile application that required secure user authentication, such as unlocking the app when it launches, I came across a few challenges with existing solutions.

1. Clunky Fallback Support

Handling fallback authentication can sometimes require additional configuration.

I wanted a solution where users could authenticate using biometrics while also having the option to fall back to their device credentials, such as:

Fingerprint
Device PIN
Pattern
Password

2. Legacy Native Dependencies

I also wanted to avoid relying on older Java-based implementations and instead use modern Android APIs with Kotlin and AndroidX Biometric.

3. Keeping Things Lightweight

For this particular use case, I wanted something simple:

A lightweight native module
A clean JavaScript/TypeScript API
Modern Android biometric APIs
Promise-based authentication
Minimal configuration

So, instead of working around those limitations, I decided to build my own native module.

Introducing `@vijeshkr/react-native-biometric-auth`

@vijeshkr/react-native-biometric-auth is an Android biometric authentication library for React Native, built with Kotlin and AndroidX Biometric.

It provides biometric authentication with optional device credential fallback.

Key Features

Kotlin Native Module — Built entirely with Kotlin.
AndroidX Biometric — Uses Android's modern BiometricPrompt APIs.
Device Credential Fallback — Supports PIN, Pattern, or Password fallback.
Promise-Based API — Works naturally with async/await.
TypeScript Support — Includes TypeScript definitions for a better developer experience.
Simple React Native Integration — Minimal setup and a straightforward API.

Getting Started

1. Installation

Install the package using npm:

npm install @vijeshkr/react-native-biometric-auth

Or using Yarn:

yarn add @vijeshkr/react-native-biometric-auth

2. Check Availability and Authenticate

Once installed, you can check whether authentication is available and then trigger the native Android authentication prompt.

import React from 'react';
import { Button, Alert, SafeAreaView } from 'react-native';
import { BiometricAuth } from '@vijeshkr/react-native-biometric-auth';

export default function App() {
  const handleAuthentication = async () => {
    try {
      // 1. Check if biometrics or device credentials are available
      const isAvailable = await BiometricAuth.isBiometricAvailable();

      if (!isAvailable) {
        Alert.alert(
          'Unavailable',
          'Biometrics or device credentials are not set up on this device.'
        );
        return;
      }

      // 2. Trigger native BiometricPrompt
      const success = await BiometricAuth.authenticate({
        title: 'Unlock Application',
        subtitle: 'Touch fingerprint sensor or enter device PIN',
        cancelText: 'Cancel',
        allowDeviceCredential: true,
      });

      if (success) {
        Alert.alert('Success', 'Welcome back!');
      }
    } catch (error) {
      console.error('Authentication Error:', error);

      Alert.alert(
        'Error',
        'Authentication failed or was cancelled.'
      );
    }
  };

  return (
    <SafeAreaView
      style={{
        flex: 1,
        justifyContent: 'center',
        alignItems: 'center',
      }}
    >
      <Button
        title="Unlock App with Biometrics"
        onPress={handleAuthentication}
      />
    </SafeAreaView>
  );
}

The API is intentionally simple: check availability, call authenticate(), and handle the returned promise.

How Does It Work Under the Hood?

The native Android implementation is written entirely in Kotlin.

The module uses Android's:

BiometricPrompt
BiometricManager
androidx.biometric

When allowDeviceCredential: true is enabled, the authentication flow allows the device credential to be used as a fallback.

Conceptually, the authentication configuration uses:

BIOMETRIC_STRONG or DEVICE_CREDENTIAL

This allows the user to authenticate using a supported strong biometric or their configured device credential, depending on the device and authentication setup.

For example, if biometric authentication isn't available or the user chooses the available fallback, the device can use credentials such as a PIN, Pattern, or Password.

This is one of the main reasons I wanted to build the module around the modern Android biometric APIs rather than implementing the authentication flow manually.

Why Kotlin?

One of my goals with this project was to get more comfortable with the native side of React Native.

React Native doesn't mean you only work with JavaScript or TypeScript.

Sometimes you need to go one layer deeper and interact directly with:

React Native → Native Module → Android APIs

For this project, Kotlin was a good fit because the Android side could remain small and focused while still taking advantage of modern Android APIs.

Building this module also helped me better understand how React Native communicates with native Android code through a custom native module.

Open Source

The project is open source, and I'd love for other React Native developers to try it out and share their feedback.

NPM Package: @vijeshkr/react-native-biometric-auth

GitHub Repository: vijeshkr/react-native-biometric-auth

If you find the project useful, consider giving it a star on GitHub.

What's Next?

This is currently focused on Android biometric authentication.

There are several things I would like to explore as the project evolves, including improvements to the authentication flow, documentation, testing, and potentially broader platform support.

I also want to continue improving my understanding of React Native's native module architecture through projects like this.

Let's Discuss

I'd love to hear from other React Native developers.

Have you faced any challenges while implementing biometric or native authentication in React Native?

Or:

What feature would you like to see added to this library next?

Feel free to share your experience or suggestions in the comments.

Happy coding!