Coder Legion - Recent posts tagged reactnative

Two native apps into one React Native codebase in six months

Sun, 11 Oct 2026 18:35:56 +0000

I owned mobile for Pulse, an offline-first inspection app for auditors, on Android and iOS, from an early prototype to 100+ B2B enterprise clients. For most of that time it was two native apps: Kotlin on Android, Swift on iOS, kept in feature parity. In 2025 I led a full rewrite of both into a single React Native codebase. I architected it and built it alongside the team, and we completed it in six months, before I left in May 2025.

This isn’t a “native versus React Native” post. The native apps worked. The earlier posts onPulse’s sync engine and ona local-only app cover why they were built the way they were. This one is about the rewrite: why we did it, what we kept, and how it reached users.

Why rewrite two apps that worked
Keeping two native apps in feature parity has a simple cost: every feature is built twice, once in Kotlin and once in Swift, and every fix has to land in both. That was the reason for the rewrite, in two parts:

One codebase to maintain instead of two.
Shipping faster , because a feature or a fix reaches Android and iOS at the same time.
Neither reason says the native apps were bad. They say that keeping two of them had a cost, and one codebase removes it.

Replicate the behaviour, don’t redesign it
The native apps’ behaviour had years of field use behind it: records that get a temporary local ID and are remapped to a server ID when they sync, photos uploaded before the form that references them, upload progress the auditor can see, and inspection forms built dynamically. So the React Native app replicated that behaviour rather than redesigning it.

The alternative is harder than it looks. A rewrite that also changes how sync works is two projects at once, and every difference between the old app and the new one is something to explain to an auditor in the field. Replicating proven behaviour keeps the rewrite to one question: does the new app do what the old one did?

I built the core, the team built on top
I set the architecture and built the core myself: sync, offline storage and uploads. The team built the screens and features on top of it.

In an offline-first app, that core is where the risk sits. Everything on screen depends on the core behaving the way the native apps did, and in an offline-first app the core is where data gets lost if something is wrong. Screens are easier to see, test and fix; a sync bug can hide until an auditor’s work goes missing.

Rolling out gradually
The new app didn’t replace the native ones for everyone at once. It rolled out gradually, with the native app still available while users moved over.

For an offline-first app that isn’t caution for its own sake. Auditors work without signal, so at any moment someone may have work on the phone that hasn’t reached the server yet. A gradual rollout means a problem in the new app reaches a few users rather than all of them, and there is still a working app to fall back on while it’s fixed.

What I’d tell another team
If you’re rewriting an offline-first app, roll it out gradually. Keep the old app available and move users over in stages. A big-bang switch bets every auditor’s unsynced work on the new app being right on day one.

The bug that survived being recycled: automaticallyAdjustKeyboardInsets and Fabric view recycling on iOS

Thu, 08 Oct 2026 09:12:17 +0000

After logging a meal in Anovi, the nutrition app I build, the next screen opened normally. The content was there. Then the first scroll ran past the end of it, into empty space that should not have existed, and stopped.

Dragging in that space did nothing. Not a slow scroll, not a bounce. Nothing moved, because there was nothing under my finger. The content was somewhere above me and there was no way to reach it. The only way out was to kill the app.

It was not every screen and not every time, which is what kept it alive through earlier rounds of testing. It produced no crash, no error, and no failed request.

In short. On iOS with the New Architecture, a scroll view that opted into keyboard inset handling can leave that behaviour switched on when React Native recycles it. The next screen to inherit that view gets a phantom inset it never asked for. Filed as react-native#57755.

If you just want to check and fix your own app, that is a separate, shorter piece.

The evidence that was missing

Every request in the sequence returned what it should, in the time it should. Nothing failed, nothing timed out, nothing appeared in the logs at the moment things went wrong. The app had not crashed and was not in an error state.

Healthy logs are usually read as the absence of a finding. Here they were the finding, because they eliminated the entire category I had been searching in. That is what promoted the next detail from background noise to the only lead.

The next detail was the keyboard. On the broken screens it appeared, briefly, and went away again. On a screen with no text input on it and nothing focused.

A keyboard reacting where there is nothing to type into is not a rendering bug. Something was still listening.

The screen that broke was not the screen at fault

React Native's new architecture recycles native views. Rather than destroying a component's native view and building a fresh one, it resets the existing view and hands it to the next component that needs the same kind. On iOS, that reset happens in a method called prepareForRecycle.

Recycling is only safe if the reset is complete. Anything left behind belongs to whoever inherits the view next.

A scroll view can opt into having iOS adjust its insets when the keyboard moves, with a prop called automaticallyAdjustKeyboardInsets. Underneath, that sets a flag on the native view and gates a keyboard observer that lives for as long as the view does. prepareForRecycle does not clear that flag.

So the broken screen was innocent. It had no text input, no keyboard props, and nothing to do with any of this. It had simply been handed a view that came out of the pool still holding someone else's settings.

Where the keyboard came from

The view came from the meal logging modal, which does have a scroll view with the prop set and a search field that focuses itself.

The interesting part is what happened when I closed it. Tapping Done dismissed the keyboard, reset the modal's internal flow back to its search step, and hid the modal, all in the same render batch. Resetting the flow remounted the search field, its autoFocus fired, and the app opened a keyboard inside a modal that was already closing.

That is the flicker. Not a leftover from typing, but a keyboard my own code summoned into a dying screen. Its scroll view then went into the recycle pool while that keyboard was still up.

None of that is a bug. A keyboard being up while a screen goes away is ordinary, and the framework is meant to survive it. What it did instead was hand the next screen a view that was still holding the last one's settings.

Building something that fails on demand

An explanation that only reproduces inside a nutrition app is not much use to anyone, and it is not something a framework maintainer can act on. So the next step was the smallest thing that still fails: a modal with the prop and a focused input that kills itself mid-animation, then a plain scroll view that mounts straight afterwards and reports its own geometry.

The detector that cried wolf

Getting the measurement right took longer than finding the bug.

The first version reported failures that were not failures. A scroll view settling after a bounce moves on its own, and sampling at the wrong moment records that jitter as displacement. Several iterations went into separating "this view is still settling" from "this view has been moved by something else".

A detector that reports a bug which is not there is worse than no detector, because it makes the real signal unfalsifiable.

Everything downstream of it, including the controls, would have been noise interpreted as evidence.

Once it was honest, the numbers were unambiguous. A scroll view that never asked for keyboard insets, with the keyboard hidden, reporting a bottom inset of 217.3 points. Its content was 840 points tall in a 234 point window, so the furthest it should ever scroll is 606. It went to 823.

Physical iPhone, iOS 26.5.2, Release build, React Native 0.86.2, New Architecture. The victim sets no keyboard props of any kind.

The controls are the argument

A reproducer that fails is a claim. A reproducer that fails, and stops failing when you remove exactly one ingredient, is evidence.

Two controls, each from a freshly killed process. Turn off the inset prop: nothing. Dismiss the keyboard and let it settle before the modal closes: nothing. Each ingredient is necessary and neither is sufficient. The failure needs a view configured for keyboard insets to be recycled while its observer is still live.

Measuring it instead of reasoning about it

Everything so far was inference, from reading source and watching behaviour. The mechanism deserved a measurement, so I instrumented the framework itself: every keyboard delivery logged with the view's address and whether it was on screen or in the recycle pool.

rec-in  view=0x108118c00 ivar=1          entering prepareForRecycle
rec-out view=0x108118c00 ivar=1          leaving it, flag still set
kbd     view=0x108118c00 ivar=1 POOLED
write   view=0x108118c00 bottom=217.3 POOLED    ‚Üê inset written while pooled
props   view=0x108118c00 old=1 new=0 ivar=0     ‚Üê next screen mounts, flag cleared

The write lands while the view is sitting in the pool, 105ms before anything mounts on it. When a screen does mount, the flag is cleared immediately, so the screen you can see is never written to at all.

That ruled out the explanation I had been carrying. An earlier test, where a poisoned view's scroll position moved after I focused an unrelated text field, had looked like proof that the recycled view was still listening while mounted. It was not. The keyboard changed the layout, the window grew from 234 points to 299, the furthest legal scroll position dropped by 65, and iOS pulled the offset back to the new limit. Arithmetic, not a live listener.

What is actually happening

The pooled view keeps receiving keyboard notifications and keeps writing insets onto itself. It is not stale; it is current. It tracks the keyboard continuously, taking a real value when a keyboard rises and zero when it falls.

Whatever value it happens to be holding at the moment someone inherits it is what that screen is stuck with, because the inset is only reassigned when a component's props change it, and a component that never set the prop has nothing to reassign.

Which means the whole thing turns on timing. Sweeping the delay before the modal tears itself down, ten cycles each from a fresh process:

modal torn down after	corrupt readings	phantom inset
~120ms	36	217.3
~220ms	0	0.0
~320ms	0	0.0
~520ms	0	0.0
keyboard dismissed first	0	0.0

Only the earliest teardown reproduces. Wait longer and the keyboard's own disappearance reaches the pooled view first, zeroes the inset, and the pool quietly cleans itself. The bug needs a screen to mount during the narrow window while a keyboard is up.

That is also why it was intermittent in production, and why it survived earlier testing rounds. Most of the time nothing mounts inside that window.

Why it could not be scrolled back

The phantom inset extends the scrollable range past the end of the content, and that extra region has no view underneath it. So it takes no touches. A drag there produces no scroll events at all.

In the reproducer a sliver of the last row stays visible, so you can grab that and pull yourself back. In the app the scroll views were full screen. Once the content had left the viewport there was nothing to grab, and no gesture in the app could recover it.

A screen recording of the reproducer on a physical device is on the original article: several poison cycles, a scroll up into the space that should not exist, then taps on an unrelated input.

That is the difference between a layout glitch and a screen that is finished until you kill the process.

What happened after filing

I reproduced it unchanged on React Native 0.86.2, the latest release at the time, and filed it as react-native#57755 with a public reproducer.

Two pull requests followed, from people I have never met. The second carries a regression test covering the whole lifecycle, and a Meta engineer imported it for internal review the same morning it appeared.

Its two lines are small: clear the flag when the view is recycled, and stop guarding the assignment behind a props comparison so a recycled view can be re-armed properly. I applied them to the reproducer and ran it on the phone that found the bug in the first place. Baseline immediately before: 36 corrupt readings in 10 cycles. With the patch: 49 cycles, zero.

What I would take from this

The healthy logs were the finding. They eliminated a whole category, which is what turned a flicker into the only lead.

Controls before claims. Any bug can be explained by a plausible story. The question is which single ingredient you can remove to make it stop, and whether you have actually tried removing it.

A detector that lies is worse than no detector. Most of the reproducer work went into eliminating false positives, not into finding the failure.

Instrument the explanation, not just the bug. A story that fits every observation is not the same as a correct one. Mine was in the right place and the wrong moment, and only logging the framework showed the difference.

If you think your own app has this, the checks and the three ways to fix it are in a shorter companion piece.

The reproducer is at github.com/PragathiJ/rn-aaki-recycle-repro.

I write about production engineering and applied AI at pragathijayaram.com.

automaticallyAdjustKeyboardInsets is leaking into your other screens: how to check and fix it

Thu, 08 Oct 2026 08:56:07 +0000

A screen opens normally, then scrolls past the end of its content into empty
space, and dragging in that space does nothing at all. Restarting the app is the
only way out.

If that sounds familiar, this is a React Native framework defect, not your code.
This page is the operational version: how to confirm it, how to find every source
in your project, and what to do. The investigation behind it, including why it
took a while to understand, is here.

Scope. iOS only, New Architecture only. The code involved is the Fabric iOS
scroll view, so the old architecture and Android take different paths.
Reproduced on React Native 0.81.4 and 0.86.2. Filed as
react-native#57755.

What is going wrong

A scroll view that sets automaticallyAdjustKeyboardInsets keeps that behaviour
switched on when React Native recycles its native view. While the view sits in the
recycle pool it carries on receiving keyboard notifications and writing insets
onto itself. The next component to be handed that view inherits whatever value was
there, and nothing puts it back, because a component that never set the prop has
no inset of its own to assign.

The result is a scroll view with extra scrollable space below its content. That
space has no view underneath it, so it takes no touches, which is why you cannot
drag your way back out of it.

Confirm it

The first sign is a keyboard appearing on a screen with nothing focused. That is
the tell, not the bug.

The test is to read the inset on a scroll view that should not have one. Put this
on a screen that sets no insets of its own, scroll it with the keyboard hidden,
and watch the console:

const reported = React.useRef(false);

<ScrollView
  scrollEventThrottle={16}
  onScroll={(e) => {
    // contentInset is iOS-only; on Android nativeEvent has no such field.
    const bottom = e.nativeEvent.contentInset?.bottom ?? 0;
    if (bottom > 0 && !reported.current) {
      reported.current = true;
      console.warn('phantom bottom inset', bottom);
    }
  }}
>
  <View style={{ height: 2000 }} />
</ScrollView>;

Two details decide whether this test is worth anything. The scroll view needs
content taller than itself, or it never scrolls, onScroll never fires, and you
will conclude you are clean without having tested anything. And the reading has to
be gated, because at a 16ms throttle an ungated console.warn buries your log.

A scroll view that never opted in should report zero. Anything else means it is
sitting on a view that came out of the pool still armed.

Find every source

grep -rn "automaticallyAdjustKeyboardInsets" src/
grep -rn "contentInset" src/   # also catches contentInsetAdjustmentBehavior

The second search matters more than it looks. Any prop that writes native insets
belongs to the native view, and therefore to the recycling pool, so a static
contentInset combined with an automatic contentInsetAdjustmentBehavior is the
same class of risk even though it has nothing to do with keyboards. In my own
sweep that turned up a grid component the first search had missed.

Then run both again against node_modules. The pool is per process, not per
module, so a scroll view inside a dependency arms it exactly as well as one of
yours. You can clean your own code completely and still be handed a poisoned view by a library you did not write.

Fix it

Option 1, remove the prop. Handle keyboard layout explicitly instead. This is
what I shipped.

// Before: the flag does the layout, and the native view keeps listening
<Modal visible={visible}>
  <ScrollView automaticallyAdjustKeyboardInsets>
    <TextInput autoFocus />
  </ScrollView>
</Modal>

