DEV Community: Mark F A

The Non-Technical Founder's Guide to Mobile App Development in 2026

Mark F A — Mon, 31 Aug 2026 11:02:00 +0000

TL;DR

Four realistic paths in 2026: agency, freelancer, no-code platform, AI-native builder.
Agencies: $45,000–$150,000, 4–7 months. Freelancers: $15,000–$60,000, 2–5 months. No-code: cheap, but you hit a ceiling and never own code. AI-native: real React Native output, days not months.
Three decisions are yours before you hire anyone: cross-platform vs native, launch sequencing, and what you refuse to build in v1.
The 30-day playbook at the bottom assumes the AI-native path. Stretch it a lot for the others.

If you are the engineer someone is about to ask "can you build my app idea," this is the piece to send them. It is written for the founder, but the useful part for you is the section on what they should decide before they land in your inbox.

What actually changed between 2023 and 2026

Three things landed at once.

AI code generation crossed from demo to production output. Models now write React Native and Expo code that boots on TestFlight without a human rewriting it from scratch. Expo tooling (OTA updates, EAS Build, universal links) stopped requiring a senior mobile engineer to configure. And a category emerged between no-code and code generation: describe the app, real code comes out, you own it.

The consequence is that a solo non-technical founder can put a working iOS and Android app in front of paying users in days, on budgets that used to cover only design.

That does not kill the old paths. It means there are four, and picking wrong is the expensive part.

Path 1: agency

Brief them, they design and build, they hand over a codebase. Typically 4–7 months for an MVP. $45,000–$150,000 in 2026 for auth, a backend, and one core workflow. Higher in North America, lower with Eastern European or Latin American shops.

Real upside: polished output, they handle App Store submission, they own the responsibility for shipping. Real downside: you are the least-informed person in every technical meeting, change requests cost money, and if the agency wobbles at month four you are stuck.

Pick this when you have capital, a fixed deadline, and requirements that genuinely need five specialists.

Path 2: freelancer

A senior React Native freelancer runs $60–$120 per hour in the US, less abroad. A lean MVP is 200–500 hours, so $15,000–$60,000 depending on location and scope discipline.

This works when you find the right person. It also generates the most founder horror stories, because "the right person" is hard to source without a technical network, and if you cannot read code you will not find out you inherited a mess until you try to hand it to someone else.

Pick this if you have a specific recommendation, or a technical advisor who can review the code.

Path 3: no-code

Bubble, Adalo, Glide, FlutterFlow. Drag components, configure logic through visual rules. No code output. The app lives in the platform runtime permanently.

You can genuinely build with zero technical background. You also cannot leave without a rewrite, complex logic turns into nested visual conditions, performance trails a native app, and App Store rejections for wrapped apps keep happening.

Pick this if the app is genuinely simple (directory, form-heavy internal tool, booking flow) and will not scale past a few thousand users.

Path 4: AI-native builders

Describe the app in plain English, sketch it, or paste a PRD. An AI generates React Native and Expo code. You own it from day one, preview on your actual phone, and iterate by describing changes.

This is what broke the cost math. Tens of dollars in credits instead of tens of thousands in labor, and evenings instead of quarters. Because the output is standard React Native on Expo, if the thing takes off you hand it to an engineer and they extend it like any other project.

The trade-off is real: these tools are strongest on the common surface area (auth, lists, forms, media, standard navigation) and need human judgment for custom device APIs, complex real-time systems, and novel UI. For a first app, the common surface area is usually the entire product.

The cost table

Comparable MVP in every row: auth, a backend, one core workflow, shipped to iOS and Android. These are ranges, not quotes.

Path	Upfront	Time to v1	Ongoing/mo	Own the code
Agency	$45,000–$150,000	4–7 months	$0 (or retainer)	Yes
Freelancer	$15,000–$60,000	2–5 months	$0 (or hourly)	Yes
No-code	$0–$500	2–6 weeks	$50–$500	No
AI-native	$0–$200	1–5 days	$20–$100	Yes

The low numbers are not typos. An AI-native builder like RapidNative produces a functional MVP for the cost of dinner, because the labor cost collapsed. What still costs money is everything you did not write: $99/year Apple, $25 one-time Google, $0–$50/month backend at MVP scale on Supabase or similar, and paid acquisition.

The three decisions a founder should make before hiring anyone

Cross-platform vs native. Native means Swift plus Kotlin, two codebases, roughly double the cost. Cross-platform means one codebase on React Native or Flutter. In 2026 the answer for almost every startup is cross-platform. The performance gap has effectively closed for standard functionality, and Instagram, Discord, Shopify, and Coinbase all run significant parts of their mobile products on React Native. Legitimate reasons to go native: hardcore graphics, a platform feature with no wrapper yet, or a strategic showcase play. If someone tells a founder otherwise, ask them to name the specific device API they cannot reach.

Launch sequencing. Cross-platform gets you both stores, so this is mostly about order. TestFlight for iOS first, 20–50 users, tune the flow, then submit to both together. Apple's review is stricter, so clearing it early prevents a launch-day surprise.

What you refuse to build. The most valuable technical decision a non-technical founder makes is the cut list. The MVP should do one thing well enough that a user recommends it despite everything missing. If you can name three core workflows, you have too many. Push notifications, IAP, social login past Google and Apple, offline mode: all cheap in v2, all expensive forced into v1.

The 30-day playbook

Assumes the AI-native path. Stretch the timeline substantially for the others.

Days 1–3. One-page PRD: who is the user, what is the single workflow they will thank you for, what does month-one success look like. Show five potential users. Rewrite. Do not skip this.

Days 4–6. Feed the PRD in. Get the core workflow working end to end, polish absent. Test on your own phone via the preview QR. Click, describe the change, watch it happen.

Days 7–10. The unglamorous parts. Auth. Settings screen. Empty states. Error states. This is the difference between a demo and something that feels real.

