DEV Community: Russel Dsouza

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.

We rewrote our pricing page 3 times. Here's what worked.

Russel Dsouza — Fri, 29 May 2026 09:32:06 +0000

We rewrote components/pricing-cards.tsx three times in six months. Same product, same Stripe checkout, same three license tiers (single | multiple | enterprise). What changed was the component. The conversion went from ~1.1% to ~3.4%.

This post is the actual diffs and the actual numbers. No theory, no funnel-graph PNGs.

The product

Applighter sells full-stack React Native + Expo templates. Each template has three license tiers stored as rows in a Supabase product_licenses table:

license_type     text check (license_type in ('single','multiple','enterprise'))
price_usd        numeric not null
allowed_users    int
allowed_projects int
is_commercial    boolean

Tiers are correct. The component rendering them was wrong three times.

Version 1: textbook, ~1.1%

{licenses.map(license => (
  <Card>
    <CardTitle>{license.license_type}</CardTitle>
    <div className="text-4xl">${license.price_usd.toFixed(2)}</div>
    <ul>{allFeatures.map(f => <li>{f}</li>)}</ul>
    <BuyButton />
  </Card>
))}

Three identical cards. Long feature matrix. .toFixed(2) on every price for "safety." A weak border on the middle card that wasn't visible in dark mode.

What the data said:

38% of sessions ended without a single pricing_card_focus event
Time spent disproportionately on the cheapest card
The multiple tier — best per-developer economics — got the least attention

Classic decision-paralysis. Three identical options read as a comparison spreadsheet, not a recommendation.

Version 2: anchor the middle tier, ~1.9%

The fix was one boolean:

function getLicenseHighlight(type: string): boolean {
  return type === "multiple";
}

Wired into the card:

<Card className={isHighlighted ? "border-primary shadow-lg" : ""}>
  {isHighlighted && (
    <Badge className="absolute -top-3 left-1/2 -translate-x-1/2">
      Most Popular
    </Badge>
  )}
  ...
</Card>

And reordered columns left-to-right by price: cheapest, recommended, premium. Buyer's eye now lands on the middle tier first; the others become reference points.

Result: ~1.1% → ~1.9% over four weeks. Almost double from one boolean and a sort.

Version 3: small fixes, ~3.4%

Fix 1: drop trailing `.00`

The one-liner that lifted conversion the most:

<span className="text-4xl font-bold">
  ${Number(license.price_usd) % 1 === 0
    ? Number(license.price_usd)
    : Number(license.price_usd).toFixed(2)}
</span>

If the price is a whole dollar, render the integer. Otherwise two decimals. $49.00 → $49.

This change, isolated for two weeks holding everything else constant, accounted for roughly half the v2→v3 lift. The most embarrassing finding in our analytics this year.

Fix 2: replace the feature matrix with six bullets per card

<ul className="space-y-3">
  <li><Check /> {license.allowed_users
    ? `Up to ${license.allowed_users} developers`
    : "Unlimited developers"}</li>
  <li><Check /> {license.allowed_projects
    ? `${license.allowed_projects} projects`
    : "Unlimited projects"}</li>
  <li><Check /> {license.is_commercial
    ? "Commercial use included"
    : "Personal use"}</li>
  {features.slice(0, 3).map(f => <li><Check /> {f}</li>)}
</ul>

Three claims from the license row, three from the product. Six bullets per card. The diff between Single and Team becomes immediately readable: one developer, one project vs. up to N developers, N projects. That's the comparison the buyer is making.

Fix 3: refund/ownership line under the CTA

<CardFooter>
  <BuyButton ... />
  <p className="text-xs text-muted-foreground mt-3">
    7-day refund · lifetime updates · own the code
  </p>
</CardFooter>

The last objection happens at the click. The answer has to live there.

Side-by-side

Version	Change	Conversion
V1	Identical cards, feature matrix, `.toFixed(2)`	~1.1%
V2	"Most Popular" badge on `multiple`, price-sorted	~1.9%
V3	Drop `.00`, 6 bullets, refund line under CTA	~3.4%

The actual lesson for devs

Most of what helped wasn't pricing strategy. It was deleting fussiness:

Layout fussiness → anchor a tier
Content fussiness → cut to 6 bullets
Formatting fussiness → drop trailing zeros

Three rewrites, three layers peeled. Ship them in order, not as one A/B test. Watch each for two weeks.

What to copy tonight

// 1. Anchor the middle tier
const isHighlighted = license.license_type === "multiple";

// 2. Smart price rendering
const price = Number(license.price_usd);
const display = price % 1 === 0 ? price : price.toFixed(2);

