DEV Community: Subrata Kumar Das

Add Web Search Tool to AI Agent | Tool Calling Explained | Microsoft Foundry AI Agent Tutorial #6

Subrata Kumar Das — Wed, 24 Jun 2026 16:20:56 +0000

Deploy Your First AI Model in Microsoft Foundry | System Prompts Explained | AI Agent Course #5

Subrata Kumar Das — Wed, 24 Jun 2026 16:18:12 +0000

Microsoft Foundry Setup Tutorial | Create Your First AI Agent Project (Azure AI Foundry Course) #4

Subrata Kumar Das — Wed, 24 Jun 2026 16:16:35 +0000

What is an AI Agent? AI Agent vs Chatbot Explained | Microsoft Foundry Course #3

Subrata Kumar Das — Wed, 24 Jun 2026 16:14:54 +0000

What is Generative AI? Understanding the Foundation of Modern AI Agents #2

Subrata Kumar Das — Fri, 19 Jun 2026 06:20:04 +0000

Everyone is talking about AI Agents.

But before you build an AI Agent, there is one concept you absolutely need to understand:

Generative AI.

Generative AI is the technology that transformed software from systems that simply follow rules into systems that can understand language, generate responses, reason through instructions, and assist users in a natural way.

As part of my new course:

Develop Your First AI Agent with Microsoft Foundry

I published the first lesson where we explore the journey from traditional software to Generative AI and understand why modern AI Agents became possible.

🎥 Watch the video here:

Why This Topic Matters

Many developers jump directly into AI Agents, prompts, tools, and frameworks.

However, without understanding the evolution of AI, it becomes difficult to understand:

Why AI Agents exist
Why Large Language Models are important
Why prompts work
Why tools are needed
How modern AI systems actually operate

In this lesson, we start from first principles and build the foundation required for the rest of the course.

What You'll Learn

Traditional Software

For decades, software followed a simple pattern:

Input → Rules → Output

Developers explicitly defined every behavior.

This worked well until humans started interacting with software using natural language.

Why Rule-Based Systems Break

Imagine building a dietician chatbot.

Users might ask:

What should I eat?
Suggest a healthy breakfast.
What foods contain protein?
Can I eat oats daily?

All of these questions are similar.

Yet they are phrased differently.

Supporting thousands of variations quickly becomes impossible with manually written rules.

Predictive AI

Machine Learning introduced a new approach.

Instead of writing rules, we train models using data.

Examples include:

Spam Detection
Fraud Detection
Recommendation Systems

Predictive AI can make decisions.

But it still cannot create content.

Prediction vs Creation

A predictive model can answer:

Fraud probability: 87%

But can it explain why?

Can it write a detailed report?

Can it create a personalized recommendation?

Not naturally.

This limitation led to the rise of Generative AI.

Generative AI

Generative AI creates new content.

It can generate:

Text
Images
Audio
Video
Code

Instead of selecting predefined responses, it dynamically creates new outputs based on user prompts.

Large Language Models (LLMs)

At the heart of Generative AI are Large Language Models.

LLMs learn language patterns from enormous amounts of data and use those patterns to generate human-like responses.

This is the technology behind modern AI systems such as ChatGPT, Microsoft Copilot, Gemini, Claude, and many others.

The Generative AI Flow

Every Generative AI application follows a simple architecture:

User Prompt → LLM → Generated Response

Understanding this flow is critical because it becomes the foundation of AI Agent architectures.

AI Agent Architecture

In the second half of the course, we will build an AI Agent using Microsoft Foundry.

The architecture we'll implement is:

User
↓
React + Vite Frontend
↓
Microsoft Foundry Agent
├── Instructions
├── Generative AI Model
└── Web Search Tool
↓
Response

Understanding Generative AI is the first step toward understanding this architecture.

Introducing Subra AI Dietician

Throughout the course, we will build:

Subra AI Dietician

A practical AI-powered dietician assistant that can:

Answer nutrition questions
Provide healthy food suggestions
Follow custom instructions
Use web search when required
Respond through a modern web interface

By the end of the course, you'll have a complete working AI Agent built using Microsoft Foundry.

Video Chapters

00:00 Introduction

01:30 The Problem With Traditional Software

02:30 Why Rule-Based Systems Break

03:51 The Rise of Predictive AI

05:06 Prediction vs Creation

05:55 What is Generative AI

06:43 What is LLM?

07:36 The Generative AI Flow

08:18 AI Agent Architecture

09:06 Subra AI Dietician

What's Coming Next?

In the next lesson, we'll answer a very important question:

If Generative AI can already answer questions, why do we need AI Agents?

We'll explore:

AI Assistant vs AI Agent
Instructions
Tools
Reasoning
Agent Workflows

and prepare for building our first Microsoft Foundry Agent.

If you're interested in AI Engineering, Microsoft Foundry, Azure AI, Agentic AI, or building practical AI applications, this series is designed for you.

Happy learning!

— Subrata Kumar Das
🌐 subraatakumar.com

Develop Your First AI Agent with Microsoft Foundry

Subrata Kumar Das — Thu, 18 Jun 2026 06:11:35 +0000

Develop Your First AI Agent with Microsoft Foundry – Course Launch

AI Agents are quickly moving from experimental technology to real-world software engineering solutions.

As developers, we are entering a phase where applications can not only respond to user input but also reason, use tools, search for information, and perform tasks on behalf of users.

To help software engineers get started with this technology, I've launched a new hands-on course:

Develop Your First AI Agent with Microsoft Foundry

This course focuses on practical implementation rather than AI theory.

Throughout the series, we'll build a complete application called Subra AI Dietician, an intelligent AI Agent powered by Microsoft Foundry and Azure AI Foundry Agent Service.

What You'll Build

By the end of the course, you'll have built:

A Microsoft Foundry AI Agent
Custom Agent Instructions
Web Search Tool Integration
Agent Testing and Evaluation
A Deployed AI Agent
A React Frontend Connected to the Agent
A Complete End-to-End AI Application

Technology Stack

Microsoft Foundry
Azure AI Foundry Agent Service
Visual Studio Code
GitHub Copilot
React
Vite

Who Is This Course For?

This course is designed for:

Software Engineers
React Developers
React Native Developers
Full Stack Developers
Technical Leads

No prior AI experience is required.

Lesson 1 Is Now Available

The first lesson introduces the course, explains what we'll build, and walks through the complete project roadmap.

📺 Watch the video:

🌐 Course Website:
https://rnm.subraatakumar.com

What's Next?

In the next lesson, we'll answer an important question:

What exactly is an AI Agent, and how is it different from traditional software applications?

I'd love to hear from the community:

What AI Agent would you build for your organization or personal projects?

ai #microsoft #azure #aifoundry #microsoftfoundry #aiagents #softwareengineering #react #reactnative #webdevelopment #githubcopilot

Lesson 1.3 - GraphQL for Screen Complexity and App Changes

Subrata Kumar Das — Wed, 17 Jun 2026 05:07:25 +0000

Good morning, class! Welcome back. In our last lesson, we explored how GraphQL fundamentally addresses the issues of over-fetching and under-fetching.

Today, we are going to connect those architectural concepts directly to real-world React Native screen complexity. Our Goal today is to understand how GraphQL simplifies your codebase when a screen demands multiple data sources, when different screens require entirely unique variations of the same resource, and when your mobile application changes and evolves over time.

1. Problem One: Codebase Complexity via Multiple API Calls

Making multiple API calls is not inherently wrong, but from a mobile product engineering perspective, it introduces a significant amount of state-tracking boilerplate inside your components.

In a traditional React Native screen driven by REST, managing multiple endpoints often forces you into a state management pattern that looks like this:

const [products, setProducts] = useState([]);
const [categories, setCategories] = useState([]);
const [loadingProducts, setLoadingProducts] = useState(false);
const [loadingCategories, setLoadingCategories] = useState(false);
const [productsError, setProductsError] = useState<string | null>(null);
const [categoriesError, setCategoriesError] = useState<string | null>(null);

Class, look closely at this block of code. We haven't even written a single line of JSX or rendered any UI yet, and our component is already drowning in individual state hooks just to track the network layer.

The moment a single screen relies on multiple independent asynchronous requests, you are forced to programmatically answer complex state orchestration questions:

Is the entire screen considered to be in a loading state, or are individual sub-sections loading independently?
What happens visually if the product list resolves successfully, but the category chip request fails?
When a user triggers a pull-to-refresh action, should it aggressively retry every single request?
Should a localized network failure on a non-critical widget block the user from interacting with the rest of the screen?

2. GraphQL Fix One: Consolidated Screen-Level Operations

Instead of forcing your UI components to orchestrate several disconnected REST endpoints, a single GraphQL operation lets you fetch the precise combination of data pieces your screen needs in one single network round-trip:

query HomeScreenData {
  categories
  products(page: 1, size: 10) {
    meta {
      total
      page
      pages
    }
    data {
      id
      name
      price
      imageUrl
      category
    }
  }
}

Now, let's be entirely clear: this does not magically erase the necessity for loading spinners or error screens. You still need to design and implement resilient UI fallbacks.

However, it vastly simplifies your frontend state logic. It collapses multiple asynchronous workflows down into one single operation for your component to reason about, dramatically reducing the state variables you need to manually track.

3. Problem Two: Screen-Specific Data Requirements

