DEV Community: running squirrel

Offline React Native Apps: How to Cache Files That Must Open Without Network

running squirrel — Sat, 25 Apr 2026 09:41:36 +0000

If you search for “offline React Native,” you will find a lot of guidance about images, lists, and optimistic UI. That is useful, but it often misses the assets that actually stop work in the field: PDFs, JSON manifests, small binaries, audio clips, and other HTTP-hosted files your app must open right now, even when connectivity is unreliable.

One of the best libraries for that specific “cache downloads to disk, open them later” capability is react-native-nitro-cache with it's simplistic api anyone can use easily.

This post is about that second category: file caching for offline-capable React Native apps.

Why “offline React Native” advice often skips the hard part

Most offline guidance optimizes what users see immediately: scrolling, perceived speed, optimistic updates. That matters, but field workflows also depend on what users can open from storage when the network disappears.

Operational apps tend to fail for file reasons, not layout reasons:

a PDF checklist did not download before the technician walked into a basement
a rules manifest is stale after a midnight policy change
a small binary or audio instruction is missing when the user is already offline

What you want in those situations is not a prettier loading state. You want a predictable HTTP file cache with explicit freshness and cleanup tools.

That is the shape of problem a file cache is meant to solve: downloads you can treat as local files, with TTL, forced refresh, and simple ways to inspect and clean up what is on disk—so your app can open operational assets offline, not only render UI faster.

The offline-first file workflow

Think in layers:

Prefetch the critical path while the user still has good connectivity (login, sync screen, “prepare for today” action).
Serve from disk during the session using stable local file paths.
Revalidate on a schedule using TTLs that match how often each asset class changes.
Force refresh when the server says “this version is invalid” (feature flags, emergency policy updates).
Observe and prune using cache stats/entries so support and QA can reason about what is on-device.

This maps cleanly to the react-native-nitro-cache primitives:

getOrFetch(url, options?) — return a valid cached file or download it
get(url) — read-through without downloading
has(url) — fast synchronous membership check against the in-memory index
getBuffer(url) — read bytes into an ArrayBuffer for small in-memory consumers
remove(url) / clear() — targeted invalidation vs nuclear reset
getStats() / getEntries() — operational visibility

Example: different TTLs for different file classes

In real apps, “freshness” is not one number. Treat manifests, templates, and media differently.

import { rnNitroCache } from 'react-native-nitro-cache';

export async function cacheManifest(url: string) {
  // Changes frequently: short TTL 10mins
  return rnNitroCache.getOrFetch(url, { ttl: ttl: 60 * 10 });
}

export async function cachePdfTemplate(url: string) {
  // Changes rarely: longer TTL 7days
  return rnNitroCache.getOrFetch(url, { ttl: 60 * 60 * 24 * 7 });
}

When an entry is returned, you typically care about:

url: absolute on-disk path you can hand to viewers/players
contentType: useful for routing and validation
size: useful for UI and telemetry
expiresAt: 0 if the entry has no TTL; otherwise the expiry instant in milliseconds since epoch

Example: parse cached JSON without inventing a parallel storage system

For small JSON blobs, getBuffer can be convenient if your consumer wants bytes in JS.

import { rnNitroCache } from 'react-native-nitro-cache';

export async function readCachedJson(url: string) {
  const buf = await rnNitroCache.getBuffer(url);
  if (!buf) return null;

  const text = new TextDecoder().decode(buf);
  return JSON.parse(text) as unknown;
}

Invalidation that matches real product events

Offline support is not only “store more.” It is also “remove the right things at the right time.”

Common triggers:

User logs out → clear() if your policy requires wiping cached HTTP assets from the device
Tenant/workspace switch → clear() or selective remove(url) for tenant-scoped URLs
Server publishes a new bundle version → getOrFetch(url, { forceRefresh: true }) for the entry points that must update immediately

Observability: treat the cache as part of your release story

If you have ever debugged “it works on Wi‑Fi,” you know the missing ingredient is visibility.

import { rnNitroCache } from 'react-native-nitro-cache';

const stats = await rnNitroCache.getStats();
console.log('cache entries:', stats.totalEntries, 'bytes:', stats.totalSize);

const entries = await rnNitroCache.getEntries();
console.log(entries.map(e => ({ path: e.url, type: e.contentType, bytes: e.size })));

This is valuable for:

QA scripts (“did we prefetch the manifest?”)
internal diagnostics screens
coarse “disk budget” warnings before downloads

