DEV Community: Jules Sarah

React Native Performance Optimization: The 2026 Playbook

Jules Sarah — Tue, 11 Aug 2026 09:48:19 +0000

Profile before changing code. Before/after numbers required in every performance PR.
New Architecture on (default since RN 0.76) is the single biggest win.
Hermes stays on; the footgun is source maps, not the engine.
FlashList for any list past ~50 items. Set estimatedItemSize.
Animations off the JS thread: Reanimated 4, Gesture Handler, Skia.
Ship a performance budget in CI with Flashlight so regressions break the build, not the App Store rating.

Most React Native apps do not need more code to feel fast. They need less of the wrong code, in the right places. In 2026 the platform has changed enough (New Architecture is default, Hermes is default, FlashList is stable, Reanimated 4 is stable) that the old advice, memoize everything, throw shouldComponentUpdate at every list item, dread the bridge, is either automatic or actively wrong.

This is the current playbook. It is opinionated, ordered by impact, and it assumes one thing above all: you measured the problem before you changed any code. That single discipline is worth more than every trick below combined.

What "fast" actually means in React Native

Before you optimize anything, agree with your team on numbers. "It feels slow" is not a spec. In 2026, a shippable React Native app on a mid-tier Android device (think Pixel 6a, Samsung A34) should hit:

Cold start under 2.0 seconds on Android, under 1.2 seconds on an iPhone 13, measured from tap to first interactive frame.
Sustained scroll at 58+ fps on lists of 500+ items with images.
Interaction latency under 100 ms from touch to visible state change.
JS heap under 180 MB during normal use, no monotonic growth over a 10-minute session.
Install size under 30 MB for the base binary, App Store thin variant.

If you cannot state your app's current numbers against these, that's the first fix. Everything below assumes you know where you stand.

Step 1: Profile first, stop guessing

React Native's performance surface spans three worlds: the JavaScript thread, the UI/main thread, and native modules. A bug in one will look identical to a bug in another until you profile.

The 2026 toolbelt:

Hermes Sampling Profiler: the primary tool for finding hot JS functions. It ships with React Native, has near-zero overhead, and produces flame graphs you can open in Chrome DevTools or Perfetto. Start every investigation here.
React DevTools Profiler: commit-by-commit view of which components rendered and why. Use it to catch re-render storms; the "Highlight updates when components render" toggle is the quickest way to see them without profiling.
Flashlight: CLI tool for measuring FPS, CPU, memory and JS thread health during scripted test runs. Puts real numbers on regressions in CI.
Perfetto (Android) and Instruments (iOS): for anything that crosses the native boundary: cold start, module init, layout, gesture responsiveness.
Expo's built-in performance inspector: if you're on Expo (you probably should be), the dev menu now includes an FPS meter and JS heap sampler that's good enough for 80% of day-to-day work.

The measurement rule is simple: produce a before number, produce an after number, and require both in the PR description. Every performance change without both numbers gets reverted on principle. This one rule alone will make your app faster than any single optimization on this list.

Step 2: Be on the New Architecture, the single biggest win

React Native 0.76 made the New Architecture the default. Expo SDK 52 followed. If you are still opted out, you are leaving a large share of your cold start and roughly all of your bridge overhead on the table.

The New Architecture is three pieces working together:

JSI (JavaScript Interface) replaces the old asynchronous JSON bridge with direct, synchronous calls between JS and native code. The bridge is gone. Calls that used to be serialize -> queue -> deserialize -> return -> deserialize are now function pointers.
Fabric is the new renderer. It's concurrent-mode aware, does layout on the UI thread, and eliminates the "commit storm" that used to cause jank during scroll + fetch combinations.
TurboModules are the successor to native modules. They load lazily (only on first use), which alone can shave 200–400 ms from cold start in apps with many linked modules.

Migration in 2026 is mostly a checkbox: "newArchEnabled": true in app.json for Expo, or the equivalent in gradle.properties and Podfile.properties.json for bare projects. What breaks are third-party native modules that never got upgraded; check each dependency's issue tracker before you flip the flag. Teams that finished the migration have reported cold starts improving by a third or more, list rendering throughput up by similar margins, lower memory use, and animation frame rates jumping from the high 40s to a steady 58–59 fps. Run your own before/after; the direction is consistent even where the exact numbers vary by app. This is the single largest performance change React Native has ever shipped.

The New Architecture in React Native 0.76+ is where the "React Native feels native" claim finally becomes true. Photo by Rob Hampson on Unsplash

Step 3: Hermes is the default, leave it on and understand what it's doing

Hermes is the JavaScript engine on iOS and Android by default in 2026. Its value is not just runtime speed, it's the ahead-of-time bytecode compilation step that happens during your build. Your app ships pre-compiled bytecode instead of raw JS, which is why cold starts on Hermes are typically much faster than on JSC.

Three things to actually do:

Confirm Hermes is on in your release build, not just dev. It's easy to miss when migrating from JSC. hermesEnabled=true in gradle.properties, :hermes_enabled => true in the Podfile, or the equivalent Expo config.
Enable bytecode precompilation in CI, so the bytecode is baked at build time rather than the first launch on device.
Check your source maps. Hermes bytecode makes stack traces unreadable in Sentry/Bugsnag without the correct source map upload. This is the one Hermes footgun that consistently bites teams in production.

The engine itself is stable. You do not need to tune it. The wins come from not accidentally disabling it and from wiring source maps correctly.

Step 4: FlashList for every list that matters

FlatList in 2026 is a fine default for short lists. The moment a list has more than ~50 items, images, or variable row heights, replace it with FlashList from Shopify. This is the single highest-leverage React Native optimization that requires you to write actual code.

FlashList is a drop-in replacement that recycles cells instead of unmounting them, does not allocate a new view for every item, and delivers several times the throughput of FlatList on data-heavy screens. On a Pixel 6a scrolling 1,000 image-plus-text rows, expect 58–60 fps sustained under FlashList against 30–40 fps with occasional freezes under FlatList.

Two rules to actually get the speedup:

Set estimatedItemSize accurately. Even off by 30% and you still get most of the win; missing entirely and FlashList falls back to slower measurement passes.
Do not put dynamic per-item work inside renderItem closures. Every re-render creates new closures; memoize row components and their handlers.

If your list has variable height rows and you cannot estimate size, use estimatedItemSize with the median height. Do not overthink it.

Step 5: Kill unnecessary re-renders, but only the ones that matter

Re-renders are the most over-optimized problem in React Native. Wrapping every component in React.memo bloats your bundle and slows down mounting. The rule for 2026: profile first, memoize where the profiler shows a hot path.

That said, four re-render anti-patterns cause most real performance bugs, and they're worth pattern-matching against:

Inline object props. <Component style={{ margin: 8 }} /> creates a new object on every parent render, which invalidates every downstream React.memo. Hoist styles into StyleSheet.create or a constant.
Inline handler props. <Button onPress={() => doThing(id)} /> creates a new function every render. Use useCallback, or better, move the handler inside a memoized child that owns the id.
Context provider sprawl. Every value change in a large context re-renders every consumer. Split contexts by update frequency: one for user identity (rarely changes), one for theme (rarely changes), one for live data (changes often). Do not put them all in a single context.
Selector reference issues. Redux/Zustand selectors that return new object references on every store update will re-render every consumer even if the values are identical. Use shallow equality checks or memoized selectors.

The why-did-you-render package is still the fastest way to find these in dev; it logs to console every time a memoized component re-renders unnecessarily.

Step 6: Move animations off the JS thread

An animation running on the JS thread will drop frames the moment JS is busy, which is always, because JS is where your business logic runs. In 2026 there is no reason to run animations on the JS thread at all.

The stack:

Reanimated 4 for anything driven by state, gesture, or timing. Its worklets run on the UI thread as native functions: a 60fps spring animation runs at 60fps even while the JS thread is parsing a 500KB JSON response.
React Native Gesture Handler for anything the user drags, swipes, or pinches. The old PanResponder API is JS-thread-bound and will jank; Gesture Handler runs on the UI thread.
Skia for anything painterly: charts, custom drawing, complex transitions. It bypasses the React view tree entirely and renders directly to a GPU canvas.