// 3. Refund line lives by the CTA, not the page footer
<BuyButton />
<p className="text-xs">7-day refund · lifetime updates</p>

That's the diff. The component is in components/pricing-cards.tsx. The rest of the engineering — Supabase rows, Stripe Checkout, Edge Function license grants — didn't change once across all three rewrites.

For more on the React Native + Expo stack behind this, the Expo docs on EAS Build and Stripe's pricing experiments guide are the two external reads worth the time.

What's the smallest pricing-page change that moved a real number for you? Drop the diff in the comments — I'm collecting examples from indie devs and small SaaS teams.

React Native AI app cost in 2026, line by line

Russel Dsouza — Thu, 28 May 2026 13:17:02 +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.

Mobile App Analytics for React Native — What to Track, What to Ignore

Russel Dsouza — Wed, 27 May 2026 07:42:39 +0000

Stop tracking 60 events. Pick 6–10. Define your activation event before you write any tracking code. Watch the cohort retention curve, not total installs. One product analytics SDK + one crash tool. Defer attribution until you spend on ads.

Most React Native apps don't die from bad code. They die from invisible problems — users who never finished onboarding, a checkout step that lost half the funnel, a feature nobody opened after week one. You can't fix what you can't see.

The trap is that "set up analytics" gets pushed to next sprint, then the sprint after, then forever. By the time you actually look at your numbers, you've shipped three months of features blind. This post is the minimum viable analytics setup you should have running before you push to TestFlight.

The five questions every mobile app has to answer

AARRR — Acquisition, Activation, Retention, Referral, Revenue. Old framework, still right.

Stage	Question	What you'd actually track
Acquisition	How do users find us?	Installs by channel, CPI
Activation	Did the first session land?	Onboarding complete, first key action
Retention	Do they come back?	D1/D7/D30, DAU/MAU
Referral	Do they bring friends?	Invite rate, viral coefficient
Revenue	Does any of this pay?	ARPU, LTV, conversion to paid

You don't need a metric in every row on day one. You need to know which row is leaking the worst, and you can only know that if you can see all five.

The single most important event: activation

Pick a behavior that strongly correlates with week-two retention. Examples from real apps:

Dropbox: "one file in one folder on two devices"
Facebook (early): "seven friends in ten days"
Fitness app: "logged one workout in first 48h"

Write this down before you write any tracking code:

A user is activated when they ___ within ___ minutes/days of installing.

This is the highest-leverage exercise in your first three months. Get this right and every other product decision becomes legible: does this change move more new users to activation?

Track this in your React Native app

A minimal event schema for any consumer mobile app. Pick a tool (Firebase, Amplitude, Mixpanel, or PostHog — they all have RN/Expo SDKs) and instrument these first:

// events.ts — your single source of truth
export const Events = {
  APP_OPEN: 'app_open',
  SIGN_UP_COMPLETE: 'sign_up_complete',
  ONBOARDING_COMPLETE: 'onboarding_complete',
  ACTIVATION: 'activation',          // your one defined event
  PURCHASE_COMPLETED: 'purchase_completed',
  SHARE_INITIATED: 'share_initiated',
  PUSH_RECEIVED: 'push_received',
  PUSH_OPENED: 'push_opened',
} as const;

export type EventName = typeof Events[keyof typeof Events];

Tracking helper that's tool-agnostic, so you can swap providers without a rewrite:

// analytics.ts
import * as Posthog from 'posthog-react-native';

export const track = (event: EventName, props?: Record<string, unknown>) => {
  if (__DEV__) console.log('[track]', event, props);
  Posthog.capture(event, props);
};

// attach user properties at sign-up
export const identify = (userId: string, traits: Record<string, unknown>) => {
  Posthog.identify(userId, traits);
};

Call sites stay clean and typed:

// in OnboardingScreen.tsx
import { track, Events } from '@/lib/analytics';

const handleComplete = async () => {
  await saveProfile();
  track(Events.ONBOARDING_COMPLETE, {
    flow: 'signup_v2',
    steps_skipped: skippedSteps.length,
  });
  navigation.replace('Home');
};

Three things this does that ad-hoc SDK calls don't:

Snake_case event names enforced via the const object — no Purchase / purchase / purchasedItem drift.
Single switch point for swapping providers — change analytics.ts, every call site keeps working.
DEV logging so you can verify events in the Metro console before they hit production.

User properties (do this once, slice everything forever)

The biggest analytics regret most teams have is not setting user properties on day one. Once they're attached, every event you've ever tracked becomes sliceable by them retroactively.