Installation and platform reality (so your readers do not get stuck)

What I would emphasize in a Medium conclusion

Offline React Native is getting more attention because teams are shipping more serious mobile workflows. But it is not just "more caching", it is the right kind of caching:

operational files you can open from disk under poor connectivity
explicit freshness (TTL) and forced refresh paths
disk-first retrieval for large assets
targeted invalidation and introspection APIs

If your roadmap includes offline inspections, offline forms, offline training content, or any “must open on-site” PDFs and manifests, a general-purpose file cache belongs in your architecture review alongside your sync and persistence strategy.

Repo link

To learn more about the library checkout it's repository on GitHub

Top 4 React Native Image Caching Libraries in 2026

running squirrel — Wed, 22 Apr 2026 20:09:14 +0000

An opinionated guide to image caching in React Native, from battle-tested classics to the blazing-fast newcomer built for the New Architecture.

Caching images in React Native has always been painful. The default <Image> component is slow, flickers on reloads, and offers almost zero control.
For years developers have relied on a handful of libraries but most of them were built before the New Architecture, before Turbo Modules or Nitro Modules, and before apps started demanding smooth video caching and zero-copy performance.

In 2026, the game has changed. Here are the Top 4 image caching libraries I recommend today, ranked by real-world usage, performance, and developer experience.
Make sure you check out the last one!

1 react-native-fast-image - The Veteran King (Still Dominant)

The library is no longer actively maintained but still being used by many. I strongly recommend the fork - @d11/react-native-fast-image

Pros

Battle-tested for years
Excellent image prioritization and cache control
Huge community

Cons

New Architecture support is patchy (community fork required)
Higher bridge overhead compared to modern Nitro solutions

Still the go-to for many production apps, but it's starting to show its age.

2 expo-image - The Expo Ecosystem Favorite

Pros

Beautiful API and great DX
Excellent New Architecture support
Built-in memory + disk caching with cachePolicy

Cons

Tied to the Expo ecosystem (less ideal for bare React Native)
Limited programmatic control (no easy remove(url) or cache inspection)

Perfect if you're already in Expo.

3 react-native-turbo-image - The Modern Native Contender

Built on Nuke (iOS) and Coil (Android), this library delivers excellent native performance and is gaining traction fast.

Pros

Very fast native image loading
Good New Architecture compatibility

Cons

Smaller community than fast-image

A strong option if you want native speed without Nitro.

4 react-native-nitro-cache - The Newcomer That's Stealing the Show

This is the one I'm most excited about in 2026.
Built from the ground up with Nitro Modules + C++, react-native-nitro-cache is a unified asset cache for images, videos, and any binary files. Has a very simple api interface, very easy to use.

Why it stands out:

Unified caching (images + videos + arbitrary files)
Zero-copy ArrayBuffer support for raw binary data
Blazing-fast in-memory retrieval with safe atomic persistence
Built-in TTL, programmatic remove(url) and cache inspection
Full New Architecture support out of the box

It feels like someone finally built the cache library we've all been waiting for since the New Architecture landed.

Conclusion

react-native-fast-image and expo-image are still solid choices, they are battle tested and the community love them.

My 2026 recommendation:

Expo-heavy project → stick with expo-image
Need maximum battle-tested stability → react-native-fast-image (with the community fork)
Want the future of unified, high-performance caching → try react-native-nitro-cache.

The library is brand new, actively developed, and already solving real pain points that the older solutions never addressed.
Have you tried it yet? Drop a comment below with your current caching setup. I'd love to hear what's working (or not working) for you in 2026.

Why Mobile Apps Deserve Their Own CMS

running squirrel — Wed, 20 Aug 2025 04:16:50 +0000

Every website has a CMS. WordPress, Shopify, Contentful — platforms that make content management simple and instant.
But mobile apps? Still waiting days for app store approvals just to fix a typo.

Why do apps lack the same content management flexibility as websites?
Because app stores were built for static releases, not agile content updates.

Product managers, marketers, and even compliance teams often need quick updates:

Change a banner for a flash sale
Update legal disclaimers
Fix onboarding text
Roll out seasonal content

None of these should require a rebuild.

ResyncBase is filling this gap:

Built for React Native apps
Instant content updates
Live previews on iOS & Android
Version history & rollback

The Benefit Beyond Speed?

Empower non-developers to make changes
Reduce developer distraction
Keep users happy with bug-free, up-to-date content