The rule: if you are writing Animated.Value with useNativeDriver: false, stop. Convert it to Reanimated or figure out why useNativeDriver: true isn't an option (usually it's an animatable prop that Reanimated supports and old Animated doesn't).

Step 7: Cold start, the number your users actually notice

Cold start is the sum of native init + JS bundle load + JS bundle execute + first render. The wins, in order of impact:

New Architecture on (Step 2). Biggest single win.
Hermes bytecode precompiled (Step 3). Second biggest.
Bundle size reduction. Every 100 KB of JS costs real parse+execute time on a mid-tier Android. Run npx react-native-bundle-visualizer and delete what surprises you. moment.js, lodash (full), and 5 different date-picker libraries you forgot you had are the usual suspects.
Lazy-load routes. Everything under React.lazy + Suspense at the route boundary. Your login screen does not need to parse your dashboard's 400KB of code.
Native module audit. Every linked native module runs its init code at startup. Remove modules you no longer use. Even removed JS imports leave native code linked until you unlink.
Font loading. Preload only the weights you use on the initial screen. Font.loadAsync for 12 weights blocks first paint for hundreds of ms.
Splash screen strategy. Keep the native splash visible until the first interactive screen is ready to render; don't cross-fade too early or you get a flash of empty content.

Instrument this with AppRegistry.setWrapperComponentProvider plus a manual mark at the first meaningful paint, log it to your analytics, and watch the median (not the mean; the mean lies).

Step 8: Memory, the silent killer

Memory leaks in React Native rarely crash the app. They just make it slower, and slower, and eventually the OS kills it in the background and users think "the app forgot me." The three sources that account for almost every leak in the wild:

Uncleaned event listeners. Every addEventListener, every subscribe, every AppState handler needs its cleanup in the useEffect return. The exhaustive-deps ESLint rule will not catch these; you have to review them.
Image caching without bounds. react-native-fast-image caches aggressively. Set a maxMemoryPolicy or your app will happily hold hundreds of MB of thumbnails. Same story for any list that renders image-heavy rows: use removeClippedSubviews and let FlashList recycle.
Uncleared timers and intervals. setInterval inside a component that mounts and unmounts on navigation is the classic leak.

Take a heap snapshot after 10 minutes of use, then again after 30, and compare. If the delta isn't roughly flat, you have a leak. The tool for this on iOS is Instruments' Allocations; on Android it's Android Studio's Memory Profiler.

Step 9: Network, the invisible half of "fast"

Users don't distinguish between "the app is slow" and "the network is slow." Your job is to hide the network from them.

TanStack Query for every fetch that has a cache key. Deduplication, background refetch, stale-while-revalidate: you get it for free. The single library that most improved perceived React Native performance in the last two years.
HTTP/2 or HTTP/3 on your API. If you're on HTTP/1.1 you're paying a full round trip per request. Cloudflare, Fastly, AWS ALB all default to HTTP/2 now.
Image CDN with responsive sizing. Serve 400×400 to the phone, not 4000×4000. Cloudinary, imgix, and Cloudflare Images all do this automatically from URL parameters.
Parallelize independent requests. Promise.all for anything that doesn't depend on the previous result.
Optimistic updates. For any user action that will succeed 99% of the time, update the UI immediately and roll back on error. Users feel every millisecond you make them wait for a spinner.

Step 10: Ship a performance budget in CI

Everything above is worthless if a well-meaning teammate ships a regression next Tuesday. The fix is a performance budget in CI, and the tool for it in 2026 is Flashlight.

Flashlight runs a scripted E2E test on a real (or emulated) Android device, records CPU/FPS/memory across the run, and fails the build if any metric exceeds the budget you set. Point it at your five most important user flows (cold start, login, main list scroll, detail view, checkout) and set the budgets 10–20% above your current numbers. Now every PR that regresses performance breaks CI, and the regression conversation happens in code review instead of in the App Store reviews six weeks later.

When to NOT optimize

Optimizing without measurement is how apps end up with 400 KB of memoization wrapping and no measurable difference. Three reasons to hold back:

The profiler doesn't show a hotspot. Then you're not fixing anything, you're just writing code.
The user cannot perceive the change. Nobody notices a 12 ms → 8 ms improvement on a screen that's already at 60 fps. They notice 30 fps → 60 fps. Chase the visible.
The optimization removes a real feature. Slower with the feature > faster without it, unless the feature is optional.

Where AI-generated code fits in

Modern AI mobile app builders like RapidNative have quietly closed a large part of this gap. When you describe an app in plain words and generate a real React Native + Expo project, the output already has the New Architecture enabled, Hermes on, FlashList for meaningful lists, Reanimated wired up, and TanStack Query for data, because those are the current defaults, and the model was trained on the current stack.

What AI generation does not do (yet, reliably) is your app's specific measurement work. It cannot know that your product screen renders 400 image cards and needs a memoized row component, or that your context provider has grown three orders of magnitude too much state. The playbook above is what you bring to a generated app: you get the correct baseline for free, and then you profile, measure, and tune what matters for your users.

If you're building a new React Native app in 2026, the fastest path is: generate the correct baseline, ship the first version, measure real user performance, and apply this playbook to what your profiler actually flags. Skip the weeks of boilerplate; spend that time on the parts of your app only you understand.

What's the optimization that actually moved your numbers, and what did you measure it with? Drop it in the comments; the profiler-verified wins are the ones worth collecting.

The App Store Privacy Declaration Checklist Nobody Gives You

Jules Sarah — Fri, 07 Aug 2026 07:36:45 +0000

Google Play's data safety form and Apple's PrivacyInfo.xcprivacy are the same idea in two formats, and both reject apps whose declarations don't match reality.
Audit every SDK before touching either form: what it collects, linked or unlinked, and the purpose.
The six categories that catch first-timers: crash reporting, IP addresses, purchase history, diagnostics, ad SDKs, account creation.
Apple's manifest has been enforced since May 2024. Missing entries surface as App Store Connect warnings, then rejections.
Automate the mapping: keep an SDK inventory file and regenerate the declaration on every release.

Every mobile app submission has a wall you don't see coming. Not the review queue, not screenshot rejections: the privacy declaration. Google Play's data safety section and Apple's privacy manifest are the same idea in two formats, and both reject an app whose declaration doesn't match reality.

Why this matters

An incorrect privacy declaration is not a technical bug, it is a policy violation. Google Play rejects the update, and repeated violations put the developer account at risk. Apple's privacy manifest (PrivacyInfo.xcprivacy, enforced since May 2024) surfaces missing entries as App Store Connect warnings, then rejections.

Most indie developers fill these forms from memory five minutes before submitting, then spend the next week resubmitting because they forgot Sentry collects device identifiers.

The full inventory audit

Before touching either form, list every third-party SDK in the app. For each, note three things: what it collects, whether that data is linked to the user (account ID or device ID) or unlinked, and whether it serves analytics, personalization, advertising, or app functionality.

Common indie-app SDKs and what they collect:

SDK	Collects	Linked?	Purpose
Firebase Analytics	Device ID, session data, user actions	Linked (Firebase user ID)	Analytics
Sentry	Device model, OS version, stack traces	Unlinked unless user context attached	Diagnostics
RevenueCat	Purchase history, subscription state	Linked (RevenueCat user ID)	App functionality
Mixpanel / PostHog	User actions, custom events	Linked (your user ID)	Analytics
AdMob / AppLovin	Device ID, ad interaction	Linked	Advertising

This audit output is what you reference against every question on both platforms' forms.

The 6 categories that trip up first-time submitters