// After: explicit layout, nothing left armed on the native view
<Modal visible={visible}>
  <KeyboardAvoidingView behavior="padding" style={{ flex: 1 }}>
    <ScrollView contentContainerStyle={{ paddingBottom: 24 }}>
      <TextInput autoFocus={visible} />
    </ScrollView>
  </KeyboardAvoidingView>
</Modal>

The autoFocus={visible} change matters more than it looks. Focusing on mount is
what starts a keyboard animation during modal presentation, which is exactly the
window the defect needs. Watch for the same shape anywhere a modal resets its
internal state as it closes: that can remount a focused field and open a keyboard
inside a screen that is already going away.

One caveat: KeyboardAvoidingView with behavior="padding" inside a Modal
behaves differently depending on presentation style and often wants a
keyboardVerticalOffset. Treat it as a shape to adapt, not a drop-in.

Option 2, keep the prop but dismiss the keyboard first. Dismiss it and let it
settle before the screen unmounts. This came back at zero in the reproducer. It is
narrower than option 1, because it depends on every exit path from that screen
doing the same thing.

Option 3, patch the framework locally. Until the upstream fix ships you can
carry it as a patch-package patch. In RCTScrollViewComponentView.mm, clear the
flag on recycle and assign it on every update instead of only when it changes:

// prepareForRecycle: disarm before the view goes back in the pool
_automaticallyAdjustKeyboardInsets = NO;

// updateProps: drop the old-vs-new condition around the assignment
_automaticallyAdjustKeyboardInsets = newScrollViewProps.automaticallyAdjustKeyboardInsets;

Both lines are needed. The first stops the leak. The second matters because
prepareForRecycle does not reset the stored props, so once the flag is cleared a
view being reused by another component that also wants keyboard insets would
skip the assignment and silently lose the behaviour.

This is the substance of react-native#57811, which a Meta engineer has imported for internal review. I verified those changes against the reproducer on a physical device: 49 cycles, zero failures, where the unpatched build produced 36 failures in 10 cycles.

If you are on 0.86.2 and patching the framework, note that React core ships
prebuilt, so edits to RCTScrollViewComponentView.mm in node_modules never
reach the binary. You need RCT_USE_PREBUILT_RNCORE=0 and a fresh pod install,
or the patch silently does nothing.

What does not work

Scrolling the screen back to the top when it opens. I shipped that early and it
does clear the wrong opening position, which is enough to make it look like a
cure. It does not remove the phantom inset, so the dead space is still waiting at
the bottom.

How to tell you have fixed it

Run the confirmation check again after the flow that used to break things. Zero
inset, and a scroll to the bottom that stops at the end of your content with
nothing beneath it.

The reproducer is at
github.com/PragathiJ/rn-aaki-recycle-repro.

I write about production engineering and applied AI at
pragathijayaram.com.

Native, Kotlin Multiplatform or React Native: how I'd choose

Tue, 06 Oct 2026 08:23:00 +0000

title: Native, Kotlin Multiplatform or React Native: how I'd choose
published: true
date: 2026-09-25 00:00:00 UTC
tags: kotlinmultiplatform,reactnative,android,ios

canonical_url: https://abhishekgoyal.me/writing/native-kmp-or-react-native

“Should we build this in Kotlin Multiplatform or React Native?” is a question teams often ask before anyone has written down what the app has to do. That’s backwards. I’ve shipped all three approaches to production: native Android and iOS apps, a shared Kotlin Multiplatform data layer in HelperBook, and a React Native rewrite of two native apps at Pulse. The framework has never been the first decision. The features are.

Start with the features, not the framework

Before choosing anything, I list what the app actually has to do, and which of those things lean on the platform. Camera capture, video playback, background work, offline data, sensors, OS integrations. Then I weigh each option against that list, along with the team that will maintain it and the time and money available.

Most of the heat in “Kotlin Multiplatform vs React Native” debates comes from people comparing the tools in the abstract. For a specific app, the answer is usually much clearer than the debate suggests.

When I’d stay fully native

Sharing code is not free, so sometimes the right amount to share is none.

The market is on one platform. HelperBook is for Indian households, where Android is the phone most people carry, so it shipped on Android first. Its records still live in a shared Kotlin Multiplatform module with SQLDelight, so an iOS app could reuse that data layer rather than rewrite it, but the app itself is native Android.
The app leans hard on platform APIs. On a video-first hiring platform I built 100% of the Android client, and the core of it was CameraX capture, Media3 playback and on-device speech transcription. That is exactly the kind of work where you want the platform’s own APIs directly, not through a layer.
The two apps look and behave differently. If the Android and iOS versions don’t share much UI or flow, a shared UI codebase saves less than it costs.

When Kotlin Multiplatform fits

Kotlin Multiplatform shares business logic and data while each platform keeps a fully native UI. I reach for it when:

Native apps already exist. You can add a shared module to the apps you have and move code into it gradually, instead of rewriting both.
The team writes Kotlin. Android developers can own the shared code without learning a new stack.
The business logic is complex and must match on both platforms. Rules, calculations and offline data that behave slightly differently on Android and iOS are a bug factory. Writing them once removes a whole class of problems.
Native feel matters. The UI stays Jetpack Compose on Android and SwiftUI or UIKit on iOS.

When React Native fits

React Native gives you one codebase for the UI as well as the logic. I recommend it when the timeline is short and the budget is small, and one team has to ship both platforms quickly. It also makes more sense when the screens are the same on both platforms, and when there’s already a React web team whose skills carry over.

Performance, honestly

People search for “Kotlin Multiplatform vs React Native performance” a lot, so here’s my view. Kotlin Multiplatform keeps the UI fully native, and native UI is smoother. For most business apps (forms, lists, dashboards) React Native is fine, and the difference users feel comes far more from the architecture than from the framework.

I haven’t shipped a Flutter app, so I won’t argue for or against it from experience. It’s a real option; it’s just not one I can speak to first-hand.

What Pulse taught me

At Pulse I owned mobile, Android and iOS, from an early prototype to 100+ B2B enterprise clients. For years it ran as two native apps, Kotlin on Android and Swift on iOS, kept at feature parity. Keeping two native apps at parity meant building every feature twice.

In 2025 I led the rewrite of both apps into one React Native codebase, architected and co-built with the team in six months, and it replaced both native apps in production. React Native fitted the situation: one codebase suited the timeline and budget, the web app was already built in React, and the screens were the same on both platforms.

The hardest part of the port was reliable background uploads, which the offline engine depended on. The inspections could run to 500+ questions and 1,000+ photos, captured offline and uploaded in the background once a connection came back, so the upload behaviour had to be as dependable after the rewrite as before it.

Looking back, React Native was a reasonable call for that timeline, budget and team. Knowing what I know now, I’d weigh Kotlin Multiplatform harder for an app with that much offline logic. The sync rules and the upload queue are exactly the kind of code you want written once and shared, while each platform keeps its own native background APIs.

How I’d decide for your app

If your app…	I’d lean towards
Targets one platform first, or leans hard on camera, video, sensors	Native
Already has native apps, or complex logic that must match on both	Kotlin Multiplatform
Needs both platforms fast, on a small budget, with the same screens	React Native

None of these is a rule. They’re where I start, and the feature list decides the rest. If you’re weighing this for a real app, here’s how I help teams adopt Kotlin Multiplatform, and every engagement starts with a paid discovery sprint that ends in a written recommendation you can use with anyone.

Why I built Animal Sudoku without a single ad

Wed, 30 Sep 2026 12:04:29 +0000

Screen time for children is broken. Most free games trade a childs focus for ad revenue. Flashing banners and loud interruptions shatter concentration during critical learning moments. I built Animal Sudoku Kids Puzzle to be a safe haven for logic.

The problem that bothered me

If you've ever handed your phone or tablet to a child, you know the script:

A "free" puzzle game opens with a 30-second video ad.
A flashing "UPGRADE NOW" button takes up a third of the screen.
A pop-up appears mid-game asking the child to rate the app.
And somewhere, quietly, an SDK is collecting behavioral data on a 5-year-old.

I'm a parent. I'm also an engineer. The combination made me increasingly uncomfortable with what I was seeing — apps designed to capture and monetize children's attention rather than support their development.

I kept thinking: the technology to do this better has existed for a decade. Why isn't anyone just… doing it?

So I built it.

