DEV Community: RapidNative

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

Angel Rose — 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)

Angel Rose — 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)

Angel Rose — 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

Angel Rose — 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)

Angel Rose — 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)

Angel Rose — 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.

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

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

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

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

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

1. AsyncStorage for anything sensitive

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

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

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

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

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

2. Real user data in design prototypes

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

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

3. Multi-stage AI workflows

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

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

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

4. Logs and crash reports

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

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

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

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

5. Bundled permissions

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

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

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

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

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

The pattern

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

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

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

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

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

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

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

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

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

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

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

The 3 questions

Scope of the change?

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

How type-heavy is your codebase?

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

Who runs it?

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

The 2-tool stacks

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

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

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

What you can skip

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

The real lesson

Tool sprawl is a symptom.

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

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

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

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

Why 77% of Your App's Users Are Gone in 3 Days (and the real fix isn't another tactic)

Famitha M A — Mon, 20 Jul 2026 09:19:50 +0000

TL;DR

77% of users who install your app stop using it within 72 hours. Most of that churn happens inside the first session.
2026 cross-industry medians: Day-1 = 26%, Day-7 = 11%, Day-30 = 5.4%. Subscription apps retain ~2.5x better at D30.
The five real churn causes: no "aha moment", ad/product mismatch, no external trigger, crashes/slow loads, and one-and-done intent (which is fine).
The uncomfortable part: you probably already know the tactics. The real bottleneck is that your experiment cycle takes 3 weeks while your cohort churns in 3 days.
Fix the cycle time, not the tactics list.

The number

77% of the users who install your app stop using it within 72 hours. Not a month. Not a week. Three days.

That stat traces back to Andrew Chen's analysis at a16z, and every benchmark report since (Adjust, AppsFlyer, Sensor Tower) lands in the same neighborhood. The 2026 numbers, by vertical:

Vertical	Day 1	Day 7	Day 30
Social & Communication	30%	15%	8%
Gaming (Casual)	27%	10%	4%
Finance & Fintech	33%	18%	12%
Health & Fitness	24%	10%	6%
E-commerce & Retail	22%	8%	4%
Productivity	29%	14%	10%
Subscription Apps (all)	35%	22%	14%
Cross-category median	26%	11%	5.4%

Two things worth noticing: subscription apps retain 2.5x better at Day 30 (paywalls are a commitment device), and fintech beats casual gaming 3x at D30 (utility beats entertainment on retention, almost always).

Make sure you're measuring the same thing as the benchmarks

Retention has three variants, and teams routinely fool themselves by measuring one internally and comparing against another:

Classic — user came back on exactly day N. Punitive, but it's what the benchmarks above use.
Rolling — user came back on day N or later. More forgiving.
Bracket — user came back anywhere in days N–M. Useful for weekly cohorts.

If you want to sanity-check your own numbers, classic Day-N retention is one query away:

-- Classic Day-N retention per install cohort
WITH installs AS (
  SELECT user_id, DATE(install_time) AS cohort_day
  FROM app_installs
),
activity AS (
  SELECT DISTINCT user_id, DATE(event_time) AS active_day
  FROM app_events
)
SELECT
  i.cohort_day,
  COUNT(DISTINCT i.user_id) AS cohort_size,
  COUNT(DISTINCT CASE WHEN a.active_day = i.cohort_day + INTERVAL '1 day'
        THEN i.user_id END) * 100.0 / COUNT(DISTINCT i.user_id) AS d1_retention,
  COUNT(DISTINCT CASE WHEN a.active_day = i.cohort_day + INTERVAL '7 day'
        THEN i.user_id END) * 100.0 / COUNT(DISTINCT i.user_id) AS d7_retention
FROM installs i
LEFT JOIN activity a USING (user_id)
GROUP BY 1
ORDER BY 1;

Segment this by acquisition channel before you conclude anything. A cohort with 15% D7 overall might be 30% from organic and 4% from one bad Facebook creative. That's not a retention problem — that's an ad-relevance problem wearing a retention costume.

Where the 77% actually dies: the first session

The churn isn't spread evenly across 72 hours. Roughly 60–70% of it happens inside the first session. Users don't drift away over three opens — they open once, hit friction, close, never return.

The consistent offenders, with rough measured costs:

Signup wall before showing value: –30-40% of installers on that screen alone
Phone verification: another –15-20%
Push permission prompt on Day 0 (before any value): ~4x lower opt-in vs. asking after value
More than five onboarding screens: ~20% more churn vs. three or fewer

