DEV Community: Subrata Kumar Das

Why I Chose Gemma 4 E2B for Subra AI: The Reality of Running LLMs on Mid-Range Phones

Subrata Kumar Das — Tue, 01 Sep 2026 05:40:44 +0000

Introduction: The Anti-Cloud Philosophy

In an era dominated by server-side APIs, Subra AI was built to prove a point: you can have a highly intelligent, ChatGPT-like assistant that lives entirely on your device. No account creation, no external server handshakes, and absolute data privacy.

To pull off this architectural high-wire act across consumer hardware like iPhones, Android devices, and Desktop computers, I needed a model that was fiercely resource-efficient yet multi-modally competent. Enter Google DeepMind’s Gemma 4 E2B.

Reason 1: The "E" Factor — Punching Way Above Its Weight Budget

The "E" in E2B stands for Effective Parameters.

The Architecture: Gemma 4 E2B uses Per-Layer Embeddings (PLE). Instead of bloating the model with deeper layers, PLE gives each decoder layer its own tiny lookup embedding table for every token.
The Benefit for Subra AI: It behaves with the semantic logic and reasoning depth of a 4B or 5B parameter model, but only executes 2.3 billion active parameters during generation. It’s the ultimate "cheat code" for getting dense intelligence inside a strict mobile sandboxed footprint.

Reason 2: Defeating the Mobile RAM Monster (1.5GB Threshold)

When executing models locally via Google LiteRT-LM (formerly MediaPipe), the biggest enemy isn't processing speed—it is operating system Out-Of-Memory (OOM) crashes.

Mid-range Android phones and older iOS devices will ruthlessly kill background tasks or heavy applications consuming over 2 GB of volatile memory.
By deploying a 4-bit quantized version of Gemma 4 E2B, Subra AI runs comfortably with a baseline memory footprint of roughly 1.2 GB to 1.5 GB of RAM. This leaves plenty of headroom for the React Native engine and OS stability.

Reason 3: Native Multimodality for Real-World Vision Checkups

A core feature of Subra AI is its ability to parse real-world data locally, such as scanning healthcare device readouts (blood pressure monitors or scales) and formatting them into structured JSON.

Older open-weight models required external, bulky vision adapter encoders bolted onto the LLM.
Gemma 4 E2B handles native image inputs natively. This tight integration keeps latency incredibly low, allowing Subra AI to instantly handle OCR, object detection, and document parsing on-device without crashing the phone's GPU/NPU cache.

Reason 4: Developer-Friendly Ecosystem Integration

Building cross-platform apps requires tools that match the target environment. Google built Gemma 4 to natively integrate with Google AI Edge SDK / LiteRT. This means:

No messy custom C++ inference wrapper debugging for Android.
Seamless optimization on Apple Silicon execution lines.
Native support for a 128K context window and strict system prompts. This allowed me to safely instruct Subra AI to act as a personal assistant without losing track of multi-turn chat history.

Conclusion: Why E2B Wins for the Edge

Could I have used the larger Gemma 4 E4B or a 7B alternative? Yes, but at the cost of high battery drain, slower tokens-per-second, and alienation of users with mid-range phones.

Choosing Gemma 4 E2B was a calculated engineering choice: it gave Subra AI the exact blend of low-latency execution, native vision capture, and a manageable RAM footprint needed to build a premium, sovereign AI product.

Giving the AI Assisted Job Search a Local Brain

Subrata Kumar Das — Fri, 28 Aug 2026 08:32:47 +0000

The next chapter in building an open-source, AI-assisted international job-search platform.

This is the second article in the JobSearch series. In Part 1, I introduced the problem, the product direction, and the first foundations of the platform. This chapter is about what happened next: turning those foundations into a usable search journey and making local AI a first-class option.

Repository: github.com/subraatakumar/job-search

The job search begins with a question

Imagine opening a job-search application after a long day.

You have a resume in one tab, a spreadsheet in another, saved searches scattered across several job boards, and a growing list of questions:

Is this role actually relevant to me?
Does the company support international candidates?
Is the listing still active?
Which version of my experience should I highlight?
Should I spend an hour applying to this role or move on?

The first version of JobSearch was mostly about building the room: authentication, profiles, resume extraction, preferences, and a protected dashboard. This next version starts furnishing that room.

The product is becoming a workspace where a candidate can describe what they are looking for, search across public sources, inspect the results, and eventually move from discovery to preparation without losing the thread.

That last part matters. Job searching is not just retrieval. It is a sequence of decisions. The application should help people make better decisions, not make hundreds of noisy applications on their behalf.

From onboarding to a real workspace

The onboarding path now has a clearer shape:

Profile → Job search preferences → AI provider → Search jobs

The user can import a text-based PDF resume, review the extracted information, describe countries and roles of interest, choose an AI provider, and arrive at the dashboard search workspace.

The final step is intentionally a dashboard rather than an unrelated jobs page. It is the place where the user’s profile, preferences, search conversation, filters, and future application workflow can meet.

This is a small product decision with a large effect: the interface should follow the user’s mental model. After configuring the assistant, the next thing a person expects is to use it.

Why local AI belongs in this project

Resumes and job preferences are personal. They contain employment history, skills, locations, contact details, and sometimes sensitive career decisions.

Some users want the quality and convenience of a hosted model. Others want control over where their data goes. Some are experimenting, learning, or working with limited budgets. A single provider assumption would exclude too many of them.

That is why JobSearch uses an OpenAI-compatible provider abstraction. The application can speak the same general API shape while allowing the model to live in different places:

Hosted provider
       or
Local Ollama model
       or
Another compatible server
              ↓
      JobSearch AI adapter
              ↓
     Search, ranking, and preparation

The provider is explicit and configurable. API keys are stored server-side and encrypted with AES-256-GCM; they are never returned to the browser. Local Ollama users can leave the API key blank.

This is not a claim that local models are always better. They can be slower, require more memory, and vary in quality. The point is choice. Privacy, cost, performance, and model quality are trade-offs that should belong to the user.

Running Ollama locally

Ollama makes it practical to run an AI model on your own machine. After installing it from ollama.com/download, start the service and download a model:

ollama serve
ollama pull llama3.2
ollama list

Then start JobSearch with Docker, open /settings, and enter:

Setting	Value
Provider	`Ollama (local)`
Model name	`llama3.2`
API endpoint with Docker	`http://host.docker.internal:11434/v1`
API endpoint without Docker	`http://localhost:11434/v1`
API key	Leave blank

The host.docker.internal detail is important. When the web application runs inside Docker, localhost means the container, not the host computer where Ollama is running. The host gateway lets the container reach the local Ollama service.

After saving the provider, JobSearch takes the user to the dashboard search workspace. The model is now available for the parts of the workflow that need AI assistance.

Searching is more than calling an endpoint

The current search direction combines several responsibilities:

Accept a natural-language request such as “senior React Native roles in Germany with visa support.”
Discover candidate links from configured public sources and web search infrastructure.
Verify individual pages where possible.
Normalize titles, companies, locations, and URLs.
Deduplicate the results.
Optionally rank them against the user’s profile.
Present evidence and useful explanations instead of a mysterious score.

That pipeline is deliberately server-side. The browser should be the place where users ask questions and review results, not the place where secrets, source orchestration, or provider credentials are exposed.

The search interface also shows progress while discovery, source checking, verification, and ranking happen. This is more honest than displaying a spinner and pretending that every result has the same level of confidence.

A privacy boundary, not just a feature list

Open-source AI projects often focus on what the model can generate. JobSearch also needs to be clear about what it will not do.

The project is designed around public job information and user control. It does not collect passwords or cookies for gated platforms. It does not aim to bypass CAPTCHAs. It does not silently auto-apply to jobs. It should not fabricate qualifications, sponsorship evidence, or application claims.

The intended workflow is:

Find an opportunity
        ↓
Understand the evidence and fit
        ↓
Improve the application with assistance
        ↓
Review everything yourself
        ↓
Choose whether to apply

That human review step is not a temporary limitation. It is part of the product philosophy.

What is working now

The repository currently includes:

Dockerized local development with PostgreSQL
OAuth and PKCE authentication through the central Auth service
Profile onboarding and review-first PDF resume extraction
Multi-country search preferences with role, sponsorship, and frequency settings
Hosted and local OpenAI-compatible AI provider configuration
Encrypted server-side provider-key storage
User and admin-managed public job sources
Initial source refresh and job normalization
Server-side web search orchestration with optional AI ranking
A dashboard workspace for searching and reviewing opportunities