Days 11–15. Ten people using it. Not user tests, actual usage. Watch them. Note every hesitation. Do not defend your app.

Days 16–20. TestFlight. Same ten plus twenty new ones from the target market.

Days 21–25. Fix the crashes, confusing flows, and typos TestFlight surfaces. Add nothing.

Days 26–30. Submit to both stores. Apple typically clears in under two days, Google is often same-day, both vary. Screenshots and the first line of the description carry most of the conversion weight.

The part engineers actually care about

The reason AI-native builders are worth taking seriously and no-code platforms mostly are not is portability. There is no proprietary runtime and no visual-logic language that exists inside one tool. The exported project is a normal Expo app. You can open it, read it, and extend it without a migration project.

That means the founder who shipped without you in month one is not handing you a rewrite in month six. They are handing you a codebase.

Which is a much better conversation to have.

If you have inherited an app a non-technical founder shipped solo, how did that handoff actually go? Curious whether the "no rewrite required" claim holds up in practice or whether you all have war stories. Drop them in the comments.

Reanimated vs Moti vs Skia: stop picking one

Mark F A — Mon, 31 Aug 2026 11:01:49 +0000

TL;DR

Reanimated runs animation math on the UI thread via worklets. It is the foundation, and you will end up with it installed regardless.
Moti is a declarative wrapper over Reanimated with a Framer Motion-style API. Great for enter/exit, skeletons, staggered lists.
Skia is Shopify's binding to Google's 2D graphics engine. Paths, shaders, blurs. Not an animation library.
These are not competitors. They are three layers of one stack, and most production apps use at least two.
Skia props accept Reanimated shared values directly, with no wrapper component. That single fact is why the combination is everywhere.

The framing problem

Every "X vs Y vs Z" post assumes you are picking one. With these three that assumption is wrong, and it produces two specific failure modes: teams that write 40 lines of Reanimated hooks to fade in a card, and teams that reach for Moti on a pan gesture and then cannot bind it to anything.

Here is what each one actually is at the runtime level.

Reanimated: worklets on the UI thread

Animations that run on the JS thread stutter whenever your app does work. Parsing JSON, rendering a list, handling touch. Reanimated moves the math onto the UI thread using worklets, small JS functions the runtime serializes and executes natively through JSI.

Three pieces:

import Animated, {
  useSharedValue,
  useAnimatedStyle,
  withSpring,
} from 'react-native-reanimated';

function Card() {
  const offset = useSharedValue(0);

  const style = useAnimatedStyle(() => ({
    transform: [{ translateX: offset.value }],
  }));

  return (
    <Animated.View style={style} onTouchEnd={() => (offset.value = withSpring(100))} />
  );
}

useSharedValue is a reactive primitive living on the UI thread, readable and writable from both sides. useAnimatedStyle is a worklet that re-runs whenever a shared value it reads changes. withTiming and withSpring drive the value over time.

Updates are scheduled against display frames rather than the JS event loop. That is why the animation stays smooth while your JS thread renders a 50-item list.

Wire it to a gesture and you get the thing Reanimated is actually for:

import { Gesture, GestureDetector } from 'react-native-gesture-handler';

const pan = Gesture.Pan().onChange((e) => {
  offset.value += e.changeX;
});

return (
  <GestureDetector gesture={pan}>
    <Animated.View style={style} />
  </GestureDetector>
);

No runOnJS, no bridge hop. The gesture callback is a worklet and it mutates a UI-thread value in the same frame.

The cost: ceremony. Shared values, worklet directives on nested functions, useAnimatedStyle for every animated view. It is more machinery than a fade-in deserves.

Moti: the same thing, four lines

<MotiView
  from={{ opacity: 0, translateY: 20 }}
  animate={{ opacity: 1, translateY: 0 }}
  exit={{ opacity: 0 }}
  transition={{ type: 'timing', duration: 300 }}
/>

Under the hood this is Reanimated. Same worklets, same UI-thread execution. You just never touch useSharedValue for the common cases. You also get AnimatePresence for exits, MotiText and MotiImage, a <Skeleton /> loader, and <Sequence /> for chaining.

Staggering a list is where the ergonomics really show:

{items.map((item, i) => (
  <MotiView
    key={item.id}
    from={{ opacity: 0, translateY: 12 }}
    animate={{ opacity: 1, translateY: 0 }}
    transition={{ delay: i * 50 }}
  />
))}

The cost: the moment you need a live gesture driving the animation, you drop back to raw Reanimated. There is no way to bind a MotiView prop to an ongoing pan translation. useDynamicAnimation exists, but using it puts you back in imperative code and the abstraction stops paying rent.

Skia: not an animation library at all

It is the 2D engine behind Chrome, Flutter, and Android's rendering pipeline, exposed to RN through a declarative component API. You use it for what the view tree cannot express: paths, SkSL shaders, blurs, blend modes, gradients beyond LinearGradient, text on curves.

The detail that matters for this comparison:

import { Canvas, Circle } from '@shopify/react-native-skia';
import { useSharedValue, withTiming } from 'react-native-reanimated';

const cx = useSharedValue(0);
cx.value = withTiming(200, { duration: 600 });

<Canvas style={{ flex: 1 }}>
  <Circle cx={cx} cy={100} r={40} color="hotpink" />
</Canvas>

Skia props accept Reanimated shared values directly. No createAnimatedComponent, no useAnimatedProps. The canvas re-renders on the UI thread as the value changes. That is the pattern under Victory Native XL, Reanimated Carousel, and basically every good animated chart in the ecosystem.

The cost: no Expo Go, so you need a dev client. Roughly 2 MB of native binary. And SkSL is its own idiom with a real learning curve.

Comparison

	Reanimated	Moti	Skia