The cheapest fix in mobile is deferring everything. Guest mode instead of a signup wall:

// Instead of gating the app behind auth, persist a local guest identity
import AsyncStorage from '@react-native-async-storage/async-storage';
import { v4 as uuid } from 'uuid';

export async function getOrCreateGuestId() {
  let id = await AsyncStorage.getItem('guest_id');
  if (!id) {
    id = `guest_${uuid()}`;
    await AsyncStorage.setItem('guest_id', id);
  }
  return id;
}

// Later, when the user actually signs up, merge the guest state
export async function upgradeGuestToUser(userId) {
  const guestId = await AsyncStorage.getItem('guest_id');
  if (guestId) {
    await api.mergeAccounts({ from: guestId, to: userId });
    await AsyncStorage.removeItem('guest_id');
  }
}

Same logic for push permissions — ask after the user has experienced value, not on launch:

// Don't request on app open. Trigger contextually, e.g. after first "aha" action
async function requestPushAfterValue(trigger) {
  const alreadyAsked = await AsyncStorage.getItem('push_prompted');
  if (alreadyAsked) return;

  if (trigger === 'first_workout_completed') {
    // Pre-permission soft prompt first — protects your one real OS prompt
    const wants = await showSoftPrompt(
      "Want a reminder before your streak breaks?"
    );
    if (wants) {
      await requestNotificationPermission();
    }
    await AsyncStorage.setItem('push_prompted', 'true');
  }
}

The five real reasons users churn

Skip the twenty-tactic listicles. Churn comes from a small set of root causes:

They never hit the "aha moment." Duolingo: first lesson done. Instagram: first personalized feed. Fintech: first balance after bank link. Users who reach it retain at 3-5x the rate of users who don't. Your entire first session should be a speedrun to that moment.
The ad promised something the app isn't. Invisible in aggregate, obvious when you segment by channel (see the SQL above).
No external trigger. Apps that survive past D7 almost always reach out — a push tied to a real event (someone messaged you, your streak's about to break), not "hi, we miss you." Apps that rely on being remembered lose to apps that reach out.
Crashes and slow screens. Users don't file bug reports; they uninstall. And crashes disproportionately hit your heaviest users, because they hit more code paths.
They got what they came for. One-time intent (check a flight, convert a currency once) isn't a retention failure. Segment churn by intent before you panic.

The part nobody writes: your bottleneck is cycle time, not tactics

Here's the uncomfortable truth: you already knew most of the above. Everyone's read the same posts. Everyone has the Notion doc of retention experiments. So why is the median D30 still 5.4%?

Because most teams can't ship a retention experiment in under three weeks.

Week 1: spec + Figma + design review. Week 2: implementation + new tracking event + QA. Week 3: ship to 20%, wait for the cohort to season, analyze. By the time you know whether the shorter signup form moved D1, the cohort you wanted to save has been gone for two and a half weeks. You're permanently fighting the last war — with eighteen more experiments queued behind this one.

Duolingo runs hundreds of A/B tests a year. Netflix ships micro-experiments continuously. The gap isn't ideas — it's that they ship an experiment in a day and you ship one a month.

This is where tooling actually changed the math. Building in an AI-native stack like RapidNative means the guest-mode experiment above is a prompt — "make signup optional, add continue-as-guest, persist state locally" — with a working build on a real device via QR code in under a minute, instead of a sprint. When iteration cost collapses that far, the strategy flips: you stop hoarding experiments and start running them in parallel.

A weekly experiment cadence that actually compounds

If your iteration cost is low enough, this rhythm works:

Monday AM — pull last week's cohorts, segmented by channel and onboarding variant. Find the biggest first-session drop-off.
Monday PM — one hypothesis, one line: "changing X to Y improves D1 by Z% for cohort A."
Tuesday — build the variant.
Wednesday — ship to 50% of new installs.
Next Monday — cohort's seasoned. Ship the winner or kill it. Next experiment.

That's ~5 experiments a month, 60 a year. Even at a 1-in-5 hit rate you're compounding at a pace nobody on a three-week cycle can touch.

The bottom line

Retention in 2026 isn't a knowledge problem. The benchmarks are public and every founder can recite why users churn. The teams that win are the ones shipping retention experiments faster than their cohorts churn.

Stop asking "which tactic should we prioritize?" Start asking "what's the smallest experiment we can put in front of real users this week?"

What's your team's actual experiment cycle time — days or weeks? And what's the one onboarding change you've been meaning to test forever? Drop it in the comments, I'm curious what's stuck in everyone's backlog. 👇