As an application grows, different mobile screens will inevitably demand entirely different variations of the exact same data model. Let’s map out a standard e-commerce flow:

Product List Screen Layout: Only needs id, name, price, and imageUrl.
Product Details Screen Layout: Requires id, name, price, imageUrl, description, brand, rating, discount, and inStock.
Cart Summary Screen Layout: Demands id, name, price, quantity, and inStock.

In a traditional REST architecture, backend teams typically handle these evolving variations by creating specific hyper-targeted endpoints (like /api/v1/products/cart-view) or by adding heavy configurations of query parameters (like /products?include=details).

While this can get the job done, over time it causes your API surface area to balloon into a tangled, unmanageable mess simply because every new screen design requires a slightly modified data payload shape.

4. GraphQL Fix Two: Component-Driven Selection Sets

GraphQL shifts data model ownership back to the client application. Instead of waiting on backend adjustments, each specific screen explicitly declares its own data requirements.

Furthermore, you can parameterize these operations dynamically using GraphQL Variables:

query ProductListScreen($page: Int!, $size: Int!, $category: String) {
  products(page: $page, size: $size, category: $category) {
    meta {
      total
      page
      pages
    }
    data {
      id
      name
      price
      imageUrl
      inStock
    }
  }
}

To execute this operation with dynamic filtering, you pass a separate Variables object alongside the query:

{
  "page": 1,
  "size": 10,
  "category": "fruits"
}

The underlying structural template of the query remains completely stable. The runtime variables change fluidly based on user interaction. This exact paradigm is exactly what makes building mobile filters, search views, and infinite-scrolling lists highly predictable and clean.

5. Problem Three: The Production Reality of App Versioning

Unlike web applications where a new deployment updates all users instantly, mobile applications stay installed on user devices for months or even years.

If a backend team alters or refactors a REST response payload, older, un-updated installations of your mobile app out in the wild can instantly crash. Because of this, mobile engineering teams are traditionally forced to implement strict, complex API versioning policies (like /api/v1/ vs /api/v2/).

GraphQL does not replace architectural discipline, but it offers natural protection against breaking changes because the client must explicitly request the fields it intends to use. If an older mobile app build doesn't know about a new rating field, it simply won't request it. If a newer build needs to display it, you append it inline without affecting old versions:

query ProductCards {
  products(page: 1, size: 10) {
    data {
      id
      name
      price
      rating # Added seamlessly for new app versions
    }
  }
}

Because the backend server knows exactly which fields are being requested by current active users, the client app is no longer tightly coupled to a monolithic, fixed response shape.

6. The Blueprint: Predictable Response Mirroring

One of the most beginner-friendly and elegant aspects of working with GraphQL is that the response payload shape directly mirrors your request query structure.

Let’s trace an active transaction:

Client Query Document:

query CategoriesAndProducts {
  categories
  products(page: 1, size: 2) {
    data {
      id
      name
    }
  }
}

JSON Server Response:

{
  "data": {
    "categories": ["Fruits", "Vegetables"],
    "products": {
      "data": [
        { "id": 1, "name": "Apple" },
        { "id": 2, "name": "Tomato" }
      ]
    }
  }
}

While the literal data values inside the strings and arrays will change based on database records, the structural nesting matches your query word-for-word, making data binding inside React Native components entirely intuitive.

7. Guided Practice in GraphiQL

Before we jump back into our mobile IDEs, let's build muscular memory by sandbox testing this query layout inside GraphiQL:

Navigate your web browser to https://backend.ecom.subraatakumar.com/graphiql.
Paste the parameterized ProductListScreen query into the main editor panel.
Open the Query Variables drawer at the bottom left and pass valid page/category variables.
Hit the Play button to execute.
Experiment: adjust the category string to another value and re-run.
Delete imageUrl from the selection set and observe the updated JSON structure.
Append rating to the selection set, execute, and verify the structural response mirrors your query change instantly.

This iterative feedback loop is the core day-to-day workflow of a productive GraphQL developer.

8. React Native Low-Level Implementation

Let’s observe how this complete multi-resource request compiles into a low-level JavaScript module using our temporary native fetch client:

async function loadProductList(page: number, category?: string) {
  const response = await fetch("https://backend.ecom.subraatakumar.com/graphql", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      query: `
        query ProductListScreen($page: Int!, $size: Int!, $category: String) {
          products(page: $page, size: $size, category: $category) {
            meta {
              total
              page
              pages
            }
            data {
              id
              name
              price
              imageUrl
              inStock
            }
          }
        }
      `,
      variables: {
        page,
        size: 10,
        category: category ?? null,
      },
    }),
  });

  const json = await response.json();

  if (json.errors) {
    throw new Error(json.errors[0].message);
  }

  return json.data.products.data;
}

Check Your Understanding

Before we wrap up this theory session and head into our practical labs, make sure you can answer these three questions clearly:

How do multiple independent REST calls compound the structural complexity of component loading and error states in React Native?
What does it mean for a screen to "own its data requirement," and how does this prevent API endpoint bloat on the backend?
What is the relationship between the structural layout of a GraphQL query document and the eventual JSON payload returned by the server?

Great work today, class. Review your notes, spend 10 minutes testing variations in the GraphiQL playground, and I will see you all in our next session!

Connect with me:

GitHub: https://github.com/TechCraft-By-Subrata
LinkedIn: https://www.linkedin.com/in/subraatakumar/
YouTube: https://www.youtube.com/@techcraftclub
Instagram: https://www.instagram.com/subraatakumar/
Reddit: https://www.reddit.com/r/ReactNativeMastery/
DEV.to: https://dev.to/subraatakumar
Discord: https://discord.gg/cA5fhVT8
WhatsApp: https://whatsapp.com/channel/0029VbCz72vFCCoUsMV4K30M
Topmate: https://topmate.io/subrata
React Native Mastery: https://rnm.subraatakumar.com/

Lesson 1.2 - REST Problems and the First GraphQL Fixes

Subrata Kumar Das — Wed, 17 Jun 2026 04:28:49 +0000

Good morning, everyone! Welcome back. In our previous lesson, we compared REST and GraphQL at a high, architectural level.

Today, we are going one layer deeper. Our Goal today is to analyze the first two critical API data-fetching problems that show up repeatedly in production-grade React Native applications: over-fetching and under-fetching.

Understanding these two issues will show you exactly why so many engineering teams choose to migrate their mobile applications to GraphQL.

1. Problem One: Over-Fetching

Over-fetching simply means that the backend API sends significantly more data fields over the wire than your specific screen layout actually requires to render.

Let's look at a concrete mobile use case. Imagine you are building a product preview card for a grid view. The UI layout only displays three pieces of information:

Product image
Product name
Price

However, when you fire a request to your standard REST endpoint, the server hands you back this entire payload block:

{
  "id": 1,
  "name": "Apple",
  "price": 40,
  "category": "Fruits",
  "imageUrl": "https://example.com/apple.png",
  "description": "Fresh red apples",
  "brand": "Farm Fresh",
  "inStock": true,
  "quantity": 25,
  "unit": "kg",
  "discount": 5,
  "rating": 4.7
}

Look at that JSON object. While properties like description, quantity, unit, and brand are absolutely vital when a user clicks through to a dedicated Product Details screen, they are completely useless waste on a high-level catalog screen.

When developing for mobile devices, this extra payload volume is not harmless metadata. Your users are interacting with your app on the move—often navigating fluctuating cellular networks, capped data plans, hardware with limited memory overhead, and battery-sensitive operating conditions. Wasting bytes on fields that are immediately discarded strains those mobile resources.

2. GraphQL Fix One: Ask for Only the Needed Fields

GraphQL eliminates this waste by putting selection power back in the hands of the client interface.

When rendering our simple product preview cards, we can construct a selection set containing exclusively the fields our layout binds to:

query ProductCards {
  products(page: 1, size: 10) {
    data {
      id
      name
      price
      imageUrl
    }
  }
}

Now, let’s look at how the exact same schema resource behaves when we shift context over to the comprehensive Product Details screen:

query ProductDetails {
  products(page: 1, size: 10) {
    data {
      id
      name
      price
      imageUrl
      description
      brand
      rating
      discount
      inStock
    }
  }
}

Notice the power here: We are hitting the exact same data resource gateway, but with completely different selection sets tailored perfectly to distinct UI requirements. That is our first major GraphQL architectural fix.

3. Problem Two: Under-Fetching

Conversely, Under-fetching means that a single endpoint fails to provide enough comprehensive data to satisfy what a single screen layout needs to render.

Consider a modern, highly dynamic e-commerce marketplace Home Screen. To provide a rich landing experience, this view simultaneously requires:

A featured list of trending products
A horizontal scrolling list of category chips
The logged-in user's active shopping cart context or recent order history

In a traditional REST architecture, this structural layout regularly forces you to coordinate and chain together multiple independent network requests:

GET /api/v1/products?page=1&size=10
GET /api/v1/categories
GET /api/v1/orders

As a mobile developer, this shifts a heavy orchestration burden onto your React Native codebase. Your UI layer suddenly has to elegantly coordinate three separate asynchronous network cycles, manage multiple individual loading spinners, catch unique localized error states, and configure fallback retry paths if request two fails while requests one and three succeed.

This state complexity isn't a theoretical edge case—it is a production reality that compounds quickly as mobile layout requirements grow.

4. GraphQL Fix Two: Request Related Data Together