This is still an early MVP. Some visible features are foundations rather than finished products. Search history, saved-job persistence, richer matching, and application preparation are active areas for improvement.

What comes next

The next chapters will move from “find jobs” toward “understand and act.” The roadmap includes:

More reliable extraction from JavaScript-heavy career pages
General web discovery through OpenSERP or another interchangeable provider
Resume-to-job matching with transparent reasons
Visa-sponsorship evidence and confidence indicators
Tailored resume and cover-letter preparation
Interview questions and practice based on a selected role
Application status, reminders, and follow-up dates
Scheduled searches and digest notifications
More automated tests and evaluation datasets

The order may change. Real user feedback should influence it.

An invitation to build the next chapter

JobSearch is intentionally open source because the job-search experience is different across countries, professions, industries, and career stages. One person may need sponsorship evidence. Another may need accessibility improvements. Someone else may know the best public career sources for a region that the project has not considered yet.

You do not need to arrive with a large pull request. Contributions can be:

Trying the local setup and reporting friction
Suggesting a feature or a better onboarding flow
Improving documentation
Adding accessibility or responsive UI improvements
Building a public-source connector
Improving resume parsing or search evaluation
Reviewing privacy and security decisions
Testing Ollama with different models
Helping define what “job fit” should mean in practice

Please start with the repository’s CONTRIBUTING.md, and open an issue for a substantial feature so the design can be discussed before implementation. Feature suggestions are especially welcome when they describe the user problem, not only the proposed button or endpoint.

Stay for the next update

The first article introduced the idea. This chapter gave the idea a local brain and a clearer destination: a search workspace that respects the person using it.

The next update will focus on making results more trustworthy and useful—better source handling, stronger matching explanations, and the first steps toward turning a job listing into a tailored preparation plan.

If you are searching internationally, building developer tools, interested in local AI, or simply curious about open-source product development, follow along. Try the project, tell me where the experience breaks, suggest what should be built next, and help shape the tool before the roadmap is set in stone.

The best version of JobSearch will not come from one person guessing what everyone needs. It will come from people bringing their own job-search stories to the project.

JobSearch is released under the MIT License. Please review the project’s security guidance before reporting sensitive issues or contributing integrations that handle personal data.

Building an Open-Source AI-Assisted International Job Search Platform

Subrata Kumar Das — Tue, 25 Aug 2026 07:08:17 +0000

Finding a job in another country is more complicated than searching for a job title.

Candidates often need to understand:

Whether the company supports visa sponsorship
Whether the role matches their actual experience
How to tailor their resume
How to write a relevant cover letter
How to prepare for the interview
How to track applications and follow-ups
Which opportunities are still active and trustworthy

I’m building an open-source project called JobSearch to bring these activities into one workspace.

GitHub repository:

https://github.com/subraatakumar/job-search

The project is still in its early MVP stage, but the initial Docker setup, authentication, resume import, and profile workflow are working.

The product idea

JobSearch is designed for people applying internationally.

For example, a user in India might want to search for:

Software engineering roles in Germany
Companies that may support visa sponsorship
Remote or relocation-friendly positions
Jobs matching a specific technology stack
Roles at a particular seniority level

The long-term workflow is:

Discover jobs
    ↓
Evaluate role and sponsorship fit
    ↓
Prepare a tailored application
    ↓
Practice for the interview
    ↓
Track the application
    ↓
Improve based on outcomes

The goal is not to automatically apply to hundreds of jobs. The goal is to help candidates make better, more informed applications while keeping the user in control.

Current MVP scope

The first version focuses on building a trustworthy foundation.

Currently implemented:

Next.js and TypeScript application
Dockerized local development
PostgreSQL container
Central authentication using OAuth and PKCE
Protected dashboard
Text-based PDF resume upload
Server-side resume text extraction
Review-first profile workflow
Responsive landing page
Open-source contributor setup script
Separate local and production-like Docker modes

Planned features include:

Structured profile fields
Public job API integrations
Company career page imports
User-provided job URL imports
Visa sponsorship evidence and confidence indicators
Job matching
Tailored resumes
Job-specific cover letters
Interview questions and practice answers
Application status tracking
Reminders and follow-up dates
OpenAI-compatible AI providers
Local Ollama support

Why open source?

There are several reasons for making this project open source.

First, job-search data is personal and sensitive. Users should be able to understand where their data goes and how the application works.

Second, different users will want different AI providers. Some may prefer a hosted provider, while others may want to run a local model through Ollama.

Third, job sources vary by country. A community can help add lawful, documented integrations for different regions without tightly coupling the core application to a single provider.

The project is released under the MIT License.

Technical architecture

The current architecture is intentionally simple:

Browser
   ↓
Next.js application
   ↓
PostgreSQL
   ↓
AI provider adapter

The application will eventually include a background worker for scheduled searches:

Scheduler
   ↓
Job source connectors
   ↓
Normalization and deduplication
   ↓
Job database
   ↓
User notifications and matching

The planned technology stack is:

Next.js
React
TypeScript
PostgreSQL
Docker Compose
OAuth with PKCE
OpenAI-compatible AI provider interface
Optional local Ollama endpoint
Background scheduler and worker

Reusing a central authentication service

The project uses an existing central authentication service based on Better Auth.

The authentication service provides:

Google sign-in
OAuth authorization-code flow
PKCE
Central user identity
Product-specific OAuth clients
Separate product-local sessions

The JobSearch application does not directly share authentication cookies or the authentication database.

The flow is:

JobSearch
   ↓
Redirect to central Auth service
   ↓
User signs in
   ↓
Auth redirects back with an authorization code
   ↓
JobSearch exchanges the code using PKCE
   ↓
JobSearch creates its own local session

This keeps the authentication boundary clear and allows other applications to reuse the same identity service without sharing application data.

Running the project locally

The project is designed to be easy to run with Docker.

Requirements:

Docker Desktop
curl
Node.js 22 or newer for non-Docker development

Clone the repository:

git clone https://github.com/subraatakumar/job-search.git
cd job-search

Create the local environment file:

cp .env.example .env

Set a strong session secret in .env, then run:

./re-run-local.sh

The local services are available at:

JobSearch:  http://localhost:3020
Dashboard:  http://localhost:3020/dashboard
Profile:    http://localhost:3020/profile
PostgreSQL: localhost:5433

To stop the services:

docker compose down

The normal shutdown command does not delete the PostgreSQL volume.

Production-like local mode

The project also includes a separate production-like mode:

cp .env.prod.example .env.prod

Configure the production values and run:

./re-run-local.sh prod

This mode uses:

JobSearch:  http://localhost:3021
PostgreSQL: localhost:5434

A Cloudflare Tunnel can route:

jobs.example.com → http://localhost:3021

Local and production-like modes use separate Compose projects and separate database volumes.

Resume import

The first version supports text-based PDF resumes.

The workflow is:

Upload PDF
    ↓
Extract text
    ↓
Create draft profile
    ↓
User reviews the information
    ↓
Confirm the master profile

The application does not yet treat extracted text as confirmed truth.

This is important because resume parsing can produce errors. A parser might misunderstand:

Dates
Job titles
Company names
Technologies
Education details
Links
Formatting and section boundaries

The user must review the extracted information before it can be used to generate an application.

Scanned or image-only PDF files are not supported in the MVP. OCR is planned for a future version after evaluating:

Accuracy
Privacy
Processing cost
Multilingual resume support
Layout complexity

AI provider flexibility

The project is designed to support OpenAI-compatible endpoints.

The long-term goal is to let users configure:

Hosted AI providers
OpenAI-compatible APIs
Local Ollama endpoints
Other compatible model servers

This is important because users have different requirements around:

Privacy
Cost
Performance
Model quality
Data residency
Offline usage

The application should never silently send a user's resume or profile data to an AI provider. Provider configuration and consent must be explicit.

Privacy and safety decisions

The project handles sensitive information, including:

Resumes
Contact details
Employment history
Education
Application notes
Interview preparation
Job-search preferences

Important design principles include:

Never commit secrets or personal data
Do not store API keys in browser code
Do not log access tokens or session cookies
Do not fabricate user qualifications
Keep generated documents linked to their source job
Require user review before application submission
Provide data export and deletion capabilities
Preserve source evidence for job information where possible

The project will not implement:

Cookie extraction
CAPTCHA bypassing
Credential theft
Unauthorized scraping
Automated applications against platforms that prohibit automation

