DEV Community: RapidNative

The Complete Guide to Push Notifications in React Native (2026)

Mark F A — Wed, 19 Aug 2026 05:16:15 +0000

TL;DR

Use expo-notifications in 2026, even in a bare React Native workflow. CNG makes the managed/bare distinction mostly irrelevant.
The token identifies a device plus install, not a user. Plan for rotation from day one.
On Android you must create a notification channel before requesting permission, or notifications silently never display.
Android 13+ needs the POST_NOTIFICATIONS runtime permission, and only if your target SDK is 33 or higher.
Never call the system permission prompt cold. It's one-shot. Put a screen you own in front of it.
react-native-push-notification (Zo0r) is dead. Don't start a new project on it.

Push notifications are the single most reliable way to bring a user back into a mobile app. Localytics data pegs day-90 retention at roughly 190 percent higher for apps that use them well, and Airship's 2024 benchmarks show median direct-open rates north of 4 percent across most verticals. Yet notifications are also the feature most React Native teams postpone the longest, because the surface spans two operating systems, two transport providers (APNs and FCM), a set of iOS entitlements that require an Apple Developer account, an Android notification-channel model that changed twice in the last five years, and at least three distinct app states you have to handle differently.

This guide is the version I wish I'd had when I first shipped push in a React Native app. It walks through the full stack (permissions, tokens, sending, receiving, deep linking, rich content, and testing) using the Expo Notifications SDK, which works for both Expo-managed and bare React Native projects on modern Expo SDK versions. Every code sample runs. Every gotcha is one I've actually hit in production.

What "push notifications" actually means

A push notification is a message your server hands to a push service (APNs for Apple, FCM for Google) which then delivers it to a specific device using a device-specific token. The device wakes up even if your app is killed, OS-level code decodes the payload, and either displays a system UI or fires an event into your app process.

Three things follow from that definition, and they cause most of the confusion:

You cannot send a push directly from your React Native app to another user. You need a server.
The token identifies a device plus app install, not a user. When a user reinstalls, logs into a second device, or clears app data, you get a new token. Tokens also rotate for other reasons and can be invalidated by the push service.
What runs inside your app is only half the story. The other half is Apple's or Google's OS-level notification presentation logic, which you configure through payload keys, notification channels, and iOS entitlements.

Local notifications, the kind you schedule from inside the app without a server, use most of the same APIs but skip the token and the push service. This guide covers both, since real apps almost always need both.

The 2026 landscape: which library

There are three real options for React Native in 2026, and the honest recommendation is: use expo-notifications, even if you're not on Expo Go and even if you use a bare React Native workflow.

Library	Best for	Trade-offs
`expo-notifications`	Almost every app	First-class support in both Expo-managed and bare RN via CNG (Continuous Native Generation). Handles APNs and FCM transparently. Actively maintained.
`@react-native-firebase/messaging`	Apps that already use other Firebase products (Firestore, Auth, Analytics) heavily	Google-only transport story; you still need a separate iOS setup for APNs credentials.
`react-native-notifications` (Wix)	Advanced native-side customization needs	Smaller community; more manual native config.

The legacy react-native-push-notification package (Zo0r) is unmaintained and should not be used in a new project.

The rest of this guide uses expo-notifications. Because Expo now supports prebuild (npx expo prebuild) and CNG, you get the same experience whether your project is Expo-managed or bare: the config plugin generates the correct native code for both.

Installing and configuring

Assuming an Expo SDK 52+ project:

npx expo install expo-notifications expo-device expo-constants

expo-device is used to skip token registration on simulators. Apple's push service does not deliver to the iOS simulator on Xcode versions below 14, and even on newer Xcode you need a paid developer account and the Simulator's push testing tools. expo-constants gives you access to easConfig.projectId, which the Expo Push Service needs to route tokens.

Add the config plugin in app.json:

{
  "expo": {
    "plugins": [
      [
        "expo-notifications",
        {
          "icon": "./assets/notification-icon.png",
          "color": "#111827",
          "sounds": ["./assets/notification-sound.wav"]
        }
      ]
    ],
    "ios": {
      "bundleIdentifier": "com.yourco.yourapp",
      "infoPlist": {
        "UIBackgroundModes": ["remote-notification"]
      }
    },
    "android": {
      "package": "com.yourco.yourapp",
      "googleServicesFile": "./google-services.json"
    }
  }
}

Two things to know:

The notification icon must be a monochrome PNG with a transparent background. Android's icon guidelines are strict, and a full-color icon renders as a white square.
On iOS, you need to enable the Push Notifications capability and the Background Modes to Remote notifications capability in your Apple Developer account. If you're using EAS Build, expo-notifications and the UIBackgroundModes config above handle this automatically.

If you're standing up a new project rather than retrofitting an existing one, starting from a config that already builds saves an afternoon. RapidNative generates Expo projects with app.json, the bundle identifier, and the Android package name already in place, so you're editing a working config instead of assembling one from an empty file.

Requesting permission the right way

This is where a lot of implementations lose would-be opt-ins. Apple's system prompt is a one-shot event: if the user taps "Don't Allow," you cannot re-prompt from your app. They would have to go into Settings.

The pattern that works is a pre-permission screen: a screen you own, explaining the value, with a "Turn on notifications" button. Only when the user taps that button do you call the system API.

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 registerForPushNotifications(): Promise<string | null> {
  if (!Device.isDevice) {
    console.warn('Push notifications require a physical device.');
    return null;
  }

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

  const { status: existing } = await Notifications.getPermissionsAsync();
  let finalStatus = existing;

  if (existing !== 'granted') {
    const { status } = await Notifications.requestPermissionsAsync();
    finalStatus = status;
  }

  if (finalStatus !== 'granted') return null;

  const projectId = Constants.expoConfig?.extra?.eas?.projectId
    ?? Constants.easConfig?.projectId;

  const token = (await Notifications.getExpoPushTokenAsync({ projectId })).data;
  return token;
}

A few details that matter:

Android 13+ (API 33) requires runtime permission via POST_NOTIFICATIONS. expo-notifications handles this for you when you call requestPermissionsAsync(), but only if your target SDK is 33 or higher.
On Android, you must create a notification channel before you request permission. Otherwise notifications will silently fail to display, even though your token is valid. Channels group notifications so users can mute categories independently in system settings.
You want the Expo push token, not the native APNs or FCM token, unless you're skipping Expo's push service. The Expo token is a single string of the form ExponentPushToken[xxxxxxxxxx] that Expo's service translates to either APNs or FCM at send time.

Where to go next

The setup above gets you a valid token and a permission prompt users actually accept. The next layer is the one that decides whether push works in production: sending from your server, handling the payload in all three app states (foreground, background, killed), routing a tap to the right screen, and testing all of it on real hardware.

What broke first when you shipped push? My money is on the Android channel. Drop yours in the comments.

How AI Is Making Mobile Accessibility Easier Than Ever

Famitha M A — Mon, 17 Aug 2026 08:27:47 +0000

TL;DR

95.9% of the top million sites have detectable a11y failures. Mobile apps are not better, they're just harder to audit.
Four things changed: on-device assistive AI, ML-assisted testing, generated alt text and captions, and AI-assisted code generation.
On-device AI raises the floor, not the ceiling. VoiceOver guessing "Button, likely a heart" is not a label.
Rule-based tools catch 30 to 40% of WCAG failures. AI pushes that up, nowhere near 100%.
The real fix is at generation time: if the model writes the JSX, it can write accessibilityLabel in the same pass, for free.

The gap between apps shipping and apps shipping accessibly has been widening for a decade. What changed recently is that AI shows up on both sides of the shipping fence: in the runtime layer (the phone), in the tooling layer (audits), and at the code-generation layer, where the app is actually being written.

Why mobile a11y is harder than the web

Native apps don't share a common semantic model. On the web you have HTML, and HTML has a built-in accessibility contract. On mobile you have UIAccessibility on iOS, AccessibilityNodeInfo on Android, two screen readers with different gesture conventions, and a framework translation layer (React Native, Flutter, SwiftUI) sitting on top of both.

That means a label that works on one platform can be silently dropped on the other. Here's the version everyone writes first:

// Ships. Announces as "Button". Useless.
<Pressable onPress={toggleFavorite}>
  <Icon name={isFavorite ? "heart-filled" : "heart"} />
</Pressable>

And the version that actually works with VoiceOver and TalkBack:

<Pressable
  onPress={toggleFavorite}
  accessibilityRole="button"
  accessibilityLabel="Add to favorites"
  accessibilityHint="Saves this item to your favorites list"
  accessibilityState={{ selected: isFavorite }}
  hitSlop={12}
>
  <Icon name={isFavorite ? "heart-filled" : "heart"} />
</Pressable>

Four extra props. Nobody argues they're hard. They just never get written, because they're invisible in the simulator and they're the last-day task that gets cut.

Regulation is closing in anyway: the European Accessibility Act took effect for consumer digital products in June 2025, and ADA Title II requires state and local government apps to hit WCAG 2.1 AA by April 2026. Regulation without automation is a punishment. AI is what makes the automation possible.