GraphQL cleanly resolves under-fetching by allowing client components to request multiple, completely distinct root resource fields inside a single, unified network transaction block.

Here is how we can aggregate our homepage data requirements into a clean operational query payload:

query HomeScreenData {
  categories
  products(page: 1, size: 10) {
    meta {
      total
      page
      pages
    }
    data {
      id
      name
      price
      imageUrl
      category
    }
  }
}

💡 A quick note on architecture: This does not mean you should bundle every single piece of data across your entire application into one gargantuan query document. It simply means that GraphQL hands you a flexible API layer capable of cleanly packaging related data blocks into a single round-trip whenever it makes your UI rendering architecture simpler and cleaner.

5. React Native Implementation Example

Let’s look at how this unified homepage fetching logic translates into a low-level JavaScript function within a mobile environment using standard fetch:

async function loadHomeScreenData() {
  const response = await fetch("https://backend.ecom.subraatakumar.com/graphql", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      query: `
        query HomeScreenData {
          categories
          products(page: 1, size: 10) {
            data {
              id
              name
              price
              imageUrl
              category
            }
          }
        }
      `,
    }),
  });

  const json = await response.json();

  if (json.errors) {
    throw new Error(json.errors[0].message);
  }

  return json.data;
}

Just like in our previous exercises, we are intentionally executing this request through raw HTTP fetch syntax so you can clearly trace the structural shape of the network request body. We will abstract this boilerplate code away with Apollo Client once we enter Module 3.

6. Core Takeaways

The fundamental advantage of introducing GraphQL into your mobile stack isn't based on magic. It boils down to two straightforward client-side performance principles:

The mobile client can request less when rendering lightweight, targeted UI elements (Fixing Over-fetching).
The mobile client can request more data fields aggregated together when populating complex, multi-source layouts (Fixing Under-fetching).

This dual-axis optimization immediately simplifies state management routines and lowers data overhead on mobile devices.

Check Your Understanding

Take a brief moment to review these questions silently to ensure today's architectural concepts are locked in:

In your own words, what is the core operational cost of over-fetching in a cellular mobile application environment?
How does under-fetching directly complicate state and error management inside your React Native UI components?
What mechanism does GraphQL use to grant the mobile client complete control over the structural shape of the incoming response payload?

External Reading

To expand on these core design topics before we start our upcoming practical coding session, explore these official reference guides:

Excellent concentration today, everyone. Pack up your laptops, and I will see you all in our next session!

Thanks for reading.

Connect with me:

GitHub: https://github.com/TechCraft-By-Subrata
LinkedIn: https://www.linkedin.com/in/subraatakumar/
YouTube: https://www.youtube.com/@techcraftclub
Instagram: https://www.instagram.com/subraatakumar/
Reddit: https://www.reddit.com/r/ReactNativeMastery/
DEV.to: https://dev.to/subraatakumar
Discord: https://discord.gg/cA5fhVT8
WhatsApp: https://whatsapp.com/channel/0029VbCz72vFCCoUsMV4K30M
Topmate: https://topmate.io/subrata
React Native Mastery: https://rnm.subraatakumar.com/

Lesson 1.1 - REST vs GraphQL

Subrata Kumar Das — Fri, 12 Jun 2026 05:04:55 +0000

Lesson 1.1 - REST vs GraphQL

Good morning, class! Welcome to the very first lesson of our course.

Before we jump ahead to writing Apollo Client code, before we discuss caching mechanisms, and before we start layout development on our mobile product screens, we need to anchor ourselves in a fundamental architectural concept: the core operational differences between REST and GraphQL.

Our Goal today is highly focused: we are going to look at both API communication styles strictly from the perspective of a React Native developer building real-world, data-driven mobile screens.

1. The API Problem Every Mobile App Has

Let’s be honest: every mobile application is essentially a visual wrapper around data.

A product list screen needs product records. A category filter drawer needs taxonomy trees. A checkout screen needs historical order logs. The architectural hurdle is never about whether your frontend application needs to communicate with a backend database. The real problem we face daily is:

How does a specific screen efficiently request the exact data it needs to render its layout?

REST and GraphQL approach this exact question from completely opposite engineering mindsets.

2. What REST Looks Like

REST (Representational State Transfer) is an API design style where the backend exposes data through multiple individual URLs, which we refer to as Endpoints.

Take a look at these real examples from our e-commerce backend architecture:

GET https://backend.ecom.subraatakumar.com/api/v1/products?page=1&size=10
GET https://backend.ecom.subraatakumar.com/api/v1/categories

In a traditional REST architecture, the endpoint dictates the shape of the data payload.

If the backend team configured the /products endpoint to return 45 data fields per item block, your React Native app will pull all 45 fields over the cellular network—even if your mobile layout only renders 3 of them (like name, price, and imageUrl).

This doesn't make REST inherently bad. REST is deeply familiar, straightforward, predictable, and runs a massive portion of the modern web. However, as mobile application layouts become highly tailored and dynamic, REST can occasionally back the client application into a corner, forcing it to swallow rigid data footprints designed for desktop environments.

3. What GraphQL Looks Like

GraphQL is a strongly-typed query language and runtime for APIs.

Instead of forcing your mobile UI to hit a dozen disconnected endpoints to build a single view, a GraphQL app sends a declarative query to a Single, Unified Endpoint and explicitly dictates the exact fields it requires to render its current layout view.

Our e-commerce GraphQL gateway address is:

POST https://backend.ecom.subraatakumar.com/graphql

Here is a look at a basic query document:

query ProductList {
  products(page: 1, size: 10) {
    data {
      id
      name
      price
      imageUrl
    }
  }
}

If you read this code block like a plain English sentence, it says:
"Dear backend server, for this specific mobile product list screen, fetch page 1 containing 10 items, but only return the id, name, price, and imageUrl fields for those items. Leave everything else behind."

This is the first critical mental paradigm shift you must master.

4. The Main Architectural Difference

To put it in simplest terms:

REST is Endpoint-First.
GraphQL is Screen-Data-First.

Let's break down the developer thought process side-by-side:

Architectural Approach	Core Question Asked by Frontend Dev
REST Mindset	"Which specific endpoint or collection of URLs gives me access to this resource?"
GraphQL Mindset	"What are the precise data properties this specific screen component needs to render right now?"

For React Native engineers, this distinction is crucial. Mobile apps operate on smaller displays, run on resource-constrained hardware, and face erratic cellular network performance. Eliminating bloated payloads directly improves app responsiveness.

5. REST Request Example

Let’s look at a standard JavaScript implementation fetching data from our REST endpoint:

async function fetchProductsWithRest() {
  const response = await fetch(
    "https://backend.ecom.subraatakumar.com/api/v1/products?page=1&size=10"
  );

  if (!response.ok) {
    throw new Error("Failed to load products");
  }

  return response.json();
}

Notice the key mechanical takeaway here: The URL structure completely controls what data payload drops into your application state.

6. GraphQL Request Example

Now, let’s observe how we accomplish the exact same product fetching intent using GraphQL via low-level native fetch:

async function fetchProductsWithGraphQL() {
  const response = await fetch("https://backend.ecom.subraatakumar.com/graphql", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      query: `
        query ProductList {
          products(page: 1, size: 10) {
            data {
              id
              name
              price
              imageUrl
            }
          }
        }
      `,
    }),
  });

  const result = await response.json();

  if (result.errors) {
    throw new Error(result.errors[0].message);
  }

  return result.data.products.data;
}

Notice the functional shift here: The HTTP endpoint stays completely static, but the inner query payload directly controls the shape and size of the incoming response.

7. What React Native Developers Should Remember

A common beginner pitfall is framing this engineering choice as an absolute binary battle: "REST vs GraphQL—which tool wins?" That is entirely the wrong lens to view your system architecture through.

The useful question you should be asking yourself as a mobile product engineer is this:

"Can my current screen component request only the exact properties it requires to render its layout, within the fewest possible round-trips over the network?"

GraphQL was engineered specifically from the ground up to solve that exact optimization problem for client apps.

Check Your Understanding

Before packed up and heading out to our next hands-on coding lab, make sure you can confidently answer these three architectural review questions:

In a traditional REST API ecosystem, who fundamentally controls the structural shape of the data response?
In a GraphQL ecosystem, who assumes control over choosing which data fields are returned for a mobile screen layout?
Why does minimizing raw payload size and network round-trips matter significantly more for mobile hardware form factors than desktop web browsers?

External Reading

To deepen your grasp of these concepts before our next class, review these foundational resources:

Great job keeping focus today. I'll see you all in the next lecture!

Thanks for reading.

Connect with me:

GitHub: https://github.com/TechCraft-By-Subrata
LinkedIn: https://www.linkedin.com/in/subraatakumar/
YouTube: https://www.youtube.com/@techcraftclub
Instagram: https://www.instagram.com/subraatakumar/
Reddit: https://www.reddit.com/r/ReactNativeMastery/
DEV.to: https://dev.to/subraatakumar
Discord: https://discord.gg/cA5fhVT8
WhatsApp: https://whatsapp.com/channel/0029VbCz72vFCCoUsMV4K30M
Topmate: https://topmate.io/subrata
React Native Mastery: https://rnm.subraatakumar.com/

The Phantom in the Sandbox: Architecting an Offline AI Coach with React Native and Gemma 4

Subrata Kumar Das — Wed, 03 Jun 2026 03:06:07 +0000