Job sources should use official APIs, permitted feeds, company career pages, user-provided URLs, or other lawful methods.

Current UI

The landing page explains the product workflow and includes:

International job-search positioning
Resume and profile setup
AI-assisted application preparation
Interview preparation
Application tracking
Local and hosted AI provider support
Open-source project access

The profile page includes a drag-and-drop PDF upload area and extracted resume preview.

The UI is being polished screen by screen instead of waiting for a large redesign at the end. This allows the product to remain usable while the underlying features are developed.

What I’m looking for

I would especially welcome feedback on:

Which job sources should be supported first?
How should visa sponsorship evidence be displayed?
What profile information is essential for international job matching?
What should the first job-search dashboard include?
Which AI providers should be supported first?
Should the app remain local-first, or become a hosted multi-user platform?
What would make this useful for your own job search?

Contributing

Contributions are welcome.

Before contributing, please read:

CONTRIBUTING.md
SECURITY.md
CODE_OF_CONDUCT.md

The project is still early, so useful contributions may include:

UI improvements
Accessibility fixes
Resume parsing improvements
Job-source connectors
Database design
AI provider adapters
Testing
Documentation
Privacy and security reviews
Product feedback

Please keep pull requests focused and include testing or verification steps.

Final thoughts

International job searching is often fragmented across job boards, spreadsheets, documents, notes, and interview preparation tools.

JobSearch is an attempt to bring those activities together while keeping the user in control of their data and AI provider.

The project is early, but the foundation is now in place:

It runs locally with Docker
Authentication works
The dashboard is protected
Resume text extraction works
The project is publicly documented
The repository is open source

If this problem interests you, I would love feedback, ideas, issues, and contributions.

GitHub:

https://github.com/subraatakumar/job-search

Subra AI: Private Offline On-Device AI

Subrata Kumar Das — Fri, 24 Jul 2026 12:39:23 +0000

Synchronous TurboModules Are Not Automatically Fast

Subrata Kumar Das — Wed, 15 Jul 2026 05:14:04 +0000

React Native’s New Architecture gives JavaScript more direct access to native functionality.

One important capability is synchronous communication through TurboModules.

That can be useful.

It can also introduce a performance problem that is easy to miss:

A native method being synchronous does not mean the native work is fast.

The communication mechanism may be efficient, but the JavaScript thread must still wait for the native operation to finish.

That difference matters in production applications.

The misleading simplicity of a synchronous API

Consider a native method exposed like this:

const token = SecureStorage.getAccessToken();

From the JavaScript side, it looks harmless.

There is no await, no callback and no visible asynchronous workflow.

The value is returned immediately from the developer’s point of view.

But the native implementation may perform several operations before returning:

access Android Keystore or iOS Keychain
decrypt stored data
read from disk
parse JSON
convert native objects into JavaScript-compatible values
communicate with another system service

If this work takes time, JavaScript cannot continue until the method returns.

The API looks simple.

The execution may not be.

What synchronous actually means

A synchronous call means the caller waits for the result.

For example:

const result = NativeModule.getValue();

renderScreen(result);

renderScreen cannot begin until getValue() finishes.

That behaviour is acceptable when the native operation is extremely small and predictable.

It becomes dangerous when the operation has variable latency.

The same method may take:

less than one millisecond when data is cached
several milliseconds when data requires conversion
much longer when storage, cryptography or system services are involved

The JavaScript thread does not care why the native method is delayed.

It simply remains blocked.

Why this affects React Native performance

React Native applications perform important work on the JavaScript thread.

This can include:

processing state updates
running application logic
handling user interactions
preparing React renders
coordinating navigation
executing animation-related JavaScript
responding to events from native modules

When a synchronous native method blocks that thread, other JavaScript work must wait.

A single call may not create an obvious problem.

Repeated calls can.

Imagine that a component reads a secure value during rendering:

function AccountScreen() {
  const token = SecureStorage.getAccessToken();

  return <AccountDetails token={token} />;
}

Now imagine that the component renders multiple times during navigation or state updates.

Every render may trigger another native operation.

If the method accesses storage and performs decryption, the application is repeatedly blocking the JavaScript thread inside the render path.

The visible result may be:

slow navigation
delayed button responses
dropped animation frames
inconsistent screen transitions
temporary UI freezes
performance that becomes worse on lower-end devices

The developer may initially investigate React re-renders.

The real problem is the synchronous native work performed during those renders.

TurboModules reduce overhead, not execution cost

This is the central distinction.

TurboModules improve how JavaScript and native code communicate.

They can reduce some of the overhead associated with the older bridge architecture.

But TurboModules do not make the native operation itself free.

Suppose a native method performs three tasks:

Read secure storage
        ↓
Decrypt the value
        ↓
Convert it into a JavaScript object

The communication layer may be efficient.

The application must still pay for:

storage access
cryptographic processing
object allocation
data conversion
thread coordination

Optimising the path between JavaScript and native code does not eliminate the work happening at the destination.

A faster doorway does not make the room behind it smaller.

When synchronous native methods are appropriate

Synchronous methods are useful when the operation is:

tiny
deterministic
memory-resident
frequently required
guaranteed not to perform slow I/O
predictable across supported devices

Examples may include reading a cached capability:

const supportsBiometrics = DeviceCapabilities.hasBiometricHardware();

Or checking a native constant:

const environment = AppConfiguration.getEnvironment();

Or performing a very small calculation:

const pixels = DisplayUtils.dpToPixels(16);

These operations are generally suitable only when their native implementation remains lightweight.

The important question is not whether the return type is small.

The important question is how the value is produced.

Returning one boolean can still be expensive if the implementation queries a system service every time.

Operations that should usually remain asynchronous

Native methods should normally be asynchronous when they involve:

Storage

const profile = await SecureStorage.getProfile();

Disk and secure-storage access may have unpredictable latency.

Cryptography

const decryptedPayload = await CryptoModule.decrypt(payload);

Cryptographic work can become expensive depending on the algorithm and input size.

Networking

const response = await NativeNetworkClient.fetchConfiguration();

Network operations are naturally unpredictable and should never block JavaScript synchronously.

Large data conversion

const records = await NativeDatabase.getRecords();

Converting thousands of native records into JavaScript objects can consume considerable time.

Image and file processing

const result = await ImageProcessor.compress(filePath);

Media processing is computationally expensive and should normally run away from latency-sensitive application work.

System services

const location = await LocationModule.getCurrentPosition();

The response time may depend on permissions, sensors, device state and operating-system behaviour.

Avoid synchronous work inside rendering

One of the strongest review rules is:

Do not perform synchronous native work inside a React render path unless the operation is proven to be trivial.

This is risky:

function Dashboard() {
  const settings = NativeSettings.getSettings();

  return <DashboardContent settings={settings} />;
}

A better design is to load the value asynchronously and store it in application state:

function Dashboard() {
  const [settings, setSettings] = useState<Settings | null>(null);

  useEffect(() => {
    let active = true;

    async function loadSettings() {
      const value = await NativeSettings.getSettings();

      if (active) {
        setSettings(value);
      }
    }

    loadSettings();

    return () => {
      active = false;
    };
  }, []);

  if (!settings) {
    return <LoadingScreen />;
  }

  return <DashboardContent settings={settings} />;
}

The exact state-management approach may differ.

The principle remains the same:

Do not make rendering wait for native storage, cryptography or system resources.

Cache deliberately, not accidentally

Sometimes a synchronous API is created because the application needs immediate access to a value.

The safer solution may be to load the value earlier and maintain an in-memory cache.

For example:

class SessionStore {
  private token: string | null = null;

  async initialise(): Promise<void> {
    this.token = await SecureStorage.getAccessToken();
  }

  getCachedToken(): string | null {
    return this.token;
  }
}

The native storage operation remains asynchronous:

await sessionStore.initialise();

Later reads are synchronous because they access application memory:

const token = sessionStore.getCachedToken();

This creates a meaningful distinction:

loading from storage is asynchronous
reading an already-loaded value is synchronous

That is much safer than hiding storage access behind a synchronous API.

However, caching introduces its own responsibilities:

cache invalidation
logout handling
token refresh
memory lifecycle
multi-process consistency
protection of sensitive values

The goal is not to make everything synchronous.

The goal is to place expensive work outside latency-sensitive paths.

Measure the whole native method

A common performance mistake is to measure only JavaScript execution.

For example:

const start = performance.now();

const token = SecureStorage.getAccessToken();