// on first install
identify(userId, {
  install_source: 'organic',         // or attribution source
  signup_date: new Date().toISOString(),
  platform: Platform.OS,             // 'ios' | 'android'
  app_version: DeviceInfo.getVersion(),
});

// on plan change
identify(userId, { plan: 'pro' });

Now you can ask "what's D7 retention for organic-install Pro users on iOS?" without touching tracking code again.

The chart that matters more than DAU

The single most useful chart in mobile analytics is the cohort retention curve — a triangle where each row is the install week and each column is the percentage of that cohort still active N weeks later.

If the curve flattens around D30, you have something. If it keeps dropping toward zero, you don't — no matter what the install counter says. Most analytics tools (Amplitude, Mixpanel, PostHog) ship this view out of the box; Firebase requires a bit more setup.

Vanity metrics to delete from your dashboard

These always go up, which is exactly why they're useless for decisions:

Total installs
Total registered users
Total screen views without context
Followers on social
Average time in app, isolated

Replace each with a ratio or a cohort:

- Total installs (12,438)
+ 30-day retained users from last month's installs (1,247 / 9,800 = 12.7%)

- Page views (84,221)
+ Screen views per session for activated users (median 14)

- Average session length (4m 12s)
+ % of sessions where activation event fired (38%)

The discipline of converting absolute numbers to ratios is the difference between a dashboard and a decision-making tool.