Type	Animation runtime	Declarative wrapper	2D graphics engine
Runs on	UI thread (worklets)	UI thread (via Reanimated)	UI thread (JSI)
Best for	Gestures, sequences	Enter/exit, transitions	Drawings, shaders
Depends on	None	Reanimated 2/3/4	None
Approx. cost	~150 KB JS + native	~30 KB JS + Reanimated	~2 MB native binary
Expo Go	Yes (SDK 47+)	Yes	No, dev client
Maintainer	Software Mansion	Fernando Rojo	Shopify

What to reach for

Task	Library
Fade in a card on mount	Moti
Drive a value from a pan or pinch	Reanimated
Chain coordinated view animations	Moti
Animated chart with line and dots	Skia + Reanimated
Blur a background as a sheet drags up	Skia + Reanimated
Layout animation on list add/remove	Reanimated 4 `LinearTransition`
Skeleton loader while fetching	Moti `<Skeleton />`
Shader-based splash screen	Skia

The dependency graph makes composition cheap. Moti pulls in Reanimated, so the incremental cost of "adding" Reanimated once you have Moti is zero. Skia is the only real commit, and you pay for it once.

The performance thing nobody mentions

All three run on the UI thread over the same JSI bridge, so raw frame timing is comparable for comparable work. Where it actually breaks in production is almost never the library. It is this pattern:

// This will drop frames
const style = useAnimatedStyle(() => ({
  height: h.value,        // triggers layout every frame
}));

// This will not
const style = useAnimatedStyle(() => ({
  transform: [{ scaleY: h.value }],  // compositor only
}));

Animating a layout property schedules a layout pass on every frame and the "60fps animation" ends up queued behind it. All three libraries let you do this. If you are chasing a stutter, profile before you refactor.

What building an AI generator taught us

We build RapidNative, which turns natural-language prompts into React Native and Expo code. Picking the animation primitive without a human in the loop surfaced two things worth stealing.

Users never say "gesture." They say "make it feel snappy" or "add some polish." We default to Moti for appearance verbs (fade, slide, pop, stagger), escalate to Reanimated the moment a prompt implies user-driven motion (drag, swipe, pull to refresh, pinch), and only pull in Skia for charts, shaders, gradients, or explicitly artistic phrasing.

Composition beats picking a tool. The worst early bug was choosing one library per screen. A screen with a draggable card and an animated hero wants Reanimated for the drag and Moti for the hero. Separate concerns, separate primitives.

That generalizes past AI. Even when a human is choosing, the either/or framing costs you.

FAQ

Is Moti just Reanimated with less code? Mostly. Same worklets, same UI-thread execution, same shared values internally. Moti adds prop-based config, AnimatePresence, sequence orchestration, and prebuilt components.

Can I use Skia without Reanimated? Yes, for static scenes and animations driven by its own value primitives. Almost nobody does, because shared values are the standard driver everywhere else in the app.

Does Reanimated 4 replace Moti? No. The CSS-like syntax narrows the ergonomic gap, but AnimatePresence and the declarative prop API are still more concise for common transitions.

What about the built-in Animated API? Wrong default for new code. JS thread by default, useNativeDriver covers only a subset of transforms and opacity, verbose interpolation, painful gesture integration.

Bottom line

Install Reanimated and Moti. Leave Skia until the design brief demands it. If you are auditing an existing codebase, the two things you will find are Moti calls that should be Reanimated (wired to a gesture later, never rewritten) and Reanimated hooks that should be Moti (fading a card in, 30 unnecessary lines).

Pick the primitive per interaction, not per app.

What is your current animation stack, and have you hit the point where you needed to mix them? Drop a comment with what you are building.

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.

From Side Project to App Store: A Non-Technical Founder's Guide (2026)

Mark F A — Fri, 14 Aug 2026 06:59:12 +0000

TL;DR

The distance between "I have an app idea" and "it's live on the App Store" collapsed in 2026.
Stack: AI mobile app builder producing real exportable React Native code, Supabase for data, TestFlight and Play Internal Testing for QA, self-submission to both stores.
Validate with 10 real interviews and a landing page before you build anything.
Budget one week for submission. Most rejections are mechanical: privacy label mismatches, placeholder content, first-minute crashes.
Retention beats downloads. Day 30 above 20% means you have something.

Somewhere between 70 and 80 percent of side projects never leave a Notion doc. Not because the ideas are bad. Because the distance between "I have an idea for an app" and "my app is live on the App Store" has always been enormous for anyone who can't code. Hiring a developer costs $20,000 to $80,000. Learning React Native takes six months. Cloning boilerplate templates leaves you stuck the moment you want anything custom.

That distance collapsed in 2026. A non-technical founder can now go from a napkin sketch to a live App Store listing in a matter of weeks, working alone, without writing a line of code, and without shipping a fragile prototype held together with duct tape.

The stack has finally shifted

What is the fastest way for a non-technical founder to build a mobile app in 2026? Use an AI mobile app builder to generate production-ready React Native code from a prompt, sketch, or PRD; back it with a managed database like Supabase; test with TestFlight and Google Play Internal Testing; and submit to both stores yourself. The whole cycle takes weeks, not months, and the code you own is real code, not a walled-garden template.

The old paths were expensive, slow, or extractive. Hire an agency and you were out $30k before a single user tapped the icon. Hire a "technical co-founder" and you gave away 40% of your company for someone who could've been replaced by tooling that didn't exist yet. Learn to code and you spent your first year fighting Xcode installation errors instead of talking to users.

The new stack does three things the old one couldn't:

Generates working, exportable code. React Native and Expo apps you can own, edit, and ship, not throwaway prototypes.
Handles the full stack. Screens, navigation, forms, auth, database, and API integration from one generation pipeline.
Runs a real preview. Hold your phone up to a QR code and use your app on iOS the same day you started.

The bottleneck used to be code. Now the bottleneck is your ability to make product decisions, which is exactly the work a founder should be doing.