console.log(`Completed in ${performance.now() - start} ms`);

This can reveal blocking time from the JavaScript side.

But deeper investigation may require native instrumentation.

On Android, developers can measure sections using native timing tools or platform profilers.

On iOS, Instruments can help identify time spent in storage, cryptography, object conversion and thread blocking.

The useful questions are:

How long does the method take on average?
What is the worst observed latency?
Does the duration change when the value is not cached?
Does the method perform disk access?
Does it allocate or convert large objects?
Is it called during rendering or navigation?
How many times is it called during one user action?
How does it behave on lower-end devices?

Average timing alone is not enough.

A method that normally completes quickly but occasionally blocks for 40 milliseconds can still create visible UI problems.

Watch for repeated synchronous calls

The cost of one method call may appear acceptable.

The call frequency may be the actual problem.

Consider:

items.map(item => NativeFormatter.format(item));

If there are 500 items, the application performs 500 synchronous native calls.

Even if each call takes only a fraction of a millisecond, the combined cost can become significant.

A stronger native API might process the entire collection:

const formattedItems = await NativeFormatter.formatBatch(items);

This can reduce:

repeated boundary crossings
repeated allocations
thread coordination
per-call conversion overhead

Batching is especially useful when working with:

database rows
image metadata
sensor records
BLE data
file lists
cryptographic operations
large arrays produced by native SDKs

The correct API shape often matters as much as the implementation.

Synchronous methods create architectural coupling

There is another risk beyond immediate performance.

A synchronous API can become slow later.

Version one may return an in-memory value:

getUserRegion(): string;

A future requirement may change the implementation:

read the region from encrypted storage
migrate an old value
consult remote configuration
query a native SDK
support multiple user profiles

The JavaScript interface remains synchronous, but the native responsibility has become heavier.

Now the team faces a difficult choice:

keep blocking JavaScript
introduce hidden caching
change the public API
maintain both synchronous and asynchronous versions

For values likely to require I/O in the future, starting with an asynchronous contract is often safer.

API design should consider how the operation may evolve, not only how it works today.

A practical decision rule

Before exposing a synchronous TurboModule method, ask:

Can this method always complete quickly without storage, networking, cryptography, large conversion or unpredictable system work?

If the answer is uncertain, use an asynchronous API.

A useful classification is:

Suitable for synchronous execution

constants
cached primitives
tiny calculations
in-memory flags
deterministic capability checks

Better suited for asynchronous execution

file access
secure storage
databases
networking
encryption and decryption
compression
image processing
large data conversion
hardware interaction
operating-system services

The method’s name is not enough.

Review the complete native execution path.

Code-review checklist

When reviewing a synchronous TurboModule method, check:

Does it perform disk or secure-storage access?
Does it call another SDK or system service?
Does it perform cryptography?
Can it return a large object or array?
Does it parse or serialise data?
Can its latency change based on device state?
Is it called during rendering?
Is it called repeatedly inside a loop?
Is the result already available in memory?
Could the method become more expensive later?

One concerning answer may be enough to reconsider the synchronous design.

Final takeaway

TurboModules can improve React Native’s native integration model.

They make direct and synchronous interactions possible where appropriate.

But capability should not become default behaviour.

The safest rule is:

Use synchronous native methods only for tiny, predictable and memory-resident operations.

Keep storage, cryptography, networking, large data processing and unpredictable system work asynchronous.

TurboModules reduce communication overhead.

They do not remove the cost of native execution.

Where have you seen a synchronous native method create unexpected UI latency in a React Native application?

Type Safety Stops at Runtime Boundaries in React Native

Subrata Kumar Das — Mon, 13 Jul 2026 14:31:13 +0000

TypeScript can make a React Native codebase safer.

It can catch missing properties, incorrect function arguments, invalid component props and many other mistakes before the application runs.

But TypeScript has one important limitation:

It cannot verify whether external data actually matches the type you assigned to it.

This becomes especially important in React Native because application data often crosses multiple runtime boundaries.

A value may come from:

a native Android module
an iOS native module
an API response
persisted storage
a deep link
remote configuration
an analytics SDK
an AI-generated JSON response

At each of these boundaries, the actual runtime value may differ from the TypeScript definition.

And TypeScript may not warn you.

A simple example

Assume a React Native application receives battery information from a native module.

type BatteryStatus = {
  level: number;
  isCharging: boolean;
};

The JavaScript layer expects a value like this:

const batteryStatus: BatteryStatus = {
  level: 82,
  isCharging: true,
};

This looks safe.

The level field is a number.

The isCharging field is a boolean.

Now imagine that the Android implementation changes and returns this instead:

{
  level: "82",
  isCharging: true
}

The level value is now a string.

At runtime, JavaScript receives:

typeof batteryStatus.level === "string";

But TypeScript may still believe that level is a number.

How can that happen?

Because the result may have been cast.

const batteryStatus =
  NativeModules.BatteryModule.getStatus() as BatteryStatus;

The cast tells TypeScript:

Trust me. This value is a BatteryStatus.

TypeScript accepts that instruction.

It does not inspect the Android or iOS runtime value.

Casting is not validation

This distinction is important.

A type cast changes what TypeScript believes.

It does not change or verify the actual value.

Consider this example:

const value = "82" as unknown as number;

TypeScript may allow the code.

But the runtime value is still a string.

console.log(typeof value);
// string

This is why the following assumption is dangerous:

const response = externalValue as ExpectedType;

The code may compile successfully while the application remains unsafe.

A better mental model is:

Casting changes the compiler's understanding. Validation checks reality.

Where the failure appears

Boundary problems do not always fail immediately.

That is one reason they can be difficult to diagnose.

The application may receive the incorrect value on one screen, store it in state and fail much later.

For example:

const nextLevel = batteryStatus.level + 10;

If level is a number:

82 + 10;
// 92

If level is a string:

"82" + 10;
// "8210"

The app may not crash.

It may simply produce the wrong result.

That is often worse because the problem can remain hidden.

The value may also fail during:

numeric comparisons
sorting
formatting
progress calculations
conditional rendering
database queries
analytics processing
business-rule evaluation

For example:

if (batteryStatus.level < 20) {
  showLowBatteryWarning();
}

JavaScript may coerce the value and produce a result.

But relying on implicit coercion makes application behaviour fragile.

Compile-time trust should stop at runtime boundaries

Inside a properly typed TypeScript system, values can usually be trusted.

For example:

function showBatteryStatus(status: BatteryStatus) {
  console.log(status.level);
}

If every caller passes a real BatteryStatus, the function is safe.

The problem begins when a value enters the system from outside.

That value has not been created or verified by TypeScript.

Therefore, the safer rule is:

Treat external values as unknown until they have been validated.

Instead of this:

const status =
  NativeModules.BatteryModule.getStatus() as BatteryStatus;

Prefer this:

const status: unknown =
  await NativeModules.BatteryModule.getStatus();

Now the application is forced to prove that the value is safe before using it.

Why `unknown` is better than `any`

Many boundary values are typed as any.

const response: any = await fetchBatteryStatus();

This removes most type protection.

You can access anything:

response.level;
response.invalidProperty;
response.anythingAtAll;

TypeScript will not stop you.

unknown behaves differently.

const response: unknown = await fetchBatteryStatus();

You cannot safely access its properties until you narrow the type.

response.level;
// TypeScript error

This may initially feel inconvenient.

But that inconvenience is useful.

It forces the code to validate the runtime value.

Manual runtime validation

A simple type guard can validate the native response.

type BatteryStatus = {
  level: number;
  isCharging: boolean;
};

function isBatteryStatus(value: unknown): value is BatteryStatus {
  if (typeof value !== "object" || value === null) {
    return false;
  }

  const candidate = value as Record<string, unknown>;

  return (
    typeof candidate.level === "number" &&
    typeof candidate.isCharging === "boolean"
  );
}

Now the boundary can be handled safely.

const rawStatus: unknown =
  await NativeModules.BatteryModule.getStatus();

if (!isBatteryStatus(rawStatus)) {
  throw new Error("Invalid battery status returned by native module");
}

const status: BatteryStatus = rawStatus;

console.log(status.level);

After the validation succeeds, TypeScript knows that rawStatus is a valid BatteryStatus.

This is a safe conversion from an untrusted value into a trusted application type.

Validate business rules, not only field types

Checking whether level is a number may not be enough.

The value may still be invalid.

{
  level: 400,
  isCharging: true
}

The shape is correct.

But a battery percentage of 400 is not valid.

