DEV Community: Russel Dsouza

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.

Why we built LetsDeployIt: the 6-week gap between 'app done' and 'app live'

Russel Dsouza — Tue, 16 Jun 2026 13:56:24 +0000

Originally written by Rishav Kumar for the LetsDeployIt blog. Republished here.

The app works.

You ran it on your phone last night. The onboarding flows, the buttons do what they should, the API calls return real data. You built it in a weekend with Lovable, or Rork, or Emergent, or RapidNative — tools that turned an idea into a working build faster than anyone would have believed two years ago. You take a screenshot. You text it to a friend. You write "shipping this week" in your notes app.

You do not ship it that week. You do not ship it the week after, either.

Six weeks later, the app is still sitting on your laptop in a TestFlight build that three people have tried. You've opened the Apple Developer portal more times than you can count, closed it in frustration nearly as often, and you've started to suspect something that feels almost too stupid to say out loud: building the app was the easy part.

We built LetsDeployIt because that gap — the distance between "app done" and "app live" — is real, it's brutal, and almost nobody talks about it honestly. This is the story of why it exists and what actually lives inside those six weeks.

The myth of "just submit it"

If you've never published a native app, the store submission step sounds like a formality. You finished the hard work — the code, the design, the logic. Surely uploading it is a button click?

It is not a button click. It's a checklist that fans out into a dozen smaller checklists, most of which you don't discover until you fail them.

To get an iOS app into review, you need a paid Apple Developer account, a correctly configured App ID, the right capabilities and entitlements, distribution certificates, provisioning profiles that match your build, an archive that's signed correctly, app icons at every required size with no alpha channel, a privacy nutrition label that accurately describes every piece of data you touch, screenshots at multiple device resolutions, an App Privacy policy hosted at a stable URL, age ratings, export-compliance answers, and metadata that doesn't trip a single one of Apple's roughly three hundred review guidelines.