Phase 1: Validate without writing a line of code

One to two weeks. Three artifacts: a landing page with a signup form, 10 completed user interviews, and a written product spec.

The 10-user test. Pick 10 people who would actually pay for or use your app. Not friends. Not "the whole world." Ten specific humans. Ask them: "Walk me through the last time you tried to solve [problem]. What did you use? What did you hate about it?" If you can't find 10 people who describe the problem the same way you do, you don't have a product. You have a hunch.

Landing page and waitlist. Spin up a one-pager on Framer, Carrd, or Webflow. Value prop, three screenshots (mock them in Figma if you have to), and a "get early access" form. Push it in one Slack community, one subreddit, and one Twitter thread. If nobody signs up, that's your answer.

Write a real PRD. Not a novel. One page listing: the target user, the top three screens, the data each screen shows, the actions the user can take, and what happens after each action. This becomes the input for the next phase.

Phase 2: Build the first working version

This is where non-technical founders used to get stuck for six months. Now it takes days.

Open an AI mobile app builder. Describe your app in plain English: "A workout tracker where users log sets and reps, see weekly volume, and get streak badges." Watch it generate a working Expo app with screens, navigation, forms, and a database schema. Scan the QR code with your phone. Use the app. Notice five things you want to change. Describe them. Regenerate. Done in an afternoon what would have taken a contractor a month.

Under the hood, the good builders run a multi-step pipeline: interpret the prompt, plan a component tree, generate React Native code, wire up state with Redux or Context, apply theming with NativeWind, and stream the result into a live preview you can interact with in real time. You don't need to know any of that, but knowing it exists is what separates "toy prototype" from "actual app I can submit to Apple."

Four input modes are worth knowing about:

Mode	What it does	Best for
Prompt to app	Describe it, get it	Founders who know what they want
Sketch to app	Draw wireframes, get working screens	Ideas more visual than verbal
PRD to app	Paste your spec, get a full prototype	Founders who already wrote the doc
Screenshot to app	Upload a UX you like, generate something similar	Cloning proven patterns

RapidNative supports all four and exports a real Expo project. Pick the mode that matches how the idea actually lives in your head.

The trick in this phase is ruthless scope-cutting. Every non-technical founder wants push notifications, in-app purchases, social login, offline mode, and dark mode on day one. Build none of that. Notifications and IAP are two-week rabbit holes each, and every screen you add is a screen you'll redesign after your first ten users.

Phase 3: Test on TestFlight and Play Internal Testing

Most founders skip this. Don't. A demo in the simulator is not a real test.

Apple TestFlight. Free, ships from your Apple Developer account, distributes to up to 10,000 external testers via email or a public link. Upload a build (EAS handles this), fill out a short test information form, invite testers. Apple runs a brief review on your first build, usually under 24 hours. After that, updates are near-instant.

Google Play Internal Testing. Also free, ships from Play Console, supports up to 100 internal testers, distributed by Google account email. More forms than Apple up front, but review is essentially zero. Internal builds go live within minutes.

Send invites to your 10 interviewees from Phase 1. After a week of use, ask each of them: What did you use it for? What was confusing? Would you pay $5/month for this?

Instrument analytics before you send it out. Expo has PostHog and Mixpanel SDKs that take five minutes to integrate. You want to know which screens users open, where they drop off, and how long sessions last. This data is worth ten times what people tell you in interviews.

Phase 4: The submission gauntlet

The phase founders fear most and, frankly, the one that trips them up least. Budget one week for both stores.

Apple App Store

Apple Developer Program: $99/year. Individual account is fine to start.
App Store Connect listing: name (30 chars), subtitle (30 chars), keywords (100 chars, comma-separated, invisible to users), description, screenshots (6.7" and 6.5" iPhone minimum), promotional text, support URL, privacy policy URL.
Privacy nutrition label: declare what data you collect, what links to the user, and what's used for tracking. This is the #1 rejection reason for solo founders.
App Tracking Transparency: required if you use third-party analytics that fingerprints devices.
Review time: around 24 hours for 90% of submissions in 2026. Complex or first-time submissions can take 2–4 days.

Google Play Store

Developer account: $25 one-time.
Play Console listing: title (30 chars), short description (80 chars), full description (4000 chars), feature graphic, screenshots, category, content rating questionnaire.
Data Safety form: Google's equivalent of Apple's privacy label. Mismatches with actual behavior get apps pulled later.
Target API level: last two API levels required. Modern Expo apps handle this automatically.
Review time: a few hours to a couple of days for new apps, faster for updates.

Three most common rejections for solo-founder apps: placeholder content still visible ("Lorem ipsum" screens are an instant reject), crashes in the first minute, and misleading metadata. Ship a build you've used yourself for a full week.

Your builder should export a complete Expo project you can submit yourself with EAS or hand to a developer for final packaging. This is where owning real, exportable code matters. You're not trapped inside a proprietary builder that can't produce an actual .ipa or .aab.

Phase 5: Launch and beyond

Getting into the store is not the launch. It's the starting line.

Soft launch first. Go live in one small market (Canada and Australia are common) for two weeks before opening globally. Watch crash rates, retention, and reviews. Fix what breaks. Then flip the geo restriction off.

Pick one launch channel and go deep. Product Hunt, a niche subreddit, an X thread, or an outreach email to 50 users. Not all four in the same day. Product Hunt in particular rewards launches that already have engagement, so warm your list before you post.

Instrument retention, not vanity metrics. Downloads are meaningless. Day 1, Day 7, and Day 30 retention are the numbers that matter. Day 30 above 20% for a consumer app means you have something worth pushing. Below 10% and you iterate on the product, not the marketing.

Iterate fast. Every piece of feedback becomes a prompt. "The signup flow is confusing" becomes a two-minute edit and a new build on TestFlight the same afternoon. Founders who take a week to ship a fix lose to founders who take two hours.