A stronger validator should also verify allowed ranges.

function isBatteryStatus(value: unknown): value is BatteryStatus {
  if (typeof value !== "object" || value === null) {
    return false;
  }

  const candidate = value as Record<string, unknown>;

  return (
    typeof candidate.level === "number" &&
    candidate.level >= 0 &&
    candidate.level <= 100 &&
    typeof candidate.isCharging === "boolean"
  );
}

Runtime validation may need to check:

required fields
primitive types
allowed ranges
enum values
string formats
nested object shapes
array item types
mutually exclusive states
domain-specific rules

A structurally correct object can still be invalid for the application.

Using a schema validation library

Manual validation works well for small objects.

For larger payloads, a schema library can make the code easier to maintain.

A common approach is to define a schema and derive the TypeScript type from it.

For example, using Zod:

import { z } from "zod";

const BatteryStatusSchema = z.object({
  level: z.number().min(0).max(100),
  isCharging: z.boolean(),
});

type BatteryStatus = z.infer<typeof BatteryStatusSchema>;

The external value can then be parsed.

const rawStatus: unknown =
  await NativeModules.BatteryModule.getStatus();

const result = BatteryStatusSchema.safeParse(rawStatus);

if (!result.success) {
  console.error(result.error);
  throw new Error("Invalid battery status");
}

const status = result.data;

The important part is not the specific library.

The important part is the boundary discipline:

Receive untrusted data.
Validate it.
Convert it into a trusted type.
Use it inside the application.

Runtime boundaries in React Native

React Native applications contain more boundaries than many teams realise.

1. Native modules

Native modules may return different types across Android and iOS.

For example:

Android returns an integer
iOS returns a floating-point number
one platform returns null
the other platform omits the field
a native SDK returns a string representation

Generated TurboModule specifications can improve contract safety, but runtime validation may still be useful when data originates from external native SDKs, persisted native state or platform APIs.

2. Network responses

An API client may declare a generic response type:

const response = await api.get<User>("/user");

This does not guarantee that the server returned a valid User.

It only tells TypeScript how the code intends to use the response.

The backend may return:

{
  "id": "123",
  "age": "42"
}

while the application expects:

type User = {
  id: string;
  age: number;
};

API types are expectations until runtime validation confirms them.

3. Persisted storage

Data stored in AsyncStorage, MMKV, SQLite or another persistence layer can become stale.

The application model may change between releases.

An older app version may have saved:

{
  "theme": "dark"
}

A newer version may expect:

type Settings = {
  theme: "light" | "dark";
  fontScale: number;
};

Reading stored JSON and casting it directly can create hidden problems.

const settings =
  JSON.parse(storedValue) as Settings;

Parsing confirms only that the value is valid JSON.

It does not confirm that it matches Settings.

4. Deep links

Deep-link parameters are external input.

A link may contain missing, malformed or unexpected values.

myapp://payment?amount=abc

The application should not assume that amount is a valid number merely because the navigation type expects one.

5. Remote configuration

Remote configuration can change without an application release.

A field that was previously boolean may accidentally be configured as a string.

{
  "newCheckoutEnabled": "true"
}

Without validation, the application may treat a non-empty string as truthy and enable behaviour unexpectedly.

6. AI-generated structured output

AI-generated JSON should always be treated as untrusted.

Even when a model is instructed to follow a specific schema, it may:

omit required fields
return additional fields
use incorrect enum values
produce malformed JSON
return numbers as strings
generate semantically invalid combinations

For example:

{
  "priority": "extremely_urgent",
  "retryCount": "-3"
}

The response may look structured while still violating the application contract.

AI output requires both structural validation and business-rule validation.

Validate once at the edge

Runtime validation should not be scattered throughout the entire application.

That creates repetitive and inconsistent checks.

A stronger architecture validates values at the edge.

async function getBatteryStatus(): Promise<BatteryStatus> {
  const rawStatus: unknown =
    await NativeModules.BatteryModule.getStatus();

  return BatteryStatusSchema.parse(rawStatus);
}

The rest of the application can now depend on the trusted function.

const status = await getBatteryStatus();

renderBatteryLevel(status.level);

This gives the codebase a clear separation:

Untrusted external data
        ↓
Boundary validation
        ↓
Trusted application model
        ↓
Business logic and UI

The validation cost is paid once.

The trusted type can then flow safely through the internal system.

Parse, do not merely check

In some cases, the application may intentionally transform external data.

Suppose the native module returns:

{
  level: "82",
  isCharging: true
}

The application may decide that numeric strings are acceptable.

Instead of rejecting the value, the boundary parser can normalise it.

function parseBatteryStatus(value: unknown): BatteryStatus {
  if (typeof value !== "object" || value === null) {
    throw new Error("Battery status must be an object");
  }

  const candidate = value as Record<string, unknown>;

  const level =
    typeof candidate.level === "string"
      ? Number(candidate.level)
      : candidate.level;

  if (
    typeof level !== "number" ||
    Number.isNaN(level) ||
    level < 0 ||
    level > 100
  ) {
    throw new Error("Invalid battery level");
  }

  if (typeof candidate.isCharging !== "boolean") {
    throw new Error("Invalid charging state");
  }

  return {
    level,
    isCharging: candidate.isCharging,
  };
}

This approach is often called parsing rather than validation.

Validation asks:

Is this value already valid?

Parsing asks:

Can this value be safely converted into the trusted form?

Both approaches are useful.

The choice should be explicit.

A practical code-review checklist

Whenever a value enters a React Native application, ask:

Where did this value come from?
Is the source controlled by the TypeScript compiler?
Is the value typed as any or cast using as?
What happens if a field is missing?
What happens if a number arrives as a string?
Are null and undefined handled differently?
Are allowed ranges and enum values checked?
Is validation performed once at the boundary?
Is the failure logged with enough context?
Can the application recover safely from invalid data?

These questions are especially important during:

native-module reviews
API integration
storage migrations
SDK upgrades
backend contract changes
AI feature development
platform-specific debugging

Final takeaway

TypeScript is excellent at preserving correctness inside a typed system.

But it does not control the values coming from outside that system.

A type definition describes what the application expects.

A type cast tells the compiler what to believe.

Runtime validation checks what the application actually received.

The engineering rule is simple:

Treat external values as unknown, validate them at the boundary and only then convert them into trusted application types.

Because in production React Native applications:

Casting is not validation.

Which runtime boundary has caused the most unexpected type failure in your React Native application?

Your Offline-First App Can Lose Correct Data Without Showing Any Error

Subrata Kumar Das — Sun, 12 Jul 2026 07:07:30 +0000

An offline-first application can complete synchronization successfully and still produce the wrong result.

The API may return 200 OK.

The local mutation queue may become empty.

The device may show that all changes are synchronized.

And yet, one valid update may have silently overwritten another.

This is one of the most dangerous offline-first failures because nothing appears broken technically.

There is no crash.

There is no network error.

There is no failed request.

The system behaves exactly as implemented.

The problem is that the implementation never defined which version of the data should win.

The Failure Scenario

Consider a maintenance application used by field technicians and supervisors.

A technician opens a maintenance request while working in an area with poor connectivity.

The current request contains:

{
  id: "REQ-1042",
  status: "OPEN",
  priority: "MEDIUM",
  notes: "Initial inspection pending",
  version: 4
}

The technician goes offline and updates the request:

{
  status: "IN_PROGRESS",
  notes: "Inspection started at the site"
}

Before the technician reconnects, a supervisor opens the same request through a web dashboard and changes the priority:

{
  priority: "HIGH",
  notes: "Potential safety risk reported"
}

Now two valid versions exist.

The technician’s device contains one valid update.

The server contains another valid update.

When the device reconnects, the mobile application sends its pending mutation.

The difficult question is not:

How do we upload the local data?

The difficult question is:

Which version should be trusted?

Why Last-Write-Wins Is Not Always Conflict Resolution

A common implementation compares timestamps and keeps the latest update.

This is known as last-write-wins.

For some fields, this may be acceptable.

For example:

a profile description
a temporary draft
a non-critical display preference
an editable note where losing an earlier version is acceptable

But last-write-wins becomes dangerous when the conflicting data includes:

approval status
inspection findings
financial values
compliance records
safety-related decisions
healthcare information
task ownership
inventory quantities

Imagine that the technician’s update is submitted five seconds after the supervisor’s update.

A timestamp-based strategy may replace the supervisor’s high-priority safety warning with the technician’s older local copy.