Shift 1: the OS started covering for you

iOS runs an on-device model that generates image descriptions for photos and unlabeled UI elements. Ship a button with no label and VoiceOver will guess: "Button, likely a play triangle." Android's TalkBack does the same with Gemini Nano, including for images inside third-party apps that never set contentDescription. Both platforms now generate Live Captions for any audio playing on the device. Voice Control on iOS understands intent, so "tap the little heart" resolves even when your label is favoriteButton.

The floor is rising. The ceiling is not. A guessed description loses to a real one every time, and the guess is silently wrong often enough to matter.

Shift 2: audits got cheap

Three categories worth knowing:

Rule engines plus ML (axe DevTools Mobile, Google's Accessibility Scanner). These now catch labels that exist but are meaningless, like contentDescription="image1.jpg".
Visual regression plus ML (Applause, BrowserStack, testRigor). Diffs screens against known-good corpora and flags contrast ratios, small tap targets, low-legibility fonts.
LLM audits. Feed in screenshots plus an accessibility tree dump, get back findings in plain English: "The 'Sign in with Apple' button has no accessibility label; VoiceOver will announce it as 'Button'."

You can wire the cheap version of the third one into CI yourself:

// jest + @testing-library/react-native
// Fails the build when an interactive element ships unlabeled.
import { render } from "@testing-library/react-native";

test("all buttons are labeled", () => {
  const { UNSAFE_root } = render(<ProductScreen />);
  const buttons = UNSAFE_root.findAll(
    (n) => n.props.accessibilityRole === "button"
  );

  expect(buttons.length).toBeGreaterThan(0);
  buttons.forEach((b) => {
    expect(b.props.accessibilityLabel).toBeTruthy();
  });
});

WebAIM's own numbers say automated tooling catches 30 to 40% of WCAG failures. AI raises it, not to 100%. Keep a human in the loop, ideally one who uses the tech.

Shift 3: the missing content is now generated

Alt text from vision models is table stakes. Whisper-class models made captions good enough for accessibility use in most languages. LLMs are producing plain-language versions of dense content on the fly, which is a genuine breakthrough for cognitive accessibility. Live cross-language captioning is built into the call stack on both platforms.

The catch: generated descriptions are only usually right, and a screen reader confidently reading a subtly wrong description is worse than one that says nothing.

Shift 4: fix it at generation time

This is the one that matters. When an LLM writes the screen, the accessibility props are not extra work, they're the same tokens. That flips the default from "no labels, ship it" to "labels came with the generation."

This is the bet RapidNative is built on: prompt in, real React Native and Expo code out, with accessibilityLabel, accessibilityRole, accessibilityHint, and accessibilityState attached at generation rather than bolted on later. An image comes out as accessibilityLabel="Sunset over the ocean" instead of a nameless <Image /> someone will theoretically label next sprint.

None of this is exclusive to one tool. A well-prompted Copilot, Cursor, or Claude does the same thing in a hand-written codebase. Put it in the repo rules and it applies to every generation:

<!-- .cursorrules / CLAUDE.md / copilot-instructions.md -->
Every interactive element must have accessibilityRole and accessibilityLabel.
Every Image must have accessibilityLabel or accessible={false}.
Touch targets must be >= 44x44 (use hitSlop when the visual is smaller).
Never use placeholder text as the only label for a TextInput.

What AI still can't do

It tells you labels exist, not that the flow is usable. Reading order that jumps around passes every automated check.
Generated alt text is generic. "A person" is compliant. "The founder of the org you're about to donate to" is what a sighted user sees.
Cognitive accessibility is barely automatable. The fix is design work, not a tag.
Live captioning fails contextually: wrong medication name, wrong price, wrong date. Plausible-but-wrong is the worst failure mode for exactly the users you were helping.
Motor accessibility is under-covered because it doesn't map cleanly onto structured tests.

Treat AI as the intern who catches the obvious stuff at 10x speed. It makes a specialist's time higher-leverage. It doesn't replace them.

The checklist I'd run on any AI-generated app

Every interactive element has accessibilityLabel, plus accessibilityRole and accessibilityHint where useful.
Images are labeled or explicitly marked decorative with accessible={false}.
Contrast passes WCAG 2.2 AA (4.5:1 body, 3:1 large). Re-check after any palette tweak.
Font scaling works. Test at 200%.
Touch targets are 44x44 minimum. Generators over-index on clean small icons, so this is the most-violated rule in generated code.
Forms have labels, not just placeholders.
Video has captions.
You personally turned on VoiceOver and TalkBack and completed the primary flow.

Point 4 is worth a snippet, since it's the one people get wrong quietly:

import { useWindowDimensions, PixelRatio, Text } from "react-native";

// Bad: fixed height locks text out of scaling
<View style={{ height: 44 }}><Text>Continue</Text></View>

// Better: let the row grow with the user's font scale
const scale = PixelRatio.getFontScale();
<View style={{ minHeight: 44 * scale, justifyContent: "center" }}>
  <Text maxFontSizeMultiplier={2}>Continue</Text>
</View>

Where this goes next

WCAG 3.0 moves toward outcome-based scoring instead of binary pass/fail, which is far better suited to LLM evaluation. EAA enforcement in Europe starts producing fines and case law in 2026, which changes the internal politics of a11y work fast. And expect compliance tooling that lives inside the AI development pipeline: reviewing PRs, gating deploys, producing an audit trail.

The direction of travel is that accessibility becomes a property of how the app was built, not a coat of paint applied afterward.

What's the a11y bug that has burned you hardest in a shipped app? Drop it in the comments. I'm especially interested in the ones no automated audit caught.

Mobile App Analytics in React Native: What to Track (and What to Skip)

Russel Dsouza — Thu, 13 Aug 2026 05:01:19 +0000

I have shipped enough React Native apps to see the same pattern every time: on launch day someone wires up fifty analytics events and six months later nobody on the team can explain what any of them are for. This is a working developer's guide to instrumenting a React Native or Expo app so the numbers actually mean something.

The Four Buckets

Every useful mobile app metric fits into one of four categories:

Acquisition: installs, CPI, CAC, install source, store conversion.
Activation: activation rate, time to value, onboarding funnel completion.
Engagement and Retention: DAU, MAU, stickiness (DAU/MAU), session length, D1/D7/D30 retention cohorts, churn.
Monetization: ARPU, conversion rate, LTV, trial-to-paid, renewal rate.

Track a couple from each bucket. Skip the rest until you outgrow them.

Technical Metrics That Are Actually Product Metrics

Performance is not a "nice to have." A slow, crashy app poisons every other metric.

Crash-Free Session Rate: target 99.5%+ for consumer, 99.9%+ if you take payment.
ANR Rate (Android only): Play Store visibility suffers when this crosses Google's bad-behavior threshold.
Cold Start Time: under 500ms good, over 1500ms bad. Hermes bytecode substantially cuts JS parse time vs JSC.
API p95 Latency: measured from the client, not the server. The tail is where users feel pain.

The Stack I Actually Use in 2026

Concern	Tool
Product analytics	PostHog (self-hosted) or Amplitude (free tier)
Errors / performance	Sentry
Subscriptions	RevenueCat
Attribution	SKAdNetwork + Play Install Referrer (free, built-in)

All of these have first-class Expo config plugins in 2026. npx expo install @sentry/react-native posthog-react-native react-native-purchases gets you 80% of the way there.

The One Instrumentation Pattern That Scales

Wrap your SDK. Always. Every screen and component should import track() from a single module, never the SDK directly.

// src/analytics/track.ts
import PostHog from 'posthog-react-native';

type EventName =
  | 'signup_completed'
  | 'paywall_viewed'
  | 'subscription_started'
  | 'workout_logged';

type EventProps = Record<string, string | number | boolean>;

export function track(event: EventName, props: EventProps = {}) {
  PostHog.capture(event, props);
}

export function identify(userId: string, props: EventProps = {}) {
  PostHog.identify(userId, props);
}

Rules I have learned the hard way:

Event names are verbs, past tense. paywall_viewed, not paywall.
User properties are stable, few, semantic. plan, cohort_week, platform_version. That is enough for 90% of segmentation.
No PII in event names or properties. Not even hashed. Just don't.
Type the event names. If your event schema is a type, refactoring becomes safe. Untyped strings are how event soup starts.

Metrics I Have Deleted From Every Dashboard

Total installs, unless you are showing it next to activated installs.
Screen views as a KPI. Useful for debugging nav, useless as a headline.
"Engagement" as a single number. It's a portfolio, not a scalar.
App Store rating without volume and recency alongside it.

Rule: for every metric, name the decision it drives, the owner of that decision, and the cadence they act on it. Can't do all three? Delete.

Privacy: The 2026 Baseline

PrivacyInfo.xcprivacy is mandatory if any of your SDKs touch required-reason APIs. Most analytics SDKs do. Skip this and your App Store submission gets rejected.
Consent for EU: non-negotiable for behavioral events. Use Klaro if you want an OSS option.
First-party > third-party: server-side event streams from your app to your own backend are increasingly the safe default. PostHog and Amplitude both support this.

Where to Go From Here

If you're starting from scratch, spin up an app with an AI React Native builder like RapidNative. It scaffolds Expo apps with the wrapper pattern above, and event schemas become just another thing you can prompt for. Faster than doing the boilerplate by hand, and consistent across every screen.

If you already have an app, delete half your events tomorrow. You'll be fine.

Which metric have you deleted from a dashboard and never missed? That list is more useful than any tracking plan; drop yours in the comments.

How to Build a HIPAA-Compliant App: A Founder's Guide for 2026

Mark F A — Wed, 12 Aug 2026 07:09:30 +0000

TL;DR

There is no HIPAA certification. No stamp, no badge. It's a continuous state you maintain through contracts, controls, and documentation.
Six technical pillars carry most of the weight: encryption at rest and in transit, unique auth with MFA, server-enforced RBAC, tamper-evident audit logs, automatic session logoff, and a signed BAA with every vendor that touches PHI.
Missing BAAs are the most common root cause of HIPAA breaches. They're also the easiest thing for an auditor to check.
You can use LLMs with PHI in 2026, but only with providers that offer a BAA, on the right plan, with identifiers redacted before the call.
The $60k-$300k agency number is real but not the only number. A React Native and Supabase stack can hit a compliant beta in eight to twelve weeks.

Every healthcare founder eventually hits the same wall. You have a real idea, sometimes even paying pilot customers, and then a hospital CTO or a payer's legal team asks the question that stops the conversation: "Is your app HIPAA-compliant?"

Suddenly the six-week MVP plan collides with a body of law from 1996, agencies quoting $150,000 to $300,000 for a "compliant build," and a vendor stack full of tools you love that quietly cannot legally touch patient data.

Here's how you'd actually do it in 2026.

What "HIPAA-compliant" actually means

HIPAA-compliant app development means every point where Protected Health Information (PHI) is created, stored, transmitted, or accessed is covered by administrative, physical, and technical safeguards defined by the HIPAA Security Rule. And every third-party vendor that touches PHI has signed a Business Associate Agreement (BAA) with you.

Compliance is not a certification you buy. There is no "HIPAA-certified" stamp issued by HHS. What exists is the HIPAA Security Rule, the Privacy Rule, and the Breach Notification Rule, plus the Office for Civil Rights that investigates breaches and complaints. Your job is to demonstrate, with documentation, contracts, and technical controls, that you meet every applicable requirement on the day someone asks.

The three rules that shape your architecture

The Privacy Rule governs how PHI can be used and disclosed. It introduces the concept every product designer bumps into first: the minimum necessary standard. Your app collects, displays, and transmits only the PHI required to do its job. If your telehealth app doesn't need a full address to run a video visit, don't ask for it. It also defines patient rights (access, amendment, accounting of disclosures) and every one of those maps to a screen or an endpoint you have to build.

The Security Rule is the one engineers live in. It covers electronic PHI and requires three safeguard categories:

Administrative: risk assessments, workforce training, access management policies, incident response.
Physical: facility access controls, workstation security, device and media disposal.
Technical: access controls, audit logs, integrity controls, transmission security. This is the layer your code implements.

The Breach Notification Rule gives you a legal duty to notify affected individuals within 60 days, notify HHS, and in some cases notify media. "Unsecured" is the operative word. Properly encrypted PHI that gets stolen is generally treated as a much lower-risk event, which is the strongest practical argument that encryption is not optional.

The 6 technical requirements that actually matter

Encryption at rest and in transit. AES-256 server-side and on device. TLS 1.2+ with modern ciphers in flight. Hardware-backed key storage for anything the client persists.
Unique user authentication with MFA. Unique identifier per user, no shared logins, MFA for anyone accessing PHI. Biometrics count as a second factor on the client.
Role-based access control. Patient sees their own record. Nurse sees their unit. Billing clerk sees charge codes but not clinical notes. Enforced on the server, never only in the UI.
Tamper-evident audit logging. Every read and write of PHI logged with who, what, when, and from where. Logs protected from modification, retained six years.
Automatic logoff and session controls. Inactive sessions terminate. On mobile this means a background timer that clears the session and forces re-auth.
Signed BAAs with every vendor that touches PHI. The one most first-time healthcare founders miss.

On mobile, requirement 1 mostly comes down to not persisting PHI in the wrong place:

// DON'T: AsyncStorage is plaintext on disk.
// On Android it's SharedPreferences XML, readable with adb.
await AsyncStorage.setItem('patient_mrn', mrn);

// DO: hardware-backed keychain/keystore, device-bound.
import * as SecureStore from 'expo-secure-store';

await SecureStore.setItemAsync('session_token', token, {
  keychainAccessible: SecureStore.WHEN_UNLOCKED_THIS_DEVICE_ONLY,
  keychainService: 'com.yourcompany.health.auth',
  requireAuthentication: true, // gates read behind Face ID / biometric
});

Better still: don't persist PHI on the device at all. Keep it in memory, fetch it per session, and let the server be the only durable store. That turns a lost-phone incident into a non-event.

Requirement 5 is the one people forget until an auditor asks. A minimal version:

// sessionTimer.js
import { AppState } from 'react-native';

const TIMEOUT_MS = 15 * 60 * 1000; // 15 min inactivity
let backgroundedAt = null;

AppState.addEventListener('change', (next) => {
  if (next === 'background') {
    backgroundedAt = Date.now();
  }
  if (next === 'active' && backgroundedAt) {
    if (Date.now() - backgroundedAt > TIMEOUT_MS) {
      clearSession();       // wipe in-memory PHI
      navigateToLogin();    // force re-authentication
    }
    backgroundedAt = null;
  }
});

Pair that with a foreground inactivity timer reset on user interaction, and log both the timeout and the re-auth to your audit trail.

The vendor stack that will actually sign a BAA

This is where most guides fail founders. They say "sign a BAA with your vendors" without saying which vendors will sign one, on which plan, at what price.

Layer	HIPAA-eligible option in 2026	Notes
Cloud infrastructure	AWS (BAA free via AWS Artifact, ~150 eligible services), Google Cloud, Azure	AWS is the most-used HIPAA cloud in 2026
Database + auth + storage	Supabase Team ($599/mo) + HIPAA add-on ($350/mo), or self-host	Check current Supabase HIPAA docs
Frontend (mobile)	React Native / Expo, no PHI in the bundle	Most common mobile framework for HIPAA apps
Email (transactional)	AWS SES (BAA available), Paubox, LuxSci	Not SendGrid on standard plans
SMS / voice	Twilio (HIPAA-eligible products only)	Sign a BAA and configure specifically for HIPAA
Push notifications	OneSignal (HIPAA plan), or AWS SNS	Never put PHI in the notification body
Error tracking	Sentry (HIPAA tier), Datadog (HIPAA tier)	Standard tiers do not qualify
Analytics	Server-side only, PHI-free events	Google Analytics does not sign BAAs
AI / LLM	Anthropic (BAA available), AWS Bedrock, Vertex AI, Azure OpenAI	See below

Two rules of thumb. If a vendor's marketing site doesn't say "HIPAA eligible" and their sales team can't produce a template BAA within a day, assume they can't. And HIPAA eligibility is almost always plan-specific, so the free tier you prototyped on almost certainly doesn't qualify.

Can you use LLMs with PHI?

Yes, but only with specific providers, on specific plans, under a signed BAA.

The major model providers now offer HIPAA-eligible tiers. Anthropic offers BAAs for enterprise customers using Claude. AWS Bedrock, Google Cloud Vertex AI, and Azure OpenAI all extend the underlying platform BAA to the models hosted on them. What you cannot do is ship PHI to a consumer API endpoint with no BAA. That's a breach the moment the request is sent, regardless of what the model does with the data.

Even under a BAA, minimize what you send:

// Redact identifiers server-side BEFORE the model call.
const SAFE_FIELDS = ['ageBand', 'sex', 'conditionCodes', 'medications'];

function toModelPayload(patient) {
  return SAFE_FIELDS.reduce((acc, k) => {
    if (patient[k] !== undefined) acc[k] = patient[k];
    return acc;
  }, {});
}

// Allow-list, not deny-list. A deny-list silently leaks
// every new field someone adds to the patient record.

Allow-list beats deny-list every time here. A deny-list quietly leaks whatever field a teammate adds next sprint. And log every prompt and response as part of your audit trail. If your AI features are purely non-PHI (educational content, appointment reminders with no diagnosis), you can often keep them on your regular non-BAA stack, as long as you can prove PHI never crosses that boundary.

The build checklist

Data classification. List every data element. Tag each PHI, non-PHI, or de-identified. Remove fields and prefer tokens over raw values.
Written risk assessment. A Security Rule requirement, not a nice-to-have. Threats, likelihoods, mitigations. Update annually and on material architecture changes.
Pick your HIPAA-eligible stack. Sign BAAs before a single byte of PHI reaches any vendor.
Implement the six pillars. Encryption, MFA, server-side RBAC, audit logs with six-year retention, session logoff, BAAs.
Secure SDLC. Code review, SAST/DAST, dependency pinning, supply chain controls. First thing a serious buyer's security team asks about.
Train your workforce. Security Awareness Training for anyone who could touch PHI. Keep records: dates, curricula, attendees.
Policies and incident response plan. Breach notification, sanctions, contingency, business continuity. Start from a template, then customize.
Third-party pen test before launch. Not required by HIPAA, but every hospital and enterprise buyer will ask for a recent report.
Privacy policy and Notice of Privacy Practices. User-facing documents, not just legal artifacts.
Continuous compliance. Quarterly access reviews, monthly log reviews, annual risk reassessment.

What it costs and how long it takes

Every agency guide says $60,000 to $300,000 and six to twelve months. That's real for a bespoke, agency-built telemedicine app with EHR integration. It's not the only number.

Baseline: whatever a non-HIPAA build of the same feature set would cost.
Add 15-25% for compliance-specific engineering: audit logging, RBAC, session management, encryption plumbing, admin console for access reviews.
Vendor upcharge: roughly $1,000-$3,000/month at MVP scale once you're on HIPAA tiers across the board.
Compliance program: policies, risk assessment, training, pen test, BAA legal review. Budget $10,000-$30,000 year one, roughly half that annually after.

Timelines compress the same way. A modern React Native and Supabase HIPAA stack, with the front-end scaffolded in an AI-assisted tool like RapidNative, can get you from zero to a working compliant beta in eight to twelve weeks. Worth being precise about the boundary, though: a code generation tool accelerates your front-end and scaffolding, not your compliance program. No AI code tool signs a BAA with you, because it doesn't touch your production PHI. And you should not paste PHI into any prompt during development. Scaffold with realistic-but-synthetic data and wire the real backend in your own environment.

What no tool can compress is the compliance program itself: writing your risk assessment, executing your BAAs, getting the pen test scheduled. Start those in parallel with engineering, not after.

FAQ

Is React Native suitable for HIPAA-compliant apps? Yes. Single codebase to native iOS and Android, access to Keychain and Keystore for hardware-backed encryption, biometric APIs for MFA, same TLS stack as native. HIPAA compliance is a property of your architecture and vendor stack, not your mobile framework.

Do I need a BAA with Apple or Google to publish? No. They don't process PHI on your behalf when they distribute your app. You do need to follow their health data policies, and you need BAAs with every cloud, analytics, notification, and backend vendor that actually handles PHI.

Can I use Firebase? Partially. Firebase Auth, Cloud Firestore, and Cloud Functions on Blaze are covered under the Google Cloud BAA when configured correctly. Firebase Analytics, Crashlytics on defaults, and Cloud Messaging with PHI payloads are not. Confirm each service against Google Cloud's current list.

What happens in a breach? Notify affected individuals within 60 days, notify HHS (immediately for 500+ people, otherwise annually), and in some cases notify media in the affected state. OCR fines range from $137 to over $2 million per violation depending on culpability. Encrypted PHI that's lost is generally a much lower-risk event.

Do I need HIPAA if only patients use my app? If you collect health data directly from consumers and aren't acting on behalf of a covered entity, you may not technically be subject to HIPAA. But you're almost certainly subject to the FTC Health Breach Notification Rule, state laws (California's CMIA, Washington's My Health My Data Act), and user expectations. Most direct-to-consumer health apps build to HIPAA-equivalent standards anyway.

The part most teams get wrong

HIPAA has a reputation for being expensive and slow because most teams treat compliance as a phase at the end of the project. It isn't. It's an architectural constraint you build in from day one, and once it's in your foundation the incremental cost is much smaller than the guides suggest.

Scaffold fast so you get to testable UI in days. Choose a HIPAA-eligible stack from the start. Get BAAs signed while engineers are still building. Write the risk assessment early, not the week before your first customer's security review.

What's your stack? Drop it in the comments and I'll flag which pieces will fail an audit. And if you've shipped a HIPAA app already, I want to know which vendor surprised you most by refusing (or agreeing) to sign a BAA.

The State of Mobile AI in 2026 — From Code Generation to Full App Creation

Famitha M A — Thu, 06 Aug 2026 07:55:07 +0000

In 2023, AI could complete a line of code. In 2026, AI can build the entire mobile app — screens, backend, auth, camera access, and a signed IPA ready for the App Store.

That's not marketing copy, it's a specific technical shift, and it happened faster than most of us in mobile expected. This post walks through the four generations of AI coding tools, why mobile lagged the web by three years, and what specifically broke open in 2026.

The four generations, briefly

Gen 1 (2021-2023): Autocomplete. Copilot. AI completes the next line. Human owns the file.
Gen 2 (2023-2024): Single-file generation. Cursor, Claude Code. AI generates entire files. Human is the integrator.
Gen 3 (2024-2025): Web full-stack. Lovable, v0, Bolt. Prompt to deployed web app.
Gen 4 (2026): Mobile end-to-end. Prompt to submission-ready native React Native + Expo app.

Every generation compressed the space between "I have an idea" and "users are running my app." Gen 4 is the first one where a non-engineer can complete that arc entirely for native mobile.

Why mobile lagged the web

Web AI moved fast because the web is forgiving. Mobile is not. Each of the following cost the ecosystem roughly a year:

Two platforms, not one. React Native shares ~80% of code across iOS and Android. The other 20% is where the pain lives: permissions, keyboard behavior, safe areas, gestures, notches. A model has to reason about platform divergence explicitly.

Native APIs are gated. Camera on web is getUserMedia. Camera on mobile is expo-camera + permission strings in app.json + runtime prompts + a config plugin. Any wrong step and it doesn't build.

Preview is genuinely hard. Web preview is an iframe. Mobile preview needs Metro, a matching JS engine (Hermes), and streaming updates without a full rebuild.

The App Store is a wall. Apple's Guideline 4.2 rejects "wrapped websites." Web-first tools with a "mobile export" button hit this and bounced. Gen 4 had to output real native code from day one.

Fullstack means fullstack. Real mobile means auth that survives app suspend/resume, secure token storage in the OS keychain, offline sync, and a data layer that handles being genuinely offline. Gen 3 tools papered over most of this — they targeted the web, which rarely needs it.

What "full app creation" actually produces in 2026

Layer	Output
Screens	React Native + navigation, gestures, safe areas
State	Redux / Zustand / Context, chosen by complexity
Backend	Provisioned Supabase project + schema + RLS + types
Auth	Keychain-backed session, deep links, sign-in flows
Data	Migrations, seed data, offline-first where relevant
Device	Camera, GPS, push, biometrics with correct config plugins
Preview	QR-code preview on real iOS and Android devices
Export	Clean React Native + Expo source, runs anywhere
Ship	Signed IPA/AAB, submitted to App Store + Play

Every row above is a place a Gen 3 "mobile export" tool fails. Every row is now Gen 4 table stakes.

The four unlocks that made 2026 different

Frontier models got good at multi-file reasoning. The current generation of frontier models can hold an entire codebase in context and reason about change propagation. Prerequisite for full app gen.
Streaming output made iteration feel instant. SSE + progressive component mounting turns "AI generation" from a batch job into a conversation.
LLM-native tooling replaced ported IDEs. Virtual filesystems the AI writes into, sandboxed runners that typecheck and lint before feedback loops back to the model, multi-step LLM pipelines. The model is the CPU; the surrounding system is the OS.
Someone had to actually build the mobile-specific infrastructure. This is the moat. Producing an Expo project that installs, builds, previews on a real device, submits to a store, and comes back with a valid receipt is a stack of ten problems requiring ten specialists.

Checklist: is a tool actually Generation 4?

If you're evaluating tools in 2026, ask:

Does the output run on a real phone via QR code, or just in a browser iframe?
Does the tool generate backend + auth in the same prompt as the frontend?
Can you export the code and run it locally without the vendor?
Does the tool handle App Store submission or stop at "here's your code"?
Does the tool support device features — camera, push, GPS, biometrics — out of the box?

Most tools calling themselves "mobile AI app builders" in 2026 fail at least two. The ones that pass are the ones defining what AI mobile app development means for the rest of the decade.

What this means for developers

Senior mobile engineers have not been displaced — the ceiling of what you can build solo has moved up, not down. The mechanical work (screen scaffolding, auth boilerplate, Expo config, navigation setup) collapses to a prompt. The architectural work (data modeling, performance profiling, complex state machines, offline sync semantics) is still where craftsmanship compounds.

The developers who ship the most in 2026 are the ones who treat AI as a code CPU and spend their time on the parts that matter.

Try it out: rapidnative.com — describe an app in plain English, get a real React Native + Expo app on your phone in minutes. Free tier is 20 credits, no credit card.

How to Build a Pet Care App with React Native (2026)

Mark F A — Fri, 31 Jul 2026 09:29:50 +0000

TL;DR

Pet care is a well-scoped React Native project: bounded MVP, cross-platform users, forgiving early adopters.
Stack: Expo SDK 52+, TypeScript, Expo Router, Supabase, NativeWind, expo-notifications, FlashList.
Store next_due_at on the vaccination row, not derived — vaccination schedules vary by jurisdiction.
Store UTC in the DB, render local with date-fns-tz, and reschedule reminders on AppState.change.
Honest timeline: 4–6 weeks solo, most of it boilerplate.

The pet care market keeps growing, and mobile apps are eating an increasing share of it — vet booking, vaccination reminders, feeding schedules. If you've been looking for a well-scoped React Native project to ship, a pet care app is genuinely one of the best options: bounded feature set, cross-platform relevance, and a user base that's forgiving of a rough v1 as long as it solves a real problem.

Here's the practical build guide, from stack decisions through App Store submission.

Why React Native fits pet care apps

Pet care apps need cross-platform reach (pet owners split evenly between iOS and Android), rich UI (photo-heavy profiles), and native features like push notifications and camera — the exact sweet spot for React Native with Expo. They also have a naturally scoped MVP: pet profiles, health records, appointments, reminders. You can ship in weeks, not months.

The MVP feature set

Ship these five features first. Adding a sixth before nailing edge cases (multi-species schedules, deleted pets, timezone-sensitive reminders) is the fastest way to never launch.

Pet profile — name, species, breed, DOB, weight, photo, microchip ID
Health record — vaccinations with next-due dates, medications, allergies
Appointment tracker — vet visits, grooming, boarding with reminders
Feeding log — food type, portion, schedule
Push notifications — vaccinations, medications, appointments

The stack

React Native with Expo SDK 52+
TypeScript (non-negotiable for anything you ship)
Expo Router for file-based routing
Supabase for hosted Postgres + auth
NativeWind for Tailwind-style styling
expo-notifications for local push
FlashList (not FlatList) for photo-heavy timelines

Scaffold it

npx create-expo-app@latest pet-care-app --template
# choose "Navigation (TypeScript)"
cd pet-care-app
npx expo install expo-notifications expo-image-picker expo-file-system
npm install nativewind zustand @supabase/supabase-js date-fns

Route structure

app/
  (tabs)/
    _layout.tsx           # Pets | Schedule | Records | Settings
    index.tsx             # pet list
    schedule.tsx
    records.tsx
    settings.tsx
  pet/
    [id].tsx
    [id]/health.tsx
    [id]/appointments.tsx
  appointment/new.tsx
  vaccination/new.tsx

Decide the route tree before writing screens. Nesting everything under (tabs)/pets/[id]/... will bite you when you need to push a full-screen modal.

Data model

Four entities cover the MVP:

Entity	Key fields
`pets`	id, owner_id, name, species, breed, date_of_birth, weight_kg, photo_url
`vaccinations`	id, pet_id, name, administered_at, next_due_at
`appointments`	id, pet_id, type, starts_at, location, notes
`feedings`	id, pet_id, food_name, portion_grams, scheduled_at, given

Two things matter more than you'd expect:

Store next_due_at on the row. Rabies is annual in some jurisdictions, triennial in others. Don't hardcode.
Store UTC in the DB, render local with date-fns-tz. Get this wrong and a reminder set for 8 AM triggers at 3 AM after a flight.

Push notifications the right way

The single feature that separates useful pet apps from forgettable ones:

import * as Notifications from 'expo-notifications';

await Notifications.scheduleNotificationAsync({
  content: {
    title: `${pet.name}'s ${vaccination.name} is due`,
    body: 'Book a vet appointment to stay on schedule.',
    data: { petId: pet.id, vaccinationId: vaccination.id },
  },
  trigger: { date: nextDueAt },
});

Two rules:

Request permissions gracefully — show a "why" screen before the OS prompt.
Reschedule on AppState.change when the app foregrounds. Timezone/DST drift is real.

The 4–6 week problem

Honest timeline for a solo developer: 4–6 weeks for a shippable MVP if you're comfortable with React Native. 10–12 weeks if you're learning Expo/TypeScript/Supabase alongside.

Most of that time is boilerplate — layout, navigation wiring, spacing, empty states, forms. None of it is the interesting part of building a pet care app.

The AI-first shortcut

Tools like RapidNative generate a working React Native + Expo codebase from a natural-language description. The workflow:

Describe the app: "A pet care app with pet profiles, vaccination tracking, appointment reminders, and a schedule tab across all pets."
Get a working app in a few minutes.
Scan a QR code, preview on your real phone.
Click any element to describe changes ("make these cards bigger, add a soft green tint when a task is done").
Export the full React Native + Expo source, or publish directly to the stores.

Same output — a real React Native app — different path. Worth trying on the boring 80% of the build so you can spend time on the interesting 20%.

App Store gotchas specific to pet apps

Three things reviewers catch:

Health claims. Track vaccinations/meds without positioning as a medical device. Be explicit in the description.
Background location. If you add walk tracking, justify the permission concretely: "To log your dog's walk route while your phone is in your pocket."
Screenshots. Empty-state screenshots underperform dramatically. Show real pets with real data.

Use eas submit — it handles both stores and eliminates most rejection loops.

Wrapping up

The features are the easy part. Reliable reminders, offline-first data, and fast photo handling are what separate 5-star pet apps from abandoned ones. Nail those, ship a focused MVP, and let owners tell you what's missing.

If you've shipped a pet app — or any app where reminders are the core value — how did you handle timezone drift on scheduled notifications? Drop a comment, I'd like to hear what actually held up in production.

Build a News Aggregator App with AI Recommendations (React Native + Expo)

Mark F A — Wed, 29 Jul 2026 06:43:33 +0000

The average reader engages with about 4% of the news they scroll past. The remaining 96% is duplication, noise, or algorithmically boosted outrage. That gap is the whole reason a well-built AI news aggregator still has room in the market — and thanks to modern tooling, it's now a weekend project instead of a quarter-long roadmap.

Here's the architecture that keeps showing up in successful indie news apps, plus a shortcut for shipping one fast.

The four layers you actually need

Ingestion — NewsAPI, RSS, publisher APIs, GDELT.
Understanding — embeddings, categorization, dedup.
Ranking — hybrid: content + collaborative + recency decay + diversity.
Presentation — reader mode, saves, offline, push, deep links.

Skip any layer and you have a directory nobody opens. Nail all four and you have a daily habit.

Reference tech stack

Layer	Choice
Client	React Native + Expo
Feed API	NewsAPI + curated RSS
Storage	Postgres (Supabase)
Embeddings	OpenAI `text-embedding-3-small`
Vector search	pgvector
Push	Expo Notifications
Offline	AsyncStorage

Nothing exotic. The hard part is the product decisions, not the pieces.

Building it fast

The traditional way: npx create-expo-app, set up navigation, build 12 screens by hand, wire the API, add state management, style everything, then start on the ranker.

The 2026 way: describe the app in a prompt to an AI app builder (I've been using RapidNative for this kind of thing) and get a working Expo project as output — real code, exportable, no lock-in. Then hand-tune the parts that actually matter (the ranker, the sources, the cold-start UX).

A prompt that produces a strong first version:

Build a news aggregator app called Skim. Vertical feed of article cards with hero image, source logo, headline, summary. Top pill row for categories: For You, Top, Tech, Business, Science, Sports. Tap opens a reader-mode view with share, save, and "More like this." Bottom tabs: Feed, Search, Saved, Profile. Dark theme, pull-to-refresh, shimmer loading.

You get a working multi-screen app in about a minute, previewable on your phone via QR.

The recommendation engine

Once you have a live feed, add three ranking signals:

Content-based. Embed each article. Store a rolling user "taste vector" as the mean of embeddings of articles they read/saved/lingered on. Cosine-similarity a new article against the user vector. Solves cold-start well.

Collaborative. Once you have enough interaction data, "users who read X also read Y" is often stronger than pure text similarity — it captures fun, authority, contrarianism, things the text doesn't.

Recency + diversity re-ranking. Multiply scores by exp(-age_hours / half_life) with a 12–24h half-life. Then, when selecting the top N, penalize each candidate by its similarity to already-selected items. This is what stops the feed from becoming five versions of the same story.

Rough weights I've seen work: 0.4 * content + 0.3 * collab + 0.2 * recency + 0.1 * diversity. Tune with real data.

Cold-start UX matters more than ranker quality

The first five swipes decide whether a new user comes back tomorrow. Default to a strong editorial mix (top stories across categories) on session 1–2. Bring personalization online after session 3. Every good news app I've studied does some version of this.

The retention features people underinvest in

Save-for-later with offline caching (people read on the subway)
"Why am I seeing this?" per-story explainer
Explicit topic mute/follow controls
Weekly digest push or email
Notifications capped at 3–5/day, gated on the user's taste vector

Copyright, briefly

Show headline + short summary + hero image + link back. Don't cache full article bodies at scale without a license. Reader mode is fine if fetched on-device (Instapaper pattern).

The full workflow

If you want to see this in action end-to-end, RapidNative turns the prompt above into a real Expo project you can extend. Free tier is 20 credits, no card. The exported code is standard Expo — you own it.

Happy to answer questions on the ranker specifics in the comments.

A Design System for Push Notifications: 12 Components, 3 States, One Figma File

Mark F A — Wed, 29 Jul 2026 06:18:29 +0000

TL;DR

Push is the surface users see 20x a week — it belongs in the design system, not in a marketing sprint.
12 notification archetypes cover almost every app: social-mention, social-activity, DM, group-message, transaction-confirm, transaction-update, reminder-user-set, reminder-streak, security-alert, content-drop, system-status, promotional.
3 states get skipped every time: grouped, expanded, and the lock-screen/Notification-Center/banner size variants.
The handoff artifact is a YAML file per component that maps 1:1 to an expo-notifications payload. If code diverges from the YAML, code review fails.
A weekly 30-minute notification review catches copy drift before users do.

Most design systems stop at the app icon. Push notifications live outside the app, on the lock screen, in the notification shade, in the app-switcher preview — and they get designed ad-hoc, by whoever is writing the marketing send that week. Then a user sees seven notifications from your brand and none of them look like they came from the same company.

Six months ago I built a push-notification design system for a React Native app the team was scaling from 20k to 200k users. Twelve components, three states each, one Figma file, and a handoff spec that maps every component to a specific expo-notifications payload shape. Here's the whole thing.

Why Push Notifications Belong in the Design System

Push is the most visible surface of your product for users who aren't in the app. If your in-app UI is polished but your notifications look like they were written by a bot, the notification is what users remember — it's the surface they see 20 times a week, versus the in-app UI they see three times.

When push isn't in the design system, three things break:

Copy voice drifts. Marketing writes chirpy, engineering writes terse, and the same user gets both.
Icon and color usage is inconsistent. Some notifications use the brand accent, some use system defaults, some use whatever emoji the sender liked.
Rich media (images, actions, replies) get added case-by-case, with no consistent affordance for users to know what interactions are available.

A design system fixes all three by making the notification a first-class component with reviewable specs, not an afterthought at the end of a marketing sprint.

The 12 Components

After working across four apps, the same twelve notification archetypes keep showing up. Design one component per archetype:

Social-mention — someone tagged/mentioned/replied to the user.
Social-activity — someone the user follows did something.
Direct-message — a 1:1 message from another user.
Group-message — a message in a group, showing group name.
Transaction-confirm — order placed, payment received.
Transaction-update — delivery moved, ride arrived, booking changed.
Reminder-user-set — the alarm/reminder the user configured.
Reminder-streak — 'you're one workout from your streak' style.
Security-alert — new login, fraud check, 2FA code.
Content-drop — new episode, new article from a followed source.
System-status — app update available, service outage.
Promotional — offer, discount, event (use sparingly).

Each component gets its own frame in Figma with a filled-in example, a spec sheet, and links to the two engineers who own the code path that sends it.

The Three States Designers Forget

Designers default to designing the single-notification-on-lock-screen state. Then production shows three other states that were never designed:

Grouped state (iOS + Android). When your app sends 3+ notifications in a session, the OS collapses them into a stack. The stack header is 'YourApp' — but if you set threadIdentifier (iOS) or channelId + group (Android), you get semantic grouping like '4 messages from Sarah.' Design what those group headers look like. Design what happens at 15 notifications (do they collapse further?). Design the tap-to-expand animation.

Expanded state. Long-press on iOS or swipe-down on Android reveals the expanded notification, which can show images, quick-reply fields, action buttons. Most apps ship the default (a bigger version of the collapsed view). You can do better: this is prime real estate for a mini-interaction that doesn't require opening the app.

Lock-screen preview vs Notification Center vs Banner. Same content, three different sizing constraints. The banner (top of screen when phone is unlocked) truncates at ~40 chars. The lock-screen preview shows 2-3 lines. Notification Center shows 4-5 lines and stacks. Design the copy for the tightest constraint first, then progressively enhance for the roomier surfaces.

Figma-to-Code Handoff That Actually Survives

The handoff spec I ship looks like this — one file per component, machine-readable:

component: social-mention
trigger: user_mentioned_in_comment
payload:
  title: "{{actor.display_name}} mentioned you"
  body: "{{excerpt}}"
  data:
    deep_link: "app://comments/{{comment_id}}"
    actor_id: "{{actor.id}}"
    thread_id: "{{parent_id}}"
ios:
  category_id: SOCIAL_MENTION
  thread_identifier: "mentions_{{parent_id}}"
  interruption_level: active
  relevance_score: 0.7
android:
  channel_id: social_mentions
  group: mentions
  priority: default
copy_rules:
  - excerpt max 60 chars, ellipsize
  - never include reactor emojis in title
  - if actor is verified, prepend U+2713

The React Native code that sends it maps 1:1:

import * as Notifications from 'expo-notifications';

async function sendMentionNotification(params: {
  actorName: string;
  actorVerified: boolean;
  excerpt: string;
  commentId: string;
  parentId: string;
}) {
  const title = params.actorVerified
    ? `\u2713 ${params.actorName} mentioned you`
    : `${params.actorName} mentioned you`;

  return Notifications.scheduleNotificationAsync({
    content: {
      title,
      body: truncate(params.excerpt, 60),
      categoryIdentifier: 'SOCIAL_MENTION',
      data: {
        deep_link: `app://comments/${params.commentId}`,
        actor_id: params.actorName,
        thread_id: params.parentId,
      },
    },
    trigger: null,
  });
}

The yaml file is the contract. If the code diverges from the yaml, code review fails. If a designer wants to change the notification, they change the yaml, which triggers a code PR. Everyone's working from the same spec, and copy can't drift silently.

Wiring the channels, categories, and deep-link routing by hand is the part that eats a sprint — the RapidNative starters ship with the expo-notifications scaffolding and channel config already in place, so you can go straight to writing the specs.

The Weekly Notification Design Review

Even with a design system, notification copy drifts. Marketing writes a one-off. Engineering hardcodes a fallback. QA never sees it because notifications only fire in production. Six months in, you have 40 slightly-off notifications your team can't remember shipping.

Run a weekly 30-minute notification design review. The agenda:

Screenshot every notification the app sent in the last 7 days (via the log I mentioned above — instrument every send).
Compare each against its yaml spec. Flag drift.
Look at delivery + open rates per component. Retire any component with under 5% open rate for two weeks running.
Discuss the copy of any new components proposed this week.

Thirty minutes, weekly. It's the single highest-leverage design meeting I've ever run — small enough that engineering shows up, focused enough that decisions actually get made, and it catches the drift before users notice.

When we ship this notification design system in RapidNative starters, teams stop treating push as marketing exhaust and start treating it as a product surface. The difference shows up in retention within a quarter.

How many of the 12 archetypes does your app actually send — and how many of them were designed on purpose? Drop a comment with the notification you know is drifting.

How to Build a Booking App for Service Businesses with AI (2026 Guide)

Mark F A — Wed, 29 Jul 2026 05:17:09 +0000

If you've ever tried to spec out a booking app for a service business — salon, cleaning company, mobile mechanic, personal trainer — you know the "obvious" features hide 40 nasty edge cases. Buffer time. Timezones. Double-booking races. No-show economics. Reminders that don't wake people up at 3 am.

This post walks through the actual engineering shape of a service-business booking app in 2026, and how AI app builders (RapidNative, in the examples below) collapse the 8–14 week custom build into 1–3 days. The generated output is real React Native + Expo you own and export, not a wrapped webview.

The 8 must-have features (skip the rest for v1)

Service catalog (name, duration, price)
Real-time availability keyed by staff or resource
Buffer time between appointments
Deposits or full prepayment (single biggest no-show reducer)
Push + SMS reminders (24h push, 2h SMS)
One-tap reschedule / cancel with a policy window
Customer profile with past appointments
Staff / admin view for daily calendar and blocking time

Gift cards, packages, loyalty, in-app chat — all v2. Ship v1 first.

The five availability checks nobody documents

is_bookable(slot_time T, staff S, service_duration D, buffer B) returns true iff:

[T, T + D + B] sits inside S.working_hours for that day
S has no other appointment overlapping [T − B, T + D + B]
S has not personally blocked that window
Date is not on the business's holiday list
T >= now() + min_lead_time (typically 60m)

Miss any one of these and a customer will discover it for you.

The workflow (works for any AI builder)

1. Write a one-page spec. Services, staff, hours, buffer, deposit, cancellation window, min-lead-time. This is the real bottleneck — not the code.

2. Paste it as a prompt. Example for a hair salon:

Build a booking app for "Wave & Co." salon. Services: Cut $45/45m, Cut+Color $150/120m, Blowout $60/45m. Stylists: Alex, Sam, Jamie. $10 Stripe deposit. Push reminder 24h out. My Bookings screen with cancel-if->24h. Staff view per stylist.

3. Preview on a real phone via QR. Never trust a booking flow you haven't tapped through on-device. Calendar UX, tap targets, and keyboard behavior on a phone-number field only make sense on real hardware.

4. Point-and-edit instead of re-prompting. Click an element in the preview and describe the change ("default the date picker to today"). RapidNative's point-and-edit mode preserves everything you already got right, which full regeneration does not.

5. Wire real integrations. Stripe PaymentIntents with capture_method: manual for deposits held until no-show, plus Expo Push and Twilio (~$0.008/SMS in the US).

6. Ship it. eas build --platform all — Expo handles the code signing pain and publishes to both stores under your developer account.

Traditional dev vs AI-built (2026 numbers)

Path	Time to v1	Upfront	You own code	Your brand on stores
Agency custom build	8–14 weeks	$10k–$25k	Depends on contract	Yes
SaaS (Fresha/Booksy)	1 day	$0–$60/mo	No	No
AI app builder (RapidNative)	1–3 days	Credit-based	Yes	Yes

Production gotchas

Timezones: store every appointment in UTC, render in user's local, never trust the client clock for availability.
End-of-day buffer: a 5:15pm 45m cut + 10m buffer ends 6:10pm — don't offer that slot if the shop closes at 6.
Race conditions: booking creation must be transactional. Lock, verify, insert or fail.
Reminders: never schedule a push for 3 am local. Clamp to max(now+24h, 9am_local_appointment_day).
No-show deposits: default deposit to a real amount ($10–$25 consumer, more for high-ticket). Overriding it manually is fine; defaulting to zero is not.

Prompt templates for 6 niches

Personal trainer, cleaning company, mobile mechanic, tutor, dog groomer, massage therapist — the full library is in the canonical post. They all share the same skeleton; the details (pricing, buffer, intake fields) are what generate different apps.

Try it

If you want to skip straight to it: rapidnative.com — free tier, 20 credits, paste a prompt, get an app on your phone. Full walkthrough with all six prompt templates and the comparison table is on the canonical post.

Happy building.

React Native Performance Monitoring: Tools and Techniques for 2026

Russel Dsouza — Tue, 28 Jul 2026 13:42:21 +0000

Flipper is gone (removed as default in RN 0.76). React Native DevTools is the sanctioned replacement.
Track eight metrics — the two most under-monitored are slow frames % and frozen frames %, the closest proxy for "feels laggy."
The pragmatic 2026 production default: Sentry for crashes + performance, optionally layered with Firebase Crashlytics (free redundancy) or Datadog RUM (if you're already on Datadog).
The New Architecture shifts the culprits: TurboModule calls blocking the JS thread, and Fabric commit contention on the UI thread.

The React Native performance monitoring landscape looks nothing like it did two years ago. Flipper is gone as the default debugger. The New Architecture — Fabric, TurboModules, and the bridgeless runtime — is on by default in every fresh app. Hermes is the assumed engine.

If you're shipping in 2026, you need a stack that reflects those changes: dev-time profilers that speak Perfetto and Hermes, production observability that captures slow frames per screen, and a workflow for turning that data into fixes before your App Store rating quietly drops from 4.6 to 4.1.

What "performance" actually means in React Native

React Native has a two-thread execution model, and every performance conversation lives inside it:

The JS thread — business logic, Redux reducers, Animated orchestration, most third-party code.
The UI (main) thread — layout, drawing, gesture recognition, native module execution, useNativeDriver animations.

A janky animation is almost always a UI thread problem. A slow list scroll under load is usually a JS thread problem. A screen that takes three seconds to appear after a tap is likely JS thread — unless it's blocking on a network call, in which case it's a waterfall issue. A frozen screen after login is often a JSI serialization stall.

Monitoring means tracking both threads, tying the data to specific user journeys, and being able to answer three questions:

Is it slow? — objective metrics on frame rate, TTI, startup.
Where is it slow? — which screen, component, native module.
Why is it slow? — flame graphs, network waterfalls, memory pressure.

If your setup only answers question one, you don't have monitoring — you have a smoke alarm.

The eight metrics that matter in 2026

Metric	What it measures	Healthy target
JS FPS	Frame rate on the JS thread	60 fps sustained (120 on ProMotion)
UI FPS	Frame rate on the native main thread	60 fps sustained (120 on ProMotion)
Cold start time	Icon tap to first interactive frame	< 2.0s on mid-tier Android
Warm start time	Time to interactive when backgrounded	< 400ms
TTI	Screen mount → first tap-responsive frame	< 1s per screen
Slow frames %	Frames rendered in > 16.67ms	< 5% per session
Frozen frames %	Frames rendered in > 700ms	< 0.1% per session
JS bundle size	Compressed bundle on first launch	< 2MB gzip

The two most under-monitored metrics are slow frames % and frozen frames % — the closest proxy for the qualitative "laggy." Sentry, Firebase, and Embrace expose them natively; if your stack doesn't, that's the first upgrade to make.

The 2026 tooling stack

Monitoring splits into two phases with different tools: dev-time profiling (finding the problem locally) and production observability (knowing it exists at all).

Development-time tools

Tool	Best for	Notes
React Native DevTools	JS profiling, network, component inspector	Default since RN 0.76. Replaces Flipper.
Hermes Sampling Profiler	Deep JS CPU flame graphs	Export as `.cpuprofile`.
Perfetto / Systrace	System-wide traces across all threads	Android. Best for bridge/native contention.
Xcode Instruments	iOS CPU, memory, energy, Core Animation	Time Profiler + Animation Hitches.
Android Studio Profiler	Java/Kotlin allocations, native memory	Pair with Perfetto.
React DevTools Profiler	Render counts, wasted renders	Ships with RN DevTools.

If a tutorial tells you to install Flipper, it's out of date. Flipper was removed as the default debugger in RN 0.76 and the community plugins are largely unmaintained. React Native DevTools is the replacement, and it's better for JS profiling.

Production observability

Platform	Strengths	Watch out for
Sentry	Crash reporting, integrated perf traces, native + JS stack merging	Sampling costs add up at scale
Firebase Performance	Free, Crashlytics integration, custom traces	Sparse UI, no session replay
Datadog RUM	Backend APM correlation, cohort analysis	Expensive at high MAU
Embrace	Session-first, full journey replay	Smaller ecosystem
Instabug	Bug reporting + perf in one SDK	Duplicates Sentry if you have it
New Relic Mobile	Enterprise-grade infra correlation	Heavier SDK

The pragmatic default for most teams: Sentry for crashes + performance + source-mapped traces, optionally with Firebase Crashlytics as a free redundant crash pipeline, or Datadog RUM if you're already on Datadog.

Minimum-viable production setup

1. Install Sentry with performance monitoring.

npx @sentry/wizard@latest -s -i reactNative

Set tracesSampleRate: 0.2 and enable enableNativeFramesTracking: true and enableAutoPerformanceTracing: true. Native frames tracking is what gives you slow/frozen frame percentages per screen.

2. Instrument navigation. Wrap your app with Sentry's navigation integration so every screen transition becomes a labelled transaction. Without this, traces are anonymous and useless.

3. Upload source maps on every release. Untranslated stack traces are worthless. Bake source map upload into CI so every TestFlight or Play build has readable traces waiting.

4. Add custom spans around slow operations. Any function over 100ms — cache hydration, a DB query, a large image decode — gets a manual span. This turns "screen X is slow sometimes" into "screen X is slow because recipe hydration takes 800ms on cold launch."

5. Set alerts for regressions:

Crash-free session rate below 99.5%
P75 cold start rising > 20% between releases
Slow frame % above 8% on any top-10 screen

A real diagnostic walkthrough: "the feed screen is laggy"

Step 1: Confirm in production data

Filter to the screen, look at P75 and P95 of slow frames per session. If P75 is fine and P95 is bad, it's a device-tier issue — likely mid-tier Android under a specific data condition. Note the device and OS distribution of the worst sessions.

Step 2: Reproduce on the right hardware

Never diagnose Android performance on an iPhone 15 Pro. Grab a Pixel 6a or a mid-tier Samsung and reproduce there. Enable the perf overlay for live JS FPS and UI FPS.

Step 3: Capture a trace

For JS-thread issues: React Native DevTools → Performance tab → record the interaction. Look for long JS tasks (> 50ms bars), high re-render counts, serialization work.

For UI-thread issues on Android: capture a Perfetto trace. Look for main-thread frames overflowing 16.67ms, and whether the overflow is in Choreographer#doFrame or in native module calls.

Step 4: Isolate the offender

Common culprits, ranked by frequency in 2026 codebases:

A FlatList with heavy renderItem work — no memoization, inline arrows. Fix: memoize the row, stabilize props, add getItemLayout if heights are known.
A large state slice re-rendering the whole tree — a selector returning new object identity every time. Fix: narrow the selector, add shallow comparison.
An image decode blocking the UI thread — full-res images in small views. Fix: server-side resize, expo-image with contentFit.
A synchronous AsyncStorage migration on cold start — reading 5MB before render. Fix: defer via InteractionManager.runAfterInteractions, or MMKV with lazy hydration.
A third-party analytics SDK spawning threads on startup — 200–400ms blocks. Fix: initialize lazily after first frame.

Step 5: Verify in a canary

Ship behind a flag or to a beta cohort. Compare P75 slow-frame % on the screen before and after. If the number doesn't move, the fix isn't the fix.

The New Architecture changes what you monitor

Under the old bridge, the biggest sinkholes were JSON serialization between JS and native, visible in traces as huge queues. The New Architecture's synchronous, typed JSI calls mostly remove that class of problem — but introduce two new ones:

Synchronous TurboModule calls that block the JS thread. A native module doing 50ms of I/O now blocks JS directly, where it used to buffer through the async bridge.
Fabric commit contention on the UI thread. Shadow-tree commits are more efficient on average but spike sharply when a large tree diff lands — watch navigation transitions where the whole screen tree re-mounts.

Modern Sentry SDKs instrument both Fabric commits and TurboModule calls when auto-performance tracing is on. On an older SDK, upgrade — you'll see spans you didn't have before.

Bundle size and startup — the fixes that compound

Startup time is the metric most correlated with day-1 retention, and the one most engineers stop optimizing after the first release.

Enable Hermes. If you're not on it, you're leaving 30–50% of cold-start performance on the table.
Precompile Hermes bytecode. Ship .hbc, not .js. RN does this for release builds — verify it.
Ship inline requires on Android. inlineRequires: true in Metro defers module evaluation until first use, cutting 200–500ms on large apps.
Split third-party SDKs. Anything not needed in the first second — analytics, remote config, feature flags — initializes after InteractionManager.runAfterInteractions.
Measure with production RUM, not local. Cold start on your dev machine is meaningless. Trust P75 from real devices.

Track JS bundle size release-over-release. A 100KB regression per release compounds fast.

FAQ

Best free monitoring tool in 2026? Firebase Performance + Crashlytics. Automatic startup and HTTP traces, custom traces, native crash reporting, all free up to a generous tier. Limitations: sparse UI, no session replay — most teams add Sentry for deeper diagnostics.

Is Flipper still usable? No — removed as default in RN 0.76, plugins unmaintained. Use React Native DevTools, plus Perfetto (Android) and Xcode Instruments (iOS) for native profiling.

How do I measure startup time in production? Sentry's enableAppStartTracking: true, or Firebase's automatic _app_start trace. Track P75 cold start — the average hides regressions behind a few fast flagship sessions.

What FPS should an app maintain? 60 fps sustained on both threads (120 on ProMotion). Track slow frames (> 16.67ms) as a percentage and aim under 5% per session.

Do I need separate monitoring for the New Architecture? Same metrics, different culprits — TurboModule calls and Fabric commit contention. Any modern SDK instruments both automatically; just don't run a pre-GA-era SDK.

The takeaway

The dev-time story is React Native DevTools plus platform-native profilers (Perfetto, Instruments). The production story is Sentry as the default, with Firebase Crashlytics as free redundancy or Datadog RUM for existing Datadog teams.

The bigger shift is philosophical: performance is a metric you monitor continuously, not a project you do once. The teams shipping the smoothest apps in 2026 have slow-frame alerts wired to Slack, source maps on every release, and a P75 startup dashboard someone actually looks at each Monday.

I write more about how we handle this in AI-generated React Native apps at RapidNative.

What's your current monitoring stack — and what's the worst "laggy screen" bug you've tracked down? Mine was a 5MB AsyncStorage migration running on every cold start.

How to Prototype a Mobile App in Hours (Wireframe React Native)

Mark F A — Fri, 24 Jul 2026 12:06:54 +0000

How to Prototype a Mobile App in Hours (Wireframe → React Native)

TL;DR:

The wireframe → clickable-prototype → coded-prototype pipeline is now collapsible into a single step
Four phases: capture wireframe (20-40 min) → generate base app (2-3 min) → iterate visually (1-2 hrs) → install on device via QR (30 sec)
First testable build: 1-3 hours vs. 2-4 weeks traditional
Includes an hour-by-hour log of a real 5-screen food-delivery MVP shipped in one afternoon

The three artifacts most guides conflate

Before we get into the workflow, one clarification that trips up most prototyping conversations:

Wireframe — static layout. No interactivity.
Clickable prototype — hotspots wired between static screens (Figma, InVision). Can't run real logic.
Working prototype — real React Native code, real navigation, real state, installable on device via QR.
Production app — the working prototype plus backend, auth, analytics, store listing.

Most "prototyping" tutorials stop at rung two. The interesting compression is going from rung one straight to rung three.

The four-phase workflow

1. Capture the wireframe (20-40 min)

Any medium that captures screens + elements + tap behavior works: hand sketch, whiteboard photo, Excalidraw, Figma frame, competitor screenshot, or a written paragraph. Treat the wireframe as disposable — its job is to be input to the generator, not a deliverable.

2. Generate the base app (2-3 min)

Feed the wireframe + a one-paragraph description into an AI mobile app builder (RapidNative is what we use — sketch/prompt/screenshot → React Native + Expo → QR preview in one editor, free tier with 20 credits and no card). You get back a live React Native + Expo app with routing, styled screens, and stubbed data. It's about 70% right — good enough to iterate against.

3. Iterate visually (1-2 hours)

The base app has ~30% wrong. Point-and-edit is the accelerator here: click any element in the live preview, describe the change ("make cards rounder, move price to top-right"), and the underlying code updates. Product teams typically do 30-50 micro-iterations in the first hour.

Two rules for this phase:

Don't accept the first version of any screen.
Don't over-specify visuals before validating flow. Colors are cheap; navigation is expensive.

4. Ship to real hardware (30 sec)

Scan a QR code, install into a preview client on iPhone or Android, and use the app on real hardware. This is where the bugs Figma can't show you actually show up: thumb-tap zones, safe areas, keyboard behavior, dark mode.

Traditional vs AI-native — the timeline table

For a 5-screen MVP:

Phase	Traditional	AI-native
Wireframing	4-8 hours	20-40 min
Hi-fi design	2-5 days	Skipped
Clickable prototype	4-8 hours	Skipped
Coded prototype	1-3 weeks	2-3 min
Iteration cycle	1-3 days per round	30 sec to 2 min
Real-device install	4-8 hours (Xcode/TestFlight)	30 sec (QR)
First testable build	2-4 weeks	1-3 hours

The compression is mostly the elimination of role handoffs. When one operator drives the whole loop, the "waiting for someone else" hours evaporate.

Which wireframe inputs convert best

Ranked worst → best in signal-to-noise:

Napkin sketch photo — works, but expect nuance loss. Pair with a written description.
Whiteboard photo — better; whiteboards force larger, more legible drawings.
Excalidraw / FigJam — excellent. Digital medium produces clean shapes and labels.
Figma frame — very good. Layout and hierarchy transfer.
Written PRD paragraph — underrated. A precise 3-4 sentence description often beats a bad sketch.
Competitor screenshot — highest signal. Already a mobile UI, so layout, typography, and interaction all transfer.

Hour-by-hour: food-delivery MVP, one afternoon

Two-person team, five screens (restaurant list → detail → cart → checkout → order tracking):

0:00-0:30 — Whiteboard sketch, phone photo.
0:30-0:38 — Upload + one-paragraph description → base app generated.
0:38-1:20 — First iteration pass. Point-and-edit ~40 changes.
1:20-1:35 — QR install on both team phones. Two nav bugs surface; fix in 3 min.
1:35-2:20 — Send QR to three test users, collect feedback in shared doc.
2:20-3:15 — Second iteration pass. Address top-10 UX notes.
3:15-3:30 — Publish shareable preview URL, drop in Slack.

Three-and-a-half hours end-to-end, iOS + Android, on real phones.

When to NOT use this workflow

The AI loop isn't universal. Stay traditional when:

Novel interaction patterns with no precedent (generators pattern-match; no pattern = no output quality).
Regulated industries (medical, aviation, financial trading) that need documented decision trails.
Pixel-perfect exec-review demos with no budget for a "70%-then-iterate" opening state.

For the other 90% — CRUD apps, marketplaces, social, dashboards, internal tools — the compressed loop wins on speed, iteration count, and cost.

Wrapping up

The whole compression comes down to one operator driving one loop: sketch it, generate it, poke at it on a real phone, repeat. Curious how the four phases feel end-to-end for others — drop a comment with what you're prototyping, and I'll answer questions for the next couple of days.

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

Famitha M A — Wed, 22 Jul 2026 09:28:13 +0000

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 ~30x faster and supports sync 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 + persistQueryClient, backed by MMKV.

Comparison table

Library	Type	Perf	Encryption	Best for
AsyncStorage	KV	1x	Community fork	Legacy/compat
MMKV	KV	~30x	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 — UI always reads from local store. Network populates store; store renders UI.
Optimistic writes — UI updates immediately, before the server acks.
Mutation queue — Durable list (SQLite or MMKV) of pending server-side changes with client IDs.
Sync engine — Background worker drains the queue with exponential backoff, 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

LWW — timestamps, newest wins. Fine for most consumer apps.
Server-authoritative — reject stale writes with a version mismatch.
CRDTs — Yjs, Automerge. Overkill unless you're building a collaborative editor.

Decision cheat sheet

Prefs / JWT? → MMKV + expo-secure-store
Instant-open cached lists? → TanStack Query + persistQueryClient on MMKV
Thousands of offline records? → op-sqlite (or WatermelonDB for reactive)
Cross-device sync? → WatermelonDB or Realm
Media? → expo-file-system + metadata in SQLite

Pitfalls to skip

Blocking JS thread with async AsyncStorage at startup
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. Pick each layer deliberately and this becomes a solved problem, not 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. Would love feedback from anyone using MMKV + TanStack Query in production.