ASO basics. Optimize your app name and subtitle around one high-intent keyword each. Use all 100 characters of the App Store keyword field. Ship screenshots that show the value in the first two frames, since that's what users see on the search page.

Five pitfalls to avoid

Building too much before showing anyone. Every screen you build without a user in front of it is a screen you'll rebuild. Ship five screens to ten users before you build the sixth.
Ignoring review guidelines. Read them once before you submit. The mechanical rejections (privacy label mismatches, missing account-deletion flow, sign-in-with-Apple requirement when you have social login) are easy to avoid and painful to hit.
No maintenance plan. Apple and Google both push OS updates yearly. If you can't ship at least one build every 6 months, your app will start breaking. A maintenance update in 2026 is a 30-minute regeneration, not a week of contractor work.
Undervaluing yourself on price. Free apps monetize on scale you don't have yet. $4.99/month or $29/year is a common indie starting price and it filters out users who were never going to convert.
Skipping the legal basics. Both stores require a privacy policy URL. Termly or Iubenda cost $10–$20 and take 15 minutes. Do it before you submit, not after.

What shipping alone actually looks like now

The old founder journey: idea, then learn to code or raise money or find a co-founder, then build for a year, then ship a bad version, then run out of runway.

The new one: idea, validate in a week, build in a week, test in two weeks, submit in a week, iterate forever. The whole cycle from opening a browser to a live App Store listing can compress into a single month.

You still need judgement: what to build, what to cut, who to talk to, how to price. Those are the parts that make you a founder. Everything else has become tooling.

What phase are you stuck in right now? Validation, building, testing, or submission? Drop it in the comments. Curious how many of you are sitting on a Notion doc that's been there over a year.

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.

React Native Authentication in 2026: The Refresh-Token Pattern That Actually Scales

Mark F A — Wed, 12 Aug 2026 06:03:55 +0000

TL;DR

Access token in memory, refresh token in expo-secure-store. AsyncStorage is plaintext on disk. Stop using it for credentials.
Access token: 15 minutes. Refresh token: 30 days. Different signing secrets. The split is about blast radius.
One singleton refreshPromise stops five concurrent 401s from firing five refresh calls (four of which will fail once rotation kicks in).
Always pass an explicit keychainService. Omit it and users get logged out after every TestFlight update, iOS only.
Total cost: roughly 200 lines of app code, no managed auth vendor required.

Most React Native auth tutorials show you how to log a user in. Almost none of them show you how the app behaves at 3 AM when five in-flight requests all hit an expired token at the same time, or how your carefully-stored token silently disappears after a TestFlight update. This post is the pattern that survived three production apps.

Why most tutorials fail

You've seen this pattern a hundred times:

const token = await AsyncStorage.getItem('access_token');
fetch(url, { headers: { Authorization: `Bearer ${token}` } });

Three problems compound in production:

AsyncStorage is not secure. It's plaintext on disk. Any process that can read your app's sandbox can read the token.
No refresh handling. The token expires, users get 401s, and your fix is "log them out and back in." That's a leaky bucket.
Race conditions on refresh. When multiple requests fire while the token is expiring, they all try to refresh at once and only one wins.

The pattern below solves all three.

The two-token model

Issue two tokens from your API on login:

Access token: short-lived (15 minutes), signed with ACCESS_SECRET. Sent with every authenticated request.
Refresh token: long-lived (30 days), signed with a different REFRESH_SECRET. Used only to mint new access tokens.

The point of the split is blast radius. If your access token leaks (network sniffer, log line), the attacker has 15 minutes. The refresh token never leaves the keychain.

Where to store each token

The rule that took me two apps to internalize:

Access token → in-memory only. A module-level variable. It dies with the JS bundle. That's fine. The app will refresh from disk if needed.
Refresh token → expo-secure-store. Backed by iOS Keychain / Android Keystore. Never AsyncStorage.

// tokens.js
import * as SecureStore from 'expo-secure-store';

let accessToken = null;

export const getAccessToken = () => accessToken;
export const setAccessToken = (t) => { accessToken = t; };

export const getRefreshToken = () =>
  SecureStore.getItemAsync('refresh_token', {
    keychainAccessible: SecureStore.WHEN_UNLOCKED_THIS_DEVICE_ONLY,
    keychainService: 'com.yourcompany.yourapp.auth',
  });

export const setRefreshToken = (t) =>
  SecureStore.setItemAsync('refresh_token', t, {
    keychainAccessible: SecureStore.WHEN_UNLOCKED_THIS_DEVICE_ONLY,
    keychainService: 'com.yourcompany.yourapp.auth',
  });

The two options on SecureStore matter:

WHEN_UNLOCKED_THIS_DEVICE_ONLY: the token is gone if the device is restored onto a new device. Prevents session cloning.
Explicit keychainService: survives TestFlight builds (more on this below).

The refresh middleware pattern

Wrap every authenticated fetch in a middleware that handles 401s transparently:

// authFetch.js
import {
  getAccessToken,
  setAccessToken,
  getRefreshToken,
  setRefreshToken,
} from './tokens';

const API = 'https://your-api.com';
let refreshPromise = null;

async function performRefresh() {
  const rt = await getRefreshToken();
  if (!rt) throw new Error('NO_REFRESH_TOKEN');

  const r = await fetch(`${API}/auth/refresh`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ refresh_token: rt }),
  });

  if (!r.ok) {
    // Refresh token invalid, user must log in again
    await setRefreshToken('');
    setAccessToken(null);
    throw new Error('REFRESH_FAILED');
  }

  const { access_token, refresh_token } = await r.json();
  setAccessToken(access_token);
  await setRefreshToken(refresh_token); // rotation: new RT every refresh
  return access_token;
}