The synchronization request succeeds.

The server accepts the payload.

The local queue is cleared.

But an important update has been lost.

That is not a networking failure.

It is an architecture failure.

Offline-First Is a Business-Rules Problem

Offline-first architecture is often described using technical components:

SQLite or Realm
local persistence
mutation queues
retries
background synchronization
connectivity listeners
optimistic UI updates

These components are important.

But they only solve the mechanics of storing and transporting data.

They do not decide what should happen when two correct versions disagree.

That decision belongs to business rules.

Before building the synchronization engine, every important field or operation should have a conflict-resolution policy.

A useful starting point is to define four possible outcomes:

Merge
Reject
Overwrite
Review

1. Merge

Use merging when both updates can safely coexist.

Suppose the server contains:

{
  tags: ["electrical"]
}

The offline device adds:

{
  tags: ["urgent"]
}

Instead of replacing one array with the other, the system can merge them:

{
  tags: ["electrical", "urgent"]
}

Append-only activity logs are another good candidate for merging.

type ActivityEvent = {
  id: string;
  requestId: string;
  type: string;
  createdAt: string;
  createdBy: string;
};

Each action becomes a separate immutable event.

The system adds new events instead of replacing the complete history.

This makes synchronization safer because concurrent actions do not compete for ownership of the same record.

2. Reject

Some fields should be controlled only by the server.

For example:

{
  approvedBy: "manager-id",
  approvedAt: "2026-07-12T10:30:00Z",
  complianceStatus: "VERIFIED"
}

A mobile device should not be allowed to overwrite these values from an old local snapshot.

If an offline mutation contains server-owned fields, the backend should reject those parts of the update.

A field ownership model may look like this:

const fieldOwnership = {
  approvedBy: "server",
  approvedAt: "server",
  complianceStatus: "server",
  notes: "shared",
  description: "shared",
  localDraft: "client"
} as const;

The client can still display server-owned fields while offline.

But it should not treat them as locally authoritative.

3. Overwrite

Overwriting is acceptable when the business explicitly allows one side to win.

For example, a user may edit a local draft on multiple devices, and the product may intentionally use the latest saved version.

The important point is that overwrite should be a documented rule, not an accidental side effect.

Instead of saying:

The latest request happened to win.

The architecture should say:

This field uses last-write-wins because losing the earlier value is acceptable.

That difference matters.

An accidental overwrite is a bug.

An intentional overwrite is a policy.

4. Review

Some conflicts cannot be resolved safely by software.

Consider these two changes:

// Technician update
{
  inspectionResult: "SAFE"
}

// Supervisor update
{
  inspectionResult: "REQUIRES_REVIEW"
}

Automatically choosing either version may create operational risk.

The correct outcome may be to preserve both versions and require a person to resolve the conflict.

A conflict record could look like this:

type SyncConflict = {
  entityId: string;
  field: string;
  localValue: unknown;
  serverValue: unknown;
  localUpdatedAt: string;
  serverUpdatedAt: string;
  resolutionStatus: "PENDING" | "RESOLVED";
};

The application can show a dedicated conflict-resolution screen:

Inspection result changed in two places.

Local version:
SAFE

Server version:
REQUIRES_REVIEW

Choose a value or escalate for supervisor review.

This is less convenient than automatic synchronization.

But convenience should not override correctness for critical data.

Use Version Numbers, Not Only Timestamps

Timestamps are useful, but they are not always reliable enough for concurrency control.

Devices may have incorrect clocks.

Requests may be delayed.

Two updates may happen within the same timestamp precision.

A stronger approach is optimistic concurrency control using version numbers.

The server stores:

{
  id: "REQ-1042",
  status: "OPEN",
  version: 4
}

The client sends the version it originally edited:

PATCH /maintenance-requests/REQ-1042
If-Match: 4

The payload may contain:

{
  "status": "IN_PROGRESS"
}

If the server still has version 4, the mutation can be accepted.

The server updates the record to version 5.

If the server already has version 5, the client edited an outdated copy.

The server can return a conflict response:

409 Conflict

Example response:

{
  "code": "VERSION_CONFLICT",
  "currentVersion": 5,
  "serverRecord": {
    "id": "REQ-1042",
    "status": "OPEN",
    "priority": "HIGH",
    "version": 5
  }
}

The client now has enough information to merge, reject, overwrite or request human review.

A Simple React Native Mutation Queue

An offline mutation should contain more than an endpoint and payload.

It should also preserve the version that the user originally edited.

type PendingMutation = {
  id: string;
  entityType: "maintenanceRequest";
  entityId: string;
  operation: "UPDATE";
  baseVersion: number;
  changes: Record<string, unknown>;
  createdAt: string;
  retryCount: number;
};

Example mutation:

const mutation: PendingMutation = {
  id: "mutation-501",
  entityType: "maintenanceRequest",
  entityId: "REQ-1042",
  operation: "UPDATE",
  baseVersion: 4,
  changes: {
    status: "IN_PROGRESS",
    notes: "Inspection started at the site"
  },
  createdAt: new Date().toISOString(),
  retryCount: 0
};

During synchronization:

async function syncMutation(mutation: PendingMutation) {
  const response = await fetch(
    `/maintenance-requests/${mutation.entityId}`,
    {
      method: "PATCH",
      headers: {
        "Content-Type": "application/json",
        "If-Match": String(mutation.baseVersion)
      },
      body: JSON.stringify(mutation.changes)
    }
  );

  if (response.status === 409) {
    const conflict = await response.json();

    return {
      type: "CONFLICT",
      mutation,
      serverRecord: conflict.serverRecord
    };
  }

  if (!response.ok) {
    throw new Error(`Sync failed with status ${response.status}`);
  }

  return {
    type: "SUCCESS",
    record: await response.json()
  };
}

The important part is that a 409 Conflict should not be treated like a normal retryable network error.

Retrying the same request repeatedly will not resolve a semantic conflict.

The system needs a conflict-resolution rule.

Classify Sync Failures Correctly

Not every failed synchronization attempt means the same thing.

A useful classification is:

Network failure

Examples:

no connectivity
request timeout
DNS failure
temporary server unavailability

Action:

retry with backoff

Authentication failure

Examples:

expired token
revoked session
missing permission

Action:

refresh credentials or require authentication

Validation failure

Examples:

invalid field value
required field missing
unsupported state transition

Action:

show the user what must be corrected

Version conflict

Examples:

server record changed after the local copy was created
two users edited the same field
an approval occurred while the device was offline

Action:

merge, reject, overwrite or review

Treating all four categories as “sync failed” creates weak architecture and confusing user experiences.

Do Not Delete the Local Mutation Too Early

A dangerous synchronization pattern looks like this:

await sendMutation(mutation);
await removeMutationFromQueue(mutation.id);

This is safe only when the server has confirmed that the mutation was accepted and correctly applied.

The mutation should remain available when:

the server returns a conflict
only part of the payload was accepted
conflict review is pending
the response cannot be validated
the application crashes before local state is updated

A safer state machine might be:

type MutationStatus =
  | "PENDING"
  | "SYNCING"
  | "CONFLICT"
  | "FAILED"
  | "COMPLETED";

The queue entry should move to COMPLETED only after the client has processed the final server response.

Conflict Resolution Should Be Field-Aware

Record-level conflict resolution is often too broad.

Suppose the local version changes:

{
  notes: "Inspection completed"
}

At the same time, the server changes:

{
  priority: "HIGH"
}

These updates affect different fields.

Rejecting the entire local mutation would be unnecessary.

A field-aware merge can preserve both changes:

{
  notes: "Inspection completed",
  priority: "HIGH"
}

But consider this case:

// Local
{
  status: "COMPLETED"
}

// Server
{
  status: "CANCELLED"
}

Both updates affect the same field.

The conflict policy for status must now decide whether to:

reject the local transition
keep the server value
ask for review
apply a domain-specific state machine

This is why conflict resolution must understand business meaning, not only JSON structure.

Define the Rules Before Selecting the Database

Teams often begin offline-first discussions with questions such as:

Should we use Realm?
Should we use SQLite?
Should we use WatermelonDB?
How should we structure the retry queue?
Which connectivity library should we use?

These are useful implementation questions.

But they come after more important architecture questions:

Which fields are client-owned?
Which fields are server-owned?
Which operations are append-only?
Which fields can use last-write-wins?
Which conflicts require human review?
How long should unresolved conflicts be retained?
Can users continue editing while a conflict is pending?
What audit trail is required?

