DEV Community: Russel Dsouza

How to Publish Your Lovable App to the App Store (Without Rebuilding It Yourself)

Russel Dsouza — Wed, 22 Jul 2026 09:43:09 +0000

Lovable builds a web app. The App Store distributes native apps. That's a category gap, not a skill gap.
WebView wrappers feel wrong (scroll momentum, transitions, haptics, back gesture) and risk rejection under App Store Guideline 4.2.
The real fix is a React Native + Expo rebuild — plus certificates, provisioning profiles, signing keys, screenshots, and metadata.
If your Lovable app uses Supabase, a native rebuild can point at the same project. No migration needed.

You built something in Lovable over a weekend. It works. You sent the link to friends and they said "wait, you built this?"

Then someone asked: "Is it on the App Store?"

That's where most Lovable projects stall.

Why you can't submit a Lovable app to the App Store directly

Building an app and shipping an app are two different projects.

Lovable is excellent at the first one. But the App Store distributes native apps, and Lovable produces a web app. That's not a skill gap — it's a category gap.

To publish, you need:

An Apple Developer account ($99/year)
A bundle identifier
A distribution certificate and provisioning profile
A signed .ipa binary
Screenshots at every required device size
A privacy nutrition label and data-usage disclosure
A human reviewer who might say no

None of that comes out of a web app builder.

Why wrapping it in a WebView doesn't work

The obvious shortcut is a wrapper: put the web app in a native shell and ship the shell. Two problems.

It feels wrong. Scroll momentum is off. Transitions don't match the platform. Text inputs behave like a browser instead of a native keyboard. No haptics. The back gesture doesn't do what a thumb expects. Users can't name it, but they register it as "website in a box."

Apple notices too. Guideline 4.2 exists specifically for repackaged websites that don't provide enough native value. Plenty of wrappers slip through, but you're rolling dice on review — and each rejection costs a full cycle.

What a real conversion actually involves

The honest answer is a native rebuild: React Native + Expo, real navigation, real gestures, real device APIs (camera, push, the rest).

Technically that's the right call. Practically it's where projects die — you spent two days building the product and you're now looking at learning the entire Apple release toolchain, or paying someone who already has.

That mismatch is the whole problem. The building was fun and fast. The shipping is neither.

If you'd rather hand that part off, RapidNative converts Lovable apps to React Native and handles the full submission — signing, screenshots, metadata, the lot. You get a preview build on your device first, the full Expo source code afterward (no lock-in), and rejections are handled at no extra cost until you're approved. Typical turnaround is 1–2 weeks.

Worth noting for anyone doing this themselves too: if your Lovable app already talks to Supabase, you don't need to migrate anything. Point the React Native app at the same project and your data layer is done.

The takeaway

Building and shipping are separate problems. Being good at one tells you nothing about how hard the other will be.

Lovable made building dramatically easier. Apple's requirements haven't moved — and Google added a 12-tester closed-testing gate on top.

If your app is stuck one wall away from the store, that's not a verdict on your product. It's just a different category of work than the one you finished.

Been through App Store submission yourself? Which screen broke you? Mine was the privacy nutrition label.

5 Places Sensitive Data Leaks in a React Native App (and How to Plug Them)

Russel Dsouza — Tue, 21 Jul 2026 07:49:01 +0000