What Animal Sudoku is (and isn't)

It's a kid-first introduction to Sudoku, with three difficulty levels — a gentle 4×4 grid for beginners, a harder 4×4 for the in-between phase, and a proper 6×6 for puzzle-loving 8+ year olds. Six animals, color-coded zones, smart hints when stuck, auto-save so progress is never lost, gentle background music, and a confetti celebration when you finish a puzzle.

There is no "Game Over." There's no time pressure unless the child wants to chase a score. There's no failure state — just exploration.

What it isn't:

❌ No advertising. None. Anywhere.
❌ No third-party analytics or tracking SDKs.
❌ No account creation or sign-up.
❌ No internet connection required to play.
❌ No "watch a video to unlock" mechanics.
❌ No data collected from your child. None. The app is fully COPPA-compliant by virtue of collecting nothing.

The full game is free. There are no required purchases. Future optional theme packs may exist, but the core game stays complete and free forever.

Engineering for Every Child: Accessibility first

Inclusion was not a nice-to-have feature. It was a core requirement from day one. I spent a significant portion of development time ensuring that children with different physical or visual needs could play independently.

VoiceOver and TalkBack Support: Every animal icon and grid cell contains a semantic accessibility label.
Voice Control: Children can navigate the board and place animals using only their voice.
Haptic Logic: I integrated haptics to provide tactile vibrations for every move, allowing children to feel the logic of the game.
Visual Clarity: Large touch targets and high-contrast color zones ensure the interface is easy to navigate for small hands.

If you have small humans in your life

I'd love for you to try it. It's on the App Store, completely free, with no strings attached:

Download Animal Sudoku on the App Store

If you give it a spin with a kid in your life, I genuinely want to hear how it goes — what worked, what didn't, what you wish it did. Reply here, send me a message, or email me directly. Every bit of feedback shapes what comes next.

Animal Sudoku Kids Puzzle is available now on iOS. Android version in development.

New to Bitrise CodePush? Here's What I Wish I Knew Before Setting It Up

Tue, 22 Sep 2026 15:32:27 +0000

New to Bitrise CodePush? Here's What I Wish I Knew Before Setting It Up

If you've never used CodePush before, the idea sounds almost too convenient.

You find a bug in a React Native app, fix the JavaScript, and instead of waiting for another App Store or Google Play release, you can push the update directly to users.

That's the part that got my attention.

But once I actually started setting it up, I realized there are quite a few things that aren't obvious from that one-line explanation.

So if you're new to Bitrise CodePush, here's what I learned while going through the setup.

First: What Does CodePush Actually Update?

The easiest way to think about CodePush is:

It updates the JavaScript and assets in your React Native app without requiring a new store release.

So if you've fixed:

A JavaScript bug
Some text or copy
A small UI issue
Another change that doesn't require native code

You can potentially deliver that fix without submitting a new binary to the App Store or Google Play.

But there's an important boundary.

If you change native code, CodePush doesn't magically bypass the app stores.

You'll still need a normal app release.

That's probably the first thing I'd make sure the team understands before using it.

What Bitrise Actually Gives You

There are two main parts to the setup.

1. CodePush inside Bitrise Release Management

This is where you manage deployments, upload releases, and control things like rollout percentages.

2. The SDK inside your application

@bitrise/code-push-sdk

The SDK is responsible for checking whether an update is available and applying it.

So the basic idea is:

Bitrise handles the release side → your app handles the update side.

Once I understood that split, the rest of the setup made a lot more sense.

Before You Touch the Code

You'll need a Bitrise account and a Release Management app.

One thing that caught my attention here is that Release Management and your normal Bitrise CI app aren't necessarily the same thing.

If you're already using Bitrise CI to build your React Native app, Release Management is something you add alongside it.

And if you're releasing for both iOS and Android, you'll need to account for both platforms in your setup.

I'd recommend getting the basic Release Management setup working before touching the React Native project.

It makes troubleshooting much easier.

Step 1: Create a Deployment

Inside the Release Management app, go to:

Configuration → Deployments → New deployment

For a real project, I'd probably start with:

Staging
Production

That separation is useful.

You don't want to be testing an update and accidentally send it to everyone using the production app.

You can either provide an existing deployment key or let Bitrise generate one.

One thing about deployment keys

This initially confused me.

The deployment key looks like something you'd normally hide in a secret.

But it isn't really a password.

The key eventually gets included in the application, which means someone with access to the built app could potentially extract it.

It's better to think of it as an identifier for the deployment rather than a secret credential.

Your API token is the thing you actually need to protect.

Step 2: Install the SDK

The first command is simple:

npm install @bitrise/code-push-sdk

After that, things depend on how your React Native app was created.

And this is one place where I wouldn't recommend blindly copying configuration from a random tutorial.

Expo and bare React Native aren't configured in exactly the same way.

If You're Using Expo

With Expo, you add the CodePush plugin to your app.json.

You'll need your deployment key and the CodePush server URL.

The URL follows this pattern:

https://<workspace-slug>.codepush.bitrise.io

Then run:

npx expo prebuild

I like doing this step because it lets you check whether the configuration actually made its way into the generated native project.

If You're Using Bare React Native

This takes a little more work.

On iOS, you'll need to make a change in AppDelegate.swift so CodePush can resolve the active release bundle instead of always using the default bundled JavaScript.

You'll also configure the deployment key and server URL in Info.plist.

On Android, the configuration goes into strings.xml, along with some Gradle configuration and a change to how MainApplication.kt resolves the JavaScript bundle.

None of these changes are particularly complicated.

They're just easy places to make a small mistake.

That's why I found it better to follow the Bitrise documentation closely rather than trying to recreate the setup from memory.

Step 3: Think About the User Experience

This was probably the part I didn't think about enough at first.

It's easy to look at CodePush as:

"There's an update, download it."

But you actually have choices about how that update reaches the user.

For example, with:

codePush.sync()

you can use different behaviours.

Silent update

The update downloads in the background and is applied when the app restarts.

For the user, the whole thing can be almost invisible.

Update when the app resumes

Instead of checking only when the app starts, the app can check when it comes back into the foreground.

Interactive update

The user gets feedback that an update is available and can be shown the download process.

For mandatory updates, you can also prevent the user from simply dismissing them.

You can even use progress callbacks if you want to show download progress.

I think this is worth deciding before you ship your first update.

The technically easiest option isn't necessarily the best experience for your users.

Step 4: Build and Release

Once the application is configured, you need to create the JavaScript bundle.

For a bare React Native project:

npx react-native bundle \
--platform ios \
--dev false \
--entry-file index.js \
--bundle-output ./build/main.jsbundle \
--assets-dest ./build

For Expo:

expo export:embed

You then package the generated files and upload them to Release Management.

You can do this manually from the dashboard, which is probably the easiest way to test your first release.

Once you've confirmed everything works, that's when I'd start thinking about automation.

Don't Immediately Send It to Everyone

This is one feature I'd definitely use in production.

When you create the release, you can control the rollout.

You can target specific app versions and use version ranges such as:

1.2.x

or:

>=1.2.3 <1.2.7

You can also mark an update as mandatory and control the percentage of users who receive it.

That last part is important.

Imagine you've made a JavaScript change that you think is completely safe.

Instead of immediately sending it to 100% of your users, you can start with a smaller percentage.

If everything looks good, increase the rollout.

That gives you a little more room to catch problems before they become everyone's problem.

What About Automation?

Once you've manually released a couple of updates, you'll probably notice the repetitive part:

Build the bundle.
Zip it.
Upload it.
Do it again for the other platform.

It works.

But I wouldn't want to do that every week.

That's where Bitrise CI comes in.

You can automate the build and upload process so that a workflow handles it for you.

One approach I like is connecting the release to an approved and labelled pull request rather than automatically releasing every merge.

That gives you a deliberate point where someone says:

"This is ready to ship."

The CI system then takes care of the repetitive work.

I wrote separately about that automation process because there are a few more details around credentials, versioning, and workflow configuration.

My Checklist Before the First Release

If I were setting this up on another project, this is the checklist I'd keep nearby:

Bitrise Release Management is configured

iOS and Android are accounted for

Staging and Production deployments are created

@bitrise/code-push-sdk is installed

Expo or native React Native configuration is complete

The app can successfully check for updates

The sync behaviour has been chosen

The first release is tested with a small rollout

Production releases have an automation plan

So, Is CodePush Worth It?

I think it makes the most sense when you regularly have small JavaScript-level fixes that don't justify going through another full app-store release.

It's not a replacement for your normal mobile release pipeline.

Native changes still need a normal build and store submission.

But if your team has ever had to submit a new mobile build because of something that could have been fixed entirely in JavaScript, that's the gap CodePush is trying to close.

For me, the biggest takeaway wasn't just:

"I can push an update without the App Store."

It was realizing that there are several decisions around how that update gets delivered, who receives it, and what the user experiences when it arrives.

That's the part I'd pay attention to before putting CodePush into a production app.

Have You Used CodePush?

Have you used CodePush or another OTA update solution with React Native?

I'd love to hear how you handled it, especially if you ran into problems during setup.

What would you add to this checklist?

Android System Back Button Closes the App After Upgrading to Target SDK 36 — React Native Fix

Tue, 22 Sep 2026 04:30:24 +0000

If you're maintaining a React Native Android application and recently upgraded your project to target SDK 36 (Android 16), you may encounter an unexpected navigation issue:

Pressing the Android system back button closes the app instead of navigating to the previous screen.

This can be particularly confusing when React Navigation is already configured correctly and the same navigation flow works perfectly on older Android target SDK versions.

This article explains what changed, how to identify the issue, the workaround I used, and what you should consider for a proper Android 16 migration.

The Problem

After upgrading the Android project from an older target SDK to:

targetSdkVersion = 36

the app started behaving differently when using the Android system back button.

For example, suppose the navigation stack is:

Home
  ↓
Products
  ↓
Product Details

When the user presses the Android system back button from Product Details, the expected behavior is:

Product Details
        ↓
    Products

Instead, the application could close.

Interestingly, navigation using React Navigation itself continued to work:

navigation.goBack();

The issue was specifically related to the Android system back event.

Environment

The issue was observed in a React Native application with a setup similar to:

React Native
React Navigation
Android SDK 36
Target SDK 36

The important change was upgrading the Android target SDK to API level 36, corresponding to Android 16.

Why Does This Happen?

The important part of the migration is the Android back-navigation change.

Android has been moving away from the older:

onBackPressed()

mechanism toward the newer:

OnBackInvokedDispatcher

and predictive back navigation APIs.

With newer Android versions and target SDK requirements, applications need to properly participate in the newer back-navigation system.

This can expose compatibility issues in applications or libraries that still rely on the older back handling mechanism.

In a React Native application, the Android system back event eventually needs to be correctly propagated into the React Native / React Navigation layer.

If that doesn't happen, Android may interpret the back action as:

No navigation handler
        ↓
Finish current Activity
        ↓
App closes

instead of:

System Back
     ↓
React Native Back Handler
     ↓
React Navigation
     ↓
Previous screen

How I Identified the Problem

The first thing I checked was whether React Navigation itself was working.

Navigation from the application was working correctly:

navigation.navigate("ProductDetails");

and programmatic back navigation also worked:

navigation.goBack();

The problem only occurred when pressing the physical/system Android back button.

I also checked whether the application was closing directly from the Home screen.

That behavior is expected:

Home
 ↓
Android Back
 ↓
App exits

The actual problem was:

Home
 ↓
Product List
 ↓
Product Details
 ↓
Android Back
 ↓
App exits ❌

instead of:

Home
 ↓
Product List
 ↓
Product Details
 ↓
Android Back
 ↓
Product List ✅

This distinction is important when debugging Android back navigation.

The AndroidManifest Configuration

The Android application can control the behavior of the newer back system using:

android:enableOnBackInvokedCallback

For example:

<application
    android:name=".MainApplication"
    android:label="@string/app_name"
    android:icon="@mipmap/ic_launcher"
    android:enableOnBackInvokedCallback="false">

In my case, setting:

android:enableOnBackInvokedCallback="false"

worked as a temporary workaround.

After adding this configuration, the Android system back button once again started navigating to the previous React Navigation screen instead of immediately closing the application.

Why Does `false` Work?

Setting:

android:enableOnBackInvokedCallback="false"

essentially disables the application's participation in the newer OnBackInvokedDispatcher behavior.

This allows the application to continue using the older back handling path.

Conceptually:

Without the workaround

Android System Back
        ↓
OnBackInvokedDispatcher
        ↓
React Native / Navigation handler
        ↓
❌ Handler not properly triggered
        ↓
Activity finishes
        ↓
App closes

With the temporary workaround

Android System Back
        ↓
Legacy back handling
        ↓
React Native BackHandler
        ↓
React Navigation
        ↓
Previous screen

So the workaround doesn't really "fix" predictive back support.

It tells Android to avoid the newer callback behavior for this application.

Is `enableOnBackInvokedCallback="false"` the Permanent Fix?

Not necessarily.

This is an important distinction.

If your application is targeting Android 16, you should ideally investigate whether your React Native version and navigation dependencies properly support Android's newer back-navigation behavior.

Using:

android:enableOnBackInvokedCallback="false"

can be useful as a compatibility workaround while migrating, but it should not automatically be considered the final Android 16 solution.

The long-term goal should be:

Android 16
      ↓
Predictive Back
      ↓
OnBackInvokedDispatcher
      ↓
React Native
      ↓
React Navigation

working correctly.

Check Your React Native Version

Before adding application-level workarounds, check the React Native version:

npm list react-native

or:

yarn why react-native

Also check React Navigation:

npm list @react-navigation/native

For example:

react-native
@react-navigation/native
@react-navigation/native-stack
@react-navigation/bottom-tabs

Older combinations may have different levels of Android predictive-back support.

It's important to evaluate the complete dependency chain rather than changing only the AndroidManifest.

Check Your `MainActivity`

Also inspect your Android MainActivity.

A typical React Native application may have something similar to:

public class MainActivity extends ReactActivity {

    @Override
    protected String getMainComponentName() {
        return "MyApp";
    }
}

If your application has custom back handling, search the Android project for:

onBackPressed

For example:

grep -R "onBackPressed" android/

Also search for:

OnBackInvokedDispatcher

and:

OnBackInvokedCallback

This helps identify whether custom native code is interfering with the new Android back-navigation mechanism.

Check React Native `BackHandler`

React Native applications can listen for Android back events using:

import { BackHandler } from "react-native";

For example:

useEffect(() => {
  const subscription = BackHandler.addEventListener(
    "hardwareBackPress",
    () => {
      navigation.goBack();
      return true;
    }
  );

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

However, don't add this globally just to hide the problem.

React Navigation normally handles Android back navigation for its navigation stack.

Adding multiple global BackHandler listeners can introduce new problems such as:

Back event being consumed too early
Incorrect navigation
Screens being popped multiple times
Modals not closing correctly
Navigation stack becoming inconsistent

So first determine whether the underlying Android back event is reaching React Native correctly.

A Useful Debugging Test

You can temporarily add a BackHandler listener to determine whether React Native receives the system back event:

useEffect(() => {
  const subscription = BackHandler.addEventListener(
    "hardwareBackPress",
    () => {
      console.log("ANDROID BACK EVENT RECEIVED");

      return false;
    }
  );

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

Then navigate to a screen and press the Android system back button.

If you see:

ANDROID BACK EVENT RECEIVED

then the event is reaching React Native.

If the app closes without the event reaching your JavaScript handler, the problem is likely further down in the Android back-dispatching path.

This is a useful way to separate:

Android back event problem

from:

React Navigation configuration problem

Don't Confuse Home Screen Behavior With a Bug

One important testing detail:

If the user is already on the root screen:

Home

pressing Android Back is normally expected to exit the application.

For example:

Home
 ↓
Android Back
 ↓
App closes

That alone isn't evidence of a problem.

The important test is:

Home
 ↓
Screen A
 ↓
Screen B
 ↓
Android Back

Expected:

Screen B
 ↓
Screen A

If instead:

Screen B
 ↓
App closes

then back navigation is not being handled correctly.

Testing Checklist After Target SDK 36 Upgrade

After upgrading to API 36, I recommend testing all of these scenarios.

Home → List → Details

Press system Back.

Expected:

Details → List

Home → A → B → C

Press Back repeatedly.

Expected:

C → B → A → Home

3. Root screen

Home

Press Back.

Expected:

App exits

Open a modal and press Back.

Expected:

Modal closes

instead of:

App exits

5. Bottom tabs

Test:

Tab A → Tab B → Screen

and verify that system Back behaves consistently with your navigation design.

6. Authentication flow

Test:

Login → OTP → Home

and make sure Back doesn't allow users to incorrectly return to authentication screens.

7. Deep links

Test:

Deep Link → Details

and verify the back stack behaves as expected.

Test using:

3-button navigation
Gesture navigation

Predictive back behavior can differ from traditional button-based testing, so both should be tested.

Temporary Workaround

If your application is currently affected and you need to stabilize the release, one possible temporary configuration is:

<application
    ...
    android:enableOnBackInvokedCallback="false">

After rebuilding the application:

cd android
./gradlew clean
cd ..

Then rebuild:

npx react-native run-android

or use your normal release build process.

For an Expo bare/prebuild project, make sure the generated Android configuration is also correctly reflected in the source configuration you use for builds, rather than relying on a manual change that can be overwritten.

Recommended Migration Approach

Instead of treating the manifest flag as the final solution, I recommend approaching the migration in this order:

1. Upgrade target SDK → 36
          ↓
2. Test system Back
          ↓
3. Check React Native version
          ↓
4. Check React Navigation versions
          ↓
5. Search for custom Android back handling
          ↓
6. Search for BackHandler overrides
          ↓
7. Test predictive back
          ↓
8. Update incompatible dependencies
          ↓
9. Use manifest workaround if required
          ↓
10. Remove workaround after proper migration

This approach makes it easier to identify the actual compatibility problem.

Important Takeaway

Upgrading:

targetSdkVersion

is not always just a build configuration change.

A target SDK upgrade can activate or expose new Android platform behavior.

For Android 16 / API 36, back navigation and predictive back behavior are especially important areas to test.

If your React Native app suddenly starts closing when the Android system back button is pressed after moving to target SDK 36, don't immediately assume that your React Navigation stack is broken.

First determine whether:

Android
   ↓
Back Dispatcher
   ↓
React Native
   ↓
React Navigation

is working correctly.

The following configuration can serve as a temporary compatibility workaround:

android:enableOnBackInvokedCallback="false"

but the preferred long-term solution is to ensure that the React Native and navigation stack properly supports Android's modern back-navigation APIs.

Final Checklist

Before releasing a target SDK 36 build, verify:

[ ] Android system Back navigates correctly
[ ] Root screen exits correctly
[ ] Nested navigation works
[ ] Modals handle Back correctly
[ ] Bottom tabs behave correctly
[ ] Authentication screens behave correctly
[ ] Deep links create the expected back stack
[ ] Gesture navigation works
[ ] 3-button navigation works
[ ] Predictive back behavior has been tested
[ ] React Native version is compatible
[ ] React Navigation dependencies are compatible
[ ] Custom BackHandler logic has been reviewed
[ ] Native onBackPressed() implementations have been reviewed
[ ] OnBackInvokedDispatcher usage has been reviewed
[ ] Any temporary enableOnBackInvokedCallback workaround is documented

Conclusion

Android 16 introduces another step in the evolution of Android back navigation. For React Native applications, upgrading to target SDK 36 can expose problems where the system Back button no longer reaches the JavaScript navigation layer as expected.

If your app starts closing instead of navigating backward, investigate the new Android back-dispatching behavior before modifying your navigation stack.

A manifest-level workaround such as:

android:enableOnBackInvokedCallback="false"

may restore the previous behavior temporarily, but dependency compatibility and proper predictive-back support should be addressed as part of the complete migration.

Target SDK upgrades should always be followed by dedicated navigation regression testing—not just build and installation testing.

✍️ Written by Dainy Jose — React Native Mobile Application Developer with 3+ years of experience building cross-platform mobile apps using React Native (Expo, TypeScript, Redux).
Currently expanding backend knowledge through the MERN Stack (MongoDB, Express.js, React.js, Node.js) to create more efficient, full-stack mobile experiences.

Tech Stack: React Native · TypeScript · Redux · Expo · Firebase · Node.js · Express.js · MongoDB · REST API · JWT · Jest · Google Maps · Razorpay · PayU · Agile · SDLC · Git · Bitbucket · Jira

Connect with me:
Portfolio
LinkedIn
GitHub

Wire AI Is Live: Beta tester open

Fri, 31 Jul 2026 11:29:54 +0000

TL;DR: Wire AI is live and early access is open. It's an AI-native growth engineer for mobile apps: your React Native app embeds an SDK, a LangGraph backend decides what to ask each user next, and deterministic code owns the routing while the model only generates content. On one live app, activation went from 69% to 93%. 15 early-access seats, 3 taken, free and installed by hand.

This article is part of my Code Meet AI newsletter: https://codemeetai.substack.com

Wire AI is live today, and early access is open.

It's the AI-native growth engineer for mobile apps: AI that replaces your growth team. It runs four versions of every step of your users' journey, live at once, and keeps what makes them stay.

On the first app it ran on, activation went from 69% to 93%.

15 seats. 3 are already gone. Free, installed by me personally, and there's no price attached because I haven't set one yet.

Below: what it does, what already shipped, what's still rough, and how to claim one of the 12 that are left.

How it works

Your users' journey has stages. They onboard, they get a plan, they hit their first real win, they get asked for a review. Wire AI runs four versions of each of those stages, live, at the same time. Users are assigned to a version and stay in it, the funnel says which version keeps more of them, and the winner gets promoted.

Then the part a testing tool doesn't do. Every finished journey feeds back in: Wire reads what happened and writes a sharper variant for the next round.

It isn't a dashboard that tells you to go run a test. It's the loop, already running.

What that looks like in your codebase

Your React Native app embeds a small SDK. When a user opens the app, the SDK talks to a backend I run, and that backend decides, one screen at a time, what to ask that specific person next. It renders as native cards. Not a webview, not a chat window bolted onto your product.

At the end it hands your app a structured plan you can save and act on, and every step streams into a funnel you can read.

So instead of writing an onboarding once and guessing for the next two years, you write a config and the AI runs it.

The part that makes it work is boring on purpose. Deterministic code controls the flow and the model only generates content. Routing is a pure function of where the session is, how many questions are left, whether the user is bailing, so the whole flow is testable without a model in the loop.

The AI writes the next question, grounded in every answer the person already gave, and writes the final plan. Everything it emits gets validated against a fixed vocabulary of components before it's allowed anywhere near a screen.

That's the difference between a generative UI demo and something you can put in front of paying users. Most AI UI demos let the model draw whatever it wants and hope. This one gives the model a small, checked job and keeps the state machine in code where it belongs.

What that gets you

A journey that adapts per user. The static onboarding asks everybody the same seven questions in the same order. Wire AI asks what follows from what the person just said, stops when it has enough, and skips what it can already infer.
Experiments that run without you. A/B/C/D variants across the journey, five stages, four arms, twenty combinations, without anybody sitting in a meeting deciding which to try next. This is the direction the product is built toward and I'll be straight about where it sits today, further down.
A funnel you can actually read. Completion, drop by step, time per screen, and the transcript of any individual session so you can read exactly what the AI asked and what the person answered. Most apps at this stage are guessing about where users give up.
You find out who your users actually are. Wire AI reads every session and hands you the patterns: what people came for, which question makes them hesitate, which wording converts. Most founders are still running on a persona doc written before launch.

Our pilot client, and what actually happened

I can't name the app, that's a client boundary I hold. What I can tell you is what it does: it helps people find spots to hang out. Live React Native app, real users, and an onboarding people were quietly dropping out of.

Here's the run, in the order it happened.

We started with an experiment, not a redesign. Three versions of the onboarding running live at the same time, users assigned stickily so nobody got a different flow on their second open, every version chasing the same goal event. Nobody sat in a room deciding which one was better.
The first read was wrong, and the loop is what caught it. One arm came back looking like a 17 point winner. At around fifty sessions that feels like a result, and it's exactly the moment a human growth team ships it and builds the next quarter on top. At scale it was worth about three and a half points. Mostly noise wearing a nice hat.
The version that actually won was the short one. The deep, thorough discovery flow lost to a fast one of about eight screens. On a flow with no real leak in it, where every individual question converts in the high nineties, length turned out to be the only lever that moved anything.
Then the part I didn't expect: we found out who the users actually were. The product context we had written assumed one kind of person, someone new to the city looking for places. The answers said something else. Younger, local, born there, social, budget conscious. My actual reaction, reading the answers: wait, these people already live here. We had spent months onboarding a user who didn't exist.
So we rewrote the messaging to the real one. New product context, questions rewritten for the person who actually shows up, one question cut completely because it was seasonal noise nobody cared about, and a guard added so the AI stops asking the same thing twice in different words.
Three learning loops in, activation had gone from 69% to 93%, and the first movement showed up inside the first week of running live.

Two honest caveats on that number, because it's the one people will quote. It's activation on one app, in one category, over one window, so it isn't a portfolio of case studies and I won't dress it up as one.

And the winning arm's completion rate moved by about thirteen points between generations of the experiment, which is a reminder that you read these numbers per run, never all-time. That lesson cost me a re-read of my own dashboard.

What already shipped

Not a landing page and a waitlist. These pieces exist and run.

The SDK is open source. wireai-rn on npm, MIT licensed, eleven built in components with validated schemas, six adapters for different model providers. Swapping providers is one environment variable, so you're not married to whoever is winning this quarter.
The transport is an open standard. The device and the backend speak Google's A2A over JSON-RPC 2.0, the same contract implemented on both ends. That's how a Python agent graph ends up driving a native React Native screen. One call, one turn, one card.
The backend is a real service. Python, FastAPI, LangGraph. Multi tenant, per app keys with scoped access, session state living outside the process so it scales sideways, data in eu-central-1 because GDPR isn't a Q3 problem.
There's a console. Register an app, edit the config without cutting a release, read the funnel, open any session and read the transcript.
It's tested like something people depend on. The drop in kit runs 630 tests on every merge, and the agent routing has its own eval suite with an accuracy gate, so "the agent got worse" shows up as a failing build instead of a feeling.

First card lands in about 130 milliseconds, against roughly three and a half seconds when I started. Onboarding is the one screen where a spinner costs you the user permanently.

What a seat gets you

If Wire AI doesn't lift your activation, you've paid nothing and you still keep the teardown.

That's the deal in one sentence. Here's everything inside it.

The Activation Teardown, before you commit to anything. I put your existing onboarding through the analysis and send you a report: where people drop, which step leaks, what I would change first and why. It's yours whether you take a seat or walk away, and you don't need to install a single line of code to get it.
The install, done by me, by hand. Up to four hours on a call, in your codebase, together. Not a docs link and good luck. This is the part that doesn't scale, and it's exactly why there are 15 seats and not 500.
Your bugs jump the queue. When you hit something broken, and you will, it gets fixed that day instead of queueing behind everything else. That stops being possible the moment this cohort is full.
A direct line to the roadmap. What gets built next is what early-access apps need next. At this stage that isn't landing-page language, it's just how the queue works, because there is nobody in front of you.
Analytics free to 1 million events a month. Any app, not only early access, and it doesn't expire when the beta does.

No price, and that's deliberate. I'm not deciding what Wire AI costs until early access tells me what it's worth, so nobody in these 15 seats gets priced by a guess.

What I want back

One thing: the truth, while you use it.

When a question the AI asks is stupid, say so. When the console confuses you, say so. When a number looks wrong, say so, and that one is worth more to me than any testimonial you could write.

That's the whole trade. You get the teardown, the install, the queue and the roadmap line. I get the thing I can't buy, which is honest reactions from a real app with real users in it.

If it isn't you, it might be someone you know

All three seats that are gone came warm. Somebody knew somebody. Not one came from a cold email, and I have sent a lot of cold emails, so I've stopped pretending that's the channel.

So if your own app doesn't fit but a name came to mind while you were reading, that's the ask. Forward this to them, or drop the name in a comment and I'll reach out and tell them you sent me.

Anyone arriving through a referral skips the queue and goes straight to a call. And I'll run the Activation Teardown on your app too, even if you never install anything.

Before you say yes, two things you should know

Only the onboarding stage is live and proven. The journey wide experimentation I described up there is the roadmap, not a shipped feature. I'd rather you hear that now than find it out in week two.
I have an open number I can't explain yet. This week my own dashboard read 23% completion on an app that had been finishing north of ninety. I spent a morning on it and I still don't have a clean answer. Best guess is the dashboard, there are two honest ways to compute a completion rate and my headline tile looks like it's reading the wrong one, but I haven't proven it and I'm not going to pretend I have.

Both of those are in a launch post on purpose. The product is deliberately incomplete at this stage, and the fastest way to harden it is with a few real apps inside it rather than a year of me polishing it alone. If that reads as a red flag, this isn't the right moment for you and that's a fair call.

Who this is for

You're a fit if you have a React Native or Expo app that's live, with real users going through an onboarding right now, and you're a solo founder or a tiny team where the person who feels the activation problem is also the person who decides.

It helps if your app already has AI or personalization in it, because then I don't have to sell you the idea and we can go straight to the mechanics.

You're not a fit if you already have a growth team running experiments every week. Genuinely. A larger company passed on this recently for exactly that reason and they were right to. The value here is removing a person from a loop you don't have. If you have the person, you don't need me.

Pre launch is also a bad fit, and I say that with some regret because those are usually the most fun conversations. Without traffic there's nothing for the loop to learn from.

How to claim a seat

Reply to this email. That's the whole process, there's no form and no demo request.

Tell me what your app does and roughly how many people go through onboarding in a week. Two sentences is plenty. If it's a fit I'll send you a time this week. If it isn't, I'll tell you straight instead of quietly moving you into a nurture sequence.

Not sure you qualify? Ask for the teardown anyway. Worst case, you get a report on your own funnel and we both move on.

12 seats left of 15. The cap is real, because the install is manual and I'm the one doing it.

How I make this

I draft with AI. I've written about my workflow more than once and it'd be strange to hide it here. The receipts, the numbers, the decisions and the opinions are mine, the sentences get a drafting partner and then a lot of editing from me. If that disqualifies me for you, fair enough. If it interests you, that's most of what this newsletter is about.

I'm Malik, 9 years building mobile apps, React Native and Expo. I write Code Meet AI, where I show what I'm building with AI and what it costs me. Wire AI lives at getwireai.com, and the SDK is open source.

Lioric: Recent Updates.

Sun, 07 Jun 2026 08:02:48 +0000

Hello Developers!

Recently, I released a new Lioric version 0.1.9

Now our Lioric Widget is completely customizable according to your website UI.

Changes happened in this update:

Now the model props in the Lioric tag are optional; you can just leave those props, our widget automatically takes the model name as "gemini-3-flash-preview." In the future, if we introduce any other models, you can just specify that model using the prop name as "model" as before.
Another major update about Liroic Widget, Now the Liroic Widget is completely customizable, starting from the widget logo to all the colours and Assistant name etc. Now the user can update the colors and the logo according to their website UI.

Updated Tag :

<Lioric
      apiKey="lioric_live_..."
      llmApiKey="your_gemini_api_key"
      assistantName="your_assisstant_name"
      logoSrc="/brand-bot.gif"
      logoAlt="Lioric"
      theme={{
        accentColor: "#2563eb",
        launcherBackground: "#111827",
        userMessageBackground: "#2563eb",
        assistantMessageBackground: "#f8fafc",
        assistantMessageTextColor: "#0f172a"
      }}
      position="bottom-left"
    />

Note: The theme prop is completely optional. If you don't want the customized colors, you can just remove them and use the default colors. same with logoAlt and logoSrc as well. All the customizations are not necessary.

That's all, Thanks!
Stay tuned for future updates with me...

Author/Builder : Vinnugollakoti

Building LifeFast: A Solo Founder's Deep Dive into Fasting App Architecture

Wed, 03 Jun 2026 19:31:21 +0000

title: Building LifeFast: A Solo Founder's Deep Dive into Fasting App Architecture
published: true

tags: reactnative, postgres, expo, healthapp

There's a specific kind of frustration that comes from using a health app that feels like it was built by engineers who've never actually used it.

The timer shows a number. The number counts down. You earn a badge. That's it.

No context about what's happening inside your body. No sense of progression. No genuine reason to keep going beyond the guilt of breaking a streak. Just a countdown and a badge that means nothing by noon.

That frustration is what made me build LifeFast — a fasting tracker that treats users like intelligent adults who deserve to understand their own biology.

This is the story of how I built it. The technical decisions, the real challenges, the things I got completely wrong, and what I'd do differently. If you're building a health app, a mobile product, or just a solo-founder side project trying to become something real — I hope this saves you some time.

The Stack (And Why I Made These Choices)

Let me get the boring part out of the way first, because the choices here shaped everything downstream.

Frontend: React Native via Expo
Backend: Node.js + Express + TypeScript
Database: PostgreSQL
State management: Redux Toolkit + RTK Query
Build: EAS Build (Expo Application Services)
Email: Resend
Payments: Google Play Billing
Push notifications: Expo Push + custom job queue

I picked React Native over Flutter primarily because I'm a JavaScript developer at heart and the ecosystem felt more familiar. Expo specifically was the right call for a solo founder — the managed workflow gets you from idea to TestFlight equivalent without spending a week configuring native build chains. The EAS Build system in particular is genuinely excellent.

PostgreSQL was a non-negotiable. I've seen enough "just use Firestore" projects hit a wall the moment they needed anything resembling a JOIN, and for a health app with users, fasts, weights, water intake, community posts, and notification jobs all needing to relate to each other — a relational database was the only sane choice.

RTK Query for data fetching was one of the better decisions I made early. The automatic caching, invalidation, and optimistic updates it provides out of the box took a huge amount of complexity off the table on the client side. Pairing it with AsyncStorage for persistence meant the app works properly offline without any heroic effort.

The Hardest Part: Modelling Time

Fasting is fundamentally about time. But time in software is famously treacherous — especially when your users are in 40+ different timezones.

The core data model for a fast looks simple:

CREATE TABLE fasts (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id UUID NOT NULL REFERENCES users(id),
  status VARCHAR(20) NOT NULL DEFAULT 'SCHEDULED',
  timezone VARCHAR(100) NOT NULL,
  start_at TIMESTAMPTZ NOT NULL,
  end_at TIMESTAMPTZ NOT NULL,
  actual_start_at TIMESTAMPTZ,
  actual_end_at TIMESTAMPTZ,
  duration_target_mins INT NOT NULL,
  duration_actual_mins INT,
  ...
);

The trap I nearly fell into: storing times as local timestamps without timezone. I'd seen this mistake in other codebases and nearly made it myself anyway. TIMESTAMPTZ stores everything as UTC internally and lets PostgreSQL handle timezone conversion correctly. Combined with storing the user's timezone string ("Africa/Nairobi", "America/New_York", etc.) — this meant every query, every calculation, every scheduled notification fired at the right local time.

The server runs a cron job every 60 seconds:

setInterval(async () => {
  if (cronRunning) return;
  cronRunning = true;
  try {
    await autoStartDueFasts();
    await processDue();
  } catch (e: any) {
    console.error("[cron] tick error:", e?.message ?? e);
  } finally {
    cronRunning = false;
  }
}, 60_000);

autoStartDueFasts() transitions SCHEDULED fasts to ACTIVE when their start_at passes. processDue() fires push notifications from a job queue. The guard (if (cronRunning) return) prevents overlap on slow ticks — simple, and it works.

The Feature That Changed Everything: Metabolic Stages

This is where LifeFast became a different kind of fasting app.

Most fasting timers show you a percentage. 43%. 68%. 100%. These numbers don't mean anything experientially. What actually happens to your body during a fast follows a predictable, fascinating sequence — and if you show users that instead of just a countdown, everything changes.

I defined fasting stages based on published metabolic research:

Stage	Hours	What's Happening
Fed State	0–3h	Digesting, insulin elevated
Early Fast	3–8h	Glycogen depleting, fat burning begins
Fasting State	8–12h	Insulin low, fat oxidation accelerating
Fat Burning	12–18h	Liver glycogen depleted, ketone production starting
Ketosis	18–24h	Ketones measurable, metabolic switch active
Autophagy	24h+	Cellular self-cleaning in full swing

Each stage has a name, a description, a colour, and a start/end threshold. On the client, I compute which stage the user is in at render time based on elapsed hours:

function getFastingStage(elapsedHours: number): FastingStage {
  const stages = [
    { label: "Fed State", color: "#94a3b8", minHours: 0, maxHours: 3 },
    { label: "Early Fast", color: "#38bdf8", minHours: 3, maxHours: 8 },
    { label: "Fat Burning", color: "#fb923c", minHours: 8, maxHours: 18 },
    { label: "Ketosis", color: "#a78bfa", minHours: 18, maxHours: 24 },
    { label: "Autophagy", color: "#34d399", minHours: 24, maxHours: Infinity },
  ];
  return stages.findLast((s) => elapsedHours >= s.minHours) ?? stages[0];
}

Inside the app's circular timer, the active stage label shows in its colour — a glowing cyan or violet or green dot next to the stage name. Users started messaging me: "I just hit Ketosis for the first time!" — not because I told them to care, but because seeing it named and coloured in real time made it real.

That's the difference between showing someone a number and showing them a story about their own biology.

Building the Community Layer

About two months in, I realised I was building a productivity tool when I should have been building a social one. Fasting is hard in isolation. It's dramatically easier when you're doing it alongside people who understand the challenge.

So I built a full community layer: groups, posts, comments, nested replies, likes, and a moderation system.

The schema is relatively conventional, but a few decisions were non-obvious.

Soft deletes for moderation. When a user reports a post and an admin hides it, the content isn't deleted — it's flagged:

ALTER TABLE community_posts
  ADD COLUMN is_hidden BOOLEAN NOT NULL DEFAULT FALSE,
  ADD COLUMN hidden_reason TEXT,
  ADD COLUMN hidden_by UUID REFERENCES users(id),
  ADD COLUMN hidden_at TIMESTAMPTZ;

This means we can review decisions, reverse them, and maintain an audit trail. Hard deletes felt wrong for a moderation workflow.

Pinned posts per group. The query for listing posts handles pinning cleanly:

ORDER BY p.is_pinned DESC, p.created_at DESC

Two-token sort. Pin always wins; recency breaks ties. Simple and fast.

The notification fan-out problem. When a post in a popular group gets a comment, who gets notified? The author only. When a comment gets a reply, the parent comment's author gets notified. I built a lightweight notification_jobs table and a worker that processes it:

CREATE TABLE notification_jobs (
  id UUID PRIMARY KEY,
  user_id UUID NOT NULL REFERENCES users(id),
  kind VARCHAR(50) NOT NULL,
  scheduled_for TIMESTAMPTZ NOT NULL,
  payload JSONB,
  status VARCHAR(20) DEFAULT 'pending',
  attempts INT DEFAULT 0
);

The worker polls every 60 seconds, picks up pending jobs past their scheduled_for time, calls Expo's push notification API, and marks them as sent or failed. Dead simple, fully auditable, no external queue infrastructure needed at this scale.

The Billing Nightmare

I'm going to be honest: Google Play Billing is the worst API I have ever worked with professionally.

The documentation is spread across three different Google sites that contradict each other. The test environment behaves differently from production in ways that are not documented. The error codes are numerical and the mapping table is buried six pages deep in a section titled "Deprecated APIs".

Here's what eventually worked:

Use the google-play-billing library on the React Native side for purchase flow
On the backend, verify every purchase token against the Google Play Developer API before granting entitlements
Store the raw purchase_token and product_id — you'll need both for future verification and refund handling
Handle ITEM_ALREADY_OWNED (error code 7) gracefully — it means the user purchased on another account or device and is more common than you'd think

The verification endpoint on my backend:

router.post("/billing/google/verify", authenticate, async (req, res) => {
  const { purchaseToken, productId, packageName } = req.body;

  const verified = await verifyGooglePurchase(packageName, productId, purchaseToken);
  if (!verified) return res.status(400).json({ success: false, error: "Invalid purchase" });

  const entitlement = getEntitlementForProduct(productId);
  await billingRepo.recordPurchase({ userId: req.user.id, purchaseToken, productId, entitlement });
  await usersRepo.grantEntitlement(req.user.id, entitlement);

  res.json({ success: true, entitlement });
});

The lesson: never grant entitlements on the client side. Always verify on the server. This is not optional.

Shipping: EAS Build and Deployment

The CI/CD pipeline runs on GitHub Actions:

Push to main triggers the workflow
TypeScript compiles, then the Express app is bundled
SSH into the production DigitalOcean Droplet
Pull latest, rebuild Docker container, swap with zero-downtime restart

For the mobile app, EAS Build handles the actual Android build:

eas build --platform android --profile production

Then submit to Google Play via:

eas submit --platform android

EAS Submit directly uploads the AAB to the Play Store internal track. For a solo founder, this is a genuinely transformative improvement over the old "manually drag an AAB file into the Play Console" workflow.

One lesson I'd pass on: set up your production and staging environments early. I shipped several breaking changes to all users before I separated the two, and the user experience was awful. A staging environment you actually test on is not optional — it's the difference between professionalism and chaos.

What I Got Wrong

Email broadcast timing. I sent an announcement to my users about a new release. I wrote the batch-sending code to fire 50 emails in parallel. I had about 250 users at the time. The email API rate limits at 5 requests per second. You can do the math. Half my users got error responses instead of emails, and the 300ms sequential delay I needed was sitting there in the documentation the whole time.

Over-engineering notifications early. I spent a week building a sophisticated notification scheduling system before I had 50 users. The simpler version — a cron job and a jobs table — does the same job. I could have built it in a day and shipped the features users actually needed instead.

Not adding the progress percentage cap sooner. The fasting percentage can technically exceed 100% if someone continues fasting past their target window. For a while, my timer showed "127%" in a progress circle — which is both mathematically accurate and completely absurd. A one-line fix:

const percentage = Math.min(100, Math.max(0, Math.round(progressRatio * 100)));

Users notice things like this. They form impressions of quality from small details. Fix the small things before they become the big things.

The Product Is Alive

LifeFast is available now on Android.

It's free. It tracks your fasting window in real time, shows you your metabolic stage as you progress, logs your water intake, tracks your weight over time, lets you log progress photos, and connects you with a community of other fasters doing the same work.

I built this without a team, without investors, and without a roadmap handed to me by a product manager. Just a problem I cared about, a stack I understood, and enough stubbornness to keep shipping.

If you're building something similar — a health app, a behaviour-change product, anything where timing and user psychology overlap — feel free to reach out. I'd genuinely enjoy the conversation.

Technical Post-Mortem: Debugging AdMob Impression Leaks in an Expo/Firebase Mobile App

Wed, 27 May 2026 11:13:12 +0000

As a mobile developer, shipping an app to production is only half the battle. The real complications begin when analyzing live telemetry and monetization data.

I recently launched a personal intermittent fasting tracker built on React Native (Expo) and Firebase called LifeFast. The app uses an ad-supported model to offset background hosting and real-time community feed sync costs.

After reviewing my first week of live AdMob metrics, I noticed a major bottleneck in the rendering lifecycle: a severe disconnect between Ad Requests and Actual Impressions.

The Data Log
Total Requests: 1.11K (Strong API connectivity)

Match Rate: 70.03% (AdMob is successfully returning inventory)

Impressions: 345 (The bottleneck)

Out of ~770 successfully returned ad units, less than half are registering as viewed by users.

Breakdown by Ad Unit Lifecycle

Interstitials (eCPM: €1.50 | 44 Impressions)
The eCPM here is the highest, but the volume is low.

The Root Cause: The layout logic was attempting to load and display the interstitial simultaneously during screen state transitions. If the user navigates faster than the network request completes, the ad is dropped, resulting in a matched request but zero impressions.

The Fix: Migrating to a pre-loading architecture using ad.load() immediately upon component mount, caching the unit globally, and only executing ad.show() during natural UX breakpoints.

App Open Ads (eCPM: €1.46 | 139 Impressions)
The Root Cause: The current trigger relies heavily on a cold app start. If a user backgrounds the app to check a message and resumes their fast tracking, the lifecycle event isn't consistently capturing the background-to-foreground transition.

The Fix: Listening directly to React Native's AppState changes to ensure the ad logic evaluates state changes from background -> active.

Banner Ads (eCPM: €0.21 | 162 Impressions)
The Root Cause: Standard fixed-size banners are occasionally clipping outside the viewport on varying Android aspect ratios, firing the request script but failing the viewability requirements.

The Fix: Deprecating fixed widths in favor of Adaptive Banners that dynamically calculate the screen width container before requesting the asset.

Marketing an Independent Project on a $0 Budget
The other engineering challenge is organic discovery. Traditional social platforms have highly aggressive automated spam filters that auto-flag direct Play Store links, making standard community outreach unviable.

To bypass this without a marketing budget, I am currently implementing a code-driven viral loop using react-native-share to let users natively export progress milestones to their personal networks, shifting the acquisition logic directly into the application codebase.

For context on the layout implementation or to see how the live UI handles these ad placements, the application is live on the Google Play Store under LifeFast.

If anyone has optimized the match-to-impression ratio inside an Expo ecosystem, I'd be interested in comparing lifecycle architectures in the comments.

Top 4 React Native Image Caching Libraries in 2026

Tue, 19 May 2026 08:39:54 +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.

Parsing hundreds of megabytes of JSON in milliseconds in React Native

Tue, 19 May 2026 08:39:22 +0000

How JSON.parse materializes entire documents in JavaScript, and how react-native-fast-json uses native simdjson + lazy JsonView access to change the cost model in React Native.

react-native-fast-json is an open-source React Native library that wraps simdjson in C++ and exposes a lazy JsonView through Nitro Modules.

Most teams treat JSON parsing as “cheap” because API responses are small. The mental model is:

bytes on wire → JSON.parse → plain objects in JS → app logic

That model breaks when the payload is hundreds of megabytes. The dominant cost is not “JSON syntax is slow” in the abstract, it is allocating and wiring up a full value tree in the JavaScript heap.

What `JSON.parse` actually does in React Native

When you call JSON.parse (or await response.json()), the engine:

Holds the UTF-16/UTF-8 string (or an internal representation of the body)
Walks the entire document
For every object, array, number, boolean, and string, creates JavaScript values with engine overhead (hidden classes, property storage, array backing stores, interned strings, etc.)

For a ~250 MB file, outcomes depend heavily on platform and available RAM:

Symptom	Typical cause
Multi-second freezes	Single-threaded parse + massive allocation on the JS thread
Memory far above file size	JS object graph overhead (often ~2–4× the raw JSON size in bad cases)
OOM / process kill	Peak JS heap + retained tree + rest of the app

On the data_250mb.json fixture in our tests: iOS could complete JSON.parse but only with extreme CPU and memory spikes; Android always crashed before parse finished, making JSON.parse impossible for that payload on Android, while native parseFile worked on both platforms.

Benchmark fixture (source)

Measurements in this repo use the public ~250 MB JSON from antonmedv/json-examples:


Repository	https://github.com/antonmedv/json-examples
File	`data_250mb.json`
Raw URL	`https://github.com/antonmedv/json-examples/raw/refs/heads/master/data_250mb.json`

The example app downloads that URL, caches it on disk, then calls parseFile on the local path.

Measured results (`parseFile`, release builds, physical devices)

Platform	Time to root `JsonView`	CPU / memory (observed)
iOS	~100 ms	Stable, no long CPU peg, no runaway JS heap growth during parse
Android	~500 ms	Stable, same qualitative behavior as iOS, slower wall time

JSON.parse / response.json() on the same fixture:

Platform	`JSON.parse`	`parseFile` + lazy `JsonView`
iOS	Many seconds; extreme CPU and memory spikes (~1.2 GB JS heap ballpark)	~100 ms; CPU and memory stable
Android	Crash, could not complete parse	~500 ms; CPU and memory stable (~400 MB mostly native buffer)

The second row is not “free memory.” The file still occupies roughly file size + simdjson padding in native memory. The win is avoiding a second full copy as a giant JS object graph until you explicitly materialize pieces.

Why “read file as string, then `JSON.parse`” can be worse at peak

A common variant:

const text = await readFile(path, 'utf8');
const data = JSON.parse(text);

At peak you may briefly hold:

The entire file as one JS string
The entire parsed tree
Parser scratch allocations

response.json() can sometimes avoid exposing one giant application-level string, but the end state is still the same: a full tree in JS. For large files, peak heap is the killer.

The technique: how react-native-fast-json does it

react-native-fast-json is what makes the native lazy model practical in React Native. Instead of returning a plain object from JSON.parse, it shifts work across a different boundary:

file bytes → native buffer (simdjson) → JsonView handle → read paths on demand

1. Native buffer (simdjson)

parseFile loads the file into a padded native buffer (simdjson::padded_string::load). Parsing runs in C++ with simdjson (SIMD-accelerated, widely used for large JSON).

The document’s canonical bytes live in native memory, not as nested JS objects.

2. Lazy `JsonView` (Nitro hybrid object)

The root returned to JavaScript is a JsonView, a Nitro hybrid object backed by C++. Calling:

getValue('metadata')
atPath('$.a.b.c')
asString() on a scalar

…does targeted native work and only crosses the bridge with small results (another JsonView handle or a primitive), not the whole document.

3. Materialization is explicit and expensive

When you call:

asObject(), subtree becomes a JS-friendly map/array structure
rawJson(), subtree becomes a JS string

…you have chosen to pay the JS heap cost for that slice. On a 250 MB document, calling these on the root is equivalent to opting back into the problem you avoided.

Architecture

HybridFastJson (cpp/HybridFastJson.cpp):

parseFile(path), load file, construct HybridJsonView, cache by path string
parseString(str), copy string into native view (not path-cached)
release(path), erase cache entry for that path

HybridJsonView, navigation, path helpers, scalar coercion, optional materialization.

Until release(path), a cached parseFile keeps the full native buffer alive even if JS drops its JsonView reference, plan releases when the flow ends.

What you still pay for (honest accounting)

Cost	Still there?
File-sized native memory	Yes, roughly JSON size + padding
Parse CPU	Yes, but native simdjson is much faster than building a JS tree
JS heap for the whole tree	No, unless you `asObject()` / `rawJson()` large parts
Bridge traffic	Per access; keep reads coarse-grained for huge docs
Path cache	`parseFile` retains buffer until `release(path)`

There is no zero memory overhead. The claim that holds up is: near-zero additional JS heap for the full document while you navigate lazily.

Why milliseconds (or low hundreds of ms) are plausible for hundreds of MB

simdjson is designed for throughput on large valid JSON. On the data_250mb.json fixture, parseFile after the file is on disk landed at ~100 ms on iOS and ~500 ms on Android in our release builds, with stable CPU and memory. By contrast, JSON.parse on iOS took many seconds with extreme spikes; on Android it always crashed, so native parse was the only viable option there.

Caveats when you reproduce benchmarks:

Fixture, use the same public file or disclose yours
Cold vs warm storage (first read after download vs re-parse)
Platform, Android was ~5× slower than iOS in our tests; do not assume one number for all devices
Device tier and storage speed
JSON shape (depth, string density) affects constant factors
Debug vs release native builds, ship measurements on release binaries

Comparison table (same fixture, measured + observed)

Dimension	`JSON.parse` (our tests)	Native `JsonView` (`parseFile`)
iOS	Completes after many seconds; extreme CPU/memory spikes	~100 ms; stable CPU/memory
Android	Crash, parse not possible on ~250 MB	~500 ms; stable CPU/memory
Primary memory	Full JS object graph (when it survives)	Native padded buffer (~file size)
UI thread risk	High during parse	Lower; still avoid huge sync work in JS
Best access pattern	Whole-tree mutation	Few paths / scalars / wildcards
Foot-guns	Retaining whole `data`	`asObject()` / `rawJson()` on huge nodes; never calling `release`

Wildcards and paths

atPath('$.a.b.c'), simple dotted segments, no [index] in the path string.
*`atPathWithWildcard('$.items[].id')**, dynamic segments; returns string[] | null` for matched scalar strings.

For very large documents, prefer narrow paths over scanning wildcards across the whole tree unless you have measured the cost.

When native lazy parsing is the wrong tool

Not a common use case, prefer better alternatives

Shipping ~250 MB JSON to a phone is a smell, not a pattern. We benchmark it because it stress-tests the parser and matches real legacy pain, not because every app should do it.

Try these first (usually cheaper than optimizing parse):

Don’t send the file, paginate, stream, or return only fields the UI needs.
Don’t use JSON on the wire, schema-driven binary formats decode faster and smaller.
Don’t keep one blob, SQLite (or similar) with indexes for the queries you actually run.
Don’t parse on the critical path, generate summaries or shards on the server; sync deltas.

Native lazy parsing is a mitigation when you are locked into large JSON. It is not a substitute for a sane data contract.

When this library still does not help enough

Small payloads, JSON.parse is simpler and fast enough.
You need the entire document in JS anyway, you will materialize everything eventually; measure whether native parse + bulk asObject() is still a win.
Heavy in-place mutation of arbitrary subtrees in JS, work on plain objects.
You cannot hold file-sized native RAM (low-RAM devices + multiple huge files), budget and serialize access; even native buffers are ~file size.

Benchmark methodology

import { fastJson } from 'react-native-fast-json';

const root = await fastJson.parseFile('/path/to/large.json');
const version = root?.getValue('metadata')?.getValue('version')?.asString();
fastJson.release('/path/to/large.json');

Fixture, data_250mb.json from antonmedv/json-examples, via
https://github.com/antonmedv/json-examples/raw/refs/heads/master/data_250mb.json
RN Version 0.85.0, New Architecture.
Device, physical iOS and Android (document model, OS, RN version, Hermes on/off).
Build, release native binary.
Scenarios
- A: response.json() or JSON.parse after full string in memory
- B: download/cache to disk → parseFile(localPath) → read N fields → release(path)
Metrics, wall time to root JsonView, JS heap snapshot, CPU/memory stability in Instruments / Android Studio.
Our results, parseFile: iOS ~100 ms, Android ~500 ms, CPU/memory stable. JSON.parse: iOS many seconds with extreme spikes; Android always crashed on this fixture.

The example app implements download + parseFile + timing UI, use it as a starting point, not as universal truth.

Summary

Idea	Detail
Problem	`JSON.parse` materializes the whole document in the JS heap.
Technique	Parse in native with simdjson; expose `JsonView`; read lazily.
Speed	`data_250mb.json`: ~100 ms (iOS) / ~500 ms (Android) for `parseFile` in our tests.
CPU / memory	Stable on native parse; `JSON.parse` had extreme spikes on iOS and crashed on Android for this fixture.
Memory model	Avoid blowing up the JS heap; native still holds ~file size.
Discipline	`release(path)`, avoid huge `asObject()` / `rawJson()`, extract scalars to plain JS when done.

Try react-native-fast-json

yarn add react-native-fast-json react-native-nitro-modules

Install pods, rebuild, then use fastJson.parseFile for large files on disk. Peer dependency: react-native-nitro-modules.

Why Senior Architects are Banning AI from their Learning Stack

Fri, 08 May 2026 13:43:06 +0000

In 2026, the software industry is fiercely obsessed with one metric: velocity. We now have generative tools capable of scaffolding an entire Flutter CRUD application from a single sentence prompt.

But for a Senior Architect, velocity without deep understanding isn't a superpower. It's just technical debt with a faster delivery date. My deep motivation for learning new stacks like migrating from Flutter to React Native and Expo without the aid of AI is incredibly simple: Intuition cannot be outsourced.

To lead a high performing engineering team, you must understand the "metal." You need to know exactly why a frame drops, how memory is allocated and garbage collected in the heap, and the precise mechanics of how the bridge communicates. If an AI writes your code, you aren't actually learning the framework; you are merely learning how to review a machine's guesswork.

The "Black Box" of Automated Development

The real danger of AI-driven development isn't that the code fails to work it's that it frequently works by accident. For enterprise-level applications, this creates three critical, systemic failures:

Architectural Drift: AI fundamentally favors "flat" and expedient structures. It will happily embed complex business logic directly inside UI widgets because that is the shortest mathematical path to a functional output. In a scalable, long-term project, this violates Clean Architecture principles and renders comprehensive testing nearly impossible.
The Debugging Ceiling: When you inevitably hit a high-level performance bottleneck such as noticeable lag rendering a real-time logistics map an AI-reliant developer hits a wall. Because they never manually traced the Widget Lifecycle or fully understood the Render Pipeline, they lack the foundational context required to isolate the root cause.
Dependency Bloat: LLMs frequently suggest outdated, heavy, or bloated packages to solve relatively simple problems that a senior engineer would handle natively perhaps with a custom Dart FFI or a lightweight platform channel.

The Solution: My Blueprint for Manual Mastery

To remain a top-tier engineer, I follow a "Manual First" approach. Here is how I ensure I actually own my knowledge:

Master the Bridge, Not Just the Syntax I don't just learn how to render a list. I learn how the engine (like JavaScript/Hermes) communicates with native threads. Understanding this overhead is the difference between a "working" app and a "smooth" 120fps experience.
Implement Design Patterns Manually Instead of letting an LLM generate boilerplate, I manually implement patterns like BLoC. Writing the events and managing the streams myself builds a mental map of the data flow. This intuition is what allows me to predict bugs before they happen.
Optimize at the Hardware Level True seniority is found where the framework ends and the hardware begins. In my work on the zerocopy package, I used Dart FFI and C++ to eliminate the "copy tax" when handling large binary data. This level of optimization requires a deep understanding of memory that AI-generated code currently cannot replicate.

AI is an Accelerator, Not a Teacher

Don't get me wrong AI is incredibly important. Once you know a stack inside and out, absolutely use AI to write your repetitive boilerplate, generate your unit tests, and speed up your workflow. AI is an unmatched accelerator. But it is a terrible teacher of fundamentals.

If you want to be an Architect who actually leads teams, builds scalable apps, and solves the impossible bugs, you have to build your mental map yourself. You have to write the state management manually. You have to understand how the JS engine actually talks to the native UI bridge. By choosing "Manual Mastery" when learning something new, you aren't being a dinosaur. You're building the foundation required to fix the complex problems that AI will inevitably create.

(Want to see what this looks like in practice? Check out some of my deep-dive work at momarkhan.com).

I'm curious to hear from other devs how do you balance using AI for speed vs actually learning the core of a new framework? Let's talk in the comments.

The Physics of Pixels: Flutter vs. React Native in 2026

Sat, 25 Apr 2026 11:40:52 +0000

By early 2026, the "Ecosystem War" between Flutter and React Native (RN) has effectively reached a stalemate. If you look at GitHub stars, the volume of third-party packages, or the availability of AI-generated boilerplate, the two frameworks appear nearly identical.

However, for senior engineers, the choice is no longer about "which library is more popular." It’s about The Physics of Rendering. When your application hits the performance ceiling, the only thing that matters is who owns the rendering pipeline.

The Universal Rendering Model

Regardless of the framework, every modern UI boils down to a three-layer state machine. Understanding how data becomes a pixel requires looking at this closed loop:

Definition: Defining the state and UI description (JSX / Widgets).
Retention: Persistent objects that manage state and logic (Fiber / Elements).
Computation: The Diffing algorithm that calculates incremental updates.
Consumption: The Rendering Engine that receives instructions and paints pixels.

⚛️ React Native: The "General Contractor" Approach

React’s philosophy is to be the "Brain of Declarative UI," but it lacks its own "hands." It manages the logic but outsources the actual work.

Layer	Implementation	Role & Constraints
Description (JSX/TSX)	Blueprint Snapshot	Immutable descriptions of "what the UI should look like."
Management (Fiber Node)	React Core Dispatcher	Manages state and calculates Diffs. All optimizations (`memo`, `useCallback`) live here.
Execution (Host Environment)	OS / Browser Engine	React has no drawing power. It sends instructions to the host (DOM or Native UI).

The Bottleneck: "The Foreign Agency Problem"

React Native is a UI Manipulation Framework. Because the actual components (Buttons, Lists) are rendered by the OS:

High Communication Overhead: Frequent updates (like high-speed scrolling) require constant "bridging" between the logic and the native UI.
Black-Box Rendering: Because rendering is delegated to Chrome or iOS/Android, React cannot intervene in how a pixel is shaded. This is why complex, custom-path animations can feel "heavy" in RN.

Flutter: The "Sovereign Ruler" Approach

Flutter doesn’t trust the operating system’s components. It brings its own engine to the party.

In Flutter, the "Three-Tree" architecture creates a full-stack closure from configuration to rasterization:

Layer	Object	Core Logic
Blueprint (Configuration)	Widget	Ultra-lightweight, immutable configurations created thousands of times per second.
Skeleton (Infrastructure)	Element	The bridge between the description and the rendered object; holds persistent state.
Rendering (Layout/Paint)	RenderObject	Flutter’s Secret Sauce. It directly handles layout and painting instructions.

The Advantage: Rendering Sovereignty

Flutter utilizes its own rendering engine (evolving from Skia to Impeller). This grants it "Sovereign" powers:

Predictable Performance: Since it doesn't rely on system components, the UI remains perfectly consistent across every device.
Efficient Synthesis: The transition from Widget → Element → RenderObject is highly optimized. Elements reuse RenderObjects whenever possible, drastically reducing the cost of expensive repaints.

The 2026 Decision Matrix: How to Choose?

We no longer choose based on "community size." We choose based on Interactive Depth.

Technical Comparison Matrix

Feature	React Native (Delegated Model)	Flutter (Sovereign Model)
Rendering Granularity	Component-level	Pixel-level
Pipeline Authority	Delegated to Host	Fully Autonomous
Animation Ceiling	Limited by Bridge efficiency	Seamless and Precise
Memory Footprint	Lower (utilizes system UI)	Higher (ships a full engine)

Strategic Recommendation

Choose Flutter if:
- You are building Performance-Intensive Apps: Video editors, high-frequency data dashboards, or precision design tools.
- Visual Consistency is Non-Negotiable: Your design team demands pixel-perfect shadows and filters that look identical on a $200 Android and a $1200 iPhone.
- Gamified UI: Your app requires custom shaders or complex, fluid animations.
Choose React Native if:
- You are building Standard Business Apps: E-commerce, social media, or CRUD tools where native components are already "good enough."
- Web Ecosystem Integration: You need to share heavy logic or hooks between your Web and Mobile teams.
- Dynamic Over-the-Air (OTA) Updates: You prioritize the ability to push logic changes without a full App Store review cycle.

The Final Word: Flutter is Building a World, while React Native is Managing a World. Understanding this distinction is the key to mastering the next era of cross-platform engineering.

author web Organize

Gradle build errors in React Native: what usually wastes the most time

Mon, 06 Apr 2026 16:49:16 +0000

If a React Native Android build fails and the output mentions Gradle, it is very easy to lose time in the wrong place.

The word “Gradle” is so broad that it can hide very different root causes:

version mismatches
plugin resolution failures
dependency conflicts
autolinking problems
corrupted caches
environment issues on the machine
native setup mistakes after upgrades

That is why “Gradle build error” is often less of a diagnosis and more of a category.

I’ve seen this kind of issue enough times to notice a pattern: the biggest time loss usually does not come from the bug itself. It comes from checking the wrong things first.

This is the checklist I would use to avoid that.

The first trap: treating Gradle as the actual problem

When people say “I have a Gradle error,” they usually mean one of two things:

the Android build failed somewhere inside the Gradle process
the terminal output included a Gradle task name, plugin message, or stacktrace

That does not automatically mean Gradle itself is the real root cause.

Very often, the actual issue is one of these:

React Native / AGP / Kotlin / JDK versions do not align
a plugin cannot be resolved
a native library was added but not integrated correctly
autolinking did not generate what the project expects
some Firebase / Android dependency is conflicting with another one
local machine setup is broken

So the first mental correction I make is:

Gradle is the place where the failure appears. It is not always the thing that is actually wrong.

What usually wastes the most time

1. Reading the last line instead of the first useful one

One of the most common wastes of time is staring at the bottom of the output.

The last line usually tells you that the build failed. It does not tell you why.

The useful clue is often earlier:

the first plugin that could not be found
the first unresolved dependency
the first incompatible version
the first task that failed for a concrete reason

If I want to save time, I search for the first meaningful error, not the most dramatic-looking one at the end.

2. Deleting everything before understanding the category of failure

Clearing caches can help sometimes.

But many people immediately do all of this:

delete .gradle
clean the project
reinstall node modules
reinstall Android Studio
reinstall the JDK
reboot the machine

Sometimes that works. But often it just burns time and makes the debugging less focused.

I only treat it as a cache/environment cleanup issue if the error actually points in that direction, such as:

corrupted transforms
temporary workspace move failures
stale artifacts
file locking
download/certificate issues

If the problem is really version alignment or plugin resolution, deleting everything does not solve the core issue.

3. Ignoring version compatibility across the Android toolchain

A lot of Gradle build errors in React Native are really compatibility problems between these pieces:

React Native version
Gradle wrapper version
Android Gradle Plugin version
Kotlin version
JDK version

If one of those is too old, too new, or mismatched with the others, the build can fail even if your app code is completely fine.

This is especially likely after:

upgrading React Native
copying Android config from another project
updating Firebase/native libraries
mixing Expo-related config with bare React Native setup

When the error looks structural, version alignment is one of the first things I check.

4. Looking only at dependencies and ignoring `settings.gradle`

Some failures are not about package versions at all.

They are about plugin resolution and build structure.

If the error mentions things like:

plugin not found
included build not found
configuration of the root project failed
React Native Gradle plugin issues
autolinking/setup task problems

then I go straight to:

android/settings.gradle
root build.gradle
plugin management / includeBuild setup

This matters a lot in newer React Native Android projects, where small mistakes in how the plugin is included can break the whole build.

5. Forgetting what changed last

This is one of the highest-value questions in debugging:

What changed right before the build started failing?

Examples:

added a native package
updated React Native
updated Firebase packages
changed Android config
changed Kotlin/Gradle/JDK versions
modified signing or release setup
switched Expo/native configuration

A lot of time gets wasted when the current error is treated as if it appeared randomly.

Usually it didn’t. Usually something moved.

The shortest path is often to inspect the most recent meaningful change.

6. Blaming Firebase too early when the issue is broader

If the problem started after adding or changing Firebase, it is tempting to assume the whole issue is “a Firebase bug.”

But many Firebase-related Gradle failures are really one of these:

dependency mismatch
version conflict
plugin/config issue
native setup not completed
packaging conflict
outdated Android build setup

So even when Firebase appears in the output, I still treat the build as a full Android build-chain problem until proven otherwise.

7. Treating all native modules as if they install the same way

React Native projects can get fragile when native modules accumulate.

Some libraries rely cleanly on autolinking. Others still depend on:

correct plugin setup
Android manifest changes
Gradle config
native initialization
version-specific setup steps

If the build started failing after adding a package, I do not just ask:

“Did I install it?”

I ask:

“What exact Android expectations did this package add?”

That distinction saves a lot of guessing.

8. Confusing machine/setup problems with project problems

Some Gradle errors are about the project.

Some are about the machine.

That is a major distinction.

I think “machine/setup issue” when the failure points toward things like:

missing SDK components
JDK problems
PATH/environment issues
SSL/certificate/download failures
local permissions
file locking on Windows
Gradle daemon state

If the project build files look normal but dependency downloads fail or local tools are inconsistent, I stop debugging app code and start checking the environment.

A practical mental model

When a React Native Android build fails with a Gradle-heavy error, I sort it into one of these buckets first.

Bucket 1: Build toolchain mismatch

Gradle wrapper
AGP
Kotlin
JDK
React Native version alignment

Bucket 2: Build structure / plugin resolution

settings.gradle
plugin management
includeBuild
plugin not found
autolinking structure

Bucket 3: Native dependency integration

newly added packages
Firebase native setup
Expo/native mix
Android-specific install expectations

Bucket 4: Cache / local environment

corrupted .gradle
locked files
SDK/JDK issues
SSL/download failures
local machine inconsistency

The goal is not to know the exact fix instantly.

The goal is to identify the correct category as early as possible.

What I would not do first

I would not immediately:

rewrite multiple Gradle files at once
downgrade random packages
reinstall everything on the machine
clear every cache without reason
assume the word “Gradle” is the real root cause
ignore the last meaningful project change

That usually increases noise instead of reducing it.

My practical order of checks

If I hit a React Native Android Gradle build error, this is the order I would usually follow:

find the first meaningful error in the build output
identify which category the failure belongs to
check RN / Gradle / AGP / Kotlin / JDK compatibility
inspect settings.gradle and plugin resolution if the error is structural
review the last package or config change
check native module integration expectations
only then treat it as a cache/environment cleanup problem if the error supports that direction

That order usually saves more time than any specific trick.

Final takeaway

The phrase “Gradle build error” often wastes time because it sounds more specific than it really is.

Most of the real causes fall into repeatable patterns:

version mismatch
plugin/build structure problem
native integration issue
cache/environment issue

The faster you identify the category, the faster the fix becomes possible.

React Native Android build failed: what I would check first

Mon, 06 Apr 2026 16:47:53 +0000

If a React Native Android build suddenly fails, the error message is often much less helpful than it looks.

Sometimes it points to Gradle, sometimes to a plugin, sometimes to a dependency, and sometimes it just fails deep inside the Android build process without making the real cause obvious.

I’ve run into this kind of problem enough times to stop treating “build failed” as one issue.

It is usually a category of issues.

This is the checklist I would go through first before changing random files or reinstalling everything.

First: treat build failures as clues, not conclusions

A React Native Android build can fail because of:

Gradle configuration issues
plugin resolution problems
dependency/version mismatches
Kotlin or AGP incompatibility
corrupted caches
autolinking problems
native module integration issues
environment/setup problems on the machine

That means the text BUILD FAILED is not the diagnosis. It is just the start of the diagnosis.

What I would check first

1. Read the first meaningful error, not the last line

One of the easiest mistakes is focusing on the bottom of the terminal output.

The last line usually just says the build failed. The useful part is often earlier:

the first missing plugin
the first unresolved dependency
the first incompatible version
the first task that actually broke

If I see a huge wall of Gradle output, I try to find the first message that clearly indicates what could not be found, resolved, or configured.

That usually narrows the problem much faster.

2. Check React Native / Gradle / AGP / Kotlin compatibility

A lot of Android build failures are really version alignment problems.

I would check whether these pieces actually make sense together:

React Native version
Gradle wrapper version
Android Gradle Plugin version
Kotlin version
installed JDK version

A mismatch here can break the build even when your app code is fine.

This is especially common after:

upgrading React Native
adding or updating native libraries
copying build config from another project
mixing Expo/native config changes

3. Look at `settings.gradle` and plugin resolution first

If the error mentions plugins not being found, configuration failing, or included builds not resolving correctly, I would go straight to:

android/settings.gradle
root build.gradle
plugin management / includeBuild setup

In newer React Native setups, especially around the Gradle plugin and autolinking, small mistakes there can break the entire build.

This is one of the first places I would inspect if the error looks structural instead of library-specific.

4. Check whether this is really a cache problem

Sometimes it is. Sometimes it is not.

I would only treat it as a cache issue when the error actually suggests things like:

temp workspace move failures
corrupted transforms
unexpected stale build behavior
dependency artifacts behaving inconsistently

In that case, I would think about:

Gradle daemon state
.gradle cache corruption
android/.gradle
android/build
whether Android Studio or another process is holding locks

But I would not start by deleting everything automatically unless the error really points that way.

5. Check native dependencies and recently added packages

If the build worked before and stopped working after adding or updating something, that is one of the strongest signals you have.

I would ask:

what changed last?
did I add a native dependency?
did I update Firebase packages?
did I change Expo/native modules?
did I update React Native or Gradle-related files?

That often gives a faster answer than staring at logs in isolation.

6. Watch for autolinking and native module issues

React Native Android builds often fail because a native module was not linked/configured the way the project expects.

This gets more likely when:

mixing Expo modules with bare React Native config
using libraries with native setup steps
upgrading React Native without updating supporting config
relying on autolinking that did not actually complete properly

If the error mentions package resolution, missing generated files, or native tasks around module setup, I would treat autolinking as a serious suspect.

7. Distinguish machine/setup problems from project problems

Sometimes the project is broken.

Sometimes the machine is.

That is an important difference.

I would think about machine/environment issues when the error points toward:

JDK problems
missing Android SDK components
PATH / environment variable issues
SSL / certificate / dependency download failures
local file locking or permissions

That is why a build issue can appear “random” even when the project itself has not changed much.

8. If Firebase is involved, do not assume it is only a Firebase issue

Firebase-related packages can surface as Android build failures even when the deeper cause is one of these:

dependency mismatch
outdated native setup
plugin/version conflict
Gradle packaging issue
release/debug configuration difference

So if the failure starts after adding Firebase or changing Firebase setup, I would still inspect the Android build chain broadly instead of narrowing too fast.

A practical mental model

When I see “React Native Android build failed,” I usually sort the possibilities into these buckets:

Bucket 1: Build system

Gradle
AGP
Kotlin
plugin management
wrapper version

Bucket 2: Native integration

autolinking
native modules
Expo/native mix
Firebase native setup

Bucket 3: Local environment

JDK
SDK
PATH
cache corruption
SSL/certificate/download issues

That mental model helps me avoid random debugging.

What I would not do first

I would not immediately:

reinstall the whole machine setup
randomly edit multiple Gradle files
downgrade several libraries at once
clear every cache without understanding the error
assume the last line in the terminal is the root cause

That usually creates more noise.

My practical order of checks

If a React Native Android build fails, this is the order I would usually go through:

find the first meaningful error in the output
check version compatibility across RN / Gradle / AGP / Kotlin / JDK
inspect settings.gradle and plugin resolution
review the most recent package or config change
check native module/autolinking issues
only then treat it as cache/environment cleanup if the error points there

That order tends to save time.

Final takeaway

“React Native Android build failed” is not one problem.

It is usually one of a few repeated categories:

version mismatch
plugin/config problem
native integration issue
cache/environment issue

The faster you identify which category you are in, the faster the build becomes fixable.

Flutter vs React Native AI Apps: My 2026 Take

Mon, 06 Apr 2026 09:04:35 +0000

This article was originally published on BuildZn.

Everyone talks about how AI will change mobile, but nobody explains which tech stack actually gets you there without burning through your seed round. You’re Googling Flutter vs React Native AI apps right now because you need clarity, not marketing fluff. I spent a solid week building a proof-of-concept for an on-device AI feature last month, wrestling with both frameworks. Here's what actually works, and where each framework shines (or trips).

Why AI-Powered Mobile Apps Aren't Just Hype Anymore

Look, in 2026, if your mobile app isn't at least thinking about AI, it's already behind. It's not about chatbots anymore; it’s about AI-powered mobile app development driving real user value and efficiency. Think personalized content feeds, real-time object recognition, intelligent automation, or even predictive analytics directly on the user's phone.

We’re past the experimental phase. Users expect smart features. Founders, you need to decide if you’re building a product that just uses AI via an API call to OpenAI, or if you're embedding complex machine learning models directly into the app for speed, offline capability, and better data privacy. This choice dictates a lot about your framework, cost, and overall strategy.

Flutter vs React Native AI Apps: The Real Deal for Your Wallet and Timeline

Alright, let's get into the brass tacks. You care about cost, time to market, and how well this thing will perform when it's handling real AI tasks. My experience across over 20 production apps – including FarahGPT with its 5,100+ users and a complex gold trading system – gives me a pretty clear view.

Here’s the breakdown:

Flutter for AI-Powered Apps

Performance: This is where Flutter often wins, hands down, for serious on-device AI. Because it compiles directly to native code, you get near-native performance. When you’re running a TensorFlow Lite model for real-time image processing or audio analysis, those milliseconds matter. The UI stays smooth even when the CPU is churning through ML inferences.
Development Speed & Cost: My team ships fast with Flutter. A single codebase for iOS and Android means half the development effort compared to building two separate native apps. For mobile app framework AI 2026 discussions, this translates directly into lower development costs and faster timelines. One team, one codebase, one set of AI integrations. Simpler to maintain too.
AI Integration:
- On-Device ML: Flutter's integration with TensorFlow Lite is solid. You drop your .tflite model, use the tflite_flutter package, and you're good. For platform-specific features like Apple's Core ML or Google's ML Kit, Flutter's FFI (Foreign Function Interface) or platform channels let you tap into native capabilities directly with minimal boilerplate. Honestly, this direct access is a huge advantage for complex, performance-critical AI tasks.
- Cloud-Based AI: For calling APIs like OpenAI, Google Gemini, or custom ML inference services, both frameworks are equally capable. It’s just standard HTTP requests, which Flutter handles efficiently.

React Native for AI-Powered Apps

Ecosystem & Flexibility: React Native rides on the massive JavaScript ecosystem. If you’re already heavy into web development and have JS talent, the learning curve is shallower. There are plenty of existing JS libraries, and some bridge to native AI SDKs.
Performance: This is where it gets tricky. For basic API calls to cloud AI, React Native is fine. But for intensive on-device machine learning apps, the JavaScript bridge can introduce overhead. When you need to process large datasets or run complex models in real-time, that bridge can become a bottleneck. You often end up writing native modules (Java/Kotlin for Android, Swift/Objective-C for iOS) for performance-critical parts, which defeats the "single codebase" promise and drives up costs.
Development Speed & Cost: Initial setup can be quick if you're familiar with React. However, once you hit native feature requirements or performance bottlenecks for AI, development slows down. You need developers proficient in React Native and native iOS/Android, effectively increasing your team size or skill requirements. This can lead to higher long-term maintenance costs and longer development cycles for complex AI-powered mobile app development.
AI Integration:
- On-Device ML: Requires finding or building native modules that expose TensorFlow Lite, Core ML, or ML Kit to JavaScript. While packages exist (e.g., react-native-tflite-camera), they often lag behind native SDK updates or have limitations. When you need something cutting-edge, you might be building a lot of custom native code.
- Cloud-Based AI: Just like Flutter, React Native handles API calls to cloud AI services perfectly well using standard libraries like Axios or Fetch.

So, who wins for AI?

My take: If your AI strategy leans heavily on custom, on-device machine learning models for real-time processing or offline capabilities, Flutter is the stronger choice. The performance advantage and simpler native integration pathways are a game-changer. If your AI is primarily cloud-based (API calls) and you have an existing JS team, React Native can work, but be prepared for potential hurdles if you later need serious on-device ML.

For founders, this translates to:

Flutter = More predictable costs, faster iteration for complex AI, better performance ceilings.
React Native = Potentially faster initial setup if JS-heavy, but higher risk of costly native refactors for advanced AI needs.

How AI Integration Actually Looks (Not Just Theory)

When we built FarahGPT, the core logic was entirely backend. The mobile app (Flutter, naturally) just sent user input to our Node.js API, which then talked to OpenAI. Simple network calls. That’s a common, effective strategy for many best framework for AI startups.

But what if you're building something else?

Cloud-Based AI (API Calls):
- This is the easiest path. Your mobile app sends data (text, image, audio) to a backend service (your Node.js API, or a direct call to Google Gemini/AWS Rekognition).
- The backend processes it, uses an AI model, and sends the result back to the app.
- Both Flutter and React Native handle this beautifully. It's just HTTP requests. The choice here comes down to your general mobile app strategy, not AI specific issues.
```
// Example: Flutter calling an AI API
Future<String> getAIResponse(String prompt) async {
  final response = await http.post(
    Uri.parse('https://api.farahgpt.com/generate'),
    headers: {'Content-Type': 'application/json', 'Authorization': 'Bearer YOUR_API_KEY'},
    body: jsonEncode({'text': prompt}),
  );

  if (response.statusCode == 200) {
    return jsonDecode(response.body)['response'];
  } else {
    throw Exception('Failed to get AI response: ${response.body}');
  }
}
```
This code is straightforward. React Native would look similar with fetch or axios.
On-Device AI (Local Models):
- This is for scenarios where you need:
  - Real-time processing: Image filters, speech-to-text, object detection that can't wait for network latency.
  - Offline functionality: AI features work without an internet connection.
  - Data privacy: Sensitive data never leaves the device.
- This is where Flutter truly shines for Flutter for machine learning apps. With TensorFlow Lite, you embed the model directly. For example, in my gold trading system, some initial data validation and pattern recognition happened on-device before hitting the main backend.
- Flutter Implementation:
  1. Add tflite_flutter to your pubspec.yaml.
  2. Place your .tflite model in your assets.
  3. Load the model and run inferences.
- React Native Implementation:
  1. Requires react-native-tflite-camera or similar, which might involve linking native modules.
  2. Often involves more complex setup and potential versioning issues with native SDKs.
  3. Performance-sensitive parts might still push you to write custom native modules.

Here's the thing — don't overcomplicate it if you don't have to. Most startups can start with cloud-based AI. Only go on-device if you absolutely need the speed, offline, or privacy benefits.

What Most Founders Get Wrong About AI Apps

I've seen founders waste a lot of cash and time because of some common misunderstandings. Don't be that founder.

Mistake 1: Assuming "AI" means everything happens on the phone.
- Reality: For 90% of use cases, your app just sends data to a powerful AI model running in the cloud. Think about how ChatGPT works – your phone isn't running a large language model. It's hitting an API. Focus on a robust backend API strategy first.
Mistake 2: Underestimating the data required.
- Reality: Your AI model is only as good as the data it's trained on. If you're building a custom AI feature, collecting and curating quality data is often 10x harder than picking a framework.
Mistake 3: Ignoring long-term maintenance costs for native modules.
- Reality: If you pick React Native but end up writing a lot of custom native code for AI, you now have three codebases to maintain (JS, iOS Native, Android Native). Updates, bug fixes, and feature enhancements become much more expensive. Flutter generally avoids this trap by handling native interactions more gracefully.
Mistake 4: Not factoring in security and privacy from day one.
- Reality: If your AI processes sensitive user data, you need to think about encryption, data anonymization, and compliance (GDPR, HIPAA, etc.). This applies to both on-device and cloud AI. Your framework choice won't fix poor security architecture.

Optimizing Your AI App: Beyond the Framework

Picking between Flutter vs React Native AI apps is just one piece of the puzzle. To build a truly performant, scalable, and secure AI app, you need to consider the whole stack.

Backend Choice: For AI APIs, I often lean on Node.js. It's fast, scalable, and great for handling concurrent requests to external AI services or your own custom models. My experience building the backend for FarahGPT and the gold trading system confirms this.
Cloud AI Services: Don't reinvent the wheel. Google Cloud ML Kit, AWS Rekognition/SageMaker, Azure AI services – these provide pre-trained models and managed infrastructure that can save you years of development. Use them, especially in the early stages.
Data Security & Compliance: Crucial for any app, but especially for AI. Encrypt data in transit and at rest. If processing sensitive info, ensure your backend infrastructure meets compliance standards.
Scalability: If your AI app takes off (and hopefully it does!), your backend needs to scale. Plan for serverless functions (AWS Lambda, Google Cloud Functions) or containerized services (Kubernetes) to handle increased AI inference requests.

FAQs

Q1: Which framework is cheaper for an AI startup?

A: For basic cloud AI, costs are similar. For complex on-device AI, Flutter often offers lower overall TCO due to better performance, fewer native development needs, and thus, fewer specialized developers required.

Q2: Can I use existing AI models with Flutter/React Native?

A: Yes, both can consume cloud AI APIs (like OpenAI, Google Gemini). For on-device, Flutter integrates well with TensorFlow Lite directly. React Native typically requires community packages or custom native modules for local ML.

Q3: What if I need super fast, real-time AI processing?

A: If low latency and high throughput are critical, Flutter is generally preferred for its near-native performance when running on-device models. This reduces reliance on network speeds and minimizes UI jank.

Look, by 2026, every app will have some AI baked in. The choice of mobile app framework AI 2026 is critical. My strong opinion? For a serious AI-powered mobile app development project, especially if you foresee needing any significant on-device machine learning or truly custom experiences, Flutter is the clear winner for its performance, developer efficiency, and future-proofing. React Native can get you there for simpler, API-driven AI, but be ready to compromise on performance or budget if you push its limits. Don't let framework hype distract you from building actual value.

Want to talk through your specific AI app idea and figure out the best stack for your budget and timeline? I've been there, done that. Let's schedule a quick call – my calendar link is [Your Calendar Link Here].

[48 Hours Lost] NativeWind + Expo Router = "Couldn't find a navigation context" Nightmare

Tue, 12 Aug 2025 13:38:49 +0000

I just spent nearly 48 hours debugging an error in my Expo Router app that had nothing to do with what the error said.
If you’re using NativeWind + React Navigation + Expo Router — this post is for you. Save your time and sanity.

The Error

"Couldn't find a navigation context."

If you're here, you’ve probably seen this and thought:

"Ah, I must’ve forgotten to wrap something with NavigationContainer."
"Maybe the layout is off."
"Is React Navigation broken?"

Nope. Everything was wired up correctly.

But navigation still refused to work.
Until I discovered that... NativeWind was silently breaking everything.

The Real Culprit: CSS Interop Race Condition

Turns out, certain NativeWind class names trigger runtime CSS parsing at render time.
And if you’re using Expo Router, this creates a subtle race condition:

React Navigation's context hasn't fully initialized yet.
NativeWind starts processing your className string.
React components try to access the navigation context.
Boom. ❌

⚠️ Problematic NativeWind Classes

Here are some of the class names that caused issues in my case:

shadow-* → e.g. shadow-sm, shadow-md
opacity-* → e.g. opacity-50, opacity-70
bg-color/opacity → e.g. bg-white/15, bg-black/30
text-color/opacity → e.g. text-white/80

They work fine in isolation.
But in an Expo Router layout, just one of these can trigger the bug.

The Symptom

If you're hitting any of these:

"Couldn't find a navigation context" errors randomly
App works one minute and crashes the next
Stack traces point to NavigationContainer setup
Nothing makes sense anymore

Check your styles.

✅ The Fix: Use Inline Styles

Replace the problematic class names with direct style props.

❌ Before:

<TouchableOpacity className="bg-white/15 shadow-sm opacity-50">

✅ After:

<TouchableOpacity 
  style={{
    backgroundColor: 'rgba(255, 255, 255, 0.15)',
    shadowOffset: { width: 0, height: 1 },
    shadowOpacity: 0.05,
    shadowRadius: 2,
    opacity: 0.5
  }}
>

This completely solved the issue in my project.

Tech Stack

This bug showed up in this combo:

Expo Router v5+
NativeWind v4+
React Navigation v6+
React Native (latest)

Why This Matters

The error message is misleading
It’s timing-dependent — the app may break or work based on device speed or render cycles
You waste hours debugging the wrong thing

✅ What I Did

Stripped it down to a minimal reproducible repo
Posted the issue to NativeWind GitHub
Writing this article to save you from going through it too

Final Thoughts

I love NativeWind.
I love Expo Router.
But the two don’t always play nice — and when they don’t, it can really mess with your head.

If you hit weird nav context issues in your app:
✅ Check your layout
✅ Then check your NativeWind className
✅ And maybe… just go inline

Have You Seen This?

If you’ve hit this bug (or others like it), drop a comment.
If this saved you time, please share it — I genuinely hope it helps someone avoid what I went through.

Thanks for reading.

Tags:

#reactnative #expo #nativewind #reactnavigation #debugging #cssinterop #mobiledev #javascript

Coder Legion - Recent posts tagged reactnative

Two native apps into one React Native codebase in six months

The bug that survived being recycled: automaticallyAdjustKeyboardInsets and Fabric view recycling on iOS

The evidence that was missing

The screen that broke was not the screen at fault

Where the keyboard came from

Building something that fails on demand

The detector that cried wolf

The controls are the argument

Measuring it instead of reasoning about it

What is actually happening

Why it could not be scrolled back

What happened after filing

What I would take from this

automaticallyAdjustKeyboardInsets is leaking into your other screens: how to check and fix it

What is going wrong

Confirm it

Find every source

Fix it

What does not work

How to tell you have fixed it

Native, Kotlin Multiplatform or React Native: how I'd choose

canonical_url: https://abhishekgoyal.me/writing/native-kmp-or-react-native

Start with the features, not the framework

When I’d stay fully native

When Kotlin Multiplatform fits

When React Native fits

Performance, honestly

What Pulse taught me

How I’d decide for your app

Why I built Animal Sudoku without a single ad

The problem that bothered me

What Animal Sudoku is (and isn't)

What it isn't:

Engineering for Every Child: Accessibility first

If you have small humans in your life

New to Bitrise CodePush? Here's What I Wish I Knew Before Setting It Up

New to Bitrise CodePush? Here's What I Wish I Knew Before Setting It Up

First: What Does CodePush Actually Update?

What Bitrise Actually Gives You

1. CodePush inside Bitrise Release Management

2. The SDK inside your application

Before You Touch the Code

Step 1: Create a Deployment

Android System Back Button Closes the App After Upgrading to Target SDK 36 — React Native Fix

The Problem

Environment

Why Does This Happen?

How I Identified the Problem

The AndroidManifest Configuration

Why Does false Work?

Without the workaround

With the temporary workaround

Is enableOnBackInvokedCallback="false" the Permanent Fix?

Check Your React Native Version

Check Your MainActivity

Check React Native BackHandler

A Useful Debugging Test

Don't Confuse Home Screen Behavior With a Bug

Testing Checklist After Target SDK 36 Upgrade

1. Normal navigation

2. Multiple navigation levels

3. Root screen

4. Modal

5. Bottom tabs

6. Authentication flow

7. Deep links

8. Android gesture navigation

Temporary Workaround

Recommended Migration Approach

Important Takeaway

Final Checklist

Conclusion

Wire AI Is Live: Beta tester open

How it works

What that looks like in your codebase

What that gets you

Our pilot client, and what actually happened

What already shipped

What a seat gets you

Why Does `false` Work?

Is `enableOnBackInvokedCallback="false"` the Permanent Fix?

Check Your `MainActivity`

Check React Native `BackHandler`

What `JSON.parse` actually does in React Native

Measured results (`parseFile`, release builds, physical devices)

Why “read file as string, then `JSON.parse`” can be worse at peak

2. Lazy `JsonView` (Nitro hybrid object)

4. Looking only at dependencies and ignoring `settings.gradle`