export async function authFetch(url, opts = {}) {
  const doRequest = async () => {
    const headers = {
      ...(opts.headers || {}),
      Authorization: `Bearer ${getAccessToken()}`,
    };
    return fetch(url, { ...opts, headers });
  };

  let response = await doRequest();

  if (response.status === 401) {
    if (!refreshPromise) {
      refreshPromise = performRefresh().finally(() => {
        refreshPromise = null;
      });
    }
    await refreshPromise; // all in-flight 401'd requests await the same refresh
    response = await doRequest();
  }

  return response;
}

The singleton refreshPromise is the piece most tutorials miss. Without it, five concurrent requests hitting an expired token cause five refresh calls. Four of them will 401, because the refresh-token rotation on the first call already invalidated the shared refresh token.

TestFlight and iOS keychain: the accessGroup trap

Here's a bug I've watched three teams hit:

"Users are getting logged out after every TestFlight update, but only on iOS."

The cause: iOS keychain items are scoped by accessGroup. When TestFlight installs a new build, it may preserve keychain access, but only if the keychainService string is consistent across builds. If your code omits keychainService, expo-secure-store generates a random-ish default that changes across builds.

Fix: always pass an explicit keychainService (as in the tokens.js above). Once set, it survives TestFlight promotions, production releases, and version bumps.

While you're at it, add a startup check that re-validates the token against your API:

export async function bootstrapAuth() {
  if (!(await getRefreshToken())) return { authenticated: false };

  try {
    // Try any authenticated endpoint that returns quickly
    const r = await authFetch(`${API}/me`);
    if (r.ok) return { authenticated: true, user: await r.json() };
    return { authenticated: false };
  } catch {
    return { authenticated: false };
  }
}

This way a truly-invalidated session (user was banned server-side, refresh token was revoked) doesn't sit stale in the app UI.

Anti-patterns

Stop doing these:

Storing tokens in AsyncStorage. It's not encrypted. On Android it's SharedPreferences XML, readable with adb.
Bearer tokens in URL query strings. They end up in server logs, analytics captures, and browser history.
A single fetch wrapper per API call. You'll forget one, and that endpoint will silently break auth. Wrap it once at the module level.
Manual logout that only clears the access token. If the refresh token is still in the keychain, the next bootstrapAuth() re-authenticates the user.
Refresh-token rotation without server-side invalidation. If your API doesn't invalidate the old refresh token on rotation, an attacker who steals it can refresh indefinitely.

What to ship first

If you're starting from a fresh React Native app:

Set up the two-token model in your API. djangorestframework-simplejwt, or jose for Node, both handle rotation out of the box.
Copy the tokens.js and authFetch.js above.
Call bootstrapAuth() in your root component's useEffect(() => {}, []).
Add a global 401 → redirect-to-login handler for the terminal case (refresh token invalid).

That's roughly 200 lines of app code. It'll outlive whichever managed auth service you were considering, and the security posture is stricter than most of them. If you'd rather not wire it by hand, RapidNative scaffolds Expo apps with this pattern preconfigured, though the pattern itself is straightforward enough that most teams should own it.

The 2026 React Native Performance Playbook (New Arch, FlashList, Reanimated 4)

Mark F A — Mon, 10 Aug 2026 07:01:59 +0000

TL;DR

Measure first. A before number and an after number in every PR beats every trick in this post.
Turn on the New Architecture. Biggest single win available: ~40% faster cold start, 35 to 43% faster list rendering, ~25% lower memory.
Confirm Hermes is on in your release build, not just dev, and upload your source maps.
Swap FlatList for FlashList past ~50 items.
Every animation goes to Reanimated 4 worklets. No exceptions.
Put a budget in CI with Flashlight so regressions break the build instead of your App Store rating.

Most React Native apps do not need more code to feel fast. They need less of the wrong code, in the right places.

The platform moved. New Architecture is default. Hermes is default. FlashList is stable. Reanimated 4 is stable. So the advice you memorized in 2022 (memoize everything, throw shouldComponentUpdate at every list item, dread the bridge) is now either handled for you or actively counterproductive.

This is the current playbook, ordered by impact. It assumes one thing: you measured the problem before you changed any code.

What "fast" actually means

"It feels slow" is not a spec. On a mid-tier Android device (Pixel 6a, Samsung A34), a shippable app in 2026 hits:

Metric	Target
Cold start (Android)	Under 2.0s, tap to first interactive frame
Cold start (iPhone 13)	Under 1.2s
Sustained scroll	58+ fps on 500+ item lists with images
Interaction latency	Under 100ms, touch to visible state change
JS heap	Under 180MB, no monotonic growth over 10 min
Install size	Under 30MB base binary, App Store thin variant

If you cannot state your current numbers against these, that is the first fix.

1. Profile first, stop guessing

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

Hermes Sampling Profiler. Ships with RN, near-zero overhead, flame graphs open in Chrome DevTools or Perfetto. Start here every time.
React DevTools Profiler. Commit-by-commit view of what rendered and why. The "Highlight updates when components render" toggle finds re-render storms in about ten seconds.
Flashlight. CLI for FPS, CPU, memory and JS thread health during scripted runs. Puts real numbers on regressions.
Perfetto (Android) / Instruments (iOS). For anything crossing the native boundary: cold start, module init, layout, gestures.
Expo's perf inspector. FPS meter and JS heap sampler in the dev menu. Good enough for 80% of day-to-day work.

The rule that matters more than any tool: before number, after number, both in the PR description. No numbers, no merge. This single policy will make your app faster than any optimization on this list.

2. Be on the New Architecture

RN 0.76 made it the default. Expo SDK 52 followed. If you are still opted out you are leaving 30 to 40% of your cold start and roughly all of your bridge overhead on the table.

Three pieces:

JSI replaces the async JSON bridge with direct synchronous calls. Serialize, queue, deserialize, return, deserialize is now a function pointer.
Fabric is the new renderer. Concurrent-aware, layout on the UI thread, no more commit storms during scroll-plus-fetch.
TurboModules load lazily on first use. That alone can shave 200 to 400ms off cold start in apps with a lot of linked modules.

Enabling it is a flag:

// app.json (Expo)
{
  "expo": {
    "newArchEnabled": true
  }
}

# gradle.properties (bare)
newArchEnabled=true

// ios/Podfile.properties.json (bare)
{
  "newArchEnabled": "true"
}

What breaks is third-party native modules that never got upgraded. Check each dependency's issue tracker before you flip it.

Teams that finished the migration in 2025 consistently report cold start down ~40%, list rendering up ~35 to 43%, memory down ~25%, and frame rates going from the high 40s to a steady 58 to 59 fps. That is not incremental. It is the largest performance change RN has ever shipped.

3. Hermes is default, so do not break it

Hermes is the engine on both platforms now. The value is not just runtime speed, it is ahead-of-time bytecode compilation at build time. You ship precompiled bytecode instead of raw JS, which is why cold starts land 20 to 40% ahead of JSC.

Three things to actually do:

Confirm Hermes is on in release, not just dev. Easy to miss when migrating off JSC. hermesEnabled=true in gradle.properties, :hermes_enabled => true in the Podfile, or the Expo equivalent.
Precompile bytecode in CI so it is baked at build time instead of first launch on device.
Upload your source maps. Hermes bytecode makes Sentry and Bugsnag stack traces unreadable without them. This is the footgun that bites teams in production, every time.

You do not need to tune the engine. You just need to not accidentally disable it.

4. FlashList for every list that matters

FlatList is fine for short lists. Past ~50 items, images, or variable row heights, use FlashList. This is the highest-leverage optimization that requires you to write actual code.

FlashList recycles cells instead of unmounting them and does not allocate a new view per item. On a Pixel 6a with 1,000 image-plus-text rows:

	FlatList	FlashList
Sustained FPS	30 to 40, with freezes	58 to 60
Cell handling	Unmount and remount	Recycled
Views allocated	One per item	Pooled

import { FlashList } from "@shopify/flash-list";

const Row = React.memo(({ item, onPress }) => (
  <Pressable onPress={onPress} style={styles.row}>
    <FastImage source={{ uri: item.thumb }} style={styles.thumb} />
    <Text style={styles.title}>{item.title}</Text>
  </Pressable>
));

export function Feed({ data, onSelect }) {
  return (
    <FlashList
      data={data}
      estimatedItemSize={88}
      keyExtractor={(item) => item.id}
      renderItem={({ item }) => <Row item={item} onPress={onSelect} />}
    />
  );
}

Two rules to actually get the speedup:

Set estimatedItemSize. Off by 30% and you still get most of the win. Missing entirely and FlashList falls back to slow measurement passes.
No dynamic per-item work inside renderItem closures. Memoize row components and their handlers.

Variable heights you cannot estimate? Use the median. Do not overthink it.

5. Kill re-renders, but only the ones that matter

Re-renders are the most over-optimized problem in React Native. Wrapping everything in React.memo bloats your bundle and slows mounting. Profile first, memoize where the profiler shows a hot path.

That said, four anti-patterns cause 80%+ of real re-render bugs.

Inline object props. New object identity every parent render, which invalidates every downstream React.memo.

// Bad
<Card style={{ margin: 8 }} />

// Good
const styles = StyleSheet.create({ card: { margin: 8 } });
<Card style={styles.card} />

Inline handler props. <Button onPress={() => doThing(id)} /> is a new function every render. useCallback, or better, move the handler into a memoized child that owns the id.

Context provider sprawl. Every value change re-renders every consumer. Split by update frequency: identity (rare), theme (rare), live data (constant). Do not put them in one provider.

Selector reference issues. Redux/Zustand selectors returning fresh object references re-render every consumer even when values are identical.

// Bad: new object every store update
const { name, avatar } = useStore((s) => ({ name: s.name, avatar: s.avatar }));

// Good
import { useShallow } from "zustand/react/shallow";
const { name, avatar } = useStore(
  useShallow((s) => ({ name: s.name, avatar: s.avatar }))
);

why-did-you-render is still the fastest way to find these in dev.

6. Get animations off the JS thread

An animation on the JS thread drops frames the moment JS is busy, which is always, because JS is where your business logic lives.

Reanimated 4 for state, gesture, or timing driven animation. Worklets run on the UI thread as native functions. A 60fps spring stays at 60fps while the JS thread parses a 500KB JSON response.
Gesture Handler for drags, swipes, pinches. PanResponder is JS-thread-bound and will jank.
Skia for anything painterly: charts, custom drawing, complex transitions. Bypasses the React view tree, renders straight to a GPU canvas.

If you are writing Animated.Value with useNativeDriver: false, stop. Convert it, or find out why useNativeDriver: true is not an option (usually it is a prop Reanimated supports and old Animated does not).

7. Cold start, the number users actually notice

Native init + bundle load + bundle execute + first render. Also the metric App Store reviewers judge you on. In order of impact:

New Architecture on. Biggest win.
Hermes bytecode precompiled. Second biggest.
Bundle size. Every 100KB of JS costs 20 to 40ms of parse-plus-execute on mid-tier Android. Run npx react-native-bundle-visualizer and delete what surprises you. moment.js, full lodash, and five date-picker libraries you forgot about are the usual suspects.
Lazy-load routes. React.lazy + Suspense at route boundaries. Your login screen does not need to parse the dashboard's 400KB.
Native module audit. Every linked module runs init at startup. Removing the JS import does not unlink the native code.
Font loading. Preload only the weights on the first screen. Font.loadAsync for 12 weights blocks first paint for hundreds of ms.
Splash strategy. Hold the native splash until the first interactive screen is ready. Cross-fade early and you get a flash of empty content.