It was 3:14 AM. The silence in the room was absolute, broken only by the hum of my laptop fan. On my desk sat two testing devices: a Xiaomi MI running Android and my daily driver iPhone 15. Both screens were completely black.

Beside them lay a half-empty glass of flat water. Irony at its finest.

For the past three weeks, I had been deep in the engineering trenches of a personal side project, trying to pull off a high-wire architectural act: embedding a fully sovereign, 100% offline, conversational AI Hydration Coach directly into the core of my application. No cloud servers. No API gateways. No network latency. And absolutely no monthly token subscriptions bleeding my runway dry.

The promise was intoxicating. A user could be on an isolated mountain trail with zero cell service, open Water Tracker with Subra AI on iOS or Android, ask their coach a question about thermal fluid loss, and receive a deeply contextualized, real-time response.

But at 3:15 AM, the log stream on my monitor wasn't giving me context. It was spitting a single, devastating error line over and over:

Fatal Exception: libc++abi: terminating with uncaught exception of type std::runtime_error: Failed to map model memory

The app wasn't just crashing; it was suffocating. I had invited an LLM ghost into my React Native sandbox, and it was ravenous for memory.

Chapter 1: The Sovereign Edge Architecture

To understand how I got here, we have to look at the architectural blueprint. Most product teams building GenAI mobile features take the comfortable path: wrapping an axios fetch request around a remote cloud API endpoint.

It’s elegant until the user steps into an elevator, a subway tunnel, or an airplane. Then, your "smart" coach reverts to an expensive loading spinner. Worse, every time a user casually chats with your app, you get billed. If your app goes viral, your API bills scale linearly, threatening to bankrupt your project before monetization even kicks in.

As a solo indie developer, I wanted a localized architecture. A sovereign edge.

To pull this off, I needed a highly optimized runtime and a model small enough to fit inside a mobile app's tight memory sandbox, yet smart enough to avoid hallucinating medical advice.

Enter Google’s newly minted LiteRT-LM stack.

For the uninitiated, LiteRT (the production-ready framework formerly known as TensorFlow Lite) is the high-performance multi-platform runtime trusted by millions of edge applications. But raw LiteRT handles low-level tensor execution. To build an LLM app, you need an orchestration layer above it to manage Key-Value (KV) caches, enforce prompt templates, handle speculative decoding, and execute function calling. That is exactly what the LiteRT-LM Overview brings to the table.

And the brain? The Gemma 4 E2B model family. Specially built for on-device applications, the E2B variant is a lightweight powerhouse. It packs a text decoder with 0.79GB of weights and 1.12GB of embedding parameters into a ~2.59 GB .litertlm file.

But don't let its size fool you. It supports a staggering 32k context length and features Multi-Token Prediction (MTP) drafters natively out of the box, allowing the framework to predict multiple upcoming tokens concurrently for a massive speedup on mobile chips.

Chapter 2: The Edge of the Bridge

While community wrappers like react-native-litert-lm have emerged to bridge these ecosystems, dropping a raw 2.5GB model file into a cross-platform environment is never a plug-and-play affair. To truly understand performance bottlenecks, optimize token-streaming speeds, and prevent memory leaks, you have to look under the hood at how LiteRT-LM binds to the device's native metal.

The actual implementation maps to raw native development guides:

The Kotlin engine setup: LiteRT-LM Android Guide
The Swift wrapper orchestration: LiteRT-LM Swift Guide

The mission was clear: Initialize a singleton instance of the LiteRT-LM inference engine natively, load the heavy .litertlm model file into memory once, expose a thread-safe sendMessage method over the bridge, and stream the generated tokens back to the JavaScript UI in chunks.

Here is the structural logic of how the native engines map to both platforms to talk back to a cross-platform state layer.

The iOS Blueprint (Swift)

On iOS, the compiler links against the local LiteRT-LM framework headers, initializing the model and managing the asynchronous stream over an RCTEventEmitter.

// WaterAIModule.swift
import Foundation
import LiteRTLM // Under the hood native framework linkage

@objc(WaterAIModule)
class WaterAIModule: RCTEventEmitter {
  private var lmEngine: Engine?
  private var currentConversation: Conversation?

  @objc func initializeEngine(_ modelPath: String, resolver resolve: @escaping RCTPromiseResolveBlock, rejecter reject: @escaping RCTPromiseRejectBlock) {
    do {
      let settings = EngineSettings(modelPath: modelPath)
      // Max out context token space allocated for conversation
      settings.mainExecutorSettings.maxNumTokens = 8192 

      self.lmEngine = try Engine.create(settings: settings)
      self.currentConversation = try self.lmEngine?.createConversation(config: ConversationConfig(
        preface: "You are an expert Hydration AI Coach. Keep answers concise, scientific, and highly practical."
      ))
      resolve("Engine Warm and Ready")
    } catch {
      reject("ERR_INIT", "Failed to awaken LiteRT-LM Engine", error)
    }
  }

  @objc func askCoach(_ message: String) {
    guard let conversation = currentConversation else {
      sendEvent(withName: "onTokenReceived", body: ["error": "Engine not initialized"])
      return
    }

    Task {
      do {
        // Stream back tokens sequentially to make UI responsive
        let stream = try await conversation.sendMessage(role: "user", content: message)
        for try await chunk in stream {
          sendEvent(withName: "onTokenReceived", body: ["token": chunk.text])
        }
      } catch {
        sendEvent(withName: "onTokenReceived", body: ["error": error.localizedDescription])
      }
    }
  }

  override func supportedEvents() -> [String]! {
    return ["onTokenReceived"]
  }
}

The Android Blueprint (Kotlin)

On the Android side, the Java Native Interface (JNI) overhead means handling context carefully, passing inputs securely down to the underlying XNNPACK or GPU backends.

// WaterAIModule.kt
package com.subraatakumar.watertracker

import com.facebook.react.bridge.*
import com.facebook.react.modules.core.DeviceEventManagerModule
import com.google.edge.litertlm.Engine
import com.google.edge.litertlm.EngineSettings
import com.google.edge.litertlm.Conversation
import kotlinx.coroutines.*

class WaterAIModule(reactContext: ReactApplicationContext) : ReactContextBaseJavaModule(reactContext) {
    private var lmEngine: Engine? = null
    private var conversation: Conversation? = null
    private val moduleScope = CoroutineScope(Dispatchers.Default + SupervisorJob())

    override fun getName(): String = "WaterAIModule"

    @ReactMethod
    fun initializeEngine(modelPath: String, promise: Promise) {
        try {
            val settings = EngineSettings.builder()
                .setModelPath(modelPath)
                .setMaxNumTokens(8192)
                .build()

            lmEngine = Engine.create(settings)
            conversation = lmEngine?.createConversation()
            promise.resolve("Android Engine Alive")
        } catch (e: Exception) {
            promise.reject("ERR_ANDROID_INIT", e.localizedMessage, e)
        }
    }

    @ReactMethod
    fun askCoach(message: String) {
        val streamConversation = conversation ?: return
        moduleScope.launch {
            try {
                streamConversation.sendMessage("user", message).collect { chunk ->
                    val map = Arguments.createMap().apply {
                        putString("token", chunk.text)
                    }
                    reactApplicationContext
                        .getJSModule(DeviceEventManagerModule.RCTDeviceEventEmitter::class.java)
                        .emit("onTokenReceived", map)
                }
            } catch (e: Exception) {
                // Handle stream drop failures cleanly
            }
        }
    }
}

Chapter 3: The 607MB Breakthrough

Back to 3:15 AM. The code looked immaculate, but the app was still imploding on startup.

The physical math of mobile development is ruthless. A standard mobile application gets allocated anywhere from 200MB to 500MB of resident RAM by the OS before it lands on the high-risk eviction list. My model file alone was 2.59 GB. How was I supposed to squeeze a mountain inside a wallet?

I poured over the technical specifications of Gemma 4 E2B. That's when I found the missing clue, hidden inside the mechanics of the runtime memory-mapping subsystem.

LiteRT-LM implements a highly advanced memory footprint optimization strategy: It splits how it treats model parameters.

Gemma 4 E2B Model (2.59 GB Total Container)
├── Text Decoder Weights (0.79 GB)  ---> Kept strictly in Resident Physical RAM
└── Embedding Parameters (1.12 GB)  ---> Memory-Mapped (.mmap) dynamically from disk

