For years, the React Native community shipped icons as fonts. FontAwesome, MaterialCommunityIcons, your custom set, all delivered as one .ttf and rendered as a <Text> component.

Then SVG components arrived, and we all switched to react-native-svg (the popular SVG renderer for React Native) because it was "the right way to do it".

Forty icons per screen meant forty React subtrees mounted and forty SVG parses. Fine on your iPhone 17 Pro Max, but laggy for the rest of the world, who don’t have an overpaid job in tech.

Software Mansion seems to agree, because to fix the problem they arguably created, they recently released react-native-nano-icons, which compiles a folder of SVGs into a custom font.

Drop your SVGs in a folder and configure your app.json (yes, Expo, because what else are you using in 2026, really?). It also supports bare React Native projects.

Copy
[
  "react-native-nano-icons",
  {
    "iconSets": [
      {
        "inputDir": "./assets/icons/your-icons",
        "fontFamily": "your-icons"
      }
    ]
  }
]

At build time, react-native-nano-icons compresses that folder into a single font file (.ttf) plus a tiny lookup table (.glyphmap.json). In your codebase, it looks like this:

Copy
import { createNanoIconSet } from "react-native-nano-icons";
import glyphMap from "./assets/icons/nanoicons/my-icons.glyphmap.json";

export const Icon = createNanoIconSet(glyphMap);

<Icon name="heart" size={24} color="tomato" />

<Icon name="person" size={52} color={['#DB227F', '#FDA780', '#231B25', '#140E19']} />

At runtime, each <Icon name="heart" /> looks up the codepoint and renders as a single native text-glyph stack: one drawGlyphs call per colour layer via CoreText on iOS (Apple's native text-rendering API), one Canvas.drawText call per layer on Android.

The icon disappears into the platform's text engine. Software Mansion's own stress test mounts 1,000 multicolour icons in a ScrollView on iOS and watches it scroll without breaking a sweat.

Their README does warn, "You should always verify your icons visually". The geometry flattener is good, not perfect. Expo Go falls back to <Text> and requires you to link the font with expo-font; the native implementation kicks in as soon as you ship a real dev build.

We sent icons through five years of "modernisation" and ended up rebuilding the icon font, just with a build pipeline that no longer requires sacrificing a Sunday afternoon to FontForge.

Some loops just take five years.

Like Half-Life 3.

👉 react-native-nano-icons

There comes a moment in the life of every fintech, healthcare, or crypto-app dev when someone from the security team, wearing a hoodie that says OFFENSIVE SECURITY and a Yubikey on a lanyard, sits down at your desk and asks, with the calm intensity of a man who has read too many breach reports, whether you're "doing jailbreak detection".

The correct answer is yes.

The honest answer is no, you forgot, please go away.

jail-monkey, maintained by Gant Laborde (@GantLaborde), ships a single import that hands you a battery of device-trust checks: isJailBroken(), canMockLocation(), isDebuggedMode(), hookDetected(), isOnExternalStorage(), AdbEnabled().

Copy
import JailMonkey from 'jail-monkey'

if (JailMonkey.isJailBroken()) {
  // alternative behaviour for jail-broken / rooted devices
}

And, I am not making this up, a function called trustFall(). Ship that one in your banking app and tell me how the code review goes.

On Android, jail-monkey wraps RootBeer (a well-named open-source root-detection library) and adds its own native checks on top, looking for telltale root-tool binaries, suspicious system properties, and write access to filesystem paths that are supposed to be read-only.

None of these checks are bulletproof. A determined attacker can patch them out, which is why for high-stakes apps the more robust answer is the Google Play Integrity API (Google itself attests, server-side, that the app, the OS, and the device haven't been tampered with; your backend then verifies the signed verdict before letting the user past the velvet rope). jail-monkey is the lighter, drop-in client-side option for when you don't need that level of assurance.

The news worth opening this section for is v3.0.0, released April 28, 2026: the long-dormant library woke up one morning and decided to support the New Architecture. The README warns that emulators are usually flagged as rooted, so disable detection in dev, unless you enjoy your simulator failing the bouncer's check every reload like a teenager getting ID'd at Wetherspoons.

Boring. Mature. MIT-licensed. Zero dependencies. TypeScript types built in. The kind of library that doesn't show up on Hacker News, doesn't get a launch tweet, and only exists in your package.json because someone, three years ago, finally won the argument with the security team.

Quietly shipping a major version while everyone else is talking about TypeScript-to-native compilers.

Boring libraries pay your mortgage.

👉 jail-monkey

We've got news.

We're building a game in React Native.

It's called “The Collapse”.

A branching narrative horror game with voice acting, atmospheric music, and locked choices that depend on what you've picked up, and timers that auto-pick if you hesitate too long.

Imagine an audio drama you can play on your phone in the dark.

The runtime is Expo (of course) + expo-audio + reanimated + react-native-svg.

Same codebase ships to iOS, Android, and the browser.

But this section isn't really about the game. It's about the Studio. The authoring tool we built to write the game. And specifically, how we built the Studio without writing any code ourselves.

Branching narrative is data, not code. Every story is a JSON file: scenes, dialogue nodes, choice graphs, audio clips, transitions, music continuity rules. The runtime reads it and plays it.

Hand-editing a 5,000-line nested document gets old in about an hour, so the Studio is a visual editor. A React Flow canvas of scenes connected by arrows, a beat composer where you drag SFX onto a timeline against the voice waveform, a dialogue tree editor with full pan/zoom, and a live preview that plays each scene back with the actual game runtime.

About 70 source files, somewhere around 10,000 lines.

We haven't read a line.

So let's talk about Software Engineering.

The diff is dead. The preview URL is the review.

EAS Workflows ships a preview deploy on every PR, so every change Claude pushes lands in a real browser, on a real URL, within minutes. Clickable, scrubbable, listenable. Nobody reads the diff anymore. You open the link, you play the scene, you decide if the transition lands at 1.5 seconds or 2.

That changes what the job actually is. Code authoring got cheap. What didn't get cheap is the loop between "the model thinks it's done" and "you confirm it's done". Anything a machine can check (typecheck, schema parse, build, test) the model fixes before you ever see it. Anything it can't, like whether the drag-snap feels precise, whether the audio fade reads as intentional, whether the scene breathes, is now the entire job. The gap between those two surfaces is the bottleneck, and shrinking it is where developer time goes.

Spec writing matters because it front-loads the decisions a preview can't make for you. The Studio's first prompt was 5,000 words by the time it hit the implementation session: data model, Zod schema, ten phases with acceptance criteria, the music-persistence cycle case, the skip-beat cancellation behaviour. By the time it dropped, the implementation model wasn't making judgment calls. It was executing. Most of the project's value was captured before the first file was written.

But the spec only earns its keep because the preview tells you, in minutes, whether it worked.

Code authoring got 1000x cheaper.

If you would like to know how we are integrating AI into our workflows.

Ask us any question. We reply to all emails.