The leaks that matter usually aren't in production code — they're in the workflow around it.
Five common ones: AsyncStorage for tokens, real user data in design mockups, multi-stage AI pipelines, logs and crash reports, and bundled permissions.
Two greps that find real bugs today: AsyncStorage.setItem near token, and console.log(user / console.log(token / console.log(prompt.
Model consent by purpose, not by OS permission. Camera consent is not AI-summarization consent.

Data protection posts usually focus on the shipped binary. Encrypt this, pin that certificate, wrap the API client. All correct, all necessary — and all too late if the leak happened three weeks earlier in a design mockup.

We build AI-generated React Native apps at RapidNative, and the interesting security bugs almost never live in production code. They live in the space between code, design, and AI workflows. Here are five leak points we've watched teams miss.

1. AsyncStorage for anything sensitive

The classic. AsyncStorage is convenient, unencrypted key-value storage. A user session token in AsyncStorage is one rooted device or one iCloud backup extraction away from being replayed.

Fix: use expo-secure-store (Keychain on iOS, Keystore on Android) for anything that unlocks an account.

import * as SecureStore from 'expo-secure-store';

export async function saveSessionToken(token) {
  await SecureStore.setItemAsync('session_token', token);
}

If your codebase greps positive for AsyncStorage.setItem and token, that's your first PR.

2. Real user data in design prototypes

A designer opens Figma, needs a realistic list, and pastes 20 rows from the production customer export. Now customer names sit in the design file, which sits in a Figma team folder, which was shared to a contractor's personal email nine months ago.

Fix: a synthetic data script committed to the repo. npx generate-mocks users 20 should be faster than exporting production data. Make the fast path the safe path.

3. Multi-stage AI workflows

Voice memo lands. Transcription service returns text. A second model extracts tasks. Teammates get pinged.

That's four handoffs, and the security review probably only covers the API endpoint at step 1.

Fix: draw the pipeline as boxes, list what data each box sees, and confirm each hop has access controls tied to the user's actual consent — not a bundle. Camera consent is not AI-summarization consent.

4. Logs and crash reports

Sentry, Bugsnag, Datadog, or whatever log aggregator you use sees everything the app hands it. Session tokens in Authorization headers. AI prompt bodies with user text. Full user IDs in breadcrumbs.

Fix: scrub before you send. Most SDKs support a beforeSend hook.

Sentry.init({
  beforeSend(event) {
    if (event.request?.headers) delete event.request.headers.Authorization;
    return event;
  },
});

Grep your codebase for console.log(user, console.log(token, and console.log(prompt. That's your second PR.

5. Bundled permissions

You ask for camera on onboarding: "we need this for document capture." The user agrees. Six months later a new AI-summarization feature ships that also uses camera frames.

Same permission, different purpose. Legally shaky (GDPR Article 25 asks for data minimization by design), and practically a betrayal of what the user thought they said yes to.

Fix: model consent as a first-class type, keyed on purpose rather than on OS permission:

type ConsentEvent = {
  userId: string;
  action: 'granted' | 'withdrawn';
  policyVersion: string;
  purpose: 'document-capture' | 'ai-summary' | 'marketing';
  surface: 'onboarding' | 'settings' | 'feature-gate';
  timestamp: string;
};

Ship a new feature, ask again for that purpose. A one-line inconvenience for the user beats the €7.1B in GDPR fines the EU has issued as of January 2026.

The pattern

Notice what the five have in common: none of them are broken TLS, weak crypto, or a mangled JWT signature. They're all workflow leaks.

Encryption and pinning are table stakes. The bugs that leak your customer's data in 2026 are the ones nobody put in the security review — because they happen in Figma, in a Slack DM, in a Sentry payload, or in an AI pipeline diagram that was never drawn.

Draw the diagram. Grep the logs. Model consent. Ship.

Full source with the OWASP and NIST references: rapidnative.com/blogs/data-protection.

Which of the five would your codebase fail right now? Mine failed #4 the first time I checked.

You Don't Need 10 Refactoring Tools. Pick 2 From This Decision Tree.

Russel Dsouza — Tue, 21 Jul 2026 07:35:58 +0000

Answer three questions — scope of change, how type-heavy your codebase is, and who runs it — and the tool choice collapses to two.
Solo TS-heavy repo: VS Code + ts-morph. Small team, one repo: WebStorm + jscodeshift. Multi-repo org: ast-grep + Sourcegraph Batch Changes.
You can skip Babel, Comby, OpenRewrite/Moderne, and ReSharper unless you're in their specific ecosystem.
Tool sprawl is a symptom: if you're debating 10 tools, the real gap is that nobody's defined what's worth automating.

Every "best refactoring tools" post in 2026 gives you the same 10 names and lets you sort them out.

But 51% of developers now use AI coding tools daily, and the refactoring-tools market is on track from $1.74B to $5.82B by 2033. That growth means more tools, not clearer choices.

Here's a smaller frame. Answer three questions, pick two tools, ignore the rest.

The 3 questions

Scope of the change?

One file, minutes of work: your IDE
Same rewrite across many files: a codemod
Same rewrite across many repos: a batch orchestrator

How type-heavy is your codebase?

Loose JS or mixed languages: AST / pattern tools
Strict TypeScript: type-aware transforms

Who runs it?

Solo: CLI is fine
Team: you need a shared recipe and review flow

The 2-tool stacks

Solo dev, TypeScript-heavy React Native repo. Pick VS Code (rename, quick fixes, everyday cleanup) and ts-morph (type-aware programmable rewrites for the times VS Code's rename gives up). Two tools, both free, both scriptable.

Small team, one repo, repetitive structural changes. Pick WebStorm (symbol-aware preview so nobody merges a broken rename) and jscodeshift (AST codemods for the "convert 200 class components to hooks" problem). WebStorm covers day-to-day, jscodeshift covers migrations.

Multi-repo org, needs consistency. Pick ast-grep (structural search-and-replace fast enough to run in CI) and Sourcegraph Batch Changes (turns a codemod into PRs across every repo). One writes the change, the other ships it everywhere.

What you can skip

Babel, if you're not building a plugin. It's a compiler with a refactoring side-quest, not a refactoring tool.
Comby, if your repo is mostly one language. Its edge is cross-language pattern matching.
OpenRewrite and Moderne, if you're not on the JVM. Excellent recipes, wrong ecosystem.
JetBrains ReSharper, if you're not shipping .NET backends. If you are, you already own it.

The real lesson

Tool sprawl is a symptom.

If your team is debating which of 10 refactoring tools to standardize on, the actual problem is that nobody has defined what kinds of changes are worth automating.

Pick a scope, pick a scale, pick two tools. Ship a codemod. Learn what breaks. That's the loop.

If you want the full 10-tool breakdown with when-to-use-each, we wrote it up here.

What's your two-tool stack? Drop it in the comments — curious what people actually settle on.

Prompt-to-App Is a Lie — Here's What Actually Happens

Russel Dsouza — Wed, 15 Jul 2026 13:02:07 +0000

You type a sentence. Twenty seconds later there's a "React Native app." That's the pitch every prompt-to-app tool ships with in 2026 — Lovable, Bolt, v0, Replit Agent, and the rest. This post is about what actually happens after the demo screen.

Prompt-to-app tools generate a live-reloading UI in a sandbox against a mocked backend. They do not generate:

A real auth system with sessions, password reset, and OAuth
A database you own with migrations and RLS
Stripe wiring with real webhooks and Apple IAP handling
An .ipa or .aab you can submit to a store
The Apple Developer certificate needed to ship

Which is roughly 90% of the actual work.

What the demo shows vs. what production needs

Demo	Production
UI in a web preview	Signed `.ipa` + `.aab` submitted to two stores
Mocked API + sample data	Postgres with migrations, backups, RLS
One screen	Deep linking, push, background tasks, offline sync
Preview URL	Real accounts, OAuth, password reset
No integrations	Stripe, IAP, RevenueCat, Sentry, analytics
No secrets	Secret storage, key rotation, review notes

The three walls

Auth. The "Sign In" button works in the preview. It doesn't do anything real. Wiring actual OAuth + sessions + RLS is a rewrite of the data layer.

Payments. On iOS, selling anything digital requires Apple IAP, not Stripe. The tools don't know or care. You'll write this yourself, and it's a two-week job when you factor in webhook handling and license grants.

Submission. No agent creates an Apple Developer certificate. No agent captures screenshots at five device sizes. No agent replies to reviewer feedback. This is 30% of any app.

Why the demo works and the app doesn't

Architecture drift. AI-heavy codebases show 39% higher code churn — code reverted or heavily rewritten within two weeks. LLMs have no persistent memory of the constraints they set twenty prompts ago. They redefine User in three files.

Hidden state. The "backend" is a black-box datastore the tool provisions. You can't run migrations. You can't add a trigger. You can't set up Supabase-style RLS.

Stack lock-in. Most tools are aggressively opinionated. v0 outputs React + Tailwind. If you need Expo, native modules, or actual app store distribution, you're outside the happy path.

No distribution story. Docs for eas submit exist because submission is a real, human-mediated process. No prompt generates it.

The workflow that actually ships

# 1. Start from a template that owns the boring stuff
git clone <template-repo> my-app
cd my-app
bun install

# 2. Point your agent at the repo
# Claude Code, Codex, Cursor, whatever
# Templates ship with .claude/skills/ so the agent knows the conventions

# 3. Extend, don't invent
# "Add a photo upload feature to the events screen"
# "Wire the settings screen to the existing Stripe customer portal"

# 4. Ship
eas build --platform all
eas submit

The agent is in this workflow. It just isn't inventing the architecture.

The split that works

// The template owns things like this:
import { supabase } from "@/lib/supabase";
import { requireAuth } from "@/lib/auth";

export async function uploadNote(userId: string, blob: Blob) {
  await requireAuth(userId);
  return supabase.storage.from("notes").upload(`${userId}/${Date.now()}`, blob);
}

// The agent adds features on top:
export async function shareNoteAsPdf(noteId: string) {
  const note = await getNote(noteId);
  const pdf = await renderPdf(note);
  return uploadNote(note.userId, pdf);
}

The template's supabase, requireAuth, and storage.from("notes") are load-bearing infrastructure. They already work. They already have RLS. The agent's job is the last function, not the first three.

When prompt-to-app is actually fine

Marketing pages and landing sites (v0 is great for this)
Prototypes for design review
One-off internal tools without auth or payments
Learning what components look like

Prompt-to-app is a rendering technology. It's not a shipping technology. Use it for what it's good at.

FAQ

Q: Are prompt-to-app tools useless?
No. Great for prototypes and marketing pages. Poor fit for shipping real mobile apps.

Q: Won't they get better?
Some of it, over years. Code signing and App Store review aren't things LLMs prompt their way through. Bet on agents inside real projects, not agents inventing them.

Q: What stack should I pick?
Expo, TypeScript, Supabase, NativeWind, Stripe (+ Apple IAP for digital goods). Boring, well-documented, agent-friendly.

I keep a set of Expo + Supabase templates wired for exactly this workflow at Applighter.

What's the wall that cost you the most time — auth, payments, or submission? Drop it in the comments.

AI Coding Agents Need a Foundation, Not a Canvas

Russel Dsouza — Wed, 01 Jul 2026 13:10:48 +0000

Same prompt, two repos: blank Expo repo → 47min / $5.20 / un-mergeable; wired foundation → 11min / $0.85 / mergeable.
The model didn't get smarter. The repo got more legible.
AGENTS.md helps ~4% (hand-written) or hurts 2–3% (LLM-generated), per a 138-repo / 5,694-PR study. Both add >20% to token cost. It's not the fix.
A real foundation ships one visible convention per cross-cutting concern, typed boundaries, one way to do each thing, pre-installed skills, and a working end-to-end path.
The evaluation heuristic: "Open the repo and ask Claude Code to add a screen. If the first thing the agent does is install three packages, the foundation is decorative."

Cold open

I had a working theory that the gap between coding agents that "feel useful" and coding agents that "feel like a coworker" was a model gap. Smarter base model, better tool use, longer context window. The usual story.

Then I ran the same prompt against two different repos and the theory died on contact.

The prompt was: "Add a weekly summary screen that fetches the last seven days of data from Supabase and renders a bar chart." Mid-tier feature, nothing exotic. I ran it against a fresh npx create-expo-app and against a fully wired React Native / Expo / Supabase foundation.

Same model. Same prompt. Two completely different sessions.

On the blank repo, the agent installed three chart libraries, picked one, then quietly imported a different one in the second file it wrote. It hardcoded the Supabase URL. It invented an api/ folder, then later invented a services/ folder, then never used either. After 47 minutes and roughly $5.20 in tokens, it produced 600 lines of code I would not merge into anything.

On the foundation, the agent did something that, at first, felt anticlimactic. It opened one existing screen, read it, and then wrote one new screen that looked exactly like the existing one. Same chart primitive. Same data fetcher. Same file structure. 11 minutes. About 85 cents in tokens. Mergeable on the first read.

The model hadn't gotten smarter. The repo had gotten more legible.

The blank-canvas problem, named

Every coding agent — Claude Code, Cursor, Codex, Windsurf, the lot — is doing roughly the same thing under the hood. It reads the repo, then writes code that "fits." When the repo has shape, "fits" means matching the shape. When the repo has no shape, "fits" means matching the median of the public internet.

The public internet is a thousand React Native tutorials, each of which makes different micro-decisions. State library: Redux, Zustand, Jotai, Recoil, Context. Data fetching: TanStack Query, SWR, raw fetch, Supabase client wrappers. Navigation: Expo Router, React Navigation, stack vs. tabs vs. drawer. Theming: NativeWind, styled-components, StyleSheet, restyle. The "median" picks one of each, often differently per file.

This is the blank-canvas problem. The agent does not fail because it is dumb. It fails because every choice is open and the choices don't compose.

The AGENTS.md cul-de-sac

The current industry answer is AGENTS.md — a Markdown file at the root of the repo describing your conventions. I have written several. They help, in the way that a sticky note on the fridge helps. They do not solve the problem.

The numbers are unkind. A study earlier this year analyzed AGENTS.md impact across 138 repositories and 5,694 pull requests. The headline:

LLM-generated AGENTS.md files hurt agent performance by 2–3%.
Hand-written AGENTS.md files improved performance by 4%.
Both raised token costs by 20%+.

4% is not the breakthrough you were hoping for. It's noise.

The intuition behind why is straightforward once you sit with it: prose about code is a weaker signal than code itself. An agent that reads three screens which all use the same data fetcher infers, very confidently, that the fourth screen should use the same fetcher. An agent that reads a sentence in AGENTS.md saying "use the data fetcher in lib/" sometimes does, sometimes doesn't.

The pattern is the prior. The AGENTS.md is a cache.

What an actual agent-ready foundation contains

The phrase "agent-ready" is doing a lot of work in boilerplate marketing. Here is what it should mean, concretely:

1. Visible conventions

Every cross-cutting concern — auth, data fetching, navigation, theming, state, payments, push — appears in at least one fully wired screen. The agent has a working example to copy. Not three contradictory examples. Not one half-finished example. One canonical example.

2. Typed boundaries

// Supabase generated types — the agent cannot fake its way past these
export interface Database {
  public: {
    Tables: {
      daily_summaries: {
        Row: {
          id: string;
          user_id: string;
          date: string;
          total_calories: number;
          // ...
        };
        Insert: { /* ... */ };
        Update: { /* ... */ };
      };
    };
  };
}

If the agent calls a column that doesn't exist, tsc fails. The foundation makes the type system enforce the prior.

3. One way to do each thing

If your foundation has both Redux and Zustand, the agent will use both. If it has only Zustand, the agent will use Zustand. Foundations make choices the agent doesn't have to.

4. Pre-installed skills and slash commands

.claude/skills/
  add-screen.md           — knows where screens go, how they're wired
  wire-supabase-rpc.md    — knows how RPCs are exposed
  add-stripe-product.md   — knows the webhook layout

A skill is a scoped operation the agent can invoke directly. It is not prompt engineering. It is the foundation describing what it lets you do.

5. A working end-to-end path

Auth → database read → typed UI → push notification, all wired up once. The agent reads the whole chain in a single context window and now has a template for every future feature that touches the chain.

What a real foundation looks like on disk

Here's what a real React Native + Expo + Supabase foundation looks like when an agent opens it:

your-app/
├── app/                        # Expo Router screens
│   ├── (tabs)/
│   │   ├── index.tsx           # Home + today's entries
│   │   ├── add.tsx             # Camera + analysis flow
│   │   └── stats.tsx           # Daily summary chart
│   └── auth/
│       └── login.tsx           # OAuth + email + Apple
├── modules/
│   ├── db/
│   │   ├── supabaseClient.ts
│   │   └── supabaseServer.ts
│   ├── auth/
│   │   └── useAuth.ts
│   └── vision/
│       └── analyzeFood.ts      # Vision API integration
├── supabase/
│   └── migrations/             # Real, dated, ordered migrations
├── components/                 # NativeWind primitives
└── .claude/
    └── skills/                 # Scoped agent operations

When the agent opens this and you ask for a weekly-summary feature, it reads stats.tsx, reuses the chart primitive in components/, calls the same supabaseServer client, drops the screen in (tabs)/, and follows the same migration pattern if it needs a new column.

The agent never asks "what state library should I use?" because the repo answered the question.

The economics, in detail

I tracked twelve sessions across three teammates — six from blank repos, six from foundations — using the same model and same prompt categories. Averages:

Metric	Blank repo	Foundation	Delta
Tokens per shipped feature	$4.30	$0.95	4.5× cheaper
Wall time per feature	42 min	9 min	4.7× faster
Diffs requiring full rewrite	4 of 6	0 of 6	—
Hallucinated imports	11 total	1 total	11× fewer

This is not a controlled study. It is, however, consistent with what teammates and customers report. The gap is real and it is wide.

If you ship one app a year, the gap doesn't matter much — you'll spend a month either way. If you ship three or four, the gap is the difference between "we can" and "we can't."

What this does not mean

Two clarifications, because the foundation argument gets oversold.

A foundation does not replace judgment. The agent still ships things you have to review. The foundation just narrows what the agent can ship.

A foundation is not forever. Two years from now the model will be stronger, the framework will have shifted, and today's foundation will feel constraining. Throw it away when it does. Until then, it earns its keep every session.

How to evaluate any foundation you're considering

Whether you're considering a paid template, a free GitHub template, or something a friend shipped — the test is the same:

Open the repo and ask Claude Code to add a screen. If the first thing the agent does is install three packages, the foundation is decorative.

Other tests, in order:

Count real screens. Five or more, all using the same conventions, is the bar.
Grep for any. If the data layer leaks any, the agent has no priors.
Find the skills directory. No skills, no scoped operations, the foundation is half-built.
Read the migrations folder. Real, dated migrations are a foundation signal. A single init.sql is a boilerplate signal.
Run the first session. Token cost and wall-clock time will tell you everything within 15 minutes.

FAQ

Is a foundation just a fancy boilerplate?
No. A boilerplate is the packaging. A foundation is the wiring. Most boilerplates are not foundations.

Why doesn't a great AGENTS.md fix this?
It helps about 4%, per the 138-repo study. The pattern is a much stronger prior than prose about the pattern.

Does this only apply to React Native?
No. It applies to every stack. React Native is the worst case because its ecosystem is the most fragmented, so the gap is largest there.

Should I buy or build the foundation?
Build if you'll ship three or more apps on the same stack. Buy if this is your first or second.

If you take one thing away: do not hand an AI coding agent an empty room and ask it to build a house. Give it a foundation. Then ask it to add the rooms.

For the longer breakdown — including the specific "one way to do each thing" heuristics I use to audit a foundation — see the Applighter blog.

What's the weirdest thing an AI coding agent has done in your blank repo? Drop it in the comments — I'm collecting the failure modes for a follow-up. (Bonus points for a token-cost screenshot.)

Buy a React Native Template or Build From Scratch in 2026?

Russel Dsouza — Tue, 30 Jun 2026 09:59:09 +0000

You've run npx create-expo-app, and three days later you're configuring NativeWind v4 PostCSS, debugging Supabase deep-link callbacks, and writing your fifth token-refresh useEffect. The decision hits: keep grinding, or buy a $79 React Native template and skip to the actual product?

This post is a decision framework with the actual numbers. No marketing — the math leans toward buying, and the rest of this post explains exactly when it doesn't.

Buy when:

The app is a recognizable pattern (auth + DB + payments + a vertical UI)
You're solo or a two-person team
Your time is worth more than $50/hour

Build from scratch when:

The UX is genuinely novel
You have hard compliance (HIPAA, PCI L1, SOC 2)
You're learning React Native and the setup is the point
You're at 1M+ user scale on day one

The setup tax

Foundation work, before any product code:

Expo + TS + ESLint + Prettier ......... 4h
Expo Router v4 (typed routes) ......... 6h
Supabase auth (email/Apple/Google) .... 14h
NativeWind v4 + dark mode ............. 8h
TanStack Query + Zustand .............. 6h
Stripe / RevenueCat ................... 16h
Push (APNs + FCM via Expo) ............ 8h
Supabase Storage + RLS ................ 6h
Sentry + PostHog ...................... 4h
EAS Build + iOS/Android signing ....... 8h
─────────────────────────────────────────
Total .................................. ~80h

At $75/hr indie rate that's $6,000 of your time. At $150/hr US contract, $12,000. Most of those hours are commodity work — you are not building a moat, you are configuring app.json.

Template price tiers in 2026

$0–29     screen kits, free boilerplates (no backend, stale fast)
$49–99    full-stack with real backend (Supabase/Firebase/Node)
$199–499  vertical clones (food delivery, marketplace, dating)

If a $79 template saves 60 of those 80 hours, the effective hourly rate for from-scratch to win is under $1.32/hour. Don't be that cheap.

Buy vs. build at a glance

Factor	Build	Buy
Time to deployable build	3–6 weeks	1–2 days
Cash cost	$0	$49–499
Time cost	80–200h	2–8h customization
Code understood day 1	100%	60–80% (100% after a week)
Architecture quality	Your choices	Template's choices
Security posture	What you remember	What was shipped
Best for	Novel UX, learning, compliance	MVPs, vertical clones, agency work

The buyer's checklist

Before you buy, verify:

# 1. Is the backend real or mocked?
grep -r "mockApi\|fixtures" src/

# 2. React Native + Expo version
cat package.json | grep -E "react-native|expo"
# Floor in 2026: RN 0.81, Expo SDK 54

# 3. Leaked keys
git log -p | grep -iE "sk_live|service_role|AKIA"

# 4. TypeScript strict mode
cat tsconfig.json | grep strict

# 5. Last commit recency
git log -1 --format=%cd

# 6. License terms
cat LICENSE

If a template fails on (1) — backend is mocked — you don't have a template, you have a screen kit. You will rebuild the entire backend.

What "production-ready" should actually mean

Six bars a template should clear before it can use the phrase:

A Postgres schema with RLS you can supabase db push — see Supabase RLS docs
Auth flows that pass App Store review (Apple Sign-In mandatory if any other social)
Server routes for anything sensitive (no API keys on device)
Error / loading / empty states wired everywhere
EAS Build profiles producing signed iOS + Android binaries — see EAS Build docs
AI agents (Claude Code, Cursor) can extend it without breaking the architecture

The sixth is the 2026 bar that didn't exist in 2023. AI agents do their best work on known-good repos. Templates that confuse agents lose to ones that don't.

When buying wins

Your app is "X for Y" where both X and Y already exist
Solo / two-person team
Agency / contractor billing a client (license permitting)
You want a security baseline you didn't write at 1 AM
You're driving development with AI agents

When building wins

Novel UX with no obvious analog
Hard compliance constraints
Learning React Native — the setup is the point
Extreme scale on day one
Template stack is wrong for you (e.g., you need Firebase, template is Supabase)

A two-minute decision framework

Screen architecture obvious in 5 min of whiteboard? → buy
App describable as "X for Y"? → buy
Timeline < 60 days? → buy
Billing a client > $5,000? → buy
Learning React Native? → build the first, buy the second

Two or more "buy" answers and you don't need a calculator.

Disclosure

I work on production-grade React Native templates ($49–99 on RN 0.81 / Expo SDK 54 / Supabase). Bias acknowledged. The math still leans toward buying for most indie apps — and when it doesn't, the post above tells you exactly why.

Whatever template you evaluate, run the buyer's checklist above. A real template ships a real backend (schema, RLS, server routes), passing App Store review, with EAS Build profiles ready to go. If it doesn't ship those, the price you spent on it bought you nothing.

If none of the templates on the market match your app shape, build from scratch. That's the only honest answer to the buy-vs-build question.

For the longer breakdown — the FAQ and the line-by-line "what a real template ships" inventory — see the Applighter blog.

What's the foundation work that ate the most hours on your last React Native project? Drop it in the comments — I'm collecting the unglamorous setup tasks indie devs underestimate for a follow-up.

Mobile App Security Best Practices in 2026

Russel Dsouza — Mon, 29 Jun 2026 10:04:58 +0000

Most mobile breaches aren't sophisticated. They're a hardcoded API key, a forgotten debug flag, or a token in plaintext AsyncStorage.
The OWASP Mobile Top 10 (2024) is your checklist — work it every release.
Tokens live in the OS keychain via expo-secure-store, never AsyncStorage. Period.
Certificate pinning for sensitive endpoints, pinned to the SPKI hash, with a backup pin and a rotation plan.
AI-generated code is untrusted input — review auth, storage, and network code with the same rigor as a new contributor's PR.
CI is where security lives: semgrep + eslint-plugin-security + npm audit + MobSF on every release artifact.

Mobile attacks are up. Regulators are watching. AI is writing more of your code than ever — and the patterns it reproduces aren't always the secure ones. Here's the practical checklist I run through for every React Native / Expo app, organized around the OWASP Mobile Top 10 (2024).

This is the working version of a longer guide — focused on what to actually change in your codebase this week.

1. Credentials: nothing sensitive in the bundle, nothing sensitive in AsyncStorage

// ❌ Don't
await AsyncStorage.setItem('access_token', token);

// ✅ Do
import * as SecureStore from 'expo-secure-store';
await SecureStore.setItemAsync('access_token', token, {
  keychainAccessible: SecureStore.WHEN_UNLOCKED_THIS_DEVICE_ONLY,
});

Anything in the bundle can be extracted with apktool in minutes. Anything in AsyncStorage is plaintext on disk. Tokens go in the OS keychain via expo-secure-store or react-native-keychain. Period.

Refresh tokens rotate on every use. Access tokens live 15 minutes. The backend is the trust boundary, not the client.

2. Supply chain: assume your dependencies are hostile

# In CI, on every PR
npm ci
npm audit --audit-level=high

A clean package.json doesn't mean a clean app. Post-install scripts run with your dev-machine privileges. Native modules run with full app privileges.

Lockfiles in source control. npm ci in CI, never npm install.
Add Socket or Snyk for behavioral analysis (what npm audit misses).
Audit native modules personally if they touch storage, networking, or credentials.

3. Auth: PKCE, short JWTs, server-side authorization

import * as AuthSession from 'expo-auth-session';

// PKCE is the default in expo-auth-session — don't disable it.
const request = new AuthSession.AuthRequest({
  clientId,
  scopes: ['openid', 'profile'],
  usePKCE: true,
  redirectUri,
});

OAuth 2.0 with PKCE for third-party identity. JWTs with 15-minute access tokens and rotated refresh tokens. Every endpoint validates the caller server-side. Hiding UI is not authorization.

Add MFA via expo-local-authentication for anything touching payments, identity, or health data.

4. Input validation: deeplinks are user input

// Treat the URL params as hostile
const handleDeepLink = (url: string) => {
  const parsed = new URL(url);
  const action = parsed.searchParams.get('action');
  if (action && /^[a-z_]{1,32}$/.test(action) && KNOWN_ACTIONS.has(action)) {
    routeTo(action);
  }
};

Deeplinks, push payloads, clipboard, QR codes, WebView messages — all untrusted. Validate type, length, format. Parameterized queries for local SQLite. originWhitelist on every WebView.

5. TLS 1.3 + certificate pinning

<!-- android/app/src/main/res/xml/network_security_config.xml -->
<network-security-config>
  <domain-config cleartextTrafficPermitted="false">
    <domain includeSubdomains="true">api.yourapp.com</domain>
    <pin-set>
      <pin digest="SHA-256">{base64-spki-hash}</pin>
      <pin digest="SHA-256">{backup-spki-hash}</pin>
    </pin-set>
  </domain-config>
</network-security-config>

Pin to the SPKI hash, not the leaf cert. Ship a backup pin. Have a rotation plan. Reject TLS 1.0/1.1 server-side.

In Expo, usesCleartextTraffic: false. Verify no allowsArbitraryLoads snuck into production.

6. Privacy controls aren't optional

Maintain a data inventory. Apply data minimization. Request permissions just-in-time with context. Build account-delete-and-export flows that actually delete and export. Audit analytics/ad SDKs quarterly — they change practices on their schedule.

7. Binary hardening: Hermes, R8/ProGuard, App Attest

Ship Hermes bytecode — much harder to reverse than plain JS.
R8 with shrinking and obfuscation on Android.
babel-plugin-transform-remove-console in release builds.
jail-monkey for rooted/jailbroken detection (signal, not block).
Apple's App Attest + Google's Play Integrity API to verify the app calling your backend is the one you shipped.

8. Configuration hygiene

__DEV__ guards on every debug code path.
android:exported="true" only when truly needed.
URL schemes and Universal Links audited as entry points.
CI check that fails the build if known test-account strings hit the binary.

9. Encrypted storage, intentional sensitivity tiers

Sensitivity	Storage
Credentials, keys	iOS Keychain / Android Keystore via `expo-secure-store`
Structured PII	SQLCipher or encrypted Realm
Non-sensitive	Regular filesystem or `AsyncStorage`

Disable backup for sensitive paths. Mask app-switcher screenshots on sensitive screens via expo-screen-capture.

10. Modern crypto, vetted libraries

import { randomBytes } from 'react-native-quick-crypto';
// AES-256-GCM. Never CBC without auth. Never ECB. Ever.

Argon2id for password hashing. HKDF for key derivation. SHA-1 and MD5 are dead. Start tracking your post-quantum migration — NIST's ML-KEM and ML-DSA are finalized.

11. Treat AI-generated code as untrusted input

This is the one most security frameworks haven't caught up to. LLMs reproduce the most common pattern in their training data — often the most common flawed pattern.

Maintain a .cursorrules or .github/copilot-instructions.md with your secure defaults.
Review AI-generated auth, storage, and network code with the same rigor as a new contributor's PR.
Run semgrep and eslint-plugin-security on AI output before merge.
Pen-test AI-generated payment and auth flows specifically.

12. CI is where security lives

Every PR:

semgrep, eslint-plugin-security, Android Lint
npm audit + Socket/Snyk
MobSF on release-build artifacts

Annually: pen test. Quarterly: SDK audit. Always: an incident response plan that includes key rotation, token revocation, and an OTA push.

Most mobile breaches aren't sophisticated. They're a hardcoded key, a forgotten debug flag, a plaintext token. The OWASP Top 10 is your checklist — work it every release.

For the longer breakdown — including the AI-safe-code generation patterns and the full OWASP-mapped CI workflow — see the RapidNative blog.

What's the security gotcha you've shipped to production and then quietly patched? Drop it in the comments — I'm collecting the failure modes that don't make it into the OWASP examples for a follow-up.

Stop Reinventing React Native Auth — Buy a Template

Russel Dsouza — Mon, 29 Jun 2026 09:43:48 +0000

Building React Native auth from scratch routinely takes 60–120 hours and ships subtle bugs (the Apple Sign In fullName trap is the classic).
The real surface area is seven traps: AsyncStorage encryption, refresh-token mutex, three OAuth deep-link code paths, fullName persistence, mandatory account deletion, magic-link rate limiting, token hashing at rest.
A vetted template covers all seven for $99–$499. Break-even is ~3 hours of saved work.
Build it yourself only if you have enterprise IdP (SAML/Okta), HIPAA/FIDO2 constraints, or your company is the auth product.

Every React Native auth implementation starts with "it's just signInWithPassword" and ends 75 hours later debugging refresh-token rotation. This post is the field guide I wish I had before I built mobile auth from scratch three times.

The seven traps

If you build auth from scratch in React Native, here's what bites you in production. None of these are in the happy-path tutorial.

1. AsyncStorage is not encrypted

// 🚫 wrong
import AsyncStorage from "@react-native-async-storage/async-storage";
await AsyncStorage.setItem("access_token", token);

// ✅ right
import * as SecureStore from "expo-secure-store";
await SecureStore.setItemAsync("access_token", token);

On iOS, SecureStore uses Keychain. On Android, EncryptedSharedPreferences. AsyncStorage is a plaintext SQLite blob.

2. Refresh-token rotation needs a mutex

Supabase rotates refresh tokens on every use. Two concurrent API calls at the moment of expiry will both try to refresh, and one of them invalidates the other's freshly-minted token. You need a single-flight mutex around refresh:

let refreshPromise: Promise<Session> | null = null;

async function getValidSession() {
  if (refreshPromise) return refreshPromise;
  refreshPromise = supabase.auth.refreshSession()
    .finally(() => { refreshPromise = null; });
  return refreshPromise;
}

3. OAuth deep links are three code paths

iOS native build: ASWebAuthenticationSession via expo-auth-session
Android native build: Chrome Custom Tabs via expo-auth-session
Expo Go: a polyfill that opens a system browser

Each one returns control through a different URL scheme. Universal Links on iOS, intent filters on Android, and an exp:// URL in Expo Go. Get any wrong and the user lands on a white screen.

4. Apple Sign In `fullName` only returns on first sign-in

const credential = await AppleAuthentication.signInAsync({
  requestedScopes: [
    AppleAuthentication.AppleAuthenticationScope.FULL_NAME,
    AppleAuthentication.AppleAuthenticationScope.EMAIL,
  ],
});
// credential.fullName is null on EVERY subsequent sign-in.
// You MUST persist it the first time, server-side.

This is the bug I've shipped on three separate projects.

5. Account deletion is mandatory

App Store guideline 5.1.1(v): you must offer in-app account deletion. That means a confirmation screen, a server endpoint that revokes all sessions, and a way to handle a GDPR data-export request. Skip it, fail review.

6. Rate limit your magic-link endpoint

Without per-email and per-IP throttling, anyone can blow up your transactional email bill. The minimum pattern:

const RATE_LIMIT_WINDOW_MS = 60_000;
const RATE_LIMIT_MAX = 3;

const recent = await supabaseServer
  .from("magic_link_tokens")
  .select("created_at", { count: "exact" })
  .eq("email", email)
  .gte("created_at", new Date(Date.now() - RATE_LIMIT_WINDOW_MS).toISOString());

if ((recent.count ?? 0) >= RATE_LIMIT_MAX) {
  return Response.json({ error: "rate_limited" }, { status: 429 });
}

7. Hash your tokens at rest

const token = crypto.randomBytes(32).toString("hex");
const tokenHash = crypto.createHash("sha256").update(token).digest("hex");
// store tokenHash, email the user `token`

If your DB ever leaks, the rows are worthless.

The cost, with numbers

Workstream	Hours from scratch	Hours with a template
Email + password screens	6h	0h
Google OAuth (iOS + Android + Expo Go)	8h	1h
Apple Sign In + name persistence	6h	1h
Magic link + email delivery	10h	1h
Secure token storage + refresh mutex	8h	0h
Biometric unlock	5h	1h
Password reset + account deletion	6h	0h
Schema + RLS policies	8h	0h
Rate limiting + email DKIM	6h	1h
Testing	12h	4h
Total	75h	9h

At $75/hour, that's $5,625 vs $675. Templates range from $99 to $499. The math isn't subtle.

What a real template ships

Production-grade React Native templates wire all seven traps above and ship them as default behavior. The baseline:

expo-secure-store token storage
Refresh-token mutex
Google + Apple + magic link + email/password
Apple Sign In fullName persistence
Account deletion endpoint
Rate-limited magic-link API with SHA-256 token hashing
Supabase migrations with RLS policies on every user-scoped table
Biometric unlock via expo-local-authentication

If a template you're evaluating doesn't ship all of these, you're getting a UI kit with a database attached — not auth. Ask to see the migrations and the magic-link route before you spend any money.

When to build it yourself

Enterprise IdP (SAML / Okta) integration
Compliance constraints (HIPAA-eligible IdPs, FIDO2 step-up)
You're literally building an auth product

Otherwise, you're paying a tax with zero offsetting return. The hours you spend rebuilding OAuth callbacks are hours your competitors are spending on features users actually see.

React Native AI app cost in 2026

Russel Dsouza — Fri, 26 Jun 2026 09:13:20 +0000

Every agency quote for a React Native AI app collapses into one fuzzy bracket: $60K–$150K. That bracket is useless. Here's the actual line-item breakdown — hours, dollars, API bills — for what a React Native AI app cost looks like in 2026.

Solo indie, from scratch:   436–832 hours = $32K–$62K
Agency, from scratch:                       $80K–$180K
Template starting point:    $79 + 20–60 hrs customization
Year-one ongoing (API + infra):             $3.6K–$30K

The line items

1. Discovery + IA + design — 60-100 hrs

The part juniors think doesn't count. Data model. Routing graph. What an "AI session" means in your domain. Empty states. Permission denials. Offline behavior. Under-estimated by 4x in every indie project I've seen.

2. Auth + Supabase + RLS — 40-80 hrs

-- The 30-line policy file that takes a full week to get right
create policy "users can only see their own transcripts"
  on transcripts for select
  using (auth.uid() = user_id);

create policy "users can insert their own transcripts"
  on transcripts for insert
  with check (auth.uid() = user_id);
-- ...repeat for every table, every action

Plus schema migrations, OAuth wiring, edge functions for secrets. The Supabase RLS guide is excellent but policy design is on you.

3. AI integration — 80-160 hrs

AI shape	Hours	Why
Image → JSON (vision)	60–100	Camera, compression, retry, structured parsing
Audio → transcript	100–160	Streaming chunks, partial results, background mode
Document → chat (RAG)	120–200	Chunking, embeddings, vector store, citations

4. UI screens — 120-240 hrs

A real AI app is not one chat screen:

onboarding (4–6 screens)
history list + detail
settings
paywall + manage-subscription
empty / error / offline states
accessibility labels on everything

Twenty-plus production screens, each needing a dark mode, a tablet layout, and a VoiceOver label. This is the block that swallows half the budget on every project I've seen.

5. Stripe + license grants — 40-60 hrs

// The 200-line webhook handler nobody writes a tutorial for
export async function POST(req: Request) {
  const sig = req.headers.get('stripe-signature');
  const event = stripe.webhooks.constructEvent(body, sig, secret);

  switch (event.type) {
    case 'checkout.session.completed':
      await grantLicense(event.data.object);
      break;
    case 'customer.subscription.deleted':
      await revokeLicense(event.data.object);
      break;
    // ...11 more cases for restore-purchases, refunds, disputes
  }
}

iOS IAP restore flow alone is two days.

6. Push notifications — 16-32 hrs

Topic logic, do-not-disturb, deep links, permission UX, silent-push retries. Expo's push service is great but the policy of when to send is yours.

7. EAS Build + store submission — 20-40 hrs

eas build --platform all --profile production
eas submit -p ios --latest

Two commands. Forty hours of metadata, screenshots at every device size, privacy nutrition labels, ATT prompts, the "what does your AI actually do" review questions, one rejection.

EAS docs cover the build; nobody covers the rejection.

8. QA + edge cases + accessibility — 60-120 hrs

VoiceOver labels. RTL. Dark mode. Tablet. Tiny phones. 4,000-item scroll test. Apple genuinely checks accessibility now.

Recurring costs

GPT-4o Vision:        ~$0.01 / image
OpenAI Whisper:       ~$0.006 / minute audio
Claude/GPT-4 chat:    $3–$15 / 1M input tokens
Supabase Pro:         $25 / month
EAS team plan:        $99 / month
pgvector (in Supabase):     $0
Pinecone (if you outgrow):  $70+ / month
Sentry developer:     $26 / month
Apple Dev Program:    $99 / year
Maintenance:          15–25% of initial build / year

Year-one all-in for an indie React Native AI app: $45K–$78K.

Comparison: scratch vs template

Line item	From scratch	Production template
Auth + Supabase + RLS	40–80 hrs	included
AI provider wiring (BYOK)	80–160 hrs	included
20+ screens	120–240 hrs	included
Stripe + license grant	40–60 hrs	included
Push notifications	16–32 hrs	included
EAS Build config	8–16 hrs	included
One-time cost	$32K–$62K	~$79
Customization	n/a	20–60 hrs
Time to App Store	4–7 months	2–6 weeks

The $79 isn't a discount on the engineering — it's the cost of buying a copy of architecture that already exists. If you want to see what a production template actually ships (RLS policies, BYOK AI wiring, Stripe license grants, 20+ screens), the Applighter blog has the full line-item breakdown and three real budget shapes.

Three real shapes, three real budgets

Image → AI insight (calorie scanner, plant ID, skincare): 380–620 hrs from scratch ($28K–$47K). Template: $79 + ~30 hrs.

Voice → transcript + summary: 480–740 hrs from scratch ($36K–$56K). Template: $79 + ~40 hrs.

Document → chat (RAG): 520–820 hrs from scratch ($39K–$62K). Template: $79 + ~50 hrs.

What free boilerplates miss

A free Expo boilerplate gives you:

Expo Router setup
A login screen
Maybe a tab bar

A free boilerplate does not give you:

AI provider abstraction (BYOK pattern)
RLS policies + migrations
Stripe webhook handlers with signature verification
License grant logic
20+ designer-vetted screens
Push notification topic logic
Accessibility audit
Dark mode tested across every screen

Paid UI kits from competitors like React Native Base ($99–$299) typically ship as UI only — backend, AI, and licensing are still yours. That's where 70% of the hours live.

When build-from-scratch wins

Three cases:

Genuinely novel on-device AI (ExecuTorch, custom-trained vision)
HIPAA / FedRAMP / on-prem constraints a template's RLS can't satisfy
Existing in-house React Native team with idle capacity

For everything else — solo indies, two-person teams, agencies shipping client demos fast — buy the architecture.

FAQ

Q: Do production AI templates include API keys?
A: The good ones don't — they use a BYOK pattern. Pick OpenAI, Anthropic, Whisper, Deepgram, AssemblyAI — your call. You pay the provider directly.

Q: Year-one ongoing costs?
A: $3.6K–$30K. Mostly AI API spend. Supabase + EAS + Sentry are ~$2K/year combined.

Q: Is React Native fast enough for streaming AI responses?
A: Yes. Reanimated v4 handles streaming text and audio waveforms at 60fps. See React Native performance docs.

What did your last React Native AI build actually cost — in hours or dollars? I'm collecting real numbers from indie devs in the comments, because the honest ones are almost impossible to find online.

React Native Performance Optimization — The 2026 Playbook

Russel Dsouza — Tue, 23 Jun 2026 07:01:15 +0000

Measure on a Pixel 4a, not your iPhone 15 Pro. Targets: cold start <2s, sustained scroll ≥58fps, tap-to-feedback <100ms, JS heap <180MB.

Turn on the New Architecture (Fabric + TurboModules + JSI). ~40% cold start improvement, ~35% rendering speedup, ~25% memory drop. Every other optimization compounds on this.
Default to FlashList, not FlatList. ~10× scroll throughput via row recycling. Set estimatedItemSize close to median row height and you're done.
Animations on the UI thread, not JS. useNativeDriver: true for Animated. Reanimated 3 with worklets for anything gesture-driven.
Audit re-renders. React DevTools → "highlight updates when rendering." Most "RN is slow" complaints are 5× re-render counts.
Trim cold start. react-native-bundle-visualizer + lazy-load non-first-frame screens. Defer analytics/remote config via InteractionManager.runAfterInteractions.

I read a React Native performance post the other week that opened with a long argument about whether useMemo was overused. The post was 2,200 words. It didn't mention the New Architecture once.

That's the state of most React Native advice you'll find in 2026. The framework has changed more in the last eighteen months than it did in the previous five years — and a lot of the writing about it hasn't caught up. So here's what I'd actually tell a team that wants their app to feel native, in the order I'd tell it.

1. Stop optimizing. Measure.

Almost every team I've worked with that complained about React Native performance had never sat down with a real low-end Android and a profiler open. They had vibes. The vibes said the app was slow. The profiler usually said the app was rendering forty-seven times when it should have rendered three. That's not a framework problem. That's a render hygiene problem, and you can't fix it until you can see it.

Here are the numbers I benchmark against. Not on the iPhone 15 Pro sitting on my desk — on a Pixel 4a, the device my actual user is holding:

Cold start                  < 2 seconds
Sustained scroll            >= 58 fps
Tap to first visual feedback < 100ms
JavaScript heap             < 180 MB

If those numbers don't mean anything to you yet, that's fine. They will after a week of measuring.

2. Turn on the New Architecture

I don't think this gets enough airtime. The New Architecture — Fabric, TurboModules, JSI — is the foundation everything else compounds on. Teams that migrate report:

~40% cold start improvement
~35% rendering speedup
~25% memory drop

The reason isn't magic. The old React Native bridge serialized every JavaScript-to-native call as JSON. It was slow on purpose, because being asynchronous and serialized was the easiest way to keep the threads sane. JSI replaced that with a direct C++ function call. Synchronous. No serialization. Latency dropped by ~40× on hot paths.

You can't really optimize on top of the old bridge anymore. Every other thing in this post assumes you're on the New Architecture. If you're not, that's your only homework.

3. Lists are where the complaints come from

Lists are where almost every React Native performance complaint comes from in production. Long feeds. Chat histories. Galleries. Anything that scrolls. The default React Native FlatList is actually pretty conservative — it doesn't know how tall your rows are, it can't recycle views, and it re-renders eagerly on data changes.

The fix is FlashList from Shopify, which gives you roughly 10× the throughput by recycling row views instead of mounting and unmounting them. The API is nearly drop-in:

import { FlashList } from '@shopify/flash-list'

<FlashList
  data={items}
  renderItem={({ item }) => <Row item={item} />}
  estimatedItemSize={88}   // <-- this is the prop that matters
  keyExtractor={(item) => item.id}
/>

The one prop that matters more than any other is estimatedItemSize. Get it close to your median row height and the rest takes care of itself.

There are cases where FlatList still wins:

Short lists under ~20 items, where FlashList's recycler is overhead you can't recoup
Wildly heterogeneous content where recycling falls apart because no two rows share a layout

These are edge cases. Default to FlashList. You will be surprised how much of your perceived "React Native is slow" feeling is actually a FlatList you should have upgraded twelve months ago.

4. Re-renders are where most developers eventually live

Unnecessary re-renders are the single most underestimated React Native performance problem. A component that renders five times when it should render once is 5× the JavaScript thread work, and the JavaScript thread is still where almost every user-perceived jank comes from.

Open React DevTools, turn on "highlight updates when rendering," and scroll through your app. If you see things flashing that have no visual change, you have a problem.

The fixes are mundane:

// Memoize leaf components that re-render with their parents
const Row = memo(({ item }) => <View>...</View>)

// useCallback for handlers passed to memoized children
const onPress = useCallback((id: string) => {
  /* ... */
}, [])

// Don't memoize primitives — net loss
// const memoizedNumber = useMemo(() => 42, [])  // pointless

Co-locate state, push it down toward where it's actually used, and reach for Zustand or Jotai before context-induced cascades start eating your frames. None of it is glamorous. All of it works.

5. Animations belong on the UI thread

If your animation is running on the JavaScript thread, it is going to drop frames. Not might. Will. The first time a network request resolves while a sheet is sliding, the animation will judder. There's no escaping this with cleverness. The fix is to get animations off the JS thread entirely.

For Animated, that means useNativeDriver: true on every property that supports it (transforms and opacity, in practice):

Animated.timing(translateY, {
  toValue: 0,
  duration: 200,
  useNativeDriver: true,  // <-- non-negotiable
}).start()

For anything gesture-driven, it means Reanimated 3 with worklets:

import { useSharedValue, useAnimatedStyle, withSpring } from 'react-native-reanimated'

const offset = useSharedValue(0)

const animatedStyle = useAnimatedStyle(() => ({
  transform: [{ translateX: withSpring(offset.value) }],
}))

// runs on the UI thread via JSI — survives a blocking JS reducer

Worklets run on the UI thread, share memory with native via JSI, and survive blocking JavaScript work without missing a beat. Pair them with react-native-gesture-handler for pan and swipe interactions — the legacy PanResponder still routes through the JS thread even on the New Architecture.

The thing about Reanimated isn't that it's faster than Animated. It's that it decouples animation work from your JS thread entirely. That's a different kind of fast. The kind that survives a poorly-written reducer.

6. Cold start is the first impression

Cold start is the user's first impression of your app every single morning, and almost every team I've audited has a cold start they could cut in half mechanically.

# Audit your bundle
npx react-native-bundle-visualizer

# Look at the ten largest modules — they'll explain ~60% of your bundle

The usual suspects: date libraries, icon sets, Lottie animations, heavy localization packages. Lazy-load screens that aren't on the first frame:

// React.lazy + dynamic import inside the navigator
const HomeTab = React.lazy(() => import('./screens/HomeTab'))
const SettingsTab = React.lazy(() => import('./screens/SettingsTab'))

The login screen should never be pulling the home tab's bundle.

And — this is the one teams forget — defer non-critical setup past first paint:

import { InteractionManager } from 'react-native'

InteractionManager.runAfterInteractions(() => {
  initAnalytics()
  bootstrapRemoteConfig()
  maybePromptForReview()
})

None of this code needs to run before your user sees the home screen. Treat the first frame as sacred.

What I've left out (and why it's second-order)

I've left a few things out — image caching with expo-image, memory leaks from uncleaned subscriptions, the case for and against writing TurboModules. They matter, but they're second-order.

If you turn on the New Architecture, move lists to FlashList, get animations on the UI thread, audit re-renders, and trim your bundle, you will have done 80% of the work that matters. The rest is housekeeping.

The teams I see ship fast React Native apps in 2026 don't have secret tricks. They have budgets. They measure. They refuse to ship a regression. That's the whole game.

If you want a project scaffold that already ships with these defaults — New Architecture on, FlashList by default, Reanimated 3 for animations, expo-image for remote images — that's what the RapidNative team has been building. The canonical post on the RapidNative blog has the same playbook plus the specific defaults the generator ships with.

What's the single optimization that bought you the most measurable wins on your last React Native app? Drop your before/after numbers in the comments — I'm collecting the patterns that work in production for a follow-up.

Stop Reinventing Auth in React Native

Russel Dsouza — Mon, 22 Jun 2026 06:08:55 +0000

Auth is a commodity surface in 2026. Don't rebuild it.
60–120 hours of senior-dev work for $59–$299 of template = obvious trade.
Vet templates for: RLS in versioned migrations, separated Supabase clients (anon vs. service_role), a working Stripe webhook, and ≤1k lines of auth code.
Roll your own only if you're regulated, weird, or learning.

You sat down to ship a side project. You opened a fresh Expo app. You typed "weekend plan: build auth."

Three weeks later you're still here.

This post is the argument for git cloneing somebody else's auth and getting back to writing the thing that's actually your app.

The full auth surface in React Native (2026)

It's never just a login screen. Real auth for a mobile app shipping on the App Store today includes:

- Email/password (optional, but users ask)
- Magic links (token hashing, single-use, expiry, rate limits)
- Google OAuth (iOS + Android URL schemes)
- Apple Sign-In (mandatory if you ship Google on iOS)
- Session persistence + refresh
- Deep links for verification emails
- RLS on every user-touching table
- Account deletion (App Store rule)
- Password reset
- Tests for at least magic link + OAuth happy paths

A focused senior dev spends 60–120 hours building this correctly. At $120/hr that's $7K–$14K of opportunity cost. And the failure mode for skipping a step isn't "ugly UI" — it's a leaked credential.

What a good template gives you

Skip ahead. The stack you want is roughly:

NextAuth for the session orchestration (provider-agnostic)
Supabase for the database, with RLS turned on
A magic-link endpoint with hashed tokens
A Stripe webhook that converts checkout → license grant
Two Supabase clients: anon for the app, service role for trusted server code

Here's what the magic-link route looks like in a real template (app/api/auth/magic-link/route.ts):

// Pseudocode showing the shape, not the literal source
const token = crypto.randomBytes(32).toString('hex')
const tokenHash = createHash('sha256').update(token).digest('hex')

await rateLimit(email, { window: 60, max: 3 })
await supabase.from('magic_link_tokens').insert({
  email,
  token_hash: tokenHash,
  expires_at: new Date(Date.now() + 15 * 60 * 1000),
})
await sendEmail({ to: email, link: `/verify?token=${token}` })

Three details to notice:

The raw token never touches the database. Only the SHA-256 hash is stored.
There's a rate limit (3 requests / 60s per email).
The expiry is 15 minutes, not "we'll check it later."

If your homegrown magic-link route is missing any one of those, you've already shipped a vulnerability.

Two Supabase clients, not one

The single most common security mistake in React Native + Supabase code is one shared client. Don't.

// modules/db/supabaseClient.ts — browser/app code
export const supabase = createClient(URL, ANON_KEY)

// modules/db/supabaseServer.ts — server-only, never imported from app/
export const supabaseAdmin = createClient(URL, SERVICE_ROLE_KEY)

The service_role key bypasses RLS. If it appears in any file that gets bundled into your client (anything under your Expo app/), you've shipped the keys to your entire database. A good template separates these two clients structurally so the bad import is visibly wrong in code review.

Build vs. buy

Capability	Roll your own	Auth-as-a-service	Template
Magic link	Build	Included	Included
Google + Apple OAuth	1–2d each	Included	Included
RLS policies	Hand-written	N/A	Versioned migrations
Stripe license grants	3–5d	DIY	Wired
Token hashing + rate limits	DIY	Included	Included
Source you own	Yes	No	Yes
Recurring cost	$0	$25–$500+/mo	One-time
Time to first signed-in user	2–6 weeks	1–3 days	1 day

Auth-as-a-service (Clerk, Auth0) is fine if your buyer is an enterprise security team and your pricing supports it. For an indie consumer app it's almost always overkill and locks you into someone's opinions about identity.

When you SHOULD roll your own

There are real cases:

Regulated industries (healthcare, fintech) where security needs a small bespoke surface to audit
Strange tenancy models (per-device identity, supervised iPad fleets)
You're learning OAuth/JWT/RLS and the project IS the learning
You have an internal IdP to integrate with

For everyone else: don't.

Vetting a template before you buy

Most templates are zombies. Use this checklist:

[ ] Auth code is under ~1,000 lines
[ ] RLS policies live in versioned migrations, not "enable it in the dashboard"
[ ] Stripe webhook writes to the same DB as auth
[ ] Anon and service_role clients are in separate files
[ ] Dependencies updated in the last 90 days
[ ] You can read the magic-link route in one sitting

If a template passes those six, you're buying real engineering, not a UI kit with a database attached.

If you want to see the actual files — lib/auth.ts, app/api/auth/magic-link/route.ts, app/api/webhook/stripe/route.ts — the longer breakdown lives on the Applighter blog, including a deeper walkthrough of how the Stripe webhook binds a checkout to a Supabase identity row.

Cross-Platform vs Native: The 2026 Debate Is Over

Russel Dsouza — Tue, 16 Jun 2026 14:14:06 +0000

If you're still picking native iOS + native Android for a new app in 2026, you're paying a tax that 95% of teams have stopped paying. This isn't a "both sides have merit" post. It's a position: cross-platform won. Here's the evidence.

For ~95% of apps shipped in 2026, cross-platform won. React Native and Flutter together cover >80% of new cross-platform work.
The performance gap collapsed. Hermes + the New Architecture (React Native) and Impeller (Flutter) closed it. The 60fps ceiling is now the floor.
The economics were never close. 30–80% cheaper, 30–40% faster to ship — and feature parity is the default, not a goal.
Native still wins in ~5% of cases. High-end games, heavy AR/VR, sub-16ms ML on camera buffers, deep OS extensions as the primary surface, specific compliance regimes.
The real debate now isn't React Native vs Swift. It's how much of your codebase a human writes vs. an AI generates.

The companies you use every day already voted

The clearest signal isn't a benchmark. It's what large engineering orgs — the ones that could afford to maintain two native teams — actually committed to.

Company	Stack	Code-share
Discord	React Native	98% across iOS/Android
Shopify	React Native	~80% shared across mobile surfaces
Microsoft (Teams, Office surfaces)	React Native	Significant shared layers
Pinterest	React Native	Core feature surfaces
Coinbase	React Native	Migrated from native
Google Pay	Flutter	Rewritten cross-platform
BMW My BMW app	Flutter	Cross-platform from launch
ByteDance (multiple apps)	Flutter	Production at scale

When Discord ships 98% shared code to hundreds of millions of users — Pixel 3 to iPhone 16 Pro — the "but cross-platform can't handle real production scale" argument stopped being an argument. It became a sentence you say to avoid making a decision.

2026 market share: Flutter ~46%, React Native ~35%, together >80% of new cross-platform work.

What "modern cross-platform" actually means

This part trips up everyone working from a 2018 mental model.

Modern React Native renders to real UIView and android.view.View instances. With the New Architecture (JSI + Fabric + TurboModules), the asynchronous JS-to-native bridge is gone. UI renders synchronously where it matters.

Modern Flutter draws every pixel via Skia (and now Impeller), pre-compiling shaders to eliminate first-frame jank.

Neither ships WebViews. Neither ships "almost native" experiences. The binaries go through the App Store and Google Play exactly like a Swift or Kotlin app. Your QA team can't tell the difference; neither can the user.

// What a 2026 React Native component actually compiles to:
// On iOS: a real UIView in the view hierarchy.
// On Android: a real android.view.View.
// No WebView. No bridge. No simulated-native abstraction.

import { View, Text, Pressable } from 'react-native';

export function Card({ title, onPress }: { title: string; onPress: () => void }) {
  return (
    <Pressable onPress={onPress}>
      <View style={styles.card}>
        <Text style={styles.title}>{title}</Text>
      </View>
    </Pressable>
  );
}

That Pressable is a real native gesture recognizer. That View is a real UIView. No wrapper, no shim.

The performance gap collapsed (three reasons)

1. Hermes + the New Architecture. Meta's JS engine built for React Native cut startup time roughly in half vs. the old JSC stack. JSI removed the bridge bottleneck for animations and scrolling.

2. Flutter's Impeller renderer. Pre-compiles shaders, eliminates the first-frame jank that defined cross-platform animation in 2019.

3. Hardware caught up. A baseline 2026 Android device has more CPU/GPU than an iPhone 7. The frame budget that used to be tight on cross-platform is now wide enough that unoptimized code clears 60fps.

For feeds, forms, e-commerce, fintech, social, dashboards, productivity, content apps, marketplaces, on-demand — there is no user-detectable performance gap. "But native is faster" became technically true and operationally irrelevant.

The economics were never close

Two codebases (Swift + Kotlin)
Two teams of senior engineers (both scarce, both expensive)
Two design system implementations
Two CI pipelines
Two release coordinations per shipped feature
Two sets of "works on iOS but not Android" bugs

Industry estimates: native dual-platform is 30–80% more expensive and 30–40% slower than cross-platform.

But cost isn't the main thing. The main thing is shipping the same feature to both platforms on the same day. The number of native teams that have ever maintained true feature parity rounds to zero. Cross-platform makes parity the default.

When native still wins (the 5%)

Be honest about which bucket you're in. Native is still the right call if:

High-end games. 3D rendering, 120Hz determinism. Use Unity, Unreal, or native Metal/Vulkan.
Heavy AR/VR. Room-scale tracking, persistent anchors, custom shaders. Wrappers exist; they lag Apple/Google by months.
Sub-16ms on-device ML. Real-time barcode at scale, pose estimation, on-device transcription on the camera buffer. Native gets you direct Core ML / NNAPI without marshalling overhead.
OS extensions as the primary surface. CarPlay, Wear OS tiles, Live Activities, App Clips, system widgets, Siri intents. Cross-platform apps regularly ship native modules for these — but if your core product lives there, native-first is honest.
Specific compliance regimes. FIPS 140-3, certain MDM and keystore behaviors, specific healthcare or fintech certifications. Shrinking, but real.

If your app doesn't sit cleanly in one of those buckets, native-by-default isn't the safe choice anymore. It's the expensive choice you're making out of habit.

The 60-second decision framework

Three questions, in order:

1. Does your core experience need direct hardware
   access at native latency?
   → YES: native. Stop here.
   → NO: continue.

2. Do you already have two full native teams in seat,
   budget locked, indefinitely?
   → YES: keep using them; switching has migration cost.
   → NO: continue.

3. Do users care more about features and shipping speed
   than which engine renders the button?
   → YES (this is ~95% of apps): cross-platform.
       Pick React Native or Flutter based on team preference.

That's it. Most teams answer it in 60 seconds and the answer is cross-platform.

The new debate that replaced the old one

Here's the part most "cross-platform vs native" posts haven't caught up to.

Once cross-platform won (and it has), one codebase becomes a target small enough for an AI to generate, modify, and maintain in real time. That's structurally not true of two native codebases — generating coherent, synchronized Swift and Kotlin for the same feature, with matching design systems and parallel state, is an order of magnitude harder.

The frameworks that won the cross-platform debate are also the frameworks AI generation works well on. That's not a coincidence. It's why this debate ended now, not five years ago.

Tools like RapidNative generate real React Native + Expo code from a prompt — TypeScript output, exportable, ships to both stores. If you tried this with Swift + Kotlin in parallel and kept them in sync, you'd still be writing prompts in 2030.

The real 2026 question isn't React Native vs Swift. It's how much of your cross-platform codebase a human writes vs. an AI generates. That's the conversation worth having.

Quick objection-handling

"Will my cross-platform app get rejected from the App Store?" No. Discord, Shopify, BMW, Coinbase, and Google Pay don't get special treatment. They ship through the same review process you would. The "Apple secretly favors native" story is residue from the WebView-era rejections of the early 2010s. Modern cross-platform doesn't use WebViews.

"Is React Native dying? Is Flutter slowing down?" Both healthier than ever. React Native shipped the New Architecture (now default). Expo's tooling around it makes setup a single command. Flutter continues shipping quarterly stable releases with Impeller, expanded web/desktop, improved Material/Cupertino. Pick whichever your team prefers writing.

"What about heavy animation?" For 95% of animation work — list scrolls, modal transitions, parallax, shared element transitions, gesture-driven interactions — both frameworks run at 60–120fps indistinguishably from native. If you're animating 10,000+ particles or a fluid simulation, that's the edge case where native or a game engine wins. For everything else, the gap is invisible.

The bottom line

Cross-platform vs native isn't over because cross-platform got perfect. It's over because the gap between "perfect" and "good enough for what 95% of apps actually need" stopped being a gap at all.

Discord, Shopify, Microsoft, Pinterest, Coinbase, Google Pay, BMW, ByteDance didn't pick cross-platform out of laziness. They picked it because the math, the talent market, the user experience, and the platform tooling all pointed the same direction.

If you're in the 5% where native belongs, you already know. If you're not — and most of you aren't — pick a cross-platform stack and ship.

What's still keeping your team on native in 2026? Genuinely curious — drop the use case in the comments. I'm collecting examples of where the 5% actually shows up in real projects.