Instead of copying the full 2.59 GB binary wholesale into physical RAM blocks, the engine uses weight caching mechanisms (like XNNPACK's native allocations). It pins the critical 0.79GB text decoder directly in execution memory, while memory-mapping the massive embedding layers directly from the device's storage on-demand.

The physical memory footprint doesn't hit 2.5 GB. It settles beautifully at just around 607MB to 700MB.

But why was my build still failing?

Because of how I packaged the model container. I had manually bundled the raw tokenizer config files and the converted layers together, blinding the engine's memory-mapping parser. It was reading the whole file layout as unaligned, un-mappable raw byte-blobs.

To fix it, I had to utilize the official serialization architecture outlined in the LiteRT-LM File Builder Documentation. The builder aligns the internal headers perfectly so the mobile OS can execute memory mapping with zero block overhead.

I spun up a Python virtual environment and ran the compiler pipeline script:

pip install litert-lm-builder

litert-lm-builder \
  output --path ./assets/gemma-4-E2B-hydra.litertlm \
  system_metadata --str engine_target "mobile-edge" \
  llm_metadata --path ./configs/gemma_policy.pb \
  tflite_model --path ./models/prefill_decode.tflite --model_type prefill_decode --backend_constraint gpu \
  hf_tokenizer --path ./tokenizer/tokenizer.json

The script ran cleanly, packaging the binary layers while injecting explicit alignment offsets into the file structure. I dragged the brand-new, optimized gemma-4-E2B-hydra.litertlm file into the app bundles.

I hit rebuild.

Chapter 4: It Listens, It Thinks, It Adapts

The compilation finished. I tapped the chat icon on the app screen. The interface faded into a clean, minimalist prompt box.

I typed: "I just finished a 5K run in 85-degree humid weather. I’ve had 500ml of water today. Am I at risk?"

I held my breath, waiting for the dreaded native crash log.

The monitor remained clear. Instead, token by token, words started cascading onto the mobile viewport with fluid speed—hitting nearly 50 tokens per second accelerated entirely by the local device's GPU layers.

[Thinking...] 
User hydration state is dangerously low given thermal conditions. 
Prefill tokens: 1024 | Decode: ~52 tok/sec.

"You are experiencing significant net fluid deficit. At 85°F with high humidity, 
your sweat rate can easily exceed 1L/hour. Consuming only 500ml puts you in an 
acute state of dehydration. Skip pure water for the next 300ml—you need 
isotonic electrolytes immediately to restore plasma volume."

No remote servers were pinged. No user tracking data escaped into the cloud. It was completely secure, private, instantaneous intelligence running locally on a handheld piece of glass.

The Takeaway: The Stack of 2030 is On-Device

Building intelligence at the edge forces you to shed the lazy habits of cloud-first development. You cannot throw infinite elastic computing resources at a bad algorithm or a bloated architectural layout when your execution limits are hard-capped by a lithium-ion battery and a mobile operating system's kernel.

But the reward? True application autonomy for a side project without ongoing maintenance costs.

If you want to experience how this architecture behaves in production under real-world constraints, you can test the implementation live on both modern ecosystems:

Download the iOS live build: Water Tracker with Subra AI on the App Store
Download the Android live build: Water Tracker Engine on Google Play

The era of writing simple wrapper apps around expensive cloud endpoints is winding down. By bridging native frameworks like LiteRT-LM into accessible cross-platform viewports like React Native, we aren't just shipping apps—we're deploying highly optimized, self-contained digital minds directly into our users' pockets.

And the best part? The next time my cloud server goes down... my users will still be perfectly hydrated.

Technical Reference Ledger & Documentation

Core Model Architecture: Gemma 4 LiteRT-LM Documentation
Runtime Core Specifications: LiteRT-LM Core Overview
Android JNI Implementation Matrix: LiteRT-LM Android Integration
iOS Metal Acceleration Layer: LiteRT-LM Swift Framework
Binary Alignment Utility: LiteRT-LM File Builder CLI

Stop Shipping 20 Locale Files in React Native: On-Device Translation for Dynamic Language Packs

Subrata Kumar Das — Tue, 02 Jun 2026 09:41:36 +0000

Stop Shipping 20 Locale Files in React Native: On-Device Translation for Dynamic Language Packs

Internationalization in mobile apps usually starts clean and then gets expensive.

At first, you keep a couple of JSON files:

en.json
es.json
fr.json

That works when your product is small and the set of languages is stable.

It breaks down when:

you want to support many languages
the product team keeps changing copy
translated files drift out of sync
some languages are only partially used
you do not want to run every string through a server-side translation pipeline

This is the problem @tcbs/react-native-language-translator is trying to solve.

It lets a React Native app keep a source language, translate missing keys on device, and cache the generated language pack locally.

Package: @tcbs/react-native-language-translator

You can see the same idea live in the Water Tracker app:

iOS: Water Tracker with Subra AI
Android: Water Tracker on Google Play

The problem

Many React Native apps treat localization as a static asset problem:

keep one JSON file per language
ship all of them in the app
update all of them whenever English changes

That model has real costs.

1. Translation files become operational debt

Every new feature adds more keys. Every copy change forces translators to update multiple locale files. Over time, the translation layer becomes a maintenance queue.

The result is predictable:

missing keys
stale translations
untranslated fallback strings
inconsistent release quality across languages

2. Shipping many locales is wasteful

Most users only need one target language. But many apps ship every locale anyway. That increases bundle size and creates a lot of dead weight for users who will never use most of those files.

3. Dynamic product copy is hard to localize well

If your app changes quickly, static translation files lag behind. Teams either accept stale translations or build a backend workflow to keep everything synchronized.

That is often more infrastructure than the app actually needs.

4. Server-side translation is not always the right tradeoff

Calling a translation API at runtime introduces:

latency
API cost
network dependency
privacy considerations
offline failure modes

For some apps, that is acceptable. For many mobile flows, it is not.

The idea behind the package

Instead of treating every target language as a fully prebuilt asset, this package treats translation as a local capability.

The app keeps one source dictionary, typically English, and then:

detects the user’s target language
checks whether that language is supported
downloads the native translation model for the language pair
translates missing keys on device
stores the translated values locally
applies the cached values to the app’s i18n layer

That changes the architecture in a useful way:

the source language stays canonical
target languages are generated incrementally
only needed translations are downloaded and cached
the app can improve coverage over time without shipping every locale file up front

What solution is it providing?

@tcbs/react-native-language-translator provides three things:

1. A React Native native bridge for on-device translation

The package exposes a native translator module for:

Android via Google ML Kit Translate
iOS via ML Kit Translate through the native bridge

This gives JavaScript code a simple interface for:

checking supported language pairs
preparing language models
translating batches of strings
reading downloaded languages

2. A supported language catalog

The package includes a ready-to-use supported languages list for building UI such as:

language pickers
onboarding preference screens
settings pages

Each entry contains:

language code
display name
flag

It also includes a small alias normalization layer, for example:

hn -> hi
od -> or

That matters because app-internal language codes and translator-supported codes do not always match cleanly.

3. A language-pack generation workflow

This is the more interesting part.

The package does not only translate text. It helps build a practical runtime flow around translation:

flatten a source dictionary
compare it with cached and bundled translations
identify missing keys
translate only the missing values
save them into a repository abstraction
apply them back into your i18n resource bundle

That turns translation from a one-off API call into a reusable app pattern.

How is it providing that solution?

The package is opinionated in a useful way: it separates the translation engine from your app’s storage and i18n implementation.

Layer 1: Native translation

The createNativeTranslatorModule() API exposes methods such as:

getSupportedLanguages()
getDownloadedLanguages()
isSupported(source, target)
prepareLanguagePair(source, target)
translateBatch(texts, source, target)

This is the lowest-level layer. It is responsible for native translation model setup and translation execution.

Layer 2: Language code normalization

The package normalizes language tags and resolves aliases before calling the native layer.

This helps when:

your app uses short internal aliases
user profile data stores non-standard codes
upstream systems do not agree on locale naming

It reduces friction between app-specific language identifiers and translator-supported codes.

Layer 3: Coverage-based language pack generation

The ensureLanguagePackReady() helper does most of the workflow orchestration.

Conceptually, it does this:

flatten the source dictionary
read existing cached translations
inspect the currently bundled translations
calculate what is missing or still effectively untranslated
prepare the language pair
translate missing values in chunks
persist generated translations
return coverage information

This design matters because production localization is not binary. It is not just “translated” or “not translated.” You need to know:

how many keys exist
how many are ready
how many are still missing
how many are still identical to source text

The package exposes that coverage model directly.

Layer 4: Storage-agnostic integration

The package does not force a database choice.

Instead, you provide a repository adapter with methods like:

getMapForLanguage()
upsertMany()

That means you can back it with:

SQLite
Realm
MMKV-backed structured persistence
any custom local store

The same pattern applies to your i18n layer. You provide an adapter with methods such as:

getResourceBundle()
addResourceBundle()

So the package can work with your existing localization setup rather than replacing it.

How many languages does it support?

The current package exports 59 supported languages.

Examples include:

English
Spanish
French
German
Arabic
Hindi
Bengali
Gujarati
Tamil
Telugu
Japanese
Korean
Chinese
Russian
Portuguese
Turkish
Ukrainian
Vietnamese

The full list is available directly from the package through supportedLanguages and getSupportedLanguages().

This is enough to cover a broad set of global product scenarios while keeping the app-side integration simple.

Why this approach is useful

There is a practical middle ground between “ship every locale file forever” and “call a translation API on every screen.”

This package sits in that middle ground.

It reduces translation maintenance pressure

You still keep a canonical source dictionary, but you do not need every target language file to be complete before the app can function.

It keeps the app responsive to copy changes

If new English keys appear, the app can generate and cache missing translated entries instead of waiting for a full manual localization cycle.

It works with offline-first thinking better than API translation

Once models and translations are downloaded, the app can reuse them locally.

It avoids forcing a backend translation service

That can be useful for teams that want fewer moving parts or tighter privacy boundaries around runtime text handling.

A realistic usage example

Here is the simple path:

import {
  createNativeTranslatorModule,
  getSupportedLanguages,
  isLanguageSupported,
  resolveTranslatorLanguageCode,
} from '@tcbs/react-native-language-translator';

const selectedLanguage = 'od';
const targetLanguage = resolveTranslatorLanguageCode(selectedLanguage);

if (!isLanguageSupported(targetLanguage)) {
  throw new Error('Unsupported language');
}

const languageOptions = getSupportedLanguages({ includeEnglish: true });
const translator = createNativeTranslatorModule();

await translator.prepareLanguagePair('en', targetLanguage);

const translated = await translator.translateBatch(
  ['Settings', 'Store'],
  'en',
  targetLanguage,
);

That is useful if you only need direct string translation.

But the more production-ready pattern is language-pack generation:

import {
  applyCachedLanguagePack,
  createNativeTranslatorModule,
  ensureLanguagePackReady,
} from '@tcbs/react-native-language-translator';

await ensureLanguagePackReady({
  sourceLanguage: 'en',
  targetLanguage: selectedCode,
  sourceDictionary: enJson,
  i18n,
  repository: localizedOverrideRepository,
  nativeModule: createNativeTranslatorModule(),
});

applyCachedLanguagePack({
  languageCode: selectedCode,
  i18n,
  repository: localizedOverrideRepository,
});

This is where the package becomes more than a translator wrapper. It becomes infrastructure for a dynamic localization workflow.

What teams should know before using it

This is not magic. There are still operational realities.

1. Translation models are runtime assets

Models need to be downloaded for the language pair. That means:

first use can take time
network availability matters during preparation
you should show clear user-facing progress states

2. Generated translations should be treated as cached output

You should think of generated language packs as local derived data, not as your source of truth.

The source dictionary remains your canonical content.

3. Quality expectations should be explicit

On-device translation is useful, but you still need product judgment.

For critical legal, medical, financial, or brand-sensitive copy, human review may still be necessary.

4. Good UX matters

If you adopt this approach, the app should explain:

that language resources may need downloading
that translation happens on device
that results are cached locally
that some screens may improve in coverage over time

Where this package fits best

This approach is especially useful for apps that:

ship fast and change copy often
want broad language reach without shipping many static locale files
want local generation and local caching
already have an i18n setup and just need a translation generation layer
want to avoid a runtime translation backend for common flows

It is less ideal if your localization model requires:

formally reviewed translations for every string before release
a centralized translation management system as the only allowed source
strict server-mediated copy governance

Final take

The interesting part of @tcbs/react-native-language-translator is not just that it translates strings.

It provides a workable architecture for dynamic localization in React Native:

source language as canonical input
native on-device translation as the engine
cached language packs as local derived output
coverage-aware helpers to manage completeness

That is a practical model for teams that want broader language support without turning localization into a backend-heavy system.

If you want to try it, the package is here:

https://www.npmjs.com/package/@tcbs/react-native-language-translator

The Death of the React Native Bridge: Moving from JSON to JSI in 2026

Subrata Kumar Das — Sat, 30 May 2026 07:37:25 +0000

What is the Native Bridge?

The React Native Bridge is a communication layer that allows the JavaScript thread and the Native threads (iOS/Android) to talk to each other.
Because JavaScript and native languages (like Swift, Objective-C, Java, or Kotlin) cannot communicate directly, they require a middleman. The Bridge functions as a message broker.

How it works:

Serialization: JavaScript converts actions or data into JSON strings.
Asynchronous Transport: The JSON payload is sent asynchronously across the bridge.
Deserialization: The native side decodes the JSON and executes the requested platform action (e.g., rendering a view or accessing hardware).

When is a Native Bridge Required?

By default, React Native handles everyday components (like or ) and APIs automatically. However, you must manually create a custom native bridge (via Native Modules or Native UI Components) in the following scenarios:

Accessing Unsupported Hardware: When you need device features lacking a built-in React Native API—such as an advanced camera sensor, biometrics (FaceID/Fingerprint), or custom Bluetooth peripherals.
Integrating Third-Party Native SDKs: When a service provider (like a payment gateway, analytics tool, or advertisement network) only gives you an iOS CocoaPod or an Android Gradle dependency.
Reusing Existing Native Code: When you are migrating an older native app to React Native and want to salvage functional Kotlin, Swift, or Objective-C business logic.
High-Performance Heavy Lifting: When executing intensive tasks—like image processing, audio manipulation, or complex database operations—that would otherwise freeze the single-threaded JavaScript environment.
Custom UI Renders: When incorporating a platform-specific UI layout that cannot be fully built using React Native's standard cross-platform components.

Important Architectural Note

React Native heavily transitioned away from this legacy asynchronous Bridge.

The newer framework versions standardise the New Architecture, swapping out the JSON bridge for the JavaScript Interface (JSI). JSI allows JavaScript to hold direct C++ memory references to native methods. This shift unlocks synchronous execution and completely eliminates JSON serialization delays, solving historic performance bottlenecks. Instead of creating old "bridges", you will typically now build TurboModules and Fabric Components.
Are you planning to build a custom native module for a specific device feature, or are you troubleshooting a performance bottleneck in your current app? Let me know in the comments.

The transition away from the old JSON native bridge to JSI (JavaScript Interface) happened as a gradual rollout over several years.

The Transition Timeline

1. When did React Native move to JSI?

The transition to JSI began experimentally in March 2022 with the release of React Native 0.68. This release introduced the very first pillars of the New Architecture (TurboModules and the Fabric renderer), which relied on JSI rather than the old asynchronous bridge.

2. To which version was the Native Bridge supported?

The old bridge framework was supported as the primary, default engine up through React Native 0.75. Here is how the deprecation and complete removal unfolded:

React Native 0.76 (October 2024): The New Architecture (JSI-powered) became the default for all new projects. An interoperability layer still existed, allowing legacy bridge-based modules to function via a temporary compatibility shim.
React Native 0.82 (October 2025): The legacy architecture was permanently disabled. Developers lost the ability to opt out of the New Architecture via flags (newArchEnabled=false was removed).
React Native 0.85 (April 2026): The legacy bridge code was removed from the codebase entirely. There is no longer a fallback mechanism or bridge interoperability layer.

Architectural Milestone Summary

React Native Version	Release Date	Bridge & JSI Status
0.68	March 2022	JSI Introduced: Experimental opt-in for the New Architecture.
0.73	Late 2023	Bridgeless Mode: Introduced as an experimental opt-in.
0.76	October 2024	Default Shift: JSI / New Architecture turned on by default. Old bridge moved to an interop layer.
0.82	October 2025	Old Architecture Disabled: Toggle flags removed; New Architecture mandatory.
0.85	April 2026	Complete Removal: The legacy bridge code is entirely deleted.

Starting in React Native 0.85, you can no longer use the old, asynchronous JSON native bridge. The legacy bridge code has been completely removed from the framework's core repository.

However, this does not mean you can no longer write custom native code. It just means the mechanism has completely changed.

What is Gone vs. What Replaces It

❌ What you cannot do anymore: You can no longer use RCTBridgeModule (iOS) or ReactContextBaseJavaModule (Android) to pass serialized JSON data back and forth asynchronously. The "interop layer" that let these old modules run on newer versions has been fully deleted.
✅ What you must do instead: You must write Turbo Native Modules and Fabric Components. They achieve the exact same goal (allowing JavaScript to trigger native code) but use JSI to call C++ functions directly, providing instant, synchronous execution without JSON serialization.

The Practical Impact

For App Developers: If your project targets React Native 0.85, any internal native code you previously wrote using the old bridge format must be rewritten into TurboModules.
For Third-Party Libraries: Any community npm package that has not updated its code to support the New Architecture will break or crash your build immediately in 0.85.

🚀 Why Learning the React Native JSON Bridge Still Matters in 2026

Learning the legacy JSON bridge is incredibly valuable because it teaches you the fundamental, underlying mechanics of how cross-platform frameworks handle inter-process communication (IPC).
Even as modern frameworks transition to zero-latency, direct-memory solutions like the JavaScript Interface (JSI), mastering the bridge gives you a deep, conceptual understanding of data serialization, asynchronous thread management, and the architectural trade-offs inherent in decoupling user interfaces from native operating systems.
Furthermore, the vast majority of enterprise-level React Native applications currently running in production were built over the last decade and still rely heavily on legacy bridge systems. By knowing how the bridge operates, you instantly become a highly competitive engineer capable of maintaining, troubleshooting, and strategically migrating massive, real-world codebases to newer architectures.

🛠️ Step-by-Step Tutorial: Building Your First JSON Native Bridge

In this tutorial, we will build a custom native module that performs a simple arithmetic addition on the native side (Android and iOS) and returns the result back to JavaScript. This will give you a clear, hands-on understanding of how data flows across the legacy JSON bridge.

Step 1: Initialize a Bridge-Compatible React Native App

Because modern versions of React Native disable the legacy bridge by default, we need to explicitly initialize our project using React Native 0.75.4.
Run the following command in your terminal:

npx @react-native-community/cli@latest init JsonBridgeDemo --version 0.75.4
cd JsonBridgeDemo

Turn Off the New Architecture Flags

To ensure the application uses the JSON bridge as its primary engine, verify that the following flags are set to false.

For Android: Open android/gradle.properties and confirm this line:

newArchEnabled=false

For iOS: Open your terminal, navigate to the ios directory, and install dependencies with the legacy architecture flag:

cd ios
RCT_NEW_ARCH_ENABLED=0 bundle exec pod install
cd ..

Step 2: Create the Android Native Bridge (Java)

We need two files on the Android side: a Module file (to define our addition logic) and a Package file (to register the module with React Native).

1. Create the Module File

Navigate to android/app/src/main/java/com/jsonbridgedemo/ and create a new file named CalculatorModule.java. Paste the following code:

package com.jsonbridgedemo;
import com.facebook.react.bridge.ReactApplicationContext;import com.facebook.react.bridge.ReactContextBaseJavaModule;import com.facebook.react.bridge.ReactMethod;import com.facebook.react.bridge.Callback;
public class CalculatorModule extends ReactContextBaseJavaModule {

    // Constructor required by React Native
    public CalculatorModule(ReactApplicationContext reactContext) {
        super(reactContext);
    }

    // This defines the name used to import the module in JavaScript
    @Override
    public String getName() {
        return "CalculatorModule";
    }

    // The @ReactMethod annotation exposes this method to the JSON Bridge
    @ReactMethod
    public void addNumbers(int num1, int num2, Callback callback) {
        int result = num1 + num2;

        // Data is serialized into a JSON format and sent back via the callback
        callback.invoke(result);
    }
}

2. Create the Package File

In the same directory, create a file named CalculatorPackage.java to register your module:

package com.jsonbridgedemo;
import com.facebook.react.ReactPackage;import com.facebook.react.bridge.NativeModule;import com.facebook.react.bridge.ReactApplicationContext;import com.facebook.react.uimanager.ViewManager;
import java.util.ArrayList;import java.util.Collections;import java.util.List;
public class CalculatorPackage implements ReactPackage {

    @Override
    public List<ViewManager> createViewManagers(ReactApplicationContext reactContext) {
        return Collections.emptyList();
    }

    @Override
    public List<NativeModule> createNativeModules(ReactApplicationContext reactContext) {
        List<NativeModule> modules = new ArrayList<>();
        // Add our custom module to the bundle list
        modules.add(new CalculatorModule(reactContext));
        return modules;
    }
}

3. Register the Package

Navigate to android/app/src/main/java/com/jsonbridgedemo/MainApplication.kt. Locate the getPackages() function and register your Java package like this:

        override fun getPackages(): List<ReactPackage> =
            PackageList(this).packages.apply {
              // Packages that cannot be autolinked yet can be added manually here, for example:
              // add(MyReactNativePackage())
              add(CalculatorPackage()) // 👈 Add this line to register your Java package!
            }

Because of interoperability, Kotlin initializes CalculatorPackage() exactly as if it were a native Kotlin class.

Step 3: Create the iOS Native Bridge (Objective-C)

On iOS, we use Objective-C macros provided by React Native to automatically bind our class and methods to the bridge.

1. Create the Header File

Open your project in Xcode, or navigate to the ios/JsonBridgeDemo/ directory and create a file named CalculatorModule.h:

#import <React/RCTBridgeModule.h>
@interface CalculatorModule : NSObject <RCTBridgeModule>@end

2. Create the Implementation File

In the same directory, create a file named CalculatorModule.m and add the following code:

#import "CalculatorModule.h"
#import <React/RCTLog.h>
@implementation CalculatorModule
// This macro exports the module to the JavaScript side under the class name
RCT_EXPORT_MODULE();
// This macro explicitly exposes the method to the JSON bridge asynchronously
RCT_EXPORT_METHOD(addNumbers:(NSInteger)num1 num2:(NSInteger)num2 callback:(RCTResponseSenderBlock)callback)
{
    NSInteger result = num1 + num2;

    // The result is serialized to a JSON payload and returned through the bridge
    callback(@[@(result)]);
}
@end

3. Link Your Files in Xcode (Crucial Step!)

Unlike Android, you don't need to manually register your iOS module in an implementation file like AppDelegate.mm. React Native’s RCT_EXPORT_MODULE() macro registers it automatically during compilation.
However, Xcode must be explicitly told that these new files exist, or it will skip compiling them entirely. Follow these quick steps to link them:

Open your project's iOS workspace (ios/JsonBridgeDemo.xcworkspace) inside Xcode.
Right-click on your main project folder (JsonBridgeDemo) in the left-hand sidebar file navigator.
Click Add Files to "JsonBridgeDemo"...
Select both CalculatorModule.h and CalculatorModule.m from your project folder.
A modal configuration sheet will drop down. Set the options precisely like this:
Action: Select Reference files in place. (This ensures Xcode reads the exact files in your workspace, allowing you to edit them seamlessly in VS Code).
- Targets: Explicitly Check [✓] the box next to your main application target JsonBridgeDemo. Leave the test target unchecked.
Click Finish.

Now Xcode knows exactly where your module is, and it will bundle your custom Objective-C code right into the application when you build it!

Step 4: Call the Native Bridge from JavaScript

Now that both native platforms have implemented the CalculatorModule, we can consume it in our application UI.
Open your root App.tsx (or App.js) file, replace its contents with the code block below:

import React, { useState } from 'react';
import { StyleSheet, Text, View, TextInput, Button, NativeModules } from 'react-native';
// Extract our custom module from the NativeModules bridge registry

const { CalculatorModule } = NativeModules;
export default function App() {
  const [number1, setNumber1] = useState('10');
  const [number2, setNumber2] = useState('20');
  const [result, setResult] = useState<number | null>(null);

  const handleCalculate = () => {
    const num1 = parseInt(number1, 10) || 0;
    const num2 = parseInt(number2, 10) || 0;

    // Triggering the asynchronous native method across the JSON bridge
    CalculatorModule.addNumbers(num1, num2, (nativeResult: number) => {
      // Receives the deserialized JSON response here on the JS side
      setResult(nativeResult);
    });
  };

  return (
    <View style={styles.container}>
      <Text style={styles.title}>JSON Bridge Calculator</Text>

      <TextInput
        style={styles.input}
        keyboardType="numeric"
        value={number1}
        onChangeText={setNumber1}
      />
      <Text style={styles.plus}>+</Text>
      <TextInput
        style={styles.input}
        keyboardType="numeric"
        value={number2}
        onChangeText={setNumber2}
      />

      <Button title="Calculate on Native Side" onPress={handleCalculate} />

      {result !== null && (
        <Text style={styles.resultText}>Result from Native: {result}</Text>
      )}
    </View>
  );
}
const styles = StyleSheet.create({
  container: { flex: 1, justifyContent: 'center', alignItems: 'center', backgroundColor: '#f5fcff' },
  title: { fontSize: 20, fontWeight: 'bold', marginBottom: 20 },
  input: { width: 200, height: 40, borderColor: 'gray', borderWidth: 1, textAlign: 'center', marginVertical: 10, borderRadius: 5, fontSize: 18 },
  plus: { fontSize: 24, fontWeight: 'bold' },
  resultText: { fontSize: 22, color: 'green', marginTop: 20, fontWeight: '600' },
});

Step 5: Run and Test the App

Boot up your bundler and launch the application on your desired test environments:

To run on Android:

npx react-native run-android

To run on iOS:

npx react-native run-ios

When you enter two numbers and tap the button, the numbers are serialized into a JSON payload, passed asynchronously through the native bridge to the OS threads, processed by the platform language, and safely passed back to update your React state!

📂 Get the Full Source Code

Want to skip the manual file configuration and see the complete working project immediately? I have uploaded the entire sandbox—including both the Java (Android) and Objective-C (iOS) bridge modules alongside the interactive React Native UI—to GitHub.

Feel free to clone it, explore the exact file organization we discussed, and use it as a reference playground for your own practice!

👉 View the Complete JSON Bridge Sandbox on GitHubQuick Start with the Repo:


# Clone the repository
git clone https://github.com
cd react-native-json-bridge-demo

# Install JS dependencies
npm install

# Run on Android
npx react-native run-android

# Run on iOS
cd ios && RCT_NEW_ARCH_ENABLED=0 bundle exec pod install && cd ..
npx react-native run-ios

🚀 Moving to the Future: Building Your First JSI / TurboModule Sandbox

Now that we have mastered how the legacy JSON bridge works, it is time to look forward. In modern React Native (versions 0.76 and newer), the asynchronous JSON bridge is replaced entirely by the JavaScript Interface (JSI).

With JSI, JavaScript references native C++ methods directly in memory. There is no JSON stringification, no message queuing, and execution is entirely synchronous. Instead of "native bridges", we now write Turbo Native Modules.

Step 1: Initialize a Modern JSI-Enabled Project

Unlike our previous playground, we want a framework version where the New Architecture and JSI are turned on by default. We will initialize a project using the latest version.
Run the following command in your terminal:

npx @react-native-community/cli@latest init JsiTurboModuleDemo
cd JsiTurboModuleDemo

Verify New Architecture State

Because we are using the latest version, the JSI engine is active out of the box. Let's verify it:

For Android: Open android/gradle.properties and verify that newArchEnabled=true is set.
For iOS: Run cd ios && bundle exec pod install && cd ... The CLI automatically configures the Fabric and TurboModule native pods.

Step 2: Define the JavaScript Spec (Codegen)

The modern architecture relies on strongly typed interfaces to automatically generate the type-safe C++ binding glue code between JavaScript and native files. This tool is called Codegen.

1. Create the Spec Folder Structure

Inside your root directory, create a folder named specs:

mkdir specs

2. Create the TypeScript Interface

Inside the specs folder, create a file named NativeCalculatorModule.ts. Paste this precise structural template:

import type { TurboModule } from 'react-native';
import { TurboModuleRegistry } from 'react-native';
// 1. Define the interface contract extending TurboModuleexport 
interface Spec extends TurboModule {
    addNumbers(a: number, b: number): number; // 👈 Synchronous execution! Returns a number directly instead of using a callback
}
// 2. Register the module naming convention with the TurboModule provider registry

export default TurboModuleRegistry.getEnforcing<Spec>('NativeCalculatorModule');

💡 Dev Note: Look at addNumbers. Notice that it returns a primitive number synchronously. In the legacy JSON bridge, everything had to be an asynchronous callback. JSI completely alters this rule!

Step 3: Configure package.json for Codegen

We must tell React Native to scan our new specs folder and generate the matching native code layouts during compilation.
Open your root package.json file and look for the "dependencies" block. Add a new configuration key named "codegenConfig" right at the bottom of the JSON object:

  "codegenConfig": {
    "name": "AppSpecs",
    "type": "modules",
    "jsSrcsDir": "specs",
    "android": {
      "javaPackageName": "com.jsiturbomoduledemo.specs"
    }
  }

Step 4: Implement the JSI Module on Android (Kotlin)

With the specification established, let's write our modern addition module using Kotlin.

1. Create the Kotlin Module File

Navigate to android/app/src/main/java/com/jsiturbomoduledemo/ and create a file named CalculatorModule.kt:

package com.jsiturbomoduledemo

import com.facebook.react.bridge.ReactApplicationContext
import com.jsiturbomoduledemo.specs.NativeCalculatorModuleSpec // 👈 Automatically available via Codegen

class CalculatorModule(reactContext: ReactApplicationContext) : NativeCalculatorModuleSpec(reactContext) {

    // Must match the string declared in the TypeScript Spec registry
    override fun getName(): String = NAME

    // Implement the addition method synchronously
    override fun addNumbers(a: Double, b: Double): Double {
        return a + b
    }

    companion object {
        const val NAME = "NativeCalculatorModule"
    }
}

2. Create the Package Registration File

In the same folder directory, create CalculatorPackage.kt:

package com.jsiturbomoduledemo

import com.facebook.react.TurboReactPackage
import com.facebook.react.bridge.NativeModule
import com.facebook.react.bridge.ReactApplicationContext
import com.facebook.react.module.model.ReactModuleInfo
import com.facebook.react.module.model.ReactModuleInfoProvider

class CalculatorPackage : TurboReactPackage() {

    override fun getModule(name: String, reactContext: ReactApplicationContext): NativeModule? {
        return if (name == CalculatorModule.NAME) {
            CalculatorModule(reactContext)
        } else {
            null
        }
    }

    override fun getReactModuleInfoProvider(): ReactModuleInfoProvider {
        return ReactModuleInfoProvider {
            val moduleInfos = HashMap<String, ReactModuleInfo>()
            moduleInfos[CalculatorModule.NAME] = ReactModuleInfo(
                CalculatorModule.NAME,
                CalculatorModule.NAME,
                false, // canOverrideExistingModule
                false, // needsEagerInit
                false, // isCxxModule
                true   // isTurboModule 👈 Tells the runtime this is a JSI module!
            )
            moduleInfos
        }
    }
}

3. Update MainApplication.kt

Open android/app/src/main/java/com/jsiturbomoduledemo/MainApplication.kt and register the package inside your getPackages() list:

        override fun getPackages(): List<ReactPackage> =
            PackageList(this).packages.apply {
              // Packages that cannot be autolinked yet can be added manually here:
              add(CalculatorPackage()) // 👈 Add this line to register your TurboModule
            }

Step 5: Implement the iOS JSI TurboModule (Objective-C++)

On iOS, TurboModule JSI bindings must be implemented in Objective-C++ (.mm) so C++ types can be used for runtime bindings.

1. Create `CalculatorModule.h`

Create ios/JsiTurboModuleDemo/CalculatorModule.h:

#import <Foundation/Foundation.h>
#import <AppSpecs/AppSpecs.h> // Generated by RN Codegen

@interface CalculatorModule : NSObject <NativeCalculatorModuleSpec>
@end

2. Create `CalculatorModule.mm`

Create ios/JsiTurboModuleDemo/CalculatorModule.mm:

#import "CalculatorModule.h"
#import <React/RCTBridgeModule.h>

@implementation CalculatorModule

RCT_EXPORT_MODULE(NativeCalculatorModule)

- (NSNumber *)addNumbers:(double)a b:(double)b
{
  return @(a + b);
}

- (std::shared_ptr<facebook::react::TurboModule>)getTurboModule:(const facebook::react::ObjCTurboModule::InitParams &)params
{
  return std::make_shared<facebook::react::NativeCalculatorModuleSpecJSI>(params);
}

@end

3. Ensure files are in the iOS target

Open ios/JsiTurboModuleDemo.xcworkspace in Xcode and confirm:

CalculatorModule.h and CalculatorModule.mm are added to the project.
CalculatorModule.mm is included in the JsiTurboModuleDemo target’s Compile Sources.

Step 6: Consume the synchronous module in JavaScript

Update App.tsx:

import React, {useState} from 'react';
import {StyleSheet, Text, View, TextInput, Button} from 'react-native';
import NativeCalculatorModule from './specs/NativeCalculatorModule';

export default function App() {
  const [number1, setNumber1] = useState('50');
  const [number2, setNumber2] = useState('25');
  const [result, setResult] = useState<number | null>(null);

  const handleCalculate = () => {
    const num1 = parseFloat(number1) || 0;
    const num2 = parseFloat(number2) || 0;

    // Synchronous TurboModule call over JSI
    const nativeResult = NativeCalculatorModule.addNumbers(num1, num2);
    setResult(nativeResult);
  };

  return (
    <View style={styles.container}>
      <Text style={styles.title}>JSI / TurboModule Calculator</Text>

      <TextInput
        style={styles.input}
        keyboardType="numeric"
        value={number1}
        onChangeText={setNumber1}
      />
      <Text style={styles.plus}>+</Text>
      <TextInput
        style={styles.input}
        keyboardType="numeric"
        value={number2}
        onChangeText={setNumber2}
      />

      <Button title="Calculate instantly via JSI" onPress={handleCalculate} />

      {result !== null && (
        <Text style={styles.resultText}>Instant Result: {result}</Text>
      )}
    </View>
  );
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    justifyContent: 'center',
    alignItems: 'center',
    backgroundColor: '#fff',
    padding: 20,
  },
  title: {
    fontSize: 20,
    fontWeight: 'bold',
    marginBottom: 20,
  },
  input: {
    width: 200,
    height: 40,
    borderColor: 'gray',
    borderWidth: 1,
    textAlign: 'center',
    marginVertical: 10,
    borderRadius: 5,
    fontSize: 18,
  },
  plus: {
    fontSize: 24,
    fontWeight: 'bold',
    marginVertical: 10,
  },
  resultText: {
    fontSize: 22,
    color: 'blue',
    marginTop: 20,
    fontWeight: '600',
  },
});