Just as websites couldn’t scale without CMS platforms, mobile apps can’t stay competitive with app store delays.
It’s time for a CMS for apps.

Join the ResyncBase waitlist now at www.resyncbase.com

How to Add a Vertical Timeline To your React Native App

running squirrel — Fri, 07 Mar 2025 07:24:58 +0000

To add a component to show the progress/timeline of a process with different statuses, you can use the library react-native-vertical-status-progress. Works with Expo and React Native.

The component from the library is designed to visually represent the progress of a multi-step process. Each step is represented by a status indicator that can be customized to show whether the step is completed or pending. This component is ideal for workflows, onboarding processes, or any scenario where you need to display progress through a series of steps. It is compatible with both Expo and React Native projects, making it versatile and easy to integrate into your existing applications.

Features

Accordion Support: Each status can be expanded or collapsed to show more details. This is useful for providing additional information or actions related to each step.
Customizable Content: You can render any component within the accordion, including call-to-action (CTA) buttons, forms, or any other React Native components.

Installation

npm install react-native-vertical-status-progress

Usage

import { VerticalStatusProgress } from 'react-native-vertical-status-progress';

const statuses = [
  {
    title: 'Sign Up Complete',
    subtitle: 'You have successfully signed up.',
    status: 'registered',
  },
  {
    title: 'Set up your account',
    subtitle: 'Add your account details to get started.',
    renderContent: (
      <TouchableOpacity>
        <Text>vbireuvgbireubgireuf</Text>
      </TouchableOpacity>
    ),
    status: 'setting_up',
  },
  {
    title: 'Account Verification',
    subtitle: 'We are verifying your account.',
    renderContent: (
      <View>
        <Text>
          We will contact you shortly if we need any additional information.
          Please contact us if you have any questions. Check your email for
          updates.
        </Text>
        <TouchableOpacity
          style={{
            backgroundColor: colors.ACCENT_BLUE,
            padding: 10,
            borderRadius: 5,
            width: 150,
            alignItems: 'center',
            marginTop: 10,
          }}
        >
          <Text style={{ color: '#fff' }}>Resend Email</Text>
        </TouchableOpacity>
      </View>
    ),
    status: 'verifying',
  },
  {
    title: 'Account Verified',
    subtitle: 'Your account has been verified.',
    status: 'waiting',
  },
  {
    title: 'All Set!',
    subtitle:
      "You're all set up and ready to go. Start using your account now.",
    renderContent: (
      <View>
        <Text>
          Lorem ipsum dolor sit, amet consectetur adipisicing elit. A ullam
          assumenda obcaecati? Minima libero vitae ducimus, omnis, excepturi
          saepe, doloribus corrupti hic deleniti id iure? Qui consequuntur at
          magnam consequatur!
        </Text>
      </View>
    ),
    status: 'ready',
  },
];

const App = () => {
    return (
        <VerticalStatusProgress statuses={statuses} />
    );
};

export default App;

Customization

You can customize the appearance of the react-native-vertical-status-progress component by passing in custom styles and render functions. Here are some examples:

Custom Ball Component

const renderCustomBall = (label, idx, isPrev, isFuture) => (
  <View style={{ backgroundColor: isPrev ? 'blue' : 'grey', width: 16, height: 16, alignItems: 'center', justifyContent: 'center', borderRadius: 4 }}>
    <Text style={{ color: 'white', fontSize: 10 }}>{idx}</Text>
  </View>
);

<VerticalStatusProgress
  statuses={statuses}
  renderBall={renderCustomBall}
/>

Custom Stick Component

const renderCustomStick = (label, idx, isPrev, isFuture) => (
  <View style={{ flex: 1, width: 5, backgroundColor: isPrev ? 'blue' : 'grey' }} />
);

<VerticalStatusProgress
  statuses={statuses}
  renderStick={renderCustomStick}
/>

Custom Chevron Component

const renderCustomChevron = (open, index) => (
  <Text>{open ? '-' : '+'}</Text>
);

<VerticalStatusProgress
  statuses={statuses}
  renderChevron={renderCustomChevron}
/>

With react-native-vertical-status-progress it becomes very easy to add any timeline for status progress on your app.

To see more details about customisation, props and example, visit the library page on npm or github.

How to Generate Types from Your Api Responses in Realtime in Typescript

running squirrel — Wed, 04 Dec 2024 11:16:35 +0000

I have always felt a bit annoyed whenever I’m working on a project and I have to add types to an api response.