A database can persist conflicting data.

It cannot decide which version is correct.

A Practical Conflict-Policy Table

Before implementation, document the policy for important fields.

Field or Operation	Ownership	Resolution Strategy	Human Review
User notes	Shared	Last-write-wins or merge history	No
Approval status	Server	Reject local overwrite	Yes
Activity log	Append-only	Merge	No
Inspection result	Shared	Compare versions	Sometimes
Compliance status	Server	Server wins	Yes
Draft description	Client	Local overwrite allowed	No
Assigned technician	Server	Reject stale update	Yes

This table becomes a shared contract between:

mobile developers
backend developers
product managers
QA engineers
security teams
compliance stakeholders

Without this contract, each layer may implement a different interpretation of “sync.”

Questions to Ask During Architecture Review

Before calling an application offline-first, ask:

What happens when local and server records both change?
Does every mutation include a base version?
Which fields are controlled by the server?
Which data can be merged safely?
Which fields may use last-write-wins?
Which conflicts must be reviewed by a person?
Is conflict history preserved for auditing?
Can the user see when synchronization is blocked?
Are semantic conflicts separated from network failures?
When is a mutation permanently removed from the queue?

If the team cannot answer these questions, the application may support offline storage, but it does not yet have a complete offline-first architecture.

Final Takeaway

Offline-first architecture is not only about local databases, queues and retry mechanisms.

Those components answer:

How will data move when connectivity returns?

Conflict policies answer the more important question:

What should happen when two valid versions disagree?

Before building the synchronization engine, define four possible outcomes:

Merge. Reject. Overwrite. Review.

Make those decisions per field or operation.

Add version numbers to mutations.

Keep unresolved conflicts visible.

And never assume that a successful API response means the correct data survived.

Which field in your application would be dangerous to resolve using last-write-wins?

Your React Native Performance Problem May Actually Be a Memory Leak

Subrata Kumar Das — Sat, 11 Jul 2026 15:15:15 +0000

Your React Native Performance Problem May Actually Be a Memory Leak

A React Native screen can render correctly and still leak memory.

That is why some performance problems are misdiagnosed.

The app feels fine after launch.

Then, after repeated navigation:

screens become slower
callbacks fire more than once
background work keeps increasing
network listeners remain active
timers continue running
state updates happen after a screen has already unmounted

The first reaction is often:

“Let us optimise re-renders.”

But re-rendering may not be the real problem.

The actual issue may be that work created by old screens never stopped.

Why this is easy to misdiagnose

Many React Native performance issues are visible immediately.

A heavy component may:

render slowly
block the JavaScript thread
display a large list inefficiently
perform expensive calculations during render

Memory leaks often behave differently.

They usually appear gradually.

The first navigation works correctly.

The second also looks fine.

But after opening and closing the same screen multiple times, the application may start doing more work than expected.

That gradual degradation makes the issue look like a rendering problem, even when the rendering logic has not changed.

The important question is not only:

What is React rendering now?

You also need to ask:

What is the previous screen still doing?

A simple failure scenario

Consider a screen that subscribes to an event:

import { useEffect } from 'react';
import { DeviceEventEmitter } from 'react-native';

function StatusScreen() {
  useEffect(() => {
    DeviceEventEmitter.addListener('device-status', status => {
      console.log('Device status:', status);
    });
  }, []);

  return null;
}

At first glance, this code looks harmless.

The subscription is created only once for each mount because the dependency array is empty.

But there is no cleanup.

Each time the screen mounts, another listener is registered.

After navigating to the screen five times, the same event may trigger five callbacks.

The screen may not look broken, but the application is now doing unnecessary work.

A safer version removes the listener during cleanup:

import { useEffect } from 'react';
import { DeviceEventEmitter } from 'react-native';

function StatusScreen() {
  useEffect(() => {
    const subscription = DeviceEventEmitter.addListener(
      'device-status',
      status => {
        console.log('Device status:', status);
      }
    );

    return () => {
      subscription.remove();
    };
  }, []);

  return null;
}

The important improvement is not in the render function.

It is in the lifecycle ownership.

Common sources of memory leaks in React Native

1. Event listeners without cleanup

Listeners are one of the most common causes of duplicated work.

Examples include:

DeviceEventEmitter
NativeEventEmitter
keyboard listeners
dimension listeners
custom event buses
navigation listeners

A common mistake is to register the listener correctly but forget to unsubscribe.

useEffect(() => {
  const subscription = Keyboard.addListener(
    'keyboardDidShow',
    handleKeyboardShow
  );

  return () => {
    subscription.remove();
  };
}, []);

Every listener should have a clear cleanup path.

2. Timers that survive screen unmount

Intervals are especially risky because they continue executing until explicitly cleared.

useEffect(() => {
  const intervalId = setInterval(() => {
    refreshStatus();
  }, 5000);

  return () => {
    clearInterval(intervalId);
  };
}, []);

Without cleanup, each screen visit may create another interval.

The result may be:

duplicate API requests
repeated state updates
unnecessary battery usage
unexpected native module calls

The code may still appear correct during a short test session.

The problem becomes visible only after repeated use.

3. AppState and NetInfo subscriptions

App lifecycle and connectivity listeners often live close to application-level logic.

That makes ownership less obvious.

useEffect(() => {
  const subscription = AppState.addEventListener(
    'change',
    handleAppStateChange
  );

  return () => {
    subscription.remove();
  };
}, []);

NetInfo has a similar subscription pattern:

useEffect(() => {
  const unsubscribe = NetInfo.addEventListener(state => {
    console.log('Connected:', state.isConnected);
  });

  return unsubscribe;
}, []);

These subscriptions can be valid at the application level.

The problem starts when the same global-style listener is created inside multiple screens or components.

Before registering one, decide:

should this listener exist once for the app?
once per navigator?
once per screen?
once per active feature?

The cleanup strategy depends on the ownership boundary.

4. Native module callbacks registered multiple times

Native integration makes memory leaks harder to diagnose because the work may continue outside React.

A native module may:

emit Bluetooth events
report sensor data
receive location updates
send foreground service events
notify JavaScript about background tasks

If the JavaScript side registers the callback repeatedly, the native module may continue sending events to multiple active listeners.

useEffect(() => {
  const emitter = new NativeEventEmitter(MyNativeModule);

  const subscription = emitter.addListener(
    'measurement',
    handleMeasurement
  );

  return () => {
    subscription.remove();
  };
}, []);

For native integrations, also verify whether cleanup is required on the native side.

Removing the JavaScript listener may not be enough if the native service itself keeps running.

Sometimes cleanup also requires calling methods such as:

MyNativeModule.stopMonitoring();

The correct lifecycle may therefore look like this:

useEffect(() => {
  MyNativeModule.startMonitoring();

  const emitter = new NativeEventEmitter(MyNativeModule);

  const subscription = emitter.addListener(
    'measurement',
    handleMeasurement
  );

  return () => {
    subscription.remove();
    MyNativeModule.stopMonitoring();
  };
}, []);

This is why memory ownership matters more than simply calling remove().

5. Async work completing after unmount

Async operations do not always create a permanent memory leak, but they can still produce stale work and unnecessary updates.

useEffect(() => {
  fetchProfile().then(profile => {
    setProfile(profile);
  });
}, []);

If the user leaves the screen before the request finishes, the callback may run after unmount.

A simple guard can prevent stale updates:

useEffect(() => {
  let isActive = true;

  async function loadProfile() {
    const profile = await fetchProfile();

    if (isActive) {
      setProfile(profile);
    }
  }

  loadProfile();

  return () => {
    isActive = false;
  };
}, []);

For network requests, cancellation is often better when supported.

With fetch, you can use AbortController:

useEffect(() => {
  const controller = new AbortController();

  async function loadProfile() {
    try {
      const response = await fetch('/profile', {
        signal: controller.signal,
      });

      const data = await response.json();
      setProfile(data);
    } catch (error) {
      if (error instanceof Error && error.name !== 'AbortError') {
        console.error(error);
      }
    }
  }

  loadProfile();

  return () => {
    controller.abort();
  };
}, []);

This avoids unnecessary work instead of only ignoring the result.

The ownership questions every subscription should answer

For every listener, timer, subscription or callback, identify four things.

1. Where is it created?

Is it created inside:

a screen
a custom hook
a context provider
a navigation container
an app-level service

This tells you where cleanup should probably live.

2. Who owns it?

Ownership should be explicit.

A screen-level listener should normally disappear with the screen.