Crash reporting. Counts as collection even if you never look at it. Sentry, Crashlytics, Bugsnag all collect declarable types.
IP addresses. Every network request logs an IP somewhere. If your backend logs IPs (it does), you collect device identifiers.
Purchase history. StoreKit or Play Billing plus RevenueCat means financial info, even though card data never touches your servers.
Diagnostic data. Performance metrics, ANR reports, custom logs. All collection.
Ad SDK data. Any monetization SDK means collecting for advertising. The most common source of rejections.
Account creation. Email, password hash, phone: always linked, always declared.

Google Play vs App Store

Same intent, different formats.

	Google Play	App Store
Format	Question-based Console form	`PrivacyInfo.xcprivacy` plist in the bundle
Structure	~40 questions across 14 data categories	Typed entries per data type plus required-reason API codes
Filled	In the Play Console UI	In code, merged from your app and every SDK's own manifest

Xcode 15+ merges your manifest with every SDK's bundled manifest into one privacy report, which feeds the App Store label. Fill the two platforms out separately; there is no shared source unless you build one.

Copy-paste starting point

For a typical indie app (analytics + crash reporting + payments):

You use	Play form answer	Apple manifest data type
Firebase Analytics	Collects: Device IDs, App interactions. Purpose: Analytics	`NSPrivacyCollectedDataTypeDeviceID`, `NSPrivacyCollectedDataTypeProductInteraction`
Sentry	Collects: Crash logs, Diagnostics	`NSPrivacyCollectedDataTypeCrashData`, `NSPrivacyCollectedDataTypePerformanceData`
RevenueCat	Collects: Purchase history	`NSPrivacyCollectedDataTypePurchaseHistory`

A starting point, not an answer key: verify each SDK's current documentation at submission time, since collection profiles change between versions.

Automate this, don't guess

Maintain a spreadsheet or JSON file with your SDK inventory and each one's collection profile, and regenerate the declaration on every release instead of recalling it. CI tooling such as LetsDeploy can diff your dependency list against the last declared inventory and fail the build when a new SDK appears undeclared. Fifteen minutes building this system saves days of rejection cycles per year.

What's the SDK that surprised you most on a privacy form? Mine was learning that crash logs count. Drop yours in the comments.

The Onboarding Chapter Missing From Most SaaS Template Reviews

Jules Sarah — Thu, 06 Aug 2026 09:37:42 +0000

The Onboarding Chapter Missing From Most SaaS Template Reviews

Most SaaS template reviews follow the same format.

Which framework does it use?
Does it support authentication?
Which database does it ship with?
Is the codebase clean?
Is it worth the price?

Those questions matter.

But they rarely cover the part that determines whether your users actually stick around:

The onboarding experience.

A modern tech stack gets people through signup.

A thoughtful onboarding flow gets them to their first success.

The tech stack tells you nothing about retention

A template with the latest version of Next.js, a polished UI, and perfect TypeScript can still lose users before they ever experience the product's value.

Meanwhile, a template running a slightly older stack—but with a carefully designed onboarding experience—can create happier users from day one.

The framework determines what's possible.

The onboarding determines whether users ever get there.

What a good onboarding flow contains

After reviewing dozens of SaaS templates, the best ones usually include most of the following.

Users land somewhere useful

Nobody likes opening a blank application.

If it's a project management app, preload a sample project.

If it's an analytics product, show demo charts.

If it's a CRM, include sample contacts.

An empty product feels unfinished.

A populated product teaches by example.

A short first-run experience

Not a ten-minute walkthrough.

Not a feature tour.

Just three to five focused steps that help users complete the product's primary workflow.

The goal isn't education.

The goal is momentum.

Activation events are already wired

The best templates don't just include analytics.

They already track the moments that matter.

trackEvent("signup_completed")
trackEvent("workspace_created")
trackEvent("first_invite_sent")
trackEvent("integration_connected")
trackEvent("subscription_started")

You can always replace the analytics provider later.

What's valuable is that somebody already identified the events worth measuring.

Empty states teach

Good empty states answer the question:

"What should I do next?"

Bad empty states say:

No projects yet.

Good empty states say:

You don't have any projects yet. Start by creating one for your team's current goal.

That's product design—not placeholder text.

Trial status is obvious

If users are on a 14-day trial, they should always know:

How many days remain
What happens when it ends
What features they're currently using

No surprises.

The first week is already planned

Great templates include more than a welcome email.

They ship with an onboarding sequence like:

Day 0 — Welcome
Day 2 — First success tips
Day 5 — Feature discovery
Day 10 — Trial reminder
Trial ended — Next steps

That saves teams days of writing and experimentation.

Ship activation events, not just dashboards

Every SaaS template includes an admin dashboard.

Very few include meaningful analytics instrumentation.

The templates worth adopting already track moments like:

Signup completed
First workspace created
First invite sent
First integration connected
First subscription started

The code itself isn't complicated.

What's valuable is the product thinking behind it.

Empty states are a UX exercise

Every empty screen is an opportunity to help users.

Compare these two messages.

Version A

No items found.

Version B

You don't have any projects yet. Most teams begin by creating a project around their current quarterly goal.

One creates confusion.

The other creates momentum.

When reviewing a SaaS template, browse every screen with zero data.

If every page says "No items yet," you'll spend weeks fixing onboarding gaps after launch.

How to spot templates that took onboarding seriously

Look for these signals:

✅ Demo ships with realistic sample data

✅ First-run onboarding is built into the demo

✅ Activation events are already instrumented

✅ Empty states teach users what to do next

✅ Subscription and trial status are visible

✅ Transactional onboarding emails are included

Templates that check every box are surprisingly rare.

When you find one, you're paying for product thinking—not just code.

Applighter's take

At Applighter, we've learned that onboarding deserves the same attention as architecture.

That's why our templates include:

Sample workspaces from day one
Activation events wired into the product
Empty states that guide instead of confuse
A complete first-week onboarding email sequence

Whether you choose Applighter or another template, evaluate onboarding with the same rigor you evaluate the tech stack.

Because users don't retain because your framework is modern.

They retain because they know what to do next.

Final thoughts

The SaaS template ecosystem spends a lot of time comparing frameworks.

Users don't.

They care about one thing:

Can I succeed in the first five minutes?

The best templates answer that question before the user ever has to ask it.

That's why onboarding deserves to be part of every SaaS template review.

Ship a React Native app in days, not months

Jules Sarah — Fri, 31 Jul 2026 10:38:06 +0000

If you've ever started a React Native project on Monday and looked up on Friday to realize you've written zero product code, only auth, DB migrations, and EAS config, this post is for you.

Applighter customers ship in days, not months. Not because they're faster developers, but because the patterns below are already in the repo when they clone it.

The setup tax

Every React Native project pays it:

Task	Days
Auth (email + OAuth)	3–5
DB schema + RLS	2–4
Stripe + entitlements	3–5
AI streaming	4–7
EAS build/submit	1
Design system	2–3
Push	2
Total	~4 weeks

Before line one of your product code.

Pattern 1: one theming primitive

// app/apps/lib/theme.ts
export function applyProductTheme(brandHex: string) {
  const hsl = hexToHsl(brandHex)
  // propagates to background, foreground, primary, secondary,
  // muted, accent, destructive — all HSL-derived
  return buildPalette(hsl)
}

One color in, full palette out. Rebrand an app in 20 minutes, not a weekend of grep-and-replace.

Pattern 2: hybrid data provider

// app/apps/lib/data/provider.ts
export async function getProductData(slug: string) {
  try {
    const data = await fetchFromSupabase(slug)
    if (data) return data
  } catch {}
  return staticFallback[slug]  // ships in the bundle
}

Cloned repo runs on the simulator without env vars. First-run latency: 60 seconds, not 90 minutes.

Pattern 3: RLS pre-baked

-- supabase/migrations/20260112085737_create_transactions_table.sql
alter table transactions enable row level security;

create policy "users read own transactions"
  on transactions for select
  using (auth.uid() = user_id);

Every table ships with the policy. You audit, you don't design.

Reference: Supabase RLS docs.

Pattern 4: Stripe → grant → download