Google Play is its own world: a Play Console account, a signed AAB (not the APK you've been testing with), a Data Safety form, a content rating questionnaire, a target-API-level requirement that changes every year, and — the one that surprises everyone in 2026 — a closed testing requirement that demands 12 testers run your app for 14 continuous days before a new personal developer account can even publish to production.

Read that again. For a brand-new Play account, there is a built-in two-week delay before you're allowed to go live, regardless of how good your app is. That alone eats a third of the six weeks, and most builders don't learn about it until they're already inside it.

Where the six weeks actually go

When we sat down and mapped the real timeline — not the optimistic one in your head, but the one that happens — it broke down with eerie consistency. Here's the gap, week by week.

Week 1 — The "this'll take an afternoon" week. You create the developer accounts. Apple charges $99/year, Google charges a one-time $25, and both take a day or two to verify your identity. You feel productive. You also discover that your app needs a bundle identifier you'll be stuck with forever, and you spend an hour second-guessing the name.

Week 2 — The signing rabbit hole. You try to make a release build and meet the single most demoralizing error category in all of mobile development: code signing. Certificates that don't match profiles. Profiles that don't include your device. "No signing certificate found." The build that ran perfectly in development now refuses to archive. You read six Stack Overflow threads, three of which contradict each other, two of which are from 2019, and you lose a full evening to a checkbox in a settings pane.

Week 3 — The assets you didn't know you needed. Screenshots, but not just any screenshots — the exact pixel dimensions for a 6.7" display and a 6.5" display and a 5.5" display and an iPad if you support one. A privacy policy, which means either paying a lawyer or pasting something generic and hoping. A support URL. A marketing description that has to sell the app without using a single word Apple considers a trademark violation. None of this is hard. All of it is slow, and all of it is required before the submit button unlocks.

Week 4 — The first rejection. You submit. You feel relief. Two days later, the relief evaporates: Guideline 5.1.1 — Data Collection and Storage or Guideline 2.1 — App Completeness or Guideline 4.2 — Minimum Functionality. The rejection notice is polite, vague, and gives you no clear path forward. Was it the login? The placeholder content? The permission you request but never explain? You guess, you fix, you resubmit, and the clock resets.

Week 5 — The back-and-forth. AI-built apps get flagged in specific, predictable ways: a sign-in flow that doesn't offer the account deletion Apple now requires, a permission prompt with no usage description, a privacy label that doesn't match what the app actually does, an app that reviewers decide is "just a website in a wrapper." Each round of the conversation with App Review costs another 24–72 hours. Most people hit two or three rounds.

Week 6 — Live, finally. If you've made it here, the app goes live and the relief is genuine. But you've spent six weeks of evenings and weekends on work that has nothing to do with your product, and the momentum you had on launch day — the friend you texted, the audience you teased — is long gone.

Why vibecoded apps hit the wall harder

Here's the uncomfortable truth we kept running into. The tools that make building an app radically easier — the AI-first, prompt-to-app platforms — are not the tools that get you through review. They were optimized for the part that's now easy. The submission layer is exactly where they leave off.

That's not a knock on them. Generating a working build is a genuine miracle compared to where we were. But it creates a specific kind of stranded founder: someone with a real, functional, often genuinely good app and zero context on entitlements, signing, store policy, or the unwritten rules reviewers apply. You have the product. You don't have the decade of accumulated submission scar tissue, and there's no prompt for scar tissue.

So the gap isn't a sign you did anything wrong. It's structural. The frontier of app creation moved years ahead of the average builder's experience with app distribution, and nobody moved the goalposts on Apple's and Google's side to match. The stores are, if anything, stricter now than they were five years ago.

What we decided to build

We didn't want to build another tool that adds one more thing to your checklist. The checklist is the problem. We wanted to take the entire thing off your plate.

So LetsDeployIt does exactly that: you hand us a working build, and we take it the last mile to the App Store and Play Store — live in 10 to 14 days, for a flat fee, approved or your money back.

The model is deliberately specific. We don't touch your product code; that's yours, and you know it best. We handle everything around the app — the part that's pure process, pattern-matching, and patience:

Accounts and signing. Certificates, profiles, entitlements, and signed release builds, done right the first time so week 2 never happens to you.
Store assets. Screenshots at every required size, a compliant privacy policy hosted at a stable URL, data-safety and privacy labels that actually match what your app does, and metadata written to pass review rather than trip it.
The submission itself. We submit, we monitor, and when a reviewer comes back with a question, we answer it — because we've seen that exact rejection before and we know what it really wants.
The Play testing requirement. We coordinate the closed-testing track so the 14-day clock starts on day one instead of the day you finally find out it exists.

Under the hood, AI generates the submission assets and a human verifies and hardens every one of them before it goes near a reviewer. The automation makes it fast; the human checkpoints make it actually pass. That combination is the whole point — it's what turns six weeks of solo guessing into a predictable two-week pipeline.

The real cost of the gap

It's tempting to measure the gap in dollars — the developer accounts, the hours, maybe a freelancer you hired and then had to manage. But the expensive part was never the money. It was the momentum.

An app launches best when there's energy behind it: a waitlist that's warm, a community that's watching, a founder who's still excited. Six weeks of code-signing errors and vague rejection notices doesn't just delay the launch — it drains the exact enthusiasm that makes a launch work. We've watched genuinely good apps die in that gap, not because anyone gave up on the product, but because they gave up on the paperwork standing in front of it. That's the outcome we exist to prevent.

The promise we make is simple, and it's the one we wished someone had made to us: you finish the app, and we make sure the world actually gets to use it. You stay in the part you're good at and enjoy — building — and the six-week gap stops being your problem.

"Couldn't I just figure it out myself?"

You absolutely could. Everything in the six-week gap is learnable, documented somewhere, and solvable by a determined person with enough evenings. We're not claiming it's impossible — we're claiming it's the wrong thing for you to spend your time on.

Think about what those six weeks actually buy you if you do them yourself. You become moderately good at code signing, a skill you'll use again maybe twice a year and forget in between. You learn the current shape of Apple's review guidelines, which will quietly change before you ship your next app. You memorize the Play Console's data-safety form, which exists nowhere else in your life. It's deep knowledge with an almost comically narrow application — the definition of work that's better delegated.

And the failure mode of doing it yourself isn't just slowness. It's the uncertainty. A rejection notice that says "Guideline 2.1" gives you no signal about whether you're one fix away or ten. You can't plan a launch around it, can't promise a date to anyone, can't tell if tomorrow's resubmission is the last one. That uncertainty is what actually breaks people — not the effort, but never knowing how much more effort is left. A flat fee and a 10-to-14-day window exist precisely to replace that open-ended dread with a date you can put on a calendar and build a launch around.

If you're stuck in the gap right now

If any of the timeline above felt less like a story and more like a diary entry, you're not behind and you're not bad at this. You hit a wall that was always going to be there, hidden one step past the moment everyone celebrates as the finish line.

The build being done is real progress. The gap is real too — but it's the most solvable part of the entire journey, because it's pure process, and process is exactly the kind of thing that should be handled by people who've run it a hundred times.

That's why we built LetsDeployIt. Bring us the build. We'll close the gap — live on the App Store and Play Store in 10 to 14 days, flat fee, approved or your money back.

Originally published on the LetsDeployIt blog.

Why Your AI-Built App Won't Pass App Store Review in 2026 (and 7 Fixes That Work)

Russel Dsouza — Fri, 12 Jun 2026 07:37:26 +0000

Originally written by Sanket Sahu, founder of LetsDeployIt. Republished here.

Your AI-built app works. Your friends love the demo. You submit to Apple expecting approval in 48 hours.

Then the email arrives.

"Your app does not comply with the App Store Review Guidelines."

No clear next step. No fix-this checklist. Just a cryptic guideline reference and a rejection.

If you built your app with Lovable, Bolt, Rork, RapidNative, v0, or any of the AI tools in 2026, this isn't a code problem. Your AI wrote fine code. It's a submission problem — and submission lives entirely outside your codebase.

Why AI-Built Apps Get Rejected More Often

Launch week is a bad time to discover your app is a near-duplicate of ten others in the queue, your payment flow violates Apple's rules, and your store screenshots don't match what's actually on screen.

That is usually when App Store review stops feeling like a formality and starts acting like a release blocker.

In 2026, Apple reviews roughly 100,000+ app submissions a week and rejects a large share of them — and AI-built apps get caught more often than most. Not because the AI wrote bad code, but because shipping to the App Store was never a code problem. The review process lives entirely outside your codebase: compliance, privacy, payments, content policy, and the human judgment of a reviewer who decides in minutes.

The practical question before you submit is straightforward: can you prove the app has a reason to exist, behaves completely, handles data correctly, and matches what its store listing claims?

That usually comes down to four checks:

Originality. Does the app do something a thousand AI templates don't?
Completeness. Can a reviewer reach and use every screen, with no placeholders or dead ends?
Compliance. Are privacy manifests, payments, and content moderation handled the way Apple requires?
Consistency. Do your screenshots, description, and metadata match the real build?

At LetsDeployIt this is the entire job — we get AI-built React Native and Expo apps approved on the App Store and Play Store, with a human on every checkpoint. Below are the seven rejections we see most on AI-generated apps, and the exact fix for each.

The Seven Rejections We See Most

4.3 — Spam and the thin-wrapper problem

This is the number-one killer for AI-built apps in 2026. Guideline 4.3(a) targets apps that are a copy of an existing app or offer little to no functionality. A huge wave of AI-generated apps are essentially the same template — a chat box wired to an LLM API, an AI photo filter, a habit tracker scaffolded from the same prompt thousands of other people used. Reviewers recognize the pattern instantly, and 4.3 rejections are notoriously hard to appeal because they are a judgment call about originality, not a fixable bug.

The fix: Give the app a reason to exist beyond "it uses AI." Add real native functionality the template doesn't have — offline mode, push notifications tied to genuine events, device features, user accounts with persisted data. Differentiate the brand, copy, and screenshots so it doesn't look mass-produced. If you're an agency shipping many similar apps, consolidate them into one app rather than submitting near-duplicates under different names.

2.1 — Broken builds, placeholders, and dead demos

AI scaffolds happy paths beautifully and edge cases poorly. Apps arrive at review with placeholder "Lorem ipsum," buttons that do nothing, links to localhost, features that crash the moment the reviewer's network is throttled, or a login wall with no test account. Guideline 2.1 (App Completeness) means the reviewer must be able to use the whole app. Anything they can't reach counts as incomplete.

The fix: Walk every screen as if you were a stranger with no context. Remove placeholder text and dummy data. If the app requires a login, provide working demo credentials in the App Review notes (and an OTP bypass if you use phone verification). Test on a real device with a poor connection. Make sure every visible button, tab, and link actually leads somewhere.

5.1.1 — The privacy manifest you didn't know you needed

Privacy is the most strictly enforced layer at upload in 2026 — and the one AI scaffolds skip. Since 2024, Apple requires a privacy manifest (PrivacyInfo.xcprivacy) declaring the data your app and its SDKs collect, plus a documented reason for every required-reason API you call (file timestamps, system boot time, disk space, user defaults, and more). In 2026 this is strictly enforced at upload. AI-generated apps almost never include it, and the third-party SDKs the AI pulled in — analytics, ads, crash reporting — often need their own manifests too. The result is an immediate rejection or a blocked upload.

What the manifest has to account for usually breaks into three layers:

Your app — Data categories collected, and a reason code for each required-reason API used
Third-party SDKs — A bundled privacy manifest and signature for each SDK (analytics, ads, crash)
App Store Connect — The App Privacy "nutrition label" matching actual app behavior

The fix: Add a PrivacyInfo.xcprivacy file declaring your data collection and the reason codes for any required-reason APIs. Confirm every SDK ships its own privacy manifest and signature. Fill out the App Privacy nutrition label in App Store Connect so it matches what the app actually does — mismatches between your declared data use and observed behavior are a fast track to rejection.

3.1.1 — Charging for AI without in-app purchase

Almost every AI app wants to charge for "pro" usage, credits, or a subscription. Guideline 3.1.1 is unambiguous: if you sell digital content or features consumed inside the app, you must use Apple's In-App Purchase — not Stripe, not a "subscribe on our website" link, not a buy-credits button pointing to an external checkout. AI starter kits almost always wire in Stripe by default because that's what works on the web. On iOS, it gets you rejected.

The fix: Use StoreKit / In-App Purchase for any digital goods or subscriptions consumed in the app, and don't link out to external payment for them. Physical goods and real-world services can stay on Stripe. If you qualify for newer external-purchase or reader-app entitlements, apply for them explicitly — don't assume they apply by default.

4.2 — Minimum functionality and webview wrappers

A common AI shortcut is to wrap an existing website in a WebView and call it an app. Guideline 4.2 requires apps to deliver lasting value and behave like native apps, not repackaged websites. If your app is mostly a browser pointed at your URL, expect rejection — and the same applies to AI apps that are a single screen with one input box.

The fix: Build native navigation and at least a few capabilities a website can't offer: push notifications, offline caching, native share, camera or photo access, biometrics, home-screen widgets. The bar is "why does this need to be an app?" — make sure you have a concrete answer the reviewer can see in thirty seconds.

1.2 / 5.1 — AI-generated content with no safety net

If your app generates content from user prompts — text, images, chat — Apple treats it like user-generated content. In 2026 reviewers actively test whether an AI app will produce harmful, offensive, or unexpected output. Apps that let users generate anything with no filter, no reporting, and no way to block content get rejected under the UGC rules.

A compliant safety story usually needs all four of these:

Filtering of both prompts and outputs
Reporting so users can flag bad content
Blocking so users can suppress content or other users
A published contact for complaints, plus an honest age rating for mature content

The fix: Add a content-moderation layer — filter prompts and outputs, let users report and block, and show a content policy. Gate mature content and set an honest age rating. Put a real support contact in the app and in your metadata. A short, visible safety story turns a likely rejection into a routine approval.

2.3 — Metadata, screenshots, and AI-written descriptions

The last mile trips up more launches than the code does. Guideline 2.3 (Accurate Metadata) catches screenshots that don't match the real app, descriptions that overpromise ("the smartest AI ever built"), keyword stuffing in the title, mentions of other platforms, and AI-generated marketing copy that claims features the app doesn't ship. Reviewers compare your store listing to what they see on screen — and reject mismatches.

The fix: Use real screenshots from the current build at the correct device sizes. Write a description that matches what the app actually does, with no superlatives you can't demonstrate. Keep the keyword field clean, drop references to Android or "coming soon" features, and make sure your support URL and privacy policy URL both resolve to live pages.

The Bottom Line: AI Builds, Humans Get It Approved

None of these rejections mean AI is bad at building apps — it's extraordinary at it. They mean the App Store review process is a separate discipline that lives outside your codebase: compliance, privacy, payments, content policy, and the human judgment of a reviewer who decides in minutes. That layer is exactly what AI tooling skips, and exactly where most AI-built apps stall.

Clean approvals come from clean submissions. The reviewer may not read your code, but inconsistent assets, missing manifests, and template-grade originality make them look closer.

If you've already eaten a rejection — or you want to avoid one before you submit — that is what we do all day. LetsDeployIt takes your finished React Native or Expo build, prepares every submission asset with AI, then has a senior reviewer harden it against each guideline above and shepherd it through to approval, usually live in 10 to 14 days. Flat fee. Approved, or your money back.

Originally published on the LetsDeployIt blog.

Push Notifications in React Native: The Complete 2026 Guide

Russel Dsouza — Wed, 10 Jun 2026 05:25:46 +0000

If you searched for "React Native push notifications" in 2026 and landed on a 2022 tutorial, half the code in it is broken. The legacy FCM endpoint was sunset in June 2024, Expo Go can't receive push on Android anymore, and Android 13+ needs a runtime permission your old guide doesn't mention.

This is a working 2026 guide for the three paths developers actually use:

Expo + expo-notifications — easiest, recommended for most teams
Bare React Native + @react-native-firebase/messaging — full native control
Hybrid with Notifee — when you need rich UI

Code is copy-paste ready. Let's go.

What changed and why your old code is broken

FCM legacy API is dead. https://fcm.googleapis.com/fcm/send returns 404. New endpoint is v1/projects/{id}/messages:send with OAuth 2.0.
Expo Go can't receive remote push since SDK 53. You need a development build.
Android 13+ requires POST_NOTIFICATIONS at runtime. Forget it and your notifications silently never appear.
iOS 15+ added interruption levels (passive, active, time-sensitive, critical) that change how notifications break through Focus modes.

Path 1: Expo + expo-notifications

Install + dev build

npx expo install expo-notifications expo-device expo-constants
eas build --profile development --platform ios

You cannot test push in Expo Go anymore — accept the dev build cost up front.

Request permission and get the token

import * as Notifications from 'expo-notifications';
import * as Device from 'expo-device';
import Constants from 'expo-constants';
import { Platform } from 'react-native';

export async function registerForPushNotificationsAsync() {
  if (!Device.isDevice) throw new Error('Physical device required');

  if (Platform.OS === 'android') {
    await Notifications.setNotificationChannelAsync('default', {
      name: 'Default',
      importance: Notifications.AndroidImportance.HIGH,
      vibrationPattern: [0, 250, 250, 250],
    });
  }

  const { status: existing } = await Notifications.getPermissionsAsync();
  let final = existing;
  if (existing !== 'granted') {
    const { status } = await Notifications.requestPermissionsAsync();
    final = status;
  }
  if (final !== 'granted') throw new Error('Permission denied');

  const projectId = Constants.expoConfig?.extra?.eas?.projectId;
  return (await Notifications.getExpoPushTokenAsync({ projectId })).data;
}

Send from your server

import { Expo } from 'expo-server-sdk';

const expo = new Expo();

export async function sendPush(tokens: string[], title: string, body: string) {
  const messages = tokens
    .filter(Expo.isExpoPushToken)
    .map((to) => ({ to, sound: 'default', title, body, data: { url: '/inbox/42' } }));

  const chunks = expo.chunkPushNotifications(messages);
  for (const chunk of chunks) {
    await expo.sendPushNotificationsAsync(chunk);
  }
}

chunkPushNotifications is required — Expo caps batches at 100.

Path 2: Bare RN + FCM HTTP v1

npm install @react-native-firebase/app @react-native-firebase/messaging
cd ios && pod install

Drop google-services.json into android/app/ and GoogleService-Info.plist into iOS. Enable Push Notifications + Background Modes in Xcode.

Permission + token

import messaging from '@react-native-firebase/messaging';
import { Platform, PermissionsAndroid } from 'react-native';

export async function registerForPushNotifications() {
  if (Platform.OS === 'android' && Platform.Version >= 33) {
    await PermissionsAndroid.request(
      PermissionsAndroid.PERMISSIONS.POST_NOTIFICATIONS,
    );
  }
  const status = await messaging().requestPermission();
  if (status === messaging.AuthorizationStatus.DENIED) {
    throw new Error('Permission denied');
  }
  return messaging().getToken();
}

Server send with FCM HTTP v1

The 2026 endpoint. Authenticate with a service account JSON, not a server key.

import { GoogleAuth } from 'google-auth-library';

async function getAccessToken() {
  const auth = new GoogleAuth({
    keyFile: 'service-account.json',
    scopes: ['https://www.googleapis.com/auth/firebase.messaging'],
  });
  const client = await auth.getClient();
  const { token } = await client.getAccessToken();
  return token;
}

export async function sendFcmV1(token: string, title: string, body: string) {
  const accessToken = await getAccessToken();
  const projectId = process.env.FIREBASE_PROJECT_ID;

  const res = await fetch(
    `https://fcm.googleapis.com/v1/projects/${projectId}/messages:send`,
    {
      method: 'POST',
      headers: {
        Authorization: `Bearer ${accessToken}`,
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({
        message: {
          token,
          notification: { title, body },
          data: { url: '/inbox/42' },
          android: { priority: 'HIGH', notification: { channel_id: 'default' } },
          apns: { payload: { aps: { sound: 'default', 'interruption-level': 'time-sensitive' } } },
        },
      }),
    },
  );
  return res.json();
}

Two big changes from the legacy API:

Platform overrides live in android and apns blocks
OAuth token rotates ~hourly — cache it

Path 3: Notifee for rich UI

Neither expo-notifications nor RNFirebase gives you full control over how a notification looks. Notifee does. Pair it with your delivery layer.

import notifee, { AndroidStyle, AndroidImportance } from '@notifee/react-native';
import messaging from '@react-native-firebase/messaging';

messaging().setBackgroundMessageHandler(async (msg) => {
  const channelId = await notifee.createChannel({
    id: 'chat',
    name: 'Chat',
    importance: AndroidImportance.HIGH,
  });

  await notifee.displayNotification({
    title: msg.data?.title,
    body: msg.data?.body,
    android: {
      channelId,
      style: {
        type: AndroidStyle.MESSAGING,
        person: { name: msg.data?.sender, icon: msg.data?.avatar },
        messages: [{ text: msg.data?.body, timestamp: Date.now() }],
      },
      actions: [
        { title: 'Reply', pressAction: { id: 'reply' }, input: true },
        { title: 'Mark read', pressAction: { id: 'mark-read' } },
      ],
    },
  });
});

This gets you Messenger-style chat notifications, ongoing progress bars, and full-screen incoming-call screens.

The thing every tutorial gets wrong: cold start

When a user taps a notification with your app killed, your handlers are not mounted. You have to check the initial payload synchronously on first render.

Expo:

const lastResponse = Notifications.useLastNotificationResponse();
useEffect(() => {
  const url = lastResponse?.notification.request.content.data?.url;
  if (url) router.push(url);
}, [lastResponse]);

RNFirebase:

useEffect(() => {
  messaging().getInitialNotification().then((msg) => {
    if (msg?.data?.url) router.push(msg.data.url);
  });
}, []);

Always test by force-quitting the app, killing it from recents, and tapping the notification cold. That's the path that breaks in production.

Token lifecycle (the 90% nobody writes about)

Working getToken() is 10% of the job. The rest:

Upsert on every cold start. Treat the token your app sends as the source of truth.
Soft-delete on UNREGISTERED / NotRegistered. Stale tokens silently kill delivery rate.
Model (user_id, device_id, token, platform, last_seen_at) rows. Not users.push_token. One user has N devices.
Retry with exponential backoff. 5xx and 429 are real. 250ms -> 500ms -> 1s -> 2s -> 4s with a circuit breaker.

Quick decision matrix

You want…	Use…
Fastest setup	Expo + `expo-notifications`
Full native control	Bare RN + `@react-native-firebase/messaging`
Rich layouts, action buttons, ongoing notifications	+ Notifee on top
Hosted dashboard, A/B testing	OneSignal
Lifecycle marketing	Customer.io / Braze

That's the whole tree.

If you want the long-form version with the production server architecture, decision matrix, and PAA section, the canonical post is on the RapidNative blog.

What did your last broken-push-notifications debugging session look like? Drop it in the comments — I'm collecting failure modes for a follow-up.

Side Project to App Store - A Non-Technical Founder's 2026 Guide

Russel Dsouza — Wed, 03 Jun 2026 05:35:53 +0000

If you're a non-technical founder shipping a React Native side project, the build is the easy part. The hard part lives between "my Expo dev build runs on my phone" and "my app is live in the App Store."

This is the practical checklist for the middle.

The five stages

Idea → Concept (3–5 evenings of validation)
Concept → Prototype (1–2 weekends with an AI app builder)
Prototype → Real phones (1 week, Expo Go + TestFlight)
The boring stuff (1–2 weeks of submission prep)
Submission and review (1–2 weeks)

Total: 6–10 weeks of evenings for a solo non-technical founder.

Stage 2: The prototype

For non-technical founders, the modern path is an AI app builder that emits real React Native and Expo code — not the no-code platforms that lock you into a hosted runtime. The output is normal Expo source: you can clone it, extend it, run npx expo prebuild, and ship it through EAS like any other React Native project.

# After exporting from the AI builder:
git clone <your-repo>
npm install
npx expo start
# Or to build for the stores:
eas build --platform all

The code is yours. No lock-in.

Stage 4: The submission checklist (where most projects die)

Developer accounts

Apple Developer Program     $99/year
Google Play Console         $25 one-time

Apple takes 1–3 days for identity verification. Google now requires a 14-day closed-testing track with 12 testers before a first-time developer can publish their first app.

Required policy + flows

Privacy policy at a public URL
In-app account deletion (both stores require this; "email us" is rejected)
Sign in with Apple if you offer any third-party sign-in
App Tracking Transparency prompt if any SDK touches an identifier
Privacy manifest declaring third-party SDKs

Required assets

App icon: 1024×1024 PNG, no transparency, no rounded corners
Six screenshots minimum
30-char app name, 80-char subtitle, 4000-char description
Optional: 15–30s preview video, no audio narration

App Store Connect setup

Bundle ID (set once, can't change without re-publishing as a new app)
Primary + secondary category
IAP products configured before submission
Push notification certificates if applicable

Stage 5: Surviving review

The top first-submission rejection reasons in 2026, in order:

Missing privacy declarations (anything you collect, including crash logs, must be declared)
Missing Sign in with Apple alongside Google or Facebook sign-in
Missing in-app account deletion
"Insufficient functionality" — looks like a website wrapped in WebView
Misleading screenshots showing features that don't exist

Submit Tuesday or Wednesday. First-app review is currently 5–7 days; resubmissions are 24–48 hours.

After launch

Set up three things in the first 90 days:

ASO experiments: test subtitle, first screenshot, and icon — the only acquisition lever that compounds without ad spend.
A single conversion event in analytics. Anything more and you'll read dashboards instead of fixing the app.
An exit interview flow for churned users. The best research interviews come from people who stopped using your app.

Reading the code

Even if you don't write it, learn to read it. Glance at the generated React Native files weekly. You don't need to be fluent — you need to be able to spot when a component is doing too much, when state is in the wrong place, or when the AI took a shortcut that'll bite later.

A non-technical founder who can read React Native is the most leveraged version of the role in 2026.

The full long-form guide with screenshots, stage-by-stage timelines, and the post-launch playbook is here on our blog.

If you want to skip Stage 2 entirely and start from a prompt, try RapidNative. It generates real Expo code you can clone and extend.

Posting instructions for Dev.to:

Use the frontmatter at the top exactly as shown — Dev.to parses it for tags, canonical, and cover image.
Tags max 4: reactnative, mobile, startup, webdev.
Cross-post 1–2 days after the canonical version is live so Google indexes your canonical first.
Best posting time: Tuesday or Wednesday, 8am EST.
Engage with the first 5 comments within an hour — Dev.to's algorithm rewards early engagement.