An application-level listener may intentionally survive navigation.

The problem is not long-lived work itself.

The problem is long-lived work without clear ownership.

3. When is it removed?

Do not rely on assumptions.

The cleanup path should be visible and testable.

For React components, this often means returning a cleanup function from useEffect.

useEffect(() => {
  const resource = createResource();

  return () => {
    resource.dispose();
  };
}, []);

4. Can it be registered more than once?

This question catches many production issues.

A listener may be duplicated because:

the component mounts repeatedly
the effect dependency changes
a navigation listener is registered during focus
a retry flow reinitialises the subscription
a native module setup method is called more than once

Always verify whether the registration is idempotent.

`useEffect` dependencies can create hidden duplication

A cleanup function alone does not guarantee correct behaviour.

Consider this effect:

useEffect(() => {
  const subscription = eventBus.subscribe(userId, handleEvent);

  return () => {
    subscription.unsubscribe();
  };
}, [userId, handleEvent]);

If handleEvent is recreated on every render, the effect may unsubscribe and resubscribe repeatedly.

That may be valid, but it may also create unnecessary churn.

Use useCallback when stable function identity is important:

const handleEvent = useCallback((event: EventData) => {
  console.log(event);
}, []);

useEffect(() => {
  const subscription = eventBus.subscribe(userId, handleEvent);

  return () => {
    subscription.unsubscribe();
  };
}, [userId, handleEvent]);

The debugging question is not simply:

Does this effect have cleanup?

It is:

How often does this effect run, and how often does it recreate the resource?

Focus listeners require extra care

React Navigation screens may remain mounted even when they are not focused.

That means screen lifecycle and focus lifecycle are not always the same.

If work should run only while the screen is active, useFocusEffect may be a better fit.

import { useCallback } from 'react';
import { useFocusEffect } from '@react-navigation/native';

useFocusEffect(
  useCallback(() => {
    const subscription = subscribeToLiveData();

    return () => {
      subscription.unsubscribe();
    };
  }, [])
);

This ensures the subscription is active only while the screen is focused.

Use this carefully.

If the subscription should survive temporary navigation changes, screen-level focus cleanup may be too aggressive.

The correct decision depends on ownership.

Why render optimisation alone may not help

Suppose you apply:

React.memo
useMemo
useCallback
list virtualisation
smaller component trees

These changes can improve rendering.

But they do not remove:

old listeners
duplicate timers
native callbacks
background services
stale async tasks

You may make the current screen render faster while previous screens continue consuming resources.

That is why profiling only render behaviour can give an incomplete picture.

Render profiling tells you what React is doing now.

Lifecycle debugging tells you what earlier components may still be doing.

You need both.

A practical debugging process

When a React Native app becomes slower after repeated navigation, use a repeatable process.

Step 1: Reproduce the degradation

Do not test only from a fresh launch.

Repeat the same flow:

open the screen
leave the screen
open it again
repeat several times
trigger the same event or action

Look for callbacks that increase with every cycle.

Step 2: Add temporary registration logs

Log when resources are created and removed.

useEffect(() => {
  console.log('Registering device listener');

  const subscription = registerDeviceListener();

  return () => {
    console.log('Removing device listener');
    subscription.remove();
  };
}, []);

For each registration, you should see a corresponding cleanup when expected.

Step 3: Count callback executions

const callbackCount = useRef(0);

function handleEvent() {
  callbackCount.current += 1;
  console.log('Callback count:', callbackCount.current);
}

If a single event triggers multiple callbacks after repeated navigation, duplicate listeners are likely.

Step 4: Inspect timers and polling

Search for:

setInterval
setTimeout
recursive polling
retry loops
animation loops

Confirm that each one is cancelled correctly.

Step 5: Inspect native services

Check whether native modules continue:

scanning
observing
polling
emitting events
tracking location
maintaining sockets

JavaScript cleanup may not stop native work automatically.

Step 6: Profile memory and activity

Use platform tools when the issue is not obvious.

For Android:

Android Studio Profiler
Memory Profiler
CPU Profiler
Logcat

For iOS:

Xcode Instruments
Allocations
Leaks
Time Profiler
Energy Log

Also use React Native tooling where useful:

React DevTools
Hermes profiling
Flipper, where supported by the project setup

The goal is not only to see memory growth.

Also check whether the number of callbacks, subscriptions or native operations grows with each navigation cycle.

A cleanup checklist for code review

When reviewing React Native lifecycle code, ask:

Does every listener have an unsubscribe path?
Does every interval have a clearInterval?
Does every timeout have a clearTimeout where required?
Does every native subscription expose disposal?
Does every background service have a stop method?
Can this effect register more than once?
Should this resource follow mount lifecycle or focus lifecycle?
Can async work be cancelled?
Can stale results update state?
Is this subscription owned by the correct architectural layer?

This checklist is more useful than asking only whether useEffect has a return function.

Cleanup is not just syntax.

It is an ownership decision.

A stronger engineering rule

Before optimising rendering, check whether the screen leaves behind any long-lived work.

For every subscription, answer:

Where is it created?
Who owns it?
When is it removed?
Can it be registered more than once?

A component may render perfectly and still damage performance over time.

The leak often exists outside the visible render path.

That is why repeated navigation is such an important test.

A fresh launch shows whether the screen works.

Repeated use shows whether the lifecycle works.

Final takeaway

Not every slow React Native screen needs render optimisation.

Sometimes the screen is slow because previous screens are still alive through:

listeners
timers
subscriptions
native callbacks
background tasks

Render profiling tells you what React is doing now.

Lifecycle cleanup tells you what old work never stopped.

When a React Native app becomes slower after repeated navigation, which cleanup path do you inspect first?

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

DEV Community: Subrata Kumar Das

Why I Chose Gemma 4 E2B for Subra AI: The Reality of Running LLMs on Mid-Range Phones

Introduction: The Anti-Cloud Philosophy

To pull off this architectural high-wire act across consumer hardware like iPhones, Android devices, and Desktop computers, I needed a model that was fiercely resource-efficient yet multi-modally competent. Enter Google DeepMind’s Gemma 4 E2B.

Reason 1: The "E" Factor — Punching Way Above Its Weight Budget

Reason 2: Defeating the Mobile RAM Monster (1.5GB Threshold)

Reason 3: Native Multimodality for Real-World Vision Checkups

Reason 4: Developer-Friendly Ecosystem Integration

Conclusion: Why E2B Wins for the Edge

Choosing Gemma 4 E2B was a calculated engineering choice: it gave Subra AI the exact blend of low-latency execution, native vision capture, and a manageable RAM footprint needed to build a premium, sovereign AI product.

Giving the AI Assisted Job Search a Local Brain

The job search begins with a question

From onboarding to a real workspace

Why local AI belongs in this project

Running Ollama locally

Searching is more than calling an endpoint

A privacy boundary, not just a feature list

What is working now

What comes next

An invitation to build the next chapter

Stay for the next update

Building an Open-Source AI-Assisted International Job Search Platform

The product idea

Current MVP scope

Why open source?

Technical architecture

Reusing a central authentication service

Running the project locally

Production-like local mode

Resume import

AI provider flexibility

Privacy and safety decisions

Current UI

What I’m looking for

Contributing

Final thoughts

Subra AI: Private Offline On-Device AI

Synchronous TurboModules Are Not Automatically Fast

The misleading simplicity of a synchronous API

What synchronous actually means

Why this affects React Native performance

TurboModules reduce overhead, not execution cost

When synchronous native methods are appropriate

Operations that should usually remain asynchronous

Storage

Cryptography

Networking

Large data conversion

Image and file processing

System services

Avoid synchronous work inside rendering

Cache deliberately, not accidentally

Measure the whole native method

Watch for repeated synchronous calls

Synchronous methods create architectural coupling

A practical decision rule

Suitable for synchronous execution

Better suited for asynchronous execution

Code-review checklist

Final takeaway

Type Safety Stops at Runtime Boundaries in React Native

A simple example

Casting is not validation

Where the failure appears

Compile-time trust should stop at runtime boundaries

Why unknown is better than any

Manual runtime validation

Validate business rules, not only field types

Using a schema validation library

Runtime boundaries in React Native

1. Native modules

2. Network responses

3. Persisted storage

4. Deep links

5. Remote configuration

6. AI-generated structured output

Validate once at the edge

Parse, do not merely check

A practical code-review checklist

Final takeaway

Why `unknown` is better than `any`

`useEffect` dependencies can create hidden duplication