// app/api/webhook/stripe/route.ts
if (event.type === "checkout.session.completed") {
  const { isBundle, targets } = await resolveGrantTargets(supabase, productId)
  await grantProducts(supabase, {
    userId,
    productId,
    licenseType,
    source: "stripe_purchase",
  }, targets)
  await sendReceiptEmail({ userId, downloadUrl })
}

Bundles expand into individual grants. Guest checkouts validated by session_id. Single/Multiple/Enterprise license types. It's the code you'd write on day 4 of a Stripe integration, except it's already there.

Pattern 5: EAS ready

// eas.json
{
  "build": {
    "development": { "developmentClient": true, "distribution": "internal" },
    "preview": { "distribution": "internal" },
    "production": { "autoIncrement": true }
  },
  "submit": { "production": {} }
}

/ship slash command → eas build --profile production && eas submit. See Expo EAS docs.

Pattern 6: agent-legible codebase

Every template ships with a .claude/ directory of slash commands. /add-screen, /swap-backend, /audit-security. They work because the codebase is:

Small files, obvious responsibilities
NativeWind classes (Tailwind semantics)
Typed data providers
Colocated components with their tests

An agent (Claude Code, Cursor) can extend it without wandering. That's a real speed multiplier in 2026.

Comparison

	From scratch	Free boilerplate	Applighter
Time to TestFlight	4–6 weeks	2–3 weeks	3–5 days
Backend	You build	Not included	Supabase, wired
Payments	You build	Not included	Stripe + grants
RLS	You design	N/A	Pre-baked
Updates	You maintain	Repo-dependent	Lifetime
Cost	~$8–20k dev time	Free + hidden time	$79 one-time

What ships in days vs. weeks

Bimodal distribution across ~500 customers:

3–5 days: rebrand-and-launch on an existing template (weather, fitness, e-learning)
2–4 weeks: novel AI product built on template infrastructure (voice notes, PDF chat, calorie tracker)

Both compress the ground-up equivalent by ~4x.

When not to use a template

Building something the data model doesn't stretch to fit (games, real-time collab)
Learning React Native for its own sake
Need a stack we don't ship (Firebase, Convex, bare RN)

FAQ

Do I need Supabase experience? No. Templates run with the DB seeded.

Can I skip the theming layer? Yes. Default colors ship out of the box.

What if a new Expo SDK breaks it? Updates are pushed to your dashboard. Pull and diff.

Refunds? 7-day money-back. Policy is on the site.

Try one

Browse the full template catalog. $79 one-time, full source, lifetime updates. Ship this week.

The React Native template launch that made us $87

Jules Sarah — Wed, 29 Jul 2026 04:34:56 +0000

Note: This is the honest developer-story version of an internal postmortem. If you want a shorter, more meme-friendly version, we have one on Medium. If you want a first, code-heavy version, it's on Dev.to. This one is the long form.

Where we started

Two founders. 180 combined hours of work. One React Native template we were quietly proud of. Twelve screens, Expo SDK, TypeScript, NativeWind, tab-based navigation, auth screens that looked like Instagram's. We priced it at $29 and launched on a Tuesday morning.

By Friday evening we had:

5 sales
4 refund requests
1 chargeback in flight
$87 in the bank
1 email from a customer named "Dev" (probably not his real name) that started with "Hey guys, I have to be honest with you..."

That email is where this post starts.

The email that changed the company

The paraphrased version:

I thought this was going to save me a week. It saved me maybe an evening. The auth doesn't connect to anything, the API returns hardcoded data, and I still have to build the entire backend. Why did I pay $29 for what's basically a Figma export in TypeScript?

Every sentence was honest. We had shipped a UI kit. Our landing page used the phrase "full-stack" four times. In the repo, "full-stack" meant this:

// src/services/mockApi.ts
export const HARDCODED_NOTES: Note[] = [
  { id: '1', title: 'Meeting notes', body: '...' },
  { id: '2', title: 'Idea', body: '...' },
];

export async function getNotes(): Promise<Note[]> {
  await sleep(300); // for that "loading" feel
  return HARDCODED_NOTES;
}

The auth screens looked professional and did nothing. The Supabase env vars were placeholders. We had, to be blunt, defrauded the word "full-stack."

The audit

Before rebuilding, we forced ourselves to write down every layer where v1 fell short of the promise on the landing page.

Layer	Landing page promise	v1 reality
Database	"Postgres schema, migrations, seed data"	Zero SQL files
Auth	"Supabase Auth with email + OAuth"	UI screens returning fake sessions
Storage	"File uploads with signed URLs"	localStorage
AI	"OpenAI + Anthropic integration"	Not present
RLS	"Row-level security policies"	Not present
Docs	"Complete setup guide"	800-word README
Demo	"See it in action"	Six screenshots

The audit was demoralizing. It was also the roadmap.

The rebuild, layer by layer

Layer 1: real Postgres schema

Every current template ships with a supabase/migrations/ folder containing the actual tables the app needs, not a hand-wavy ER diagram. Buyers can run supabase db push and have a working schema before they've written a single line of code.

-- supabase/migrations/00_notes.sql
create table notes (
  id uuid primary key default gen_random_uuid(),
  user_id uuid not null references auth.users on delete cascade,
  title text not null,
  body text,
  created_at timestamptz default now()
);

alter table notes enable row level security;

create policy "Users read their own notes"
  on notes for select
  using (auth.uid() = user_id);

Layer 2: auth that actually authenticates

Email, Apple, and Google via Supabase Auth, with session hooks that persist across app restarts and refresh silently. The auth screens no longer lie.

Layer 3: storage with signed URLs and RLS

For templates like Chat with PDF, file uploads go straight to Supabase Storage with a signed URL flow and per-user RLS. No customer support ticket has ever said "the file upload doesn't work."

Layer 4: real AI service layer

An Edge Function proxies OpenAI, Anthropic, or ElevenLabs calls using the buyer's own API keys. It's modular: swap GPT-4o for Claude by changing a config constant. No vendor lock-in.

Layer 5: RLS policies from day one

Every template ships with per-table policies and two seed users so buyers can immediately verify that user A cannot see user B's data. This is table-stakes for production apps, and yet somehow rare in the template market.

Layer 6: 12,000-word docs, plus video

The single highest-leverage rebuild task. Written as copy-pasteable step lists with expected output. If a step is ambiguous, it gets rewritten.

Layer 7: agent-readiness

The one most competitors still ignore. Every template ships with:

A root CLAUDE.md describing the codebase in agent-friendly terms
Slash commands and skills for the common workflows (/add-screen, /add-supabase-table, /swap-ai-provider)
Real TypeScript types across the board (no any)
A file layout an agent can grep in one pass

It's tested against Claude Code, Codex, Cursor, OpenCode, and Windsurf, because in 2026 the buyer's first interaction with your codebase is via an agent.

Pricing: from $29 to $79

Counterintuitive lesson: raising the price improved every downstream metric.

At $29, we attracted price-shopping buyers whose expectations were "this must also do my dishes." Refund rate was around 40%.

At $79, we attracted senior indies who value their own hour at $100+ and are buying back time. Refund rate dropped to around 4%.

The right customer for a React Native template is not price-sensitive. They are time-sensitive. Price signals seriousness.

The demo video, in detail

40 seconds. Silent. One take. This is the shot list:

Terminal shows git clone, then npx expo start
iOS Simulator boots
Sign up as a new user
Do the hero action (record voice note, upload PDF, whatever the app does)
Cut to the Supabase table view showing the row that just landed
Fade out on the app logo

Nothing else. No music. No voiceover. The point is to remove doubt, not to entertain.

v1 vs v2 vs building from scratch

	v1 ($29)	v2 ($79)	From scratch
Setup time	~2 hours	~30 minutes	3–6 weeks
Backend	Mocked JSON	Real Supabase	You build it
RLS	None	Per-table + seed users	You write it
Demo	Screenshots	40-sec video	N/A
Agent-ready	None	Skills + slash commands	You configure
Docs	800 words	~12,000 words + video	N/A
Refund rate	~40%	~4%	N/A