Day-one stack (don't overthink this)

✅ ONE product analytics SDK   → Firebase | Amplitude | Mixpanel | PostHog
✅ ONE crash tracker            → Sentry (or Crashlytics)
✅ 6–10 events                  → not 60
✅ Snake_case names             → enforced in a const object
✅ User properties attached     → on sign-up + on plan change

⏸️ Attribution (AppsFlyer/Adjust) → defer until you spend on paid acquisition
⏸️ Session replay               → defer until activation rate stabilizes
⏸️ A/B testing platform         → defer until you have a hypothesis worth testing

Stack three analytics tools on launch day and you'll end up with three half-broken instrumentations and zero confidence in the data.

The build–measure–learn loop, for real

The teams that compound are the ones who decided, on day one, which question they were trying to answer — and built the tracking against that question first. They didn't install Mixpanel and then figure out what to track. They figured out the activation event first, then picked the tool, then built the screens.

If you're earlier than that — still figuring out what the app even is — the bigger lever is speed of iteration, not analytics tooling. The faster you can put a build in front of real users and watch what they do, the sooner you'll know what to instrument in the first place. RapidNative generates real React Native + Expo source from a prompt — meaning you ship, instrument with the snippets above, watch what happens, and iterate in hours instead of sprints. The code is yours, so swapping in PostHog or Amplitude is just a normal RN package install.

Quick FAQ

How many events should a new app track?
6–10. Tracking 60 on day one almost guarantees none of them will be reliable.

What's a good D1 retention rate?
Rough rule: 25–40% for consumer apps. The shape of the curve matters more than any single day — does it flatten, or keep falling?

Do I need a paid tool for an MVP?
No. Firebase is free, has solid RN/Expo SDKs, and covers events, funnels, and retention. Most MVPs don't outgrow it until they have meaningful revenue.

Mixpanel vs Amplitude vs PostHog for React Native?
All three have first-class RN SDKs. Amplitude has the strongest cohort UI for product-led growth teams. Mixpanel has mature reports and a generous free tier. PostHog is open-source-friendly and self-hostable if you care about data ownership. Firebase is the free default if integrated with the rest of Google's stack matters more than UI polish.

What are you tracking in your React Native app right now — and which event do you wish you'd instrumented from day one? Drop a comment with your activation event; I'm collecting examples from the indie dev side.

3 Pricing Page Rewrites: What Finally Converted

Russel Dsouza — Tue, 19 May 2026 10:07:20 +0000

We rewrote the Applighter pricing page three times in eleven months. Here is what each version was, why it failed (or worked), and the structure we kept.

For context: we sell production-ready React Native templates. Each one is a full Expo app with a Supabase backend, NativeWind styling, AI integration where relevant, and a Stripe-powered license grant on purchase. Pricing is one-time, $79 per template, no subscription. That detail matters because two of our three rewrites pretended otherwise.

Version 1: the SaaS-tier menu

The first page was the one every founder builds in week one.

| Starter $79  | Pro $79      | Team $79     |
|--------------|--------------|--------------|
| ✓ Source     | ✓ Source     | ✓ Source     |
| ✓ Backend    | ✓ Backend    | ✓ Backend    |
|              | ✓ Most       |              |
|              |   Popular    |              |

Three columns. "Most Popular" badge. Monthly/annual toggle (we don't sell monthly anything). It looked professional. It looked familiar.

Conversion was bad. Support email volume was worse. The questions were:

"Is the $79 per template or for the whole library?"
"Do I have to pay every month?"
"If I pay $79, do I get the source code or just access to a dashboard?"

The page was telling buyers a SaaS story. The product was a zip of TypeScript and a Supabase project. Mismatch.

Lesson: Don't borrow the pricing UX of a different business model.

Version 2: the comparison wall

When buyers are confused, every founder's reflex is give them more information. We built a 32-row feature matrix comparing Applighter to "DIY," "UI templates," and "marketplace bundles."

const featureMatrix = [
  { feature: "TypeScript",          applighter: true,  diy: "depends", ui: true,    bundle: true  },
  { feature: "Supabase backend",    applighter: true,  diy: false,     ui: false,   bundle: false },
  { feature: "Auth",                applighter: true,  diy: "build it", ui: false,  bundle: "mock" },
  { feature: "Commercial license",  applighter: true,  diy: "n/a",      ui: "ext",  bundle: "ext" },
  // ... 28 more rows
];

Session recordings: median scroll-past in under three seconds.

The table was answering questions nobody was asking. The questions buyers actually had — can I use this commercially, what happens after I pay, what if it doesn't work for my project — were buried in a footer FAQ link nobody clicked.

Worse, the comparison framed the product as defensive. Buyers don't pay $79 to validate your competitive position.

Lesson: Read your support inbox before you read CRO articles.

Version 3: one product, three license sizes

The current page is shorter than either previous version. Top to bottom:

Hero with the product, not the price. Screenshot of the template running on an iPhone. The price exists, but it isn't the headline.
License picker, not a tier ladder. Single / Multiple / Enterprise — described by who is buying, not by features unlocked. Every license includes the same source code.
What's included, plainly. Six bullets. No checkmarks. No comparisons.
Refund policy next to the buy button. Seven-day, no-questions. The single biggest move on V3.
FAQ above the fold of the second screen. Pulled directly from real support tickets, in the buyer's own words.
One soft secondary path: browse other templates.

The implementation:

// app/buy/page.tsx (sketch)
export default async function BuyPage() {
  const tiers = await getLicenseTiers();
  return (
    <>
      <Hero product={product} />
      <LicensePicker tiers={tiers} />
      <RefundLine policy="7-day money-back" />
      <BuyButton />
      <Faq source={faqJson} />
      <RelatedTemplates />
    </>
  );
}

License tiers are stored in Postgres and read at request time, so we can adjust per-template without a deploy. The FAQ is read from data/faq.json and used on both the homepage and the buy page so the messaging stays consistent.

What conversion actually moved

Pricing page	Layout	Optimized for	What buyers did
V1: SaaS tier menu	Starter / Pro / Team	Looking like a "real" company	Asked support if it was a subscription
V2: Comparison wall	32-row feature matrix	Defending against alternatives	Scrolled past in 3 seconds
V3: License picker	Hero → license sizes → FAQ → refund	Removing friction the buyer named	Bought, or refunded inside 7 days (rarely)

V1 → V2 made things worse. More info to a confused buyer = more confusion.
V2 → V3 was the largest jump. Refund line + license picker carried most of it.
Refund rate dropped after V3, not V2. Refunds correlate with surprise.
Support ticket volume on pricing questions fell roughly in half.

We did not run A/B tests. Traffic on a $79 product wasn't high enough for significance in a useful timeframe. We talked to buyers, watched email, and changed the page.

Five lessons that survived

Match the pricing UX to the business model. A one-time digital product is not a SaaS.
The buyer's questions are not your competitor's questions. Read the inbox.
The refund policy is part of the offer. Surface it.
Less ships faster than more. Every rewrite removed something.
Ship a page, don't ship an A/B test. At our volume, ten buyer conversations beat a multivariate framework.

What we would do differently

Skip V1 and V2. Start at V3. The shape of the right page was sitting in the support inbox the whole time.

If you want to see the structure in production, the Applighter template catalog is built on the V3 pattern — same hero-then-license-picker-then-refund-line shape on every product page.

For the React Native + Supabase + Expo stack underneath, the relevant docs are Expo, Supabase, and Stripe Checkout.

If you've rewritten your own pricing page and learned something the slow way — especially if you sell a one-time digital product — drop a comment with what moved the needle for you. Curious whether the "refund line next to CTA" pattern holds for other indie devs or whether it's specific to our buyer.