Step 7: Build and run

From project root:

# iOS (run once after native/codegen changes)
cd ios && pod install && cd ..
npx react-native run-ios

# Android
npx react-native run-android

If iOS build still uses stale artifacts, clean build folder in Xcode and rerun.

📂 Get the Full JSI Source Code

Want to skip the file configurations and explore a fully functional, zero-latency production setup right now? I have published the entire sandbox codebase—featuring the TypeScript spec files, Kotlin (Android) configurations, and Objective-C++ (iOS) native interfaces—to GitHub.

Feel free to clone it, reference the layout files, and use it as your modern, New Architecture practice template!
👉 View the Complete JSI / TurboModule Sandbox on GitHub

Quick Start with the Repo:

Clone the repository

git clone https://github.com
cd react-native-jsi-turbo-module-demo

Install project dependencies

npm install

Run on Android (New Architecture active by default)

npx react-native run-android

Run on iOS (Installs Fabric and TurboModule pods dynamically)

cd ios && bundle exec pod install && cd ..
npx react-native run-ios

⚖️ Summary: Legacy JSON Bridge vs. Modern JSI

To wrap up this evolution timeline, let's look at a direct architectural comparison between what we built in the first playground versus our modern JSI sandbox:

Architectural Feature	Legacy JSON Bridge (Pre-0.76)	Modern JSI / TurboModules (0.76+)
Communication Type	Asynchronous Only (Batched message queues)	Synchronous & Asynchronous (Direct method execution)
Data Overhead	High (JSON stringification and parsing delays)	Zero (Direct sharing of C++ memory reference points)
Type Safety	None (Loose arguments verified manually at runtime)	Guaranteed (Enforced at compile-time via Codegen Specs)
Native Files (iOS)	Standard Objective-C (.m)	Objective-C++ (.mm) required for C++ integration
Native Files (Android)	Java (.java)	Modern Kotlin (.kt) natively integrated
UI Updates	Prone to lag / frame drops on heavy calculations	Fluid, zero-latency execution directly on the UI thread

🏁 Conclusion

Understanding where React Native came from helps you appreciate where it is today. While the legacy JSON bridge was a groundbreaking concept that powered cross-platform apps for nearly a decade, the shift to JSI turns React Native into a truly native-speed engine.
As a mobile developer, mastering both sides of this equation prepares you to support aging enterprise apps while confidently architecting high-performance modern applications.