For comparison, competitor templates like Ignite Cookbook ship strong scaffolding but leave the backend and AI as reader exercises. In 2026 that's the wrong tradeoff.

The cost of getting it wrong

180 hours on v1 that no one wanted
$600 in ads that returned nothing
200 hours on the rebuild
~$40k in real engineering opportunity cost
Six months of momentum

The postmortem was expensive. This blog post is us trying to make it slightly cheaper for the next founder considering a React Native template.

What I'd tell 2025-me

Docs first. If they're hard to write, the product is wrong.
$79 minimum. Cheaper attracts refund-prone buyers.
Real backend day one. Mock nothing a reasonable buyer expects to be real.
One demo video per template. 40 seconds. Silent. Happy path.
Ship for agents. CLAUDE.md, slash commands, real types.
Refund policy above the buy button. In big text.

The gap between "nice UI in a week" and "template a senior indie pays $79 for" is roughly three months of unglamorous infrastructure. Skip any of it and the launch dies quietly.

You can see where all of this ended up at Applighter.

Cutting React Native template support 70% with docs

Jules Sarah — Fri, 24 Jul 2026 09:52:54 +0000

We sell React Native templates. In Q1 2026 we rewrote our docs. Support tickets dropped 70%. This is the exact process, the exact structure, and the numbers.

The audit (do this first)

Before rewriting a single page, tag every support ticket for six weeks. Six columns:

date | customer | category | root_cause | resolution | in_docs?

Categories we ended up with: install, configure, extend, ship, billing, other.

Root causes: docs_missing, docs_wrong, docs_unfindable, product_bug, user_misunderstanding, out_of_scope.

The audit output for us:

Category	% of tickets	Docs-fixable?
install	24%	yes
configure	21%	yes
extend	18%	yes
ship	5%	yes
billing	10%	no
other	22%	mostly no

68% of tickets were docs-fixable. That number is the whole rest of the article.

The four-mode structure

Restructure your doc site around the four stages a new customer hits, in order:

docs/
├── getting-started/     # install
│   ├── installation.mdx
│   ├── environment.mdx
│   ├── quick-start.mdx
│   └── folder-structure.mdx
├── core-concepts/       # configure
│   ├── supabase.mdx
│   ├── expo-integration.mdx
│   └── ui-components.mdx
├── extend/              # extend
│   ├── adding-a-screen.mdx
│   ├── auth-guards.mdx
│   └── swapping-ai-provider.mdx
└── ship/                # ship
    ├── eas-build.mdx
    ├── app-store.mdx
    └── ota-updates.mdx

Order matters. Doc-site ordering is not aesthetic — it's a state machine. Each page assumes the customer completed the previous one.

The five rules

Print these. Stick them to a monitor.

1. First paragraph states the outcome, not the topic.

Bad:

# Authentication

This page covers authentication in the template.

Good:

# Adding auth to a new screen

By the end of this page, tapping a locked screen will redirect
signed-out users to `/sign-in` and preserve the deep link they
originally opened.

2. Every code block is copy-paste runnable.

Bad:

// ... existing imports
export function Screen() {
  const { user } = useSupabase();
  // ...
}

Good:

import { useSupabase } from "@/lib/supabase";
import { Redirect } from "expo-router";

export function ProtectedScreen() {
  const { user, loading } = useSupabase();
  if (loading) return null;
  if (!user) return <Redirect href="/sign-in" />;
  return <YourScreenContents />;
}

3. Every page links to the next page. Never let the customer bounce to Google.

4. If you answer the same email twice, the docs get updated that day. Same day. This is the only rule with real leverage.

5. Ship a claude.md at the project root. If your customer opens the template in Claude Code, Cursor, or any AI-native editor, the AI reads this file first. Ours looks roughly like this:

# Applighter — <template name>

## Stack
- Expo 54, React Native 0.76
- Supabase (auth, Postgres, storage, edge functions)
- NativeWind 4, React Native Reusables (primitives)
- TanStack Query 5

## Key files
- `app/(auth)/*` — auth flows
- `app/(app)/*` — signed-in surface
- `lib/supabase.ts` — client + typed helpers
- `supabase/migrations/*` — schema (RLS policies live here)

## Conventions
- All server access via TanStack Query hooks in `hooks/`
- Never call supabase-js directly from a component
- Add new tables with a migration, not the dashboard

## Env vars
See `.env.example`.

The AI now writes correct code the first time. The customer never emails you.

Operational loop

Once the docs exist, keep them alive:

Log every ticket in a shared sheet (six columns above).
30-minute triage every Friday. Flag anything asked twice.
Doc gap → paragraph inline or new page scaffolded same day.

That's it. No LLM classification. No analytics vendor. The marginal cost of writing one paragraph is much lower than the marginal cost of answering the same email eight times.

Results

Support tickets: −70%
Docs-caused refunds: −85% (from ~4% to ~0.6% of purchases)
Time-to-first-customized-screen: 2–4 hours → 25–45 min
Five-star reviews mentioning "docs": 2 → 34 across two quarters

What we didn't do

No chatbot. Deflection metrics are gameable.
No paywalled docs. Public and indexable.
No community forum. Half-populated forums are worse than none.
No codebase restructure to match docs. Different audiences, different shapes.

Reference docs I used

Diátaxis framework — the closest published version of what we independently arrived at
Expo docs — the bar for RN documentation
Supabase docs — same

We build production-ready React Native templates at Applighter — the docs described above ship with every one of them.

If you've run this audit on your own support inbox, what was your docs-fixable percentage? I suspect 68% isn't unusual.

The Complete Guide to Offline Storage in React Native (2026)

Jules Sarah — Wed, 22 Jul 2026 11:25:11 +0000

Offline storage is five categories, not one library: key-value, secure, structured, file system, and server-state cache.
MMKV is the new default over AsyncStorage — roughly 30× faster with synchronous reads.
The offline-first pattern has four parts: local-first reads, optimistic writes, a durable mutation queue, and a sync engine.
Conflict resolution: last-write-wins is fine for most consumer apps. CRDTs are overkill unless you're building a collaborative editor.

Most React Native apps treat the network as an always-on dependency, and it shows the moment a request stalls.

Offline storage isn't one library — it's a stack: key-value stores for preferences, secure enclaves for tokens, structured DBs for domain data, and query caches for server state.

This post walks through the whole stack and the offline-first pattern that ties it together.

The five categories of RN offline storage

Key-value — AsyncStorage (compat) or MMKV (default). MMKV is ~30× faster and supports synchronous reads.
Secure — expo-secure-store or react-native-keychain. Backed by iOS Keychain / Android Keystore.
Structured — expo-sqlite, op-sqlite (JSI, synchronous), WatermelonDB (reactive + sync), Realm (Atlas Device Sync).
File system — expo-file-system for media. Never base64 blobs into KV storage.
Server-state cache — TanStack Query with persistQueryClient, backed by MMKV.

Comparison table

Library	Type	Perf	Encryption	Best for
AsyncStorage	KV	1×	Community fork	Legacy / compat
MMKV	KV	~30×	Built-in	New default
expo-secure-store	Secure KV	—	OS keychain	Tokens
op-sqlite	SQL	JSI	SQLCipher	Structured data
WatermelonDB	Reactive DB	Lazy	SQLCipher	Large offline lists + sync
Realm	Object DB	Fast	Yes	Atlas Device Sync

The offline-first pattern

Four moving parts:

Local-first reads. The UI always reads from the local store. The network populates the store; the store renders the UI.
Optimistic writes. The UI updates immediately, before the server acknowledges.
Mutation queue. A durable list (SQLite or MMKV) of pending server-side changes, each with a client ID.
Sync engine. A background worker drains the queue with exponential backoff and reconciles conflicts.