Instrument with AppRegistry.setWrapperComponentProvider plus a manual mark at first meaningful paint, log to analytics, and watch the median. Not the mean. The mean lies.

8. Memory, the silent killer

Leaks rarely crash a React Native app. They just make it slower, and slower, until the OS kills it in the background and the user thinks "the app forgot me." Three sources cover nearly every leak in the wild:

Uncleaned listeners. Every addEventListener, subscribe, and AppState handler needs cleanup in the useEffect return. exhaustive-deps will not catch these.
Unbounded image cache. react-native-fast-image caches aggressively. Set a maxMemoryPolicy or hold hundreds of MB of thumbnails.
Uncleared timers. setInterval in a component that mounts and unmounts on navigation is the classic.

useEffect(() => {
  const sub = AppState.addEventListener("change", onChange);
  const id = setInterval(poll, 5000);
  return () => {
    sub.remove();
    clearInterval(id);
  };
}, [onChange, poll]);

Heap snapshot at 10 minutes, another at 30, compare. Delta not roughly flat means you have a leak. Instruments Allocations on iOS, Android Studio Memory Profiler on Android.

9. Network, the invisible half of "fast"

Users do not distinguish "the app is slow" from "the network is slow." Hide the network from them.

TanStack Query for every fetch with a cache key. Dedup, background refetch, stale-while-revalidate for free. The single library that most improved perceived RN performance in the last two years.
HTTP/2 or HTTP/3. On HTTP/1.1 you pay a full round trip per request. Cloudflare, Fastly, AWS ALB all default to HTTP/2 now.
Image CDN with responsive sizing. Serve 400x400 to a phone, not 4000x4000.
Promise.all for anything that does not depend on a previous result.
Optimistic updates for any action that succeeds 99% of the time. Users feel every millisecond of spinner.

10. Ship a performance budget in CI

All of the above is worthless if someone ships a regression next Tuesday.

Flashlight runs a scripted E2E test on a real or emulated Android device, records CPU/FPS/memory, and fails the build when a metric exceeds budget. Point it at five flows (cold start, login, main list scroll, detail view, checkout), set budgets 10 to 20% above current numbers, and now the regression conversation happens in code review instead of in your App Store reviews six weeks later.

When NOT to optimize

The profiler shows no hotspot. You are not fixing anything, you are writing code.
The user cannot perceive it. Nobody notices 12ms to 8ms on a screen already at 60fps. They notice 30fps to 60fps.
It removes a real feature. Slower with the feature beats faster without it, unless the feature is optional.

Where AI-generated code fits

Here is the part that surprised me. Generating a React Native project with an AI builder like RapidNative now gives you the New Architecture enabled, Hermes on, FlashList on meaningful lists, Reanimated wired up, and TanStack Query for data, because those are the current defaults and the model trained on the current stack. Steps 2, 3, 4 and 6 of this playbook come pre-done.

What it cannot do is your measurement work. It does not know your product screen renders 400 image cards and needs a memoized row, or that your context provider grew three orders of magnitude too much state. You get the correct baseline for free. The profiling and tuning is still yours.

So the fast path in 2026: generate the correct baseline, ship v1, measure real user performance, apply this playbook to whatever the profiler actually flags. Skip the six weeks of boilerplate and spend them on the parts of the app only you understand.

What is the biggest perf win you have shipped this year? Drop it in the comments, especially the ones that surprised you after profiling. I want to know which of these ten actually moved your numbers and which did nothing.

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.

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.

DEV Community: Mark F A

The Non-Technical Founder's Guide to Mobile App Development in 2026

TL;DR

What actually changed between 2023 and 2026

Path 1: agency

Path 2: freelancer

Path 3: no-code

Path 4: AI-native builders

The cost table

The three decisions a founder should make before hiring anyone

The 30-day playbook

The part engineers actually care about

Reanimated vs Moti vs Skia: stop picking one

TL;DR

The framing problem

Reanimated: worklets on the UI thread

Moti: the same thing, four lines

Skia: not an animation library at all

Comparison

What to reach for

The performance thing nobody mentions

What building an AI generator taught us

FAQ

Bottom line

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

TL;DR

What "push notifications" actually means

The 2026 landscape: which library

Installing and configuring

Requesting permission the right way

Where to go next

From Side Project to App Store: A Non-Technical Founder's Guide (2026)

TL;DR

The stack has finally shifted

Phase 1: Validate without writing a line of code

Phase 2: Build the first working version

Phase 3: Test on TestFlight and Play Internal Testing

Phase 4: The submission gauntlet

Apple App Store

Google Play Store

Phase 5: Launch and beyond

Five pitfalls to avoid

What shipping alone actually looks like now

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

TL;DR

What "HIPAA-compliant" actually means

The three rules that shape your architecture

The 6 technical requirements that actually matter

The vendor stack that will actually sign a BAA

Can you use LLMs with PHI?

The build checklist

What it costs and how long it takes

FAQ

The part most teams get wrong

React Native Authentication in 2026: The Refresh-Token Pattern That Actually Scales

TL;DR

Why most tutorials fail

The two-token model

Where to store each token

The refresh middleware pattern

TestFlight and iOS keychain: the accessGroup trap

Anti-patterns

What to ship first

Related patterns worth reading

The 2026 React Native Performance Playbook (New Arch, FlashList, Reanimated 4)

TL;DR

What "fast" actually means

1. Profile first, stop guessing

2. Be on the New Architecture

3. Hermes is default, so do not break it

4. FlashList for every list that matters

5. Kill re-renders, but only the ones that matter

6. Get animations off the JS thread

7. Cold start, the number users actually notice

8. Memory, the silent killer

9. Network, the invisible half of "fast"

10. Ship a performance budget in CI

When NOT to optimize

Where AI-generated code fits

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