The process usually goes like this:

write a function to fetch data
call the function on a component or page
either log the response or inspect the network tab to view the response
copy this response, create a new file and paste the response
start editing the response to create a new type or interface
import the new type to the function file and set it’s return type.

This had been going on for a while and then I thought to find a way to automate it.

This led to my discovery of a few libraries that can generate types. Unfortunately they were not convenient to work with because they were not generating the types effortlessly and in realtime. They required a lot of manual process as well. I wanted something I could just plug in and be done with and continue with my normal development flow.

So I decided to build a library that will automate this process for me.

realtime-api-types

The aim of this library is to take the pain away from trying to add types from your api responses.

Find out more on: npm or github

With this library, as you get responses from an api, it generates the type for you and saves it to your project, in real time.

It also imports the new type and sets it as the return type of your api call. How awesome is that!

Just import the helper function and start the server. Thats all. You can then go on with your normal development flow.

This setup is meant only for development and not for production! You should not deploy this into your production pipeline.

This library was inspired by an old project I stumbled upon, called MakeTypes.

Installation

To get started, simply run:

npm install realtime-api-types --save-dev

Configuration

There are some configs you need to set. Go to your package.json and add the following:

"realtime-api-types": {
    "objectType": "type",
    "typePath": "src/types",
    "apiPath": "src/apis",
    "fetchType": "axios"
  }

The shape of the config is:

export type Config = {
  objectType: 'interface' | 'type'; // whether you want to generate interfaces or types 
  fetchType: 'fetch' | 'axios'; // how you fetch data, fetch or axios
  typePath: string; // the path to where you want to save generated types
  apiPath: string; // the path to where your api methods exist
};

Start Service

To start the type generator service, run: npx realtime-api-types --init.

Code Sample & Usage

Wrap your apis in an object and wrap the object with typedApiWrapper.

You should make your api methods pure, simply return the api call.

You can use property assignments or methods or both.

Please note that when you're done developing, remove typedApiWrapper from this file completely.

// Example 

// src/apis/exercise.ts api file

import {typedApiWrapper} from "realtime-api-types"
import axios from 'axios'

export const ExerciseApi = typedApiWrapper({
  // with fetch, property assignment style
  getExercises: () => fetch("https://example-api.com").then((res) => res.json()),
    // with axios, method style
   getExerciseById(id: string) {
    return axios.get(`https://example-api.com/${id}`);
  },
  // api post method
  postExercise(data: any) {
    return axios.post(`https://example-api.com`, data)
  }
});


// src/App.tsx file

useEffect(() => {
   ExerciseApi.getExercises()
}, [])

With this setup, whenever an api is called at any point in time, the service will intercept and try to generate type from the response.

When type generation is successful, the example file above would be automatically updated to something like this:

// updated exercise.ts api file

import {typedApiWrapper} from "realtime-api-types"
import axios from 'axios'
import { GetExercises } from "../types/getExercises";
import { GetExerciseById } from "../types/getExerciseById";
import { PostExercise } from "../types/postExercise";

export const ExerciseApi = typedApiWrapper({
  // with fetch, property assignment style
  getExercises: (): Promise<GetExercises> => fetch("https://example-api.com").then((res) => res.json()),
    // with axios, method style
   getExerciseById(id: string): Promise<{ data: GetExerciseById }> {
    return axios.get(`https://example-api.com/${id}`);
  },
  // api post method
  postExercise(data: any): Promise<{ data: PostExercise }> {
    return axios.post(`https://example-api.com`, data)
  }
});

Note the difference in structure of return type from fetch and axios.
axios returns a data: Type. Do not mix axios and fetch in your project, else you'll get wrong types.

Naming Convention

Note the naming convention in the example above.

The name of the type file is the same as the name of the api method called.
The name of the type itself is the same as the name of the api method but in pascal case.

React Native or Expo

For this to work with React native or Expo, make sure you follow their guide on how to enable api calls to localhost

Limitations

Cannot generate enums from response.
Cannot extend type from different type files. If the response from a call contains object that is similar to another type in another file, it cannot extend it. A new type will be generated in the new file.
Cannot give custom file names or type names. File name and type name is solely based on the name of the api method.
Once a type has been generated for an api call, the type will not update with new api calls. You need to delete the previous generated type file to generate a new one.

This library only serves to help you get started quickly and reduce time spent adding types to api calls. You might need to make some updates to the generated types sometimes. It does not solve all your type problems.