async function markMessageAsRead(id: string) {
  db.write(() => {
    db.messages.update(id, { readAt: Date.now(), pendingSync: true });
  });

  await mutationQueue.enqueue({
    kind: 'message.markRead',
    payload: { id, readAt: Date.now() },
    clientId: uuid(),
  });

  syncEngine.wake();
}

Conflict resolution

Last-write-wins. Timestamps, newest wins. Fine for most consumer apps.
Server-authoritative. Reject stale writes with a version mismatch.
CRDTs. Yjs or Automerge. Overkill unless you're building a collaborative editor.

Decision cheat sheet

Preferences or JWT? → MMKV + expo-secure-store
Instant-open cached lists? → TanStack Query with persistQueryClient on MMKV
Thousands of offline records? → op-sqlite, or WatermelonDB if you want reactive
Cross-device sync? → WatermelonDB or Realm
Media? → expo-file-system with metadata in SQLite

Pitfalls to skip

Blocking the JS thread with async AsyncStorage calls at startup
Storing blobs in KV stores
No cache wipe on logout
Infinite retry loops in the mutation queue
Persisting Redux state without a schema version

Wrap-up

Offline-first isn't a defensive posture — it's a performance strategy. Reading from local storage beats a round-trip every time, and a good sync engine hides the network from your users entirely.

Pick each layer deliberately and this becomes a solved problem rather than a recurring one.

I built RapidNative, an AI mobile app builder that generates production-ready React Native code you can extend with any of these libraries.

Anyone running MMKV + TanStack Query in production? Curious how the persistence layer has held up for you at scale.

Rejected Under Guideline 4.2? Here's the Honest Decision Tree

Jules Sarah — Wed, 22 Jul 2026 10:22:04 +0000

Appeal only if the reviewer made a factual error (missed features behind a login). Otherwise you burn 1–3 weeks in Resolution Center limbo.
Bolt on native features (APNs push, Face ID, native tabs, offline) improves your odds — but it's still a WebView underneath, so reviewers vary and each retry costs a cycle.
Rebuild in React Native is the only path that removes the 4.2 category entirely. Real UIView, not DOM in a browser shell.
The real question isn't "how do I pass review" — it's "how many review cycles can I afford to lose finding out?"

You shipped it. You waited. Then the email arrived:

Guideline 4.2 — Design — Minimum Functionality
We found that the experience your app provides is not sufficiently different from a web browsing experience, as it would be if displayed in Safari.

Here's the thing nobody tells you up front: most advice about 4.2 is written by people selling WebView wrappers. Their answer is always "add push notifications and resubmit," because their business depends on that working.

Sometimes it does. Often it doesn't. This is the honest version.

What Apple is actually saying

The full guideline text:

Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or "app-like," it doesn't belong on the App Store.

The operative word is "elevate." Apple isn't banning web technology — plenty of major apps use WebViews internally. What they're rejecting is the ratio: an app whose primary value is showing you a website you could have visited in Safari.

That tells you what reviewers actually measure. Not "does this contain a WebView," but "would a user be worse off just using the browser?"

Your three options

Diagram released under CC0 — reuse it freely.

Path 1: Appeal

Reply in Resolution Center arguing the reviewer missed something.

Works when it's true. If your app genuinely has native features the reviewer didn't find — behind a login, or three taps deep — a targeted reply with screenshots pointing at specific capabilities does get decisions reversed.

Fails badly when it isn't. The Apple Developer Forums are full of people two weeks into an appeal with no response, watching a launch window close. One developer's app was tied to an event launching the following week, with the appeal pending a fortnight and no update.

Appeal if the reviewer made a factual error. Don't appeal to argue taste.

Path 2: Bolt on native features

The standard vendor advice: add push notifications, Face ID, offline caching, native tab navigation. Resubmit.

This is real advice and it does work — reviewers respond to APNs push especially, because it's hard evidence of native platform integration. Face ID is the other easy win.

But be clear about what you're doing: you're improving your odds on a dice roll, not removing the dice. The app is still a WebView underneath. Reviewers vary. The same binary that passes with one reviewer gets bounced by another, and each attempt costs a full review cycle.

Pattern worth watching: if you've bolted on features twice and been rejected twice, a third attempt is usually not the highest-value use of your week.

Path 3: Rebuild the UI natively

Move the interface to React Native (or Flutter). These compile to actual native UI components — real UIView and UIButton instances — rather than rendering DOM inside a browser shell.

This is the one option that removes the rejection category entirely. You're no longer in the "repackaged website" bucket, so 4.2 stops being a thing that can happen to you.

Honest cost: a genuine rewrite of your UI layer. Business logic, API calls, Supabase queries — those largely survive. The components don't.

The question worth asking

The reframe that actually helps:

The question isn't "how do I pass review?" It's "how many review cycles can I afford to lose finding out?"

Each rejection-and-resubmit loop is roughly a week. Pre-launch with no deadline? Gambling on Path 2 is cheap and reasonable. Launch date, investors, a client waiting? The expected cost of two more failed cycles usually exceeds the cost of doing the rebuild once.

It's a business calculation more than a technical one.

If you're coming from Lovable, v0, or Bolt

A lot of 4.2 rejections trace back to the same origin story.

You built a web app with an AI builder. It's good. Then you tried to ship it and discovered these tools generate React web apps — they don't produce native binaries. The App Store takes compiled .ipa files; Google Play takes .aab. A React web app compiles to neither.

So people reach for a wrapper, and land here.

If that's your path, Path 2 is a particularly weak bet — your app is the website, structurally, and there's not much to elevate. Path 3 is where you were always going to end up.

The rebuild is more mechanical than it sounds: your Supabase backend connects to a React Native app without migration, and your API layer ports mostly unchanged. It's the component tree that needs redoing.

If you'd rather not do that project yourself, RapidNative converts Lovable apps into real React Native + Expo builds and handles the full App Store and Play Store submission — signing, screenshots, and metadata included, with source code and full ownership.

The checklist, if you're taking Path 2 anyway

Sometimes bolting on is the right call — tight deadline, genuinely content-heavy product. Prioritise in this order:

APNs push notifications. Strongest single signal to a reviewer.
Face ID / Touch ID. Native API usage, easy to implement, easy to see.
Native tab bar and navigation. Not a hamburger menu rendered in HTML.
Real offline handling. If it shows "No Internet Connection" like a browser, that's a rejection risk on its own.
Rewrite your App Store description. If it says "access our website on your phone," you're asking for the rejection.

Three of these is roughly the threshold where reviewers start passing wrapper apps.

The takeaway

Guideline 4.2 isn't Apple being arbitrary. It's a floor on what an app is, and wrappers sit right on that line by design.

Appeal when the reviewer was factually wrong. Bolt on features when you have time to gamble. Rebuild when the launch actually matters.

Whichever you pick — pick it deliberately, rather than defaulting into another resubmit because it feels like the smaller decision. It usually isn't.

Been through a 4.2 rejection? Which path did you take, and did it work? The data on what actually passes is mostly anecdotal — more anecdotes would help everyone.

Nine Screens of Pain: The UX of Submitting to the App Store

Jules Sarah — Fri, 17 Jul 2026 11:51:01 +0000

If you've ever submitted your first app, what follows will feel familiar. If you haven't, bookmark this — you're going to want to reference it around week two of the process.

The starting state: a fresh App Store Connect account

You've paid the $99. You've verified the DUNS number. You've waited three business days for Apple to enroll you.

Now you're staring at App Store Connect, trying to figure out how to actually submit the app you've built. The dashboard shows icons for iTunes Connect (deprecated, but still visible), Certificates, TestFlight, Users and Access, Contracts. None of them say "Submit an App." That option lives under "My Apps" — which is one of the icons, but isn't labeled as such.

You have spent fifteen minutes and made zero progress.

Screen-by-screen through the actual flow

Screen 1: Bundle ID registration. In the developer portal — a different site than App Store Connect. Get this wrong and you can't rename it later.

Screen 2: Certificate + provisioning profile. Two of each, development and distribution. Apple's UI walks you through it but assumes you already know what a certificate does.

Screen 3: Xcode signing configuration. Six dropdowns, three of which look identical. If any one is wrong, the build fails with "no provisioning profile matches," and you go Google the exact error string.

Screen 4: Archive + upload. Ten minutes of "processing," then usually success. Sometimes an email thirty minutes later: "Your build has one or more issues." No indication of which.

Screen 5: App Information. Category, subcategory, content rights, age rating. That last one is a twenty-question survey.

Screen 6: Pricing and Availability. Choose the countries. Pick the tier. Explain whether the app is free but has in-app purchases.

Screen 7: App Privacy. Answer questions about data collection. Every "yes" cascades into four to six follow-up questions. Miss one and your submission is rejected.

Screen 8: The version you're submitting. Description, keywords (100 characters), promotional text, support URL, marketing URL, screenshots (six iPhone sizes minimum), preview video.

Screen 9: Review information. Contact info, demo account credentials, review notes. Then, finally, the "Submit for Review" button.

And that's not counting the TestFlight side, which is another five screens.

The 3am "invalid binary" moment

Every indie dev has this moment. You've finished all nine screens. You upload the build. Twenty minutes later, an email arrives:

The uploaded build has invalid binary architecture.

Or:

The provisioning profile does not include the Push Notifications entitlement.

Google says: rebuild with different Xcode settings. You do. Same error. You Google more. It turns out you also had to add a capability in the developer portal. You do that. Build. Upload. Wait twenty minutes. Different error.

This is where most people give up on their first-month timeline.

Why this UX pattern persists

Apple has zero pressure to simplify submission. Every indie who quits has ten replacements. And Apple's real customer isn't the indie dev — it's the enterprise studio with a team dedicated to this workflow.

That isn't going to change from within Apple. But it means the leverage for indie tooling is enormous — whoever solves this UX gap earns loyalty from a badly underserved segment.

What a good submission tool looks like

A good submission tool would:

Ask the App Privacy questions in plain English, once. Then fill in App Store Connect automatically.
Cross-check your build against the top 20 rejection reasons before upload. Fail loudly if any are hit.
Show real-time status. "In review, 47h in queue, median for your category is 26h" — not "Waiting for Review" for five days.
Handle rejections as tickets. The rejection reason parsed into a diff you can apply, with a resubmit button.
Never let you reach a 3am invalid-binary moment. Every failure mode should surface before upload, not twenty minutes after.

That's the product I want to use as an indie dev — and it's part of why we built RapidNative to handle the generate-to-submit path so the nine screens stop being your problem.

Takeaway

The App Store submission flow is a UX artifact of Apple's incentives, not a law of nature. Until it improves, treat it like the gauntlet it is: budget a full week, expect one rejection, and surface every failure mode you can before you hit upload.

Which App Store rejection got you at 3am — invalid binary, missing entitlement, or a privacy label you filled out wrong? Drop it in the comments.

Auth Is Where User Trust Is Decided — What Indie Founders Miss About Expo + Supabase Flows

Jules Sarah — Wed, 15 Jul 2026 13:07:33 +0000

There's a ~30-second window, usually mid-auth, where a new user decides to lean in or swipe away.
Four moments break trust: a magic link that opens Safari instead of the app, an OAuth flow stuck in limbo, error messages that read like stack traces, and sessions silently lost on app resume.
Most fixes don't need a designer — copy error-message tone from apps you love, test the magic-link flow on a real device with the app closed, and add a "check your email" confirmation.
The single biggest lever: seamless session refresh on resume. Wiring it took install-to-week-1 retention from 32% to 41%.

I've watched a lot of first-time app installs. There's a moment about 30 seconds in where users either lean forward and start actually using the app, or lean back and swipe it away. That moment is almost always mid-auth-flow — and it's mostly decided by whether the auth flow feels trustworthy.

This isn't a marketing insight. It's a UX one. Founders overwhelmingly underweight it, especially indies who see auth as "plumbing." Here's what actually happens in that 30 seconds, and how a good Expo + Supabase setup helps.

The 30-second trust window

The user opens your app fresh. They see a splash screen (fine), a welcome screen (fine), and then the sign-up screen. From here they make four judgments in rapid succession:

Do I understand what I'm being asked? Email + password? Magic link? Social? All three?
Do I trust this with my email? Is the design polished? Does it look like a real product?
Does anything obviously break? Autocorrect mangling my email, the keyboard covering the CTA, weird focus behavior?
Do I get a signal that it worked? After I hit sign-up, do I see confirmation, or does the app just… sit there?

Break any of these and you lose the user before they see a single product feature.

The four moments that break trust

Moment 1: The magic link opens in Safari, not the app. The user taps the email link, iOS opens Safari, they see a "redirecting…" page, then get bounced back to the app — but the auth state didn't sync. They tap the link again. Same result. They quit. This happens when Universal Links aren't wired properly, or expo-linking isn't handling the auth callback URL.

Moment 2: The OAuth flow leaves them in limbo. The user taps "sign in with Google," gets the browser sheet, taps back — and the app is stuck on a loading spinner. Flows that don't handle the OAuth-cancelled state leave the user stranded.

Moment 3: The error message reads like a stack trace. "Invalid credentials" or "Auth session missing!" terrifies non-technical users. "That password doesn't look right. Reset it?" converts them.

Moment 4: Session lost after app resume. The user signs in, backgrounds the app, comes back an hour later — signed out. supabase-js's default token refresh doesn't always fire on iOS resume. Wiring AppState to supabase.auth.refreshSession() explicitly solves this.

Fixes without a designer

Even as a solo founder with no design help:

Copy the error-message tone from a well-loved app you use (Linear, Notion, Superhuman).
Test the magic-link flow yourself on a real device, with the app fully closed, before you launch.
Add an "account created — check your email" confirmation screen. Users need the feedback.

Run a 20-minute usability test

Grab someone who's never seen your app. Watch them sign up. Don't help.

Note every place they hesitate for more than two seconds. Those are your trust breakpoints. Fix the top three before you launch.

The one feature that changed my install-to-DAU rate

All of the above matters, but the single thing that most moved my numbers: seamless session refresh on app resume, so users never got signed out unexpectedly.

My install-to-week-1 retention went from 32% to 41%. That's a large lift, and it came from one wired hook.

Takeaway

Auth is a UX surface, not a plumbing task. If your Expo + Supabase foundation ships wired session refresh, correct deep-link handling, and a proper OAuth-cancel state, you're buying trust — not just code.

If you'd rather start from a foundation with these already solved, I keep a set of Expo + Supabase templates wired for exactly this at Applighter.

Which of the four trust-breakers has cost you the most users? Drop it in the comments.

40 React Native Devs on What They Wish Their Boilerplate Fixed

Jules Sarah — Wed, 08 Jul 2026 14:36:42 +0000

I asked ~40 indie React Native devs one question: "What do you wish your boilerplate did differently?"
Three wishes dominated: less opinionated navigation (28/40), TypeScript without wrapper-type overhead (24/40), and real dark-mode wiring, not just a CSS toggle (19/40).
Nobody asked for more features. Not one. Every wish was subtractive.
The next wave of boilerplates will win by shipping less, cleaner, with better exit points.

Over the past two months I've been talking to indie React Native developers about the boilerplates they use. The question that got the most useful answers wasn't "which boilerplate do you use?" — it was "what do you wish your boilerplate did differently?"

I've now heard back from about 40 devs across a handful of communities (r/reactnative, the Expo Discord, some Twitter DMs). The pattern is clear enough to be worth writing down.

How the survey ran and who answered

Informal, DM-based, ~10 minutes each. Sample skews toward:

Solo devs and 2-3 person teams (35 of 40)
Shipping paid apps, not free (~28 of 40)
Using either an off-the-shelf boilerplate or one they'd built themselves (~half and half)

So the sample is biased toward serious builders — people whose CI/CD choices matter to their revenue. That's the right audience for a survey about tooling ergonomics.

The top three wishes, in order

1. Less opinionated navigation (28 of 40 mentioned this, often first)

Most boilerplates ship a navigation shape — tab bar with a stack per tab, a modal presentation pattern, a drawer for settings — and it's the choice devs said they most often had to unwind. The frustration wasn't the specific shape; it was that the boilerplate had committed to one before knowing the product.

What they wanted: a navigation layer they could rip and replace in an afternoon. What they got: a navigation layer that other screens assumed, so ripping it meant refactoring every screen.

2. TypeScript throughout, without wrapper types getting in the way (24 of 40)

Everyone wants TS. What they don't want is a boilerplate whose author defined 40 custom wrapper types on top of standard SDK types (Supabase, Stripe, Expo APIs) because they wanted stricter typing.

// ❌ What devs are complaining about
import type { AppUser } from '@/lib/types/user'
import type { AppSession } from '@/lib/types/session'

// You have to learn the boilerplate's vocabulary
// before you can find what you need in the SDK docs.

// ✅ What they want instead
import type { User, Session } from '@supabase/supabase-js'

// The SDK's own types. No translation layer.

The wish is TS-native, TS-first, but using the SDK's own types wherever possible. Wrap only when the SDK types are genuinely painful.

3. Real dark-mode wiring, not just a CSS toggle (19 of 40)

This one surprised me. Many boilerplates advertise "dark mode included" and what they mean is a theme toggle that swaps a color palette. What devs actually want:

System-color-scheme detection that respects OS-level user preference
Persistence of user override across app restarts
Correct behavior for platform-specific dark-mode surfaces (iOS blur, Android edge-to-edge)
Status bar + navigation bar following the theme
Charts, images, and third-party components that don't fight the theme

"Dark mode included" should mean all of the above. Mostly it means a toggle.

The features nobody asked for

Equally interesting: nobody asked for more features. Not one respondent said "I wish my boilerplate had more built-in screens" or "I wish it included analytics + i18n + AI chat + [something]." Every wish was subtractive: less friction, less coupling, less opinion.

The implication is unusual for a product category: feature-heavy boilerplates are competing on the wrong axis. The market wants fewer, better, cleaner-seamed layers.

What that tells us about product/market fit for starter kits

Boilerplates are a maturing category. The first wave sold on feature counts because that was legible. The current audience has been burned by feature counts enough times that they now audit for extensibility. The next wave of boilerplates will win by having a smaller surface area and cleaner exit points.

That's a hard product story to tell. "We include less than the competition" doesn't sell landing pages. But it's what devs 6 months into a project actually want.

Conclusion: subtractive design wins in tooling

The finding I keep coming back to: developers judge tools by how well they get out of the way, not by how much they do. Boilerplates are no different.

If you're building a starter kit, the next feature to add is probably a layer to remove. If you're picking one, run the 60-minute strip-down test. Either way, subtractive design is the axis of quality.

Feature counts are dead. Long live ergonomics.

What did you wish your React Native boilerplate did differently? Drop it in the comments — I'm collecting responses for a follow-up survey and yours might be the pattern that makes the shortlist next time.

Stop Hand-Coding React Native Forms. Generate Them Instead.

Jules Sarah — Wed, 01 Jul 2026 12:20:58 +0000

Every mobile app is mostly forms, and every form comes with the same boilerplate tax: library choice, schema, keyboard config, KeyboardAvoidingView, validation, error/loading/disabled states, cross-platform testing.
AI generation produces all of that from a plain-English prompt — including the props you always forget (autoCapitalize="none", textContentType, returnKeyType).
Where it still needs you: domain-specific validation, custom UX choices, and swapping the placeholder fetch for your real endpoint.
The real win is iteration speed: tap a field, describe the change, only that field updates.

Stop Hand-Coding React Native Forms. Generate Them Instead.

Ask any React Native dev what part of the job they enjoy least, and forms come up fast. This post walks through generating forms with AI instead — what you get out of the box, what still needs your hand, and where the shortcuts hurt.

Why Forms Are the Worst

Every mobile app is mostly forms with some chrome around them. Signup, checkout, profile edit, "leave a review," "add a task" — all forms. And every form comes with the same tax:

Pick a form library (react-hook-form? Formik? roll your own?)
Wire up a schema library (Zod, Yup)
Configure the keyboard for each field (keyboardType, autoCapitalize, autoComplete, textContentType)
Fight KeyboardAvoidingView until the submit button stops hiding under the keyboard
Handle blur validation, submit validation, error rendering, disabled states, loading states
Test on both iOS and Android

Multiply by 15 forms and there goes your sprint.

What "AI-Generated Forms" Actually Produces

I've been building with RapidNative — an AI mobile app builder that takes plain English and outputs React Native + Expo — and forms are the use case where AI generation feels closest to a superpower. Here's what a prompt like this:

A signup screen with email, password, confirm password, and a role picker (founder, designer, developer). Validate all fields on blur. Auto-advance to the next field on return.

...actually generates:

const [formData, setFormData] = useState({
  email: '',
  password: '',
  confirmPassword: '',
  role: '',
});
const [errors, setErrors] = useState({});

const emailRef = useRef(null);
const passwordRef = useRef(null);
const confirmRef = useRef(null);

const validateField = (field, value) => {
  // per-field validation
};

return (
  <KeyboardAvoidingView
    behavior={Platform.OS === 'ios' ? 'padding' : 'height'}
    style={styles.container}
  >
    <ScrollView keyboardShouldPersistTaps="handled">
      <TextInput
        ref={emailRef}
        placeholder="Email"
        keyboardType="email-address"
        autoCapitalize="none"
        autoComplete="email"
        textContentType="emailAddress"
        returnKeyType="next"
        onSubmitEditing={() => passwordRef.current?.focus()}
        value={formData.email}
        onChangeText={(v) => setFormData({ ...formData, email: v })}
        onBlur={() => validateField('email', formData.email)}
      />
      {errors.email && <Text style={styles.error}>{errors.email}</Text>}
      {/* password + confirm + picker follow */}
    </ScrollView>
  </KeyboardAvoidingView>
);

Every prop I usually forget on the first try — autoCapitalize="none", textContentType="emailAddress", returnKeyType="next", the KeyboardAvoidingView wrapper — is there by default. Not because I remembered to ask, but because the generator knows what an email field needs.

What's Actually Hard About Mobile Forms

The interesting details, the ones AI generation handles well:

Keyboard type per field. Email → email-address, phone → phone-pad, card number → number-pad.
Autofill hints. textContentType="emailAddress" on iOS, autoComplete="email" on RN. Both required for OS autofill to fire.
Focus chain. returnKeyType="next" + onSubmitEditing + refs to the next input.
Password fields. secureTextEntry + textContentType="password" (or newPassword on signup) so iOS offers to save/generate a password.
Keyboard avoidance. KeyboardAvoidingView with different behavior per platform, wrapped around a ScrollView with keyboardShouldPersistTaps="handled".

These are the kind of details that get skipped when a human is tired. They're the kind of details that never get skipped by a generator, because they're pattern-heavy and well-documented.

Where AI Generation Still Needs You

Being honest: not everything is a slam dunk.

Very domain-specific validation (tax IDs, national ID formats, complex phone number rules) — you'll want to review or specify these explicitly.
Custom UX flows where the "correct" pattern is a design choice, not a technical one, still benefit from a human eye.
Integration with your existing backend — the generator produces a placeholder fetch you replace with your actual endpoint. Not automatic magic, but a two-line edit.

Iteration Wins

The real unlock isn't the first-generation speed — it's how fast you can iterate. Tap a field in the preview, say "make this a dropdown with 4 options," and only that field changes. Say "the submit button should be disabled until the form is valid," and it wires it up.

Compare that to: open the file, find the TextInput, replace with Picker, update state binding, add options array, restyle, save, reload the preview. Forms live-edited with a chat interface are unreasonably fast.

Try It

Give it a shot: RapidNative. Free to start. Type in a form description and see what falls out.

What's the form screen that's eaten the most of your time? Drop a comment with what you're building.