DEV Community: Hugo Rus

Mobile App Development Platform (MADP): The 2026 Guide

Hugo Rus — Mon, 02 Nov 2026 05:56:32 +0000

Originally published at rapidnative.com by Sanket Sahu.

What a mobile app development platform is, how the category went from MEAP to MADP to low-code to AI, and the eight questions that separate a good platform from an expensive detour.

If you have ever sat through an enterprise software review, you have heard someone ask which mobile app development platform the company should standardize on. The question sounds simple. The answers rarely are, because the category has been renamed four times in fifteen years, and the tools sold under the label range from visual workflow builders to raw frameworks to, now, AI that writes the whole app from a paragraph of text.

This guide untangles it. It covers what a mobile app development platform (MADP) actually is, where the term came from, the five kinds of platforms you will meet in 2026, and the questions that tell a good one from an expensive detour. We build RapidNative, an AI mobile app builder, so we have a point of view, and we will be clear about where it fits and where it doesn't.

What is a mobile app development platform?

A mobile app development platform (MADP) is a set of tools and services for designing, building, testing, publishing and maintaining mobile apps for iOS and Android from one place. A typical MADP combines a front-end builder or framework, backend services, integrations with existing systems, security controls, and a way to distribute and update apps once they are in people's hands.

The key word is platform. A framework like React Native or Flutter is one ingredient. A platform wraps the ingredients into a lifecycle: you start a project, connect data, give it to testers, ship it to the App Store and Google Play (or to employees' managed devices), and keep it updated, without assembling a dozen separate products yourself.

From MEAP to MADP to MXDP to LCAP: a short history

Most of the vocabulary comes from analyst firms, chiefly Gartner, whose Magic Quadrant reports shaped how enterprises shopped for mobile tools. The names changed as the market did.

Era	Term	What it described
2008 to early 2010s	MEAP, mobile enterprise application platform	Middleware and tools to build and run internal apps for employees, often across BlackBerry, Windows Mobile and early iPhone
Around 2010	MCAP, mobile consumer application platform	The customer-facing sibling of MEAP, a short-lived separate category
2012 to 2018	MADP, mobile app development platform	One category for employee and customer apps, as smartphones went mainstream
2019 to early 2020s	MXDP, multiexperience development platform	Apps across mobile, web, wearables, chat and voice from one toolset
2019 onward	LCAP, enterprise low-code application platform	Visual, model-driven platforms where mobile is one output among many
2023 onward	AI app builders	Platforms that generate the app from natural language

A few details are worth knowing. Gartner coined MEAP in a 2008 Magic Quadrant, along with a "rule of three": a MEAP made sense once a company had three or more mobile apps, three or more mobile operating systems, or three or more backend systems to connect. The category was later renamed MADP to reflect that mobile had gone mainstream. In July 2019 Gartner published its first Magic Quadrant for Multiexperience Development Platforms, which superseded the MADP report. Its leaders were mostly low-code vendors: OutSystems, Mendix, Salesforce, Oracle, Progress and Kony.

The vendors themselves moved too. Kony was acquired by Temenos in 2019, and its non-banking platform was licensed to HCL and relaunched as HCL Volt MX. OutSystems bought Ionic, the team behind Capacitor. Today most of the old MADP leaders are evaluated as enterprise low-code platforms, and "MADP" survives mainly as a search term and an RFP line item. That is useful to know: when someone asks you for a MADP, they usually mean "one supported way to build our mobile apps", not a specific product category.

What a mobile app development platform includes

Whatever the label, buyers expect a MADP to cover the full lifecycle of an app. In practice that breaks into six layers.

Front-end development. How screens get built: visual drag and drop, a code framework, generated code, or a mix. This decides how the app looks and feels and how fast your team can change it.
Backend services. Data storage, sign-in, file storage, push notifications and realtime updates, often called mobile backend as a service (MBaaS). Some platforms bundle their own; others connect to Firebase, Supabase or your existing APIs.
Integration. Connectors to the systems an enterprise already runs: identity providers, ERP and CRM, internal REST or GraphQL APIs.
Security and management. Single sign-on, role-based access, data encryption, and support for mobile device management (MDM) or mobile application management (MAM) so IT can control company data on phones.
Testing and distribution. Previewing on real devices, beta testing, and publishing to the App Store and Google Play, or privately to employees through Apple Business Manager and managed Google Play.
Lifecycle and updates. Over-the-air updates, crash reporting, analytics, and a way to keep the app current as iOS and Android change every year.

No platform is best at all six. The useful question is which layers you want the platform to own, and which you want to keep in your own hands.

The five types of mobile app development platforms in 2026

The market has split into five approaches. They differ less in features than in two things: what they output, and what you are left holding if you leave.

Type	Examples	What you get	Who it suits	The catch
Native SDKs	Xcode with Swift, Android Studio with Kotlin	Two separate native codebases	Teams with dedicated iOS and Android engineers	Two of everything: code, bugs, hiring
Cross-platform frameworks	React Native, Flutter, Kotlin Multiplatform	One codebase, native apps	Product teams with mobile developers	You still assemble backend, CI, distribution yourself
Enterprise low-code (LCAP)	OutSystems, Mendix, Microsoft Power Apps, HCL Volt MX	Visual apps on the vendor's runtime	Large IT teams building many internal apps	Per-user pricing and runtime lock-in
No-code builders	FlutterFlow, Adalo, Glide	Apps assembled visually, some with code export	Small teams and simple apps	Hand-building every screen; limits on custom logic
AI app builders	RapidNative for native mobile; Lovable, Bolt and v0 for web	An app generated from a description	Teams that want working software in days	Quality depends on the output being real, ownable code

Two observations from building in this space.

First, the framework layer has been commoditized. In 2012 a MADP's main job was solving cross-platform: write once, run on iOS, Android and BlackBerry. React Native and Flutter solved that for free. What a platform sells today is everything around the framework: speed, backend, governance, and the last mile into the stores.

Second, runtime lock-in is the real dividing line. Many low-code and no-code platforms run your app inside their own engine. That is fine until pricing changes, a feature you need sits on their roadmap, or the company is acquired. Platforms that output standard source code give you an exit. We wrote more about this in our guide to avoiding vendor lock-in on the RapidNative blog.

How to evaluate a mobile app development platform: 8 questions

Feature matrices all look the same. These questions don't.

1. Is the output a native app or a website in a frame?

Many tools that call themselves mobile platforms produce a web app wrapped in a web view. Users notice the scrolling, the keyboard, the lack of native gestures. Apple notices too: App Store Review Guideline 4.2 rejects apps that are "a repackaged website". Ask for a build on a real phone, not a desktop browser preview. For the longer version of this argument, see our post on native vs hybrid app development.

2. Can you leave with working source code?

"Export" can mean a zip that still calls the vendor's runtime. Ask for the exported project, hand it to a developer who has never used the platform, and see whether they can build and run it with standard tools. If they can't, you are renting, not owning.

3. Where does the data live, and can you point it elsewhere?

A bundled backend is great for speed. Check you can also connect your own database, identity provider and APIs, and that data can be exported in a standard format.

4. How does it handle identity and device management?

For internal apps: SSO through your identity provider, role-based access, and compatibility with your MDM or MAM tooling. For customer apps: sign-in methods, account deletion (which both stores now require), and privacy labels.

5. How do apps reach users?

Publishing is where many projects stall. Certificates, provisioning profiles, store listings, screenshots, privacy policies and review rejections take weeks if nobody on the team has done it. Ask the vendor to walk you through the path from "done" to "live in both stores", and to private distribution if you need it.

6. How are updates shipped?

Can you push a fix without a full store review? Frameworks like Expo support over-the-air updates for JavaScript changes within the store rules. Native changes still go through review.

7. Who on your team can use it?

If only certified specialists can work in the tool, it becomes a bottleneck. The best platforms let a product manager or designer make real progress while engineers stay in control of the codebase.

8. What does it cost at 10x the users?

Per-user licensing that looks cheap for a 50-person pilot can be the biggest line item at 5,000 employees, or impossible for a consumer app. Model the price at the scale you are hoping for, not the scale you start at.

Where AI fits in mobile app development platforms

The newest entrant changes the economics of question 7 and question 2 at the same time.

Low-code made building faster by replacing code with visual blocks, at the cost of ownership. AI app builders make building faster by writing the code for you, which means the speed and the ownership no longer have to trade off. The catch is that most AI app builders generate web apps. For mobile, the output has to be a real native project, or you are back to the web-view problem in question 1.

This is the gap we built RapidNative to fill. You describe the app, or upload a sketch, a screenshot or a product requirements document, and it generates a full-stack React Native and Expo app: screens, navigation, a database, sign-in, file storage and realtime updates. You scan a QR code to run it on your own phone while you build, and change it by chatting or by clicking an element and describing the change. On paid plans you download the complete Expo project, written in TypeScript with Expo Router and NativeWind, with no proprietary runtime. When the app is ready, LetsDeploy.It, our sister service, handles the App Store and Google Play submission.

Mapped against the six layers above, that covers front-end, backend, testing and publishing, with your own Supabase or APIs plugged in where you need them. Teams also use it alongside an existing stack: generate the first version in days, then move the exported project into their own repository and CI. Larger teams can bring their design system so generated screens match their brand.

It is not the right tool for everything. If you need to model hundreds of approval workflows across an ERP, an enterprise low-code platform with built-in process automation will serve you better. If you have a mature native team, a cross-platform framework and your existing CI may be all you need. AI-generated code is a starting point you own, not a replacement for engineering judgment on security and scale.

Is MADP still the right term?

Strictly, no. The analyst category moved on in 2019. But the need it named hasn't changed: one supported, governed way to get good mobile apps built and shipped. If an RFP asks for a MADP, answer the underlying questions above rather than the acronym. For the full list of acronyms you will run into (MEAP, MBaaS, LCAP, MXDP, MDM, MAM and the rest), see our enterprise mobile glossary and our enterprise mobile app development guide on the RapidNative blog.

The bottom line

A mobile app development platform is less a product category than a promise: build once, ship to both stores, keep it running. Over fifteen years that promise has been sold as middleware, as cross-platform tooling, as low-code and now as AI. The best choice in 2026 is the one that gets a real native app on a real phone fastest, while leaving you holding source code you can take anywhere.

The quickest way to judge any platform is to build one real screen of your own app with it. If you want to try that with RapidNative, start from a prompt on the free plan. Read the full guide on RapidNative for links to everything mentioned here.

How to Turn Your App Idea Into a Real Mobile App With AI (Step-by-Step Guide for 2026) 📱✨

Hugo Rus — Fri, 30 Oct 2026 13:01:27 +0000

Introduction

You have an app idea. Maybe it's a habit tracker, a booking app for your business, or a tool your friends keep asking for. A few years ago, the next step was hiring a developer or spending months learning to code.

In 2026, you can describe your app to an AI and have a working mobile app on your phone the same day. But "describe your app" hides a lot of small decisions, and those decisions are what separate an app that looks like a demo from one people actually use.

This guide walks through the whole path, from a rough idea to an app in the App Store and Google Play, using RapidNative, an AI app builder that creates real React Native mobile apps.

Disclosure: this guide is from the RapidNative team. The steps apply whichever tool you use.

Mobile app or web app? Decide first

Before anything else, decide whether you need a mobile app or a website. Many popular AI builders, like Lovable, Bolt and v0, create web apps. They're great in a browser, but putting them in the App Store means converting them into native apps later.

If you want people to download your app, get notifications and open it from their home screen, start with a builder that makes mobile apps from day one. RapidNative creates React Native apps built on Expo, the same technology many professional mobile teams use, so there's nothing to rebuild when it's time to launch.

Step 1: Shrink your idea to one main job

The most common reason AI-built apps feel messy is that the idea is too big. Before you write a single prompt, finish this sentence:

"My app helps [who] to [do one thing]."

For example: "My app helps dog walkers keep track of which dogs they walked today and send owners a quick update."

Everything else, like chat, payments or social features, can come later. A focused first version is faster to build, easier for the AI to get right and easier for your first users to understand.

Step 2: List your screens

Next, write down the 3 to 6 screens your app needs for that one job. For the dog walker app, that might be:

Today: the list of dogs to walk today.
Walk: a timer and a button to mark the walk done.
Update: a quick note and photo to send to the owner.
Dogs: all dogs with owner contact details.
Settings: profile and notifications.

You don't need to design them. A rough sketch on paper, or even a screenshot of an app you like, gives the AI a much clearer picture. RapidNative can start from a sketch or screenshot as well as from words.

Step 3: Write a prompt that gives the AI what it needs

A good first prompt has four parts: who the app is for, the main job, the screens, and the look and feel. Here's an example:

Build a mobile app for professional dog walkers.

Main job: keep track of today's walks and send owners a quick update.

Screens:
1. Today – list of dogs scheduled today, with photo, name and walk time
2. Walk – a big start/stop timer and a "Mark as done" button
3. Update – add a short note and a photo, then send to the owner
4. Dogs – all dogs with breed, owner name and phone number
5. Settings – profile and notification settings

Use a bottom tab bar for Today, Dogs and Settings.
Style: friendly and clean, white background, green accents, rounded cards, large buttons that are easy to tap while walking.

Notice what the prompt includes: real content, clear navigation and a style. The more specific you are, the less you'll need to fix later.

Step 4: Generate the first version

Paste your prompt into RapidNative and let it build. In a few minutes you'll have your screens, navigation and styling as a working React Native app.

Don't expect perfection on the first try. Think of it as a first draft from a fast designer and developer working together. Your job now is to review it like a user would.

Step 5: Improve it one screen at a time

The best way to refine an AI-built app is with small, specific requests, one change at a time. Compare these two:

Too vague: "Make it better."
Specific: "On the Today screen, show the walk time on the right side of each card and make the dog's name bold."

A few more tips that save a lot of back and forth:

Fix navigation first, then layout, then colors. Moving screens around later can undo styling work.
Use real example content. Real dog names and times reveal layout problems that "Lorem ipsum" hides.
Check every screen on a small phone. Text that fits on a large screen often wraps badly on smaller ones.

Step 6: Connect real data

So far your app shows example content. To make it work for real users, it needs somewhere to store data and a way for people to sign in. Many builders use a backend service like Supabase or Firebase for accounts, data and photo storage.

Because RapidNative gives you standard React Native code, you can connect the backend you prefer, and export the code to keep working in your own editor or with a developer.

Step 7: Test it on your own phone

Nothing replaces holding your app in your hand. Because RapidNative apps are built on Expo, you can run them on a real phone during development. Use the app the way your users would: outside, one-handed, in a hurry.

Then hand it to three or four people who match your "who" from Step 1. Watch them use it without explaining anything. Wherever they hesitate, there's something to fix.

Step 8: Prepare for the App Store and Google Play

Launching takes a little paperwork, and planning for it early avoids surprises:

Developer accounts: Apple's costs $99 a year and Google Play's costs $25 once.
Store screenshots: these sell your app before anyone opens it. AppShots generates App Store screenshots with AI from your app.
A privacy policy describing what data you collect.
Account deletion inside the app, if people can sign up. Both Apple and Google require it.
Sign in with Apple, if you offer Google or other social login on iPhone.
A closed test on Google Play: new personal developer accounts need 12 testers for 14 days before they can publish.

Step 9: Launch, listen and update

Your first version is a starting point. Once real people are using it, their feedback will tell you what to build next far better than any plan. Add one improvement at a time, using the same small, specific prompts from Step 5, and ship updates regularly.

Common mistakes to avoid

Building every feature at once. Start with one main job and add the rest after launch.
Prompting without screens in mind. A list of screens turns a vague idea into a clear plan for the AI.
Choosing a web builder when you need a mobile app. Converting later costs time; starting mobile saves it.
Skipping real-phone testing. Apps feel very different in your hand than in a preview.
Leaving store requirements until the end. Account deletion and Sign in with Apple are much easier to add early.

FAQ

Can I build a mobile app with AI without knowing how to code? Yes. AI app builders like RapidNative let you create the screens, navigation and design by describing them. Some steps, like connecting a backend or publishing, are easier with a little technical help, but you can get a working app on your phone without writing code.

How long does it take to build an app with AI? A first working version can take an afternoon. A polished app ready for the stores usually takes a few days to a few weeks, depending on features and testing.

How much does it cost to build an app with AI? Most AI builders have free plans or credits to start, plus paid plans for more usage. To publish, you'll also pay Apple $99 a year and Google $25 once.

Do I need a Mac to publish to the App Store? Not necessarily. Expo's cloud build service can build and submit iPhone apps without a Mac.

Can I keep the code? With RapidNative, yes. You get standard React Native and Expo code you can export and keep building on.

Conclusion

Turning an idea into a real mobile app has never been more achievable. Keep the first version focused, plan your screens, write specific prompts, and test on a real phone before you launch. If your goal is an app people download from the App Store and Google Play, start building with RapidNative and go from idea to app on your phone today.

What app are you planning to build? Share your idea in the comments, and we'll suggest a first prompt for it.

App Rejected Under Guideline 4.8? How to Fix Login for AI-Built Apps

Hugo Rus — Thu, 29 Oct 2026 12:57:39 +0000

Short answer: your app lets people sign in with Google (or Facebook, GitHub, X) but doesn't offer a login option that keeps their data private. Apple's Guideline 4.8 says that if you offer a third-party login, you must also offer one that limits what you collect. Sign in with Apple is the quickest way to meet it, and for apps built with Lovable, Bolt, Base44 or v0 it usually takes an afternoon.

AI app builders make it easy to add "Continue with Google". It works on the web, so nobody thinks about it again until the App Store review note arrives:

Guideline 4.8 - Design - Login Services

Nothing in your app is broken. Apple just wants iPhone users to have a login option that doesn't hand their data to another company.

What does Guideline 4.8 ask for?

If your app uses a third-party or social login service to set up or sign in to the main account, you must also offer another login option with all three of these features:

It only collects the person's name and email address.
It lets people keep their email address private from everyone, including you.
It doesn't track people for advertising without their consent.

Sign in with Apple has all three built in. Since early 2024, Apple accepts any login service that meets them, but Sign in with Apple is still the one reviewers expect, and the only one that comes ready-made on every iPhone.

Do I have to use Sign in with Apple?

Not strictly. Apple's wording asks for "another login service" with the three features above, so another provider that meets them counts. In practice, Sign in with Apple is the safest choice:

Reviewers recognize it immediately, so there's nothing to argue about.
It uses Face ID or Touch ID, so it's the fastest login on an iPhone.
Supabase, which most AI-built apps use for login, supports it out of the box.

Does email and password login count?

Usually not as the fix. Your own email and password sign-up is your account system, not a login service with private email built in. The exemption for your own accounts only applies when your app only uses them. Once you add Google login, Apple expects a private third-party option next to it. If you want to avoid Guideline 4.8 entirely, the other route is removing social login and keeping email and password only.

Which apps don't need it?

Guideline 4.8 doesn't apply if your app:

Only uses your own email and password accounts, with no social login.
Is an education or enterprise app where people sign in with an existing school or work account.
Uses a government or industry-backed identity system, such as a national e-ID.
Is a client for a specific third-party service, where people sign in to that service directly (for example, an app that reads their Google Drive files).

If none of those fit and you have Google login, plan on adding Sign in with Apple.

How to add Sign in with Apple to a Supabase app

Most apps built with Lovable, Bolt, Base44 or v0 store their users in Supabase, so here's the path for a native React Native and Expo app with Supabase.

Turn on the capability. In your Apple Developer account, open Identifiers, select your app's App ID and enable Sign in with Apple.
Turn on the Apple provider in Supabase. In Authentication, then Providers, enable Apple and add your app's bundle ID (for example it.letsdeploy.myapp) to the Client IDs. If you also want Apple login on your website, create a Services ID and a signing key in Apple Developer and add those too.
Add the Expo package. Install expo-apple-authentication and set "usesAppleSignIn": true under ios in your app.json.
Add the button and sign in. Show Apple's own button, then pass the token Apple gives you to Supabase:

import * as AppleAuthentication from 'expo-apple-authentication';
import { supabase } from './supabase';

export async function signInWithApple() {
  const credential = await AppleAuthentication.signInAsync({
    requestedScopes: [
      AppleAuthentication.AppleAuthenticationScope.FULL_NAME,
      AppleAuthentication.AppleAuthenticationScope.EMAIL,
    ],
  });

  if (!credential.identityToken) throw new Error('No identity token from Apple');

  const { error } = await supabase.auth.signInWithIdToken({
    provider: 'apple',
    token: credential.identityToken,
  });
  if (error) throw error;

  // Apple only sends the name the first time, so save it now
  if (credential.fullName?.givenName) {
    await supabase.auth.updateUser({
      data: { full_name: `${credential.fullName.givenName} ${credential.fullName.familyName ?? ''}`.trim() },
    });
  }
}

Test on a real iPhone with a fresh Apple ID: sign in, choose "Hide My Email", and check the new user appears in Supabase.

On the web, Supabase handles Apple login with a redirect, the same way it does Google, so your Lovable or Bolt web version can keep working as it does.

The mistakes that get apps rejected again

The Apple button is hidden or smaller. Put Sign in with Apple at least as high and as large as Google on the login screen. Use Apple's official button style, not a custom one.
The name is lost. Apple sends the person's name only on the first sign-in. If you don't save it then, you'll never get it again, and your profile screens show blanks.
Emails to "Hide My Email" users bounce. People who hide their email get an address ending in privaterelay.appleid.com. To send them emails (password resets, receipts), register your sending domain in Apple Developer under the private email relay settings.
Account deletion doesn't revoke Apple tokens. If you offer Sign in with Apple, Apple expects you to revoke the person's tokens when they delete their account. Our account deletion guide covers the full deletion flow.

What to write back to App Review

When you resubmit, add a short note in App Store Connect so the reviewer doesn't have to hunt:

Where it is: "Sign in with Apple is now on the login screen, above Continue with Google."
What it offers: "It collects only name and email and supports Hide My Email."
A demo account in the App Review information, if parts of the app need a login to review.

Apps rejected under 4.8 are often rejected for something else in the same review. The Guideline 4.2 guide covers the most common one for AI-built apps, and the launch checklist lists everything else Apple and Google ask for.

Can you fix it yourself?

Yes. If you can edit your app's login screen and your Apple Developer settings, most people fix this in an afternoon.

It gets harder when login touches several places: the native app, the web version, Supabase, the private email relay and account deletion. That's part of the store work we do when we convert an app to native, with steps for Lovable, Bolt.new, Base44 and v0. See how it works or our plans.

FAQ

Is Sign in with Apple required if I only have email and password login?

No. Guideline 4.8 only applies when you offer a third-party or social login, such as Google, Facebook or GitHub.

Do I need Sign in with Apple on Android too?

No. Guideline 4.8 is an App Store rule. You can show the Apple button only on iOS and keep Google login on Android.

Can I use Google login and nothing else?

Not on the App Store, unless your app fits one of the exemptions. You need at least one login option with the three privacy features next to it.

Will Apple reject a custom-styled Apple button?

It can. Apple's design guidelines ask you to use their official button styles, and expo-apple-authentication gives you those buttons ready-made.

Does Lovable add Sign in with Apple automatically?

No. Lovable, Bolt, Base44 and v0 build web apps and usually add email and Google login. Sign in with Apple needs Apple Developer setup and, in a native app, the native sign-in sheet.

Can I fix this without a new build?

No. Adding a login option changes the app, so you need a new build and a new submission. Expo's EAS Build makes that a single command once the code is in.

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

Hugo Rus — Fri, 16 Oct 2026 11:57:33 +0000

Pick the wrong storage library in React Native and your app stalls on launch. Pick the right one and it feels instant on a subway with no signal. Here's the 2026 landscape: what each option is good at, when to combine them, and the architecture that makes writes survive airplane mode.

The six options, by job

AsyncStorage: the classic default. A simple async key-value store. Fine for a handful of small preferences; slow for anything large, because every call is asynchronous and values are stored as serialized strings.

MMKV: Tencent's key-value engine, exposed to JavaScript through JSI with synchronous reads. Its README claims it's about 30x faster than AsyncStorage, and it supports optional encryption. For a new project in 2026, it's the go-to key-value store.

import { createMMKV } from 'react-native-mmkv'; // v4 API

const storage = createMMKV({ id: 'prefs' });
storage.set('onboarded', true);
const onboarded = storage.getBoolean('onboarded'); // synchronous

On MMKV v3, the equivalent is new MMKV({ id: 'prefs' }).

Expo SecureStore: a thin wrapper over the iOS Keychain and Android Keystore, encrypted by the OS. Slower than the others and meant for small values. Use it for refresh tokens and secrets only.

expo-sqlite: full relational SQLite with a synchronous API. Indexes, joins, transactions. Comfortably handles large datasets on a modern phone.

import * as SQLite from 'expo-sqlite';

const db = SQLite.openDatabaseSync('app.db');
db.execSync(`
  CREATE TABLE IF NOT EXISTS notes (
    id TEXT PRIMARY KEY,
    body TEXT,
    updated_at INTEGER
  )
`);

const since = Date.now() - 24 * 60 * 60 * 1000;
const rows = db.getAllSync('SELECT * FROM notes WHERE updated_at > ?', [since]);

WatermelonDB: an ORM on top of SQLite with reactive queries and a sync protocol. Reach for it when you have tens of thousands of records and two-way sync.

Realm: a reactive object database with its own engine. It still works well locally, but MongoDB ended Atlas Device Sync in September 2025, so don't plan on hosted sync.

The decision table

Need	Pick	Why
Secrets, tokens	Expo SecureStore	OS-level encryption
Preferences, flags, hot reads	MMKV	Fast synchronous reads
Structured, queryable records	expo-sqlite	SQL, indexes, joins
Large offline-first data with sync	WatermelonDB	Reactive queries + sync
Reactive object DB, local only	Realm	Clean object API

Most production apps use three at once: SecureStore + MMKV + SQLite. They don't conflict; each owns a different concern.

The offline-first architecture (the part everyone skips)

Picking a library is the easy part. The architecture around it is what makes an app work offline.

1. Hydrate from local storage on launch, refresh in the background

const cached = storage.getString('home_feed');
if (cached) hydrateFeed(JSON.parse(cached));
void refreshFeedInBackground();

Users should never see a blank screen because of a network request.

2. Queue writes while offline

On every change, store two things: the local row (so the UI updates instantly) and an entry in a sync queue.

CREATE TABLE IF NOT EXISTS mutation_queue (
  id TEXT PRIMARY KEY,
  type TEXT,
  payload TEXT,
  created_at INTEGER,
  attempts INTEGER DEFAULT 0
);

3. Drain the queue when the network is really back

Check isInternetReachable, not just isConnected: a captive portal Wi-Fi reports "connected" while nothing actually loads.

import NetInfo from '@react-native-community/netinfo';

const API_URL = process.env.EXPO_PUBLIC_API_URL;
let draining = false;

NetInfo.addEventListener(async (state) => {
  if (state.isInternetReachable !== true || draining) return;
  draining = true;

  try {
    const pending = db.getAllSync(
      'SELECT * FROM mutation_queue ORDER BY created_at ASC'
    );

    for (const m of pending) {
      try {
        const res = await fetch(`${API_URL}/${m.type}`, {
          method: 'POST',
          headers: {
            'Content-Type': 'application/json',
            'Idempotency-Key': m.id,
          },
          body: m.payload,
        });
        if (!res.ok) throw new Error(`HTTP ${res.status}`);
        db.runSync('DELETE FROM mutation_queue WHERE id = ?', [m.id]);
      } catch {
        db.runSync(
          'UPDATE mutation_queue SET attempts = attempts + 1 WHERE id = ?',
          [m.id]
        );
        break; // keep order; retry on the next reconnect
      }
    }
  } finally {
    draining = false;
  }
});

Three details matter here:

Idempotency-Key: without it, a flaky network creates duplicates whenever a request succeeds on the server but the response never arrives. Your server must store and honor the key.
The draining flag: NetInfo can fire several events in a row. Without a guard, two loops send the same mutations at once.
Checking res.ok: fetch only throws on network failure, not on a 500. Without the check, failed writes get deleted from the queue.

4. Resolve conflicts explicitly

Three strategies:

Last write wins: compare timestamps. Simple, but can lose data. Fine for most single-user apps.
Server-authoritative merge: the server applies changes in order and returns the canonical state.
CRDTs (Yjs, Automerge): needed for real-time collaborative editing. Heavier, but correct.

Five pitfalls to avoid

Serializing giant arrays into AsyncStorage. A classic cause of slow launches. Move large data to SQLite.
Hard-coding an MMKV encryptionKey. Encryption is opt-in, and a key in your source code is readable by anyone. Generate a random key on first launch and keep it in SecureStore.
Trusting isConnected. Use isInternetReachable.
Retrying without idempotency keys. You'll create duplicate records.
Loading huge tables with getAllSync. Synchronous reads block the JS thread. Paginate, add indexes, or use the async API for large queries.

Want this scaffolded for you?

If you're starting a new React Native app and want SecureStore + MMKV + SQLite pre-wired with hydration on launch and a sync queue skeleton, RapidNative generates it from a plain-English prompt and lets you export the full Expo project.

Everything in this guide is a pattern you can copy by hand too; the whole stack is open source and well documented. Pick the engines that match your access patterns, wrap them in an offline-first architecture, and your app will feel instant whether the network is there or not.

Stop Your AI Agent Writing 2023 React Native: A CLAUDE.md for Expo + Supabase Apps

Hugo Rus — Thu, 15 Oct 2026 11:37:49 +0000

Ask an AI coding agent to "add a video player" to your Expo app, and there's a good chance it reaches for expo-av. Ask for a login screen, and it may store the session token in plain AsyncStorage, wrap the screen in SafeAreaView from react-native, and install packages with npm install instead of npx expo install.

None of that is the agent being careless. It's the agent averaging over years of tutorials, most of which were written for older versions of React Native and Expo.

The fix is cheap: a project rules file. Claude Code reads CLAUDE.md at the start of every session, and other agents read similar files (AGENTS.md, Cursor rules). A rules file tells the agent how this project works, so it stops guessing.

Here's one built for Expo + Supabase apps, section by section, then the checks that catch what still slips through.

What makes a good rules file?

Specific over general. "Write clean code" changes nothing. "Use expo-image, not Image from react-native" changes the output.
Short. It's loaded into every session. Keep it to things the agent actually gets wrong.
Includes the commands. Tell the agent how to check its own work, and it will.
Lives in the repo. Commit it, so every teammate and every agent gets the same rules.

The CLAUDE.md

Copy this into the root of your project and edit it to match your stack.

# Project rules

## Stack
- Expo (managed workflow, development builds) + TypeScript (strict)
- Expo Router for navigation (file-based, in /app). Do NOT add React Navigation directly.
- Supabase for auth, database, and storage. Client in /lib/supabase.ts.

## Packages
- Install with `npx expo install <pkg>`, never `npm install`, so versions match the SDK.
- Before adding a dependency, check if Expo already provides one.
- Use: expo-image (images), expo-video / expo-audio (media; NOT expo-av),
  react-native-safe-area-context (NOT SafeAreaView from react-native),
  react-native-reanimated (animations), expo-secure-store (tokens/secrets).

## Navigation
- Screens live in /app. Layouts in _layout.tsx.
- Auth gating uses Stack.Protected guards in app/_layout.tsx. No useEffect redirects.
- Navigate with <Link href> or router.push. Use typed routes.

## Supabase
- Never use the secret/service key in the app. Only the publishable key.
- Every new table: enable RLS in the same migration, with policies.
- Schema changes go in supabase/migrations/, never only in the dashboard.
- After a schema change, regenerate types: `npm run db:types`.
- Pass the generated Database type to createClient. No `any` for query results.

## Code style
- Function components and hooks only.
- Handle loading, empty, and error states for every screen that fetches data.
- Every user-facing string that requests a permission needs a clear reason.
- No inline secrets. Public config uses EXPO_PUBLIC_*; everything else stays on the server.

## Before you say you're done
Run these and fix any failures:
- `npx tsc --noEmit`
- `npx expo lint`
- `npx expo-doctor`

Why each section is there

Packages

npx expo install picks versions compatible with your Expo SDK. Plain npm install grabs the latest, which is how you end up with a native module that doesn't match your SDK and a build that fails in EAS.

The "use X, not Y" list is the highest-value part of the whole file. Each line replaces a deprecated or weaker default the agent would otherwise pick:

Agents often write	Current choice
`expo-av`	`expo-video` and `expo-audio` (`expo-av` is deprecated)
`SafeAreaView` from `react-native`	`react-native-safe-area-context` (the core one is deprecated)
`Image` from `react-native`	`expo-image` (caching, placeholders, better formats)
`Animated` API	`react-native-reanimated`
Tokens in AsyncStorage	`expo-secure-store` for anything sensitive

Update this table when you upgrade SDKs. It's the part that ages fastest.

Navigation

Agents trained on years of React Navigation code will happily add a NavigationContainer to an Expo Router app. One line prevents it. The auth rule matters too: protected routes handle redirects and history correctly, while scattered useEffect redirects cause flashes and back-button bugs.

Supabase

These four rules prevent the mistakes that actually hurt:

Secret key in the app: anyone can extract it from the bundle and bypass every security rule.
A table without RLS: readable by anyone with your public key.
Dashboard-only schema changes: they vanish on the next reset, and your teammates never get them.
Stale types: the compiler can't catch a renamed column if the types are out of date.

"Before you say you're done"

This is the section that changes agent behavior the most. Claude Code runs commands, so when the rules say "run these and fix failures," it type-checks and lints its own work before handing it back. expo-doctor also catches dependency versions that don't match your SDK.

What should you still review by hand?

A rules file reduces mistakes; it doesn't remove them. When reviewing agent-written Expo code, check these first:

Permissions: is every permission request explained, and only asked for when needed?
Empty and error states: what does the screen show with no data, or no network?
Secrets: search the diff for key, secret, and token.
New tables: does the migration enable RLS?
New dependencies: were they needed, and were they installed with npx expo install?
Platform differences: did it test only iOS? Keyboard handling and back buttons often break on Android.

How do you keep the rules useful?

Add a rule every time you correct the agent twice. If you fix the same mistake again, it belongs in the file.
Delete rules the agent never breaks. Shorter files get followed better.
Review it on every SDK upgrade. Deprecated packages are the fastest-changing part.
Share it across tools. If your team uses several agents, keep one source of truth and point the other files at it.

Wrapping up

AI agents write React Native the way the internet wrote it, which is often a few versions behind. A one-page CLAUDE.md tells them how your project works today: which packages, which navigation, which security rules, and how to check their own work.

If you'd rather start from a project that already follows these conventions, AppLighter's Expo + Supabase templates come with Expo Router, Supabase auth, and RLS set up, so your agent builds on a clean base.

What's the one rule your agent keeps breaking? Drop it in the comments.

Supabase Background Jobs, Tested Locally: Cron, Queues, HTTP from SQL, and Webhooks

Hugo Rus — Mon, 12 Oct 2026 09:58:40 +0000

Every Supabase app eventually grows a background layer. A nightly cleanup job. A digest email every morning. A queue that processes uploads one at a time. A webhook that fires when an order is paid.

In Supabase, that layer is mostly SQL: pg_cron schedules jobs, pgmq queues work, pg_net makes HTTP calls from the database (usually to an Edge Function), and database webhooks fire on inserts and updates.

It's also the part of the app most teams never run locally. It's easy to push a cron job straight to the hosted project and find out the next morning that the schedule was in the wrong timezone, or that the Edge Function it calls rejected the request.

This post walks through the four building blocks with working SQL, the patterns that hold up in production, and how to exercise all of it on your laptop before it ships.

The four building blocks

Tool	Job	Typical use
`pg_cron`	Run SQL on a schedule	Nightly cleanup, scheduled digests
`pg_net`	Make HTTP requests from SQL	Call an Edge Function from a cron job or trigger
`pgmq`	Durable message queue in Postgres	Process work one item at a time, with retries
Database webhooks	HTTP call on insert, update, or delete	React to a row changing

Most real setups combine them: a cron job uses pg_net to call an Edge Function, which reads work from a pgmq queue.

1. Scheduled jobs with `pg_cron`

select cron.schedule(
  'purge-old-sessions',          -- job name
  '0 3 * * *',                   -- every day at 03:00
  $$ delete from public.sessions where created_at < now() - interval '30 days' $$
);

Inspect jobs and their runs:

select jobid, jobname, schedule, active from cron.job;

select jobid, status, return_message, start_time
from cron.job_run_details
order by start_time desc
limit 20;

Remove a job by name:

select cron.unschedule('purge-old-sessions');

The timezone trap. Hosted Supabase runs cron schedules in UTC. 0 3 * * * is 3am UTC, which might be the middle of your users' afternoon. Write the timezone in the job name or a comment, and check it before you ship.

2. Calling an Edge Function from SQL with `pg_net`

Most cron jobs shouldn't do the work in SQL. They should kick off an Edge Function that can call APIs, send email, and use secrets.

select net.http_post(
  url := 'https://<project-ref>.supabase.co/functions/v1/send-digest',
  headers := jsonb_build_object(
    'Content-Type', 'application/json',
    'Authorization', 'Bearer ' || (
      select decrypted_secret from vault.decrypted_secrets where name = 'digest_function_key'
    )
  ),
  body := jsonb_build_object('kind', 'daily')
);

Combine it with cron:

select cron.schedule(
  'daily-digest',
  '0 8 * * *',   -- 08:00 UTC
  $$
    select net.http_post(
      url := 'https://<project-ref>.supabase.co/functions/v1/send-digest',
      headers := jsonb_build_object(
        'Content-Type', 'application/json',
        'Authorization', 'Bearer ' || (select decrypted_secret from vault.decrypted_secrets where name = 'digest_function_key')
      ),
      body := '{"kind":"daily"}'::jsonb
    );
  $$
);

pg_net is asynchronous: net.http_post queues the request and returns a request ID immediately. Check what came back in the response table:

select id, status_code, content, created
from net._http_response
order by created desc
limit 10;

Two rules:

Keep keys in Vault, not in the job's SQL. Anything written inline into cron.schedule is stored in plain text in cron.job.
Check net._http_response for failures. A 401 or 500 from your function won't surface anywhere else.

3. Queues with `pgmq`

When work needs to happen reliably, one item at a time, with retries if something fails, use a queue instead of a bare cron job.

select pgmq.create('image_jobs');

-- Producer: enqueue work (from a trigger, an RPC, or app code)
select pgmq.send('image_jobs', '{"image_id": "abc123"}'::jsonb);

A worker (usually an Edge Function called on a schedule) reads a batch:

-- Read up to 10 messages, hiding them from other readers for 60 seconds
select msg_id, read_ct, message
from pgmq.read('image_jobs', 60, 10);

When a message is processed, delete or archive it:

select pgmq.delete('image_jobs', 42);     -- done, discard
select pgmq.archive('image_jobs', 43);    -- done, keep a record

If the worker crashes before deleting a message, the visibility timeout (60 seconds above) expires and the message becomes readable again. That's your retry. Use read_ct to spot messages that keep failing and move them aside after a few attempts, so one bad message doesn't block the queue forever.

4. Database webhooks

Webhooks call a URL when rows change. The payload has a fixed shape your Edge Function can rely on:

{
  "type": "INSERT",
  "table": "orders",
  "schema": "public",
  "record": { "id": "o1", "status": "paid", "user_id": "u1" },
  "old_record": null
}

For UPDATE, both record and old_record are set. For DELETE, record is null.

Make handlers idempotent. Deliveries can be retried, and an UPDATE can fire even when the column you care about didn't change. Compare record and old_record before sending a receipt, and record what you've already processed.

Testing all of it locally

The usual options for running this before deploying:

The Supabase CLI (supabase start) runs the full Docker stack, including these extensions. It's the highest-fidelity local option, at about a dozen containers and roughly 1.4 GB of RAM.
tinbase, an open-source, Supabase-compatible backend that runs as one process with no Docker. It emulates pg_cron, pgmq, pg_net, Vault, and database webhooks, so the SQL above runs as written.

A local test loop with tinbase:

npx tinbase start

Put your jobs in a migration so every environment gets the same schedule:

-- supabase/migrations/20261012000000_background_jobs.sql
select pgmq.create('image_jobs');

select cron.schedule('process-images', '* * * * *', $$
  select net.http_post(
    url := 'http://127.0.0.1:54321/functions/v1/process-images',
    headers := jsonb_build_object('Content-Type', 'application/json'),
    body := '{}'::jsonb
  );
$$);

Then, in the Studio-style dashboard's SQL editor or from a test:

Enqueue a few messages with pgmq.send.
Wait a minute for the cron job to fire.
Check cron.job_run_details for the run.
Check net._http_response for the function's status code.
Check that the queue is empty (or the bad message is still there with a higher read_ct).

Edge Functions written with Deno.serve run in-process from supabase/functions/, so the cron → pg_net → function → queue loop happens entirely on your laptop.

What to know about the emulation:

It implements the surface real projects call, not every function each extension offers. If you use something exotic, check tinbase's compatibility table.
It's alpha, and built for local development and CI, not production.
Edge Functions with npm: or jsr: imports need bundling first.
Run your jobs once against the real Supabase CLI or a staging project before deploying, especially anything time-sensitive.

Checklist before shipping background jobs

[ ] Jobs are defined in migrations, not typed into the dashboard
[ ] Every schedule's timezone is written down (hosted cron runs in UTC)
[ ] Function keys live in Vault, never inline in cron.schedule
[ ] Someone (or something) checks net._http_response for errors
[ ] Queue workers delete or archive every processed message
[ ] Messages that fail repeatedly are moved aside using read_ct
[ ] Webhook handlers are idempotent and compare record with old_record
[ ] The whole loop has run at least once before it reaches production

Background jobs fail quietly, at 3am, in UTC. Running them on your laptop first is the cheapest insurance you can buy.

What's the background job that bit you hardest? I'd like to collect the war stories.

Your Own Expo Boilerplate in 60 Minutes: The Day-One Setup I Wish I'd Done Every Time

Hugo Rus — Thu, 08 Oct 2026 14:45:25 +0000

Every Expo project I've regretted had the same origin story: npx create-expo-app, straight into building screens, and "I'll set up the boring stuff later." Later arrived as a broken production build, secrets in the bundle, a crash nobody could reproduce, and a weekend of retrofitting.

The boring stuff takes about an hour on day one. On day ninety it takes a week. This is the checklist I now run before writing a single feature, in order, with the commands. At the end you have your own boilerplate: a repo you can copy for every new app.

0. Start from the current template (2 minutes)

npx create-expo-app@latest my-app
cd my-app
npx expo-doctor

The default template already gives you TypeScript, Expo Router, and an @/* path alias. Run expo-doctor immediately and fix anything it flags while the project is still empty.

1. Make TypeScript strict (5 minutes)

In tsconfig.json:

{
  "extends": "expo/tsconfig.base",
  "compilerOptions": {
    "strict": true,
    "noUncheckedIndexedAccess": true,
    "paths": { "@/*": ["./*"] }
  }
}

Add a script so CI and you run the same check:

{
  "scripts": {
    "typecheck": "tsc --noEmit"
  }
}

Turning strict mode on later means fixing hundreds of errors at once. Turning it on now means fixing zero.

2. Linting and formatting (5 minutes)

npx expo lint          # sets up ESLint with Expo's config on first run
npm i -D prettier eslint-config-prettier

Add the rules that catch real bugs, not style debates:

react-hooks/exhaustive-deps as an error
@typescript-eslint/no-explicit-any as an error
no-restricted-imports for @react-navigation/*, so navigation always comes from expo-router

3. Decide the folder structure before it decides itself (5 minutes)

app/                  # routes only (Expo Router)
components/           # reusable UI
features/<name>/      # screens' logic, hooks, and components per feature
lib/                  # clients (supabase, api), utilities
queries/              # data-fetching hooks
theme/                # colors, spacing, typography tokens

The rule that matters most: app/ contains routes, not logic. A route file imports a screen from features/ and renders it. Routes stay thin, and features stay testable.

4. Theme tokens before the first screen (5 minutes)

// theme/tokens.ts
export const colors = {
  bg: '#0B0B0F',
  surface: '#16161D',
  text: '#F5F5F7',
  muted: '#9A9AA3',
  primary: '#3B82F6',
  danger: '#EF4444',
} as const;

export const space = { xs: 4, sm: 8, md: 16, lg: 24, xl: 32 } as const;
export const radius = { sm: 6, md: 12, lg: 20 } as const;

Whether you use NativeWind, StyleSheet, or a UI kit, the tokens live in one place. When the designer changes the primary color, it's one line, not a search across forty files.

5. Data fetching that handles loading and errors (5 minutes)

npm i @tanstack/react-query

// app/_layout.tsx
import { QueryClient, QueryClientProvider } from '@tanstack/react-query';
import { Stack } from 'expo-router';

const queryClient = new QueryClient();

export default function RootLayout() {
  return (
    <QueryClientProvider client={queryClient}>
      <Stack />
    </QueryClientProvider>
  );
}

Then make it a rule: no fetch or database calls inside useEffect in screens. Every request goes through a hook in queries/, which gives you caching, retries, and loading and error states for free.

6. Secure storage for anything sensitive (3 minutes)

npx expo install expo-secure-store

Session tokens and refresh tokens go in the Keychain (iOS) or Keystore (Android) via expo-secure-store, not in AsyncStorage. Set the pattern now and every auth library you add later plugs into it.

7. Environment variables, the safe way (5 minutes)

Two kinds of values, two places:

Public config (API URL, publishable keys): EXPO_PUBLIC_ variables, which are inlined into the JavaScript bundle.
Secrets (third-party API keys, service keys): never in the app. They live on your server or in a serverless function the app calls.

Store build-time values in EAS so every machine and CI run uses the same ones:

npm i -g eas-cli
eas init
eas env:create --environment production --name EXPO_PUBLIC_API_URL --value https://api.example.com
eas env:pull --environment development

Add a CI check that fails if anything like EXPO_PUBLIC_.*SECRET appears in the repo.

8. Build profiles and a development build (10 minutes)

npx expo install expo-dev-client
eas build:configure

Set up three profiles in eas.json, each linked to its environment:

{
  "cli": { "appVersionSource": "remote" },
  "build": {
    "development": { "developmentClient": true, "distribution": "internal", "environment": "development" },
    "preview": { "distribution": "internal", "environment": "preview", "channel": "preview" },
    "production": { "environment": "production", "channel": "production", "autoIncrement": true }
  }
}

Then make your first development build:

eas build:dev --platform ios

From here on, you develop in your own dev client instead of Expo Go. Push notifications, payments, and most native modules don't work in Expo Go, so finding out on day one beats finding out the week before launch.

9. Over-the-air updates, configured safely (5 minutes)

npx expo install expo-updates
eas update:configure

In app.json, use the fingerprint runtime policy so an update only reaches binaries that can run it:

{
  "expo": {
    "runtimeVersion": { "policy": "fingerprint" }
  }
}

Now a JavaScript-only bug fix is a five-minute publish instead of a store review.

10. Crash reporting before the first user (5 minutes)

npx @sentry/wizard@latest -i reactNative

The wizard adds the SDK, the config plugin, and source map uploads during EAS builds. A crash report with a readable stack trace is the difference between "fixed in an hour" and "can't reproduce."

11. CI that runs on every pull request (5 minutes)

# .github/workflows/ci.yml
name: CI
on: [pull_request]
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 22, cache: npm }
      - run: npm ci
      - run: npm run typecheck
      - run: npx expo lint
      - run: npx expo install --check

Three checks: types, lint, and dependency versions that match your Expo SDK. That last one catches the "works locally, fails on EAS" class of bugs before they cost a build.

12. The two screens every app needs (optional, but cheap now)

Settings → Account → Delete account. Both app stores require in-app account deletion if users can sign up. Add the route now, even if the button is a stub.
Error and empty states. A shared <ErrorState /> and <EmptyState /> component means every screen handles failure the same way.

Save it as your boilerplate

Once all twelve are done, commit the repo, tag it, and mark it as a GitHub template repository. Every new app starts with:

gh repo create my-next-app --template you/expo-boilerplate --private --clone

Update the template whenever you upgrade the Expo SDK, and every future project starts current.

The checklist

[ ] Fresh template, expo-doctor clean
[ ] Strict TypeScript and a typecheck script
[ ] ESLint and Prettier with bug-catching rules
[ ] Folder structure: routes in app/, logic in features/
[ ] Theme tokens in one file
[ ] TanStack Query for all data fetching
[ ] expo-secure-store for tokens
[ ] Public vs secret env vars separated; values on EAS
[ ] Three build profiles and a development build
[ ] expo-updates with fingerprint runtime version
[ ] Sentry with source maps
[ ] CI: typecheck, lint, dependency check
[ ] Account deletion route and shared error/empty states

About an hour of work, and every app you build afterward starts from a foundation instead of a to-do list.

If you'd rather skip straight to screens, RapidNative generates Expo apps as real React Native code you own, so you can drop them into a setup like this one and keep going.

What's on your day-one list that isn't on mine?

React Native Accessibility: The 2026 WCAG 2.2 Compliance Guide

Hugo Rus — Mon, 05 Oct 2026 11:00:29 +0000

Most React Native apps fail accessibility audits for the same dozen reasons, and almost none of them are hard to fix. An unlabeled icon button. A tap target that's 28 points wide. A modal that VoiceOver can read straight through. Text that clips at 200% font size.

This guide maps WCAG 2.2 Level AA to the React Native APIs that satisfy it, with code for each. If you build to WCAG 2.2 AA, you also meet WCAG 2.1 AA, because 2.2 is backwards compatible and only adds criteria (plus removes one obsolete one, 4.1.1 Parsing).

Not legal advice. If you're building for a government agency, a public university, or a healthcare provider, confirm your specific obligations with counsel.

Why this matters in 2026

The U.S. Department of Justice's ADA Title II rule makes WCAG 2.1 Level AA the technical standard for web content and mobile apps provided by state and local governments, including public schools, universities, courts, transit authorities, and public hospitals. That includes apps built for them by contractors.

The deadlines moved. On April 20, 2026, four days before the original deadline, DOJ published an interim final rule extending them by a year:

Public entity	Original deadline	Current deadline
Population 50,000 or more	April 24, 2026	April 26, 2027
Population under 50,000, and special districts	April 26, 2027	April 26, 2028

Two things the extension didn't change. First, it only delays the WCAG compliance dates; Title II's underlying nondiscrimination obligations still apply today, and those have supported accessibility lawsuits for years. Second, the separate HHS Section 504 rule for recipients of HHS funding kept its May 11, 2026 first deadline.

And outside the U.S., the European Accessibility Act has applied to many consumer-facing apps (banking, e-commerce, transport, e-books) since June 28, 2025.

Even without a legal requirement, roughly one in six people worldwide lives with a significant disability. Accessibility is a big chunk of your addressable market.

1. Label everything a screen reader can focus

WCAG 1.1.1 Non-text Content (A), 4.1.2 Name, Role, Value (A)

The single most common failure: icon-only buttons with no label. VoiceOver reads "button." TalkBack reads "unlabeled."

// ❌ Screen reader says: "button"
<Pressable onPress={onDelete}>
  <TrashIcon />
</Pressable>

// ✅ Screen reader says: "Delete note, button. Removes this note permanently."
<Pressable
  onPress={onDelete}
  accessibilityRole="button"
  accessibilityLabel="Delete note"
  accessibilityHint="Removes this note permanently"
>
  <TrashIcon />
</Pressable>

Rules of thumb:

Labels describe what it is, not what it looks like. "Delete note," not "trash can icon."
Don't put the role in the label. "Delete button" becomes "Delete button, button."
Hints are optional and describe the result. Use them only when the label isn't enough.
Decorative images should be hidden: accessible={false} on the Image, or wrap them in a parent that sets importantForAccessibility="no" on Android.

Since React Native 0.71 you can also use the web-style aria-* props and role, which map to the same native properties:

<Pressable role="button" aria-label="Delete note" onPress={onDelete}>
  <TrashIcon />
</Pressable>

Pick one style per codebase and lint for it.

2. Expose state, not just labels

WCAG 4.1.2 Name, Role, Value (A)

A checkbox that looks checked but announces nothing about its state fails, even with a perfect label.

<Pressable
  accessibilityRole="checkbox"
  accessibilityState={{ checked: isDone }}
  accessibilityLabel="Buy groceries"
  onPress={toggle}
>
  <Checkbox value={isDone} />
  <Text>Buy groceries</Text>
</Pressable>

Other states worth wiring up: selected for tabs and segmented controls, expanded for accordions, disabled for inactive buttons, and busy while something loads.

For sliders and progress bars, use accessibilityValue:

<View
  accessibilityRole="adjustable"
  accessibilityLabel="Volume"
  accessibilityValue={{ min: 0, max: 100, now: volume }}
  accessibilityActions={[{ name: 'increment' }, { name: 'decrement' }]}
  onAccessibilityAction={(e) =>
    setVolume((v) => (e.nativeEvent.actionName === 'increment' ? v + 10 : v - 10))
  }
/>

Without accessibilityActions, screen reader users can't change the value at all; swipe up and down on an adjustable element does nothing.

3. Group related content

WCAG 1.3.1 Info and Relationships (A)

A product card with an image, title, price, and rating becomes five separate swipe stops by default. Group it so it reads as one sentence:

<Pressable
  accessible
  accessibilityRole="button"
  accessibilityLabel={`${name}, ${price}, rated ${rating} out of 5`}
  onPress={openProduct}
>
  <Image source={{ uri: photo }} />
  <Text>{name}</Text>
  <Text>{price}</Text>
  <StarRating value={rating} />
</Pressable>

Setting accessible on the parent makes it a single focusable element. The label you write replaces the children's text, so make sure it includes everything that matters.

4. Make tap targets big enough

WCAG 2.5.8 Target Size (Minimum), new in 2.2 (AA)

WCAG 2.2 requires targets of at least 24×24 CSS pixels, with spacing exceptions. That's the legal floor. Apple's Human Interface Guidelines recommend 44×44 points and Material Design recommends 48×48 dp; aim for those.

You don't have to make the icon bigger. Use hitSlop to expand the touchable area:

<Pressable
  onPress={onClose}
  accessibilityRole="button"
  accessibilityLabel="Close"
  hitSlop={{ top: 12, bottom: 12, left: 12, right: 12 }}   // 20pt icon → 44pt target
>
  <CloseIcon size={20} />
</Pressable>

Watch for adjacent targets: two 24-point icons touching each other technically pass the size rule but are still hard to hit. Leave space between them.

5. Provide alternatives to dragging

WCAG 2.5.7 Dragging Movements, new in 2.2 (AA)

If a feature only works by dragging (reordering a list, a swipe-to-delete row, a range slider), there must be a single-pointer alternative. Typical fixes:

Swipe-to-delete → also show a delete action in a long-press menu or an edit mode.
Drag-to-reorder → add "Move up" and "Move down" buttons, or expose them as accessibility actions:

<View
  accessible
  accessibilityLabel={item.title}
  accessibilityActions={[
    { name: 'moveUp', label: 'Move up' },
    { name: 'moveDown', label: 'Move down' },
  ]}
  onAccessibilityAction={(e) => move(item.id, e.nativeEvent.actionName)}
/>

Screen reader users reach these through the actions rotor on iOS and the actions menu on Android.

6. Keep focus visible and unobscured

WCAG 2.4.7 Focus Visible (AA), 2.4.11 Focus Not Obscured (Minimum), new in 2.2 (AA)

Mobile users navigate with keyboards, switch control, and external devices more than most developers assume. The rule in 2.2: when an element receives focus, it can't be completely hidden behind something else, like a sticky footer, a floating action button, or a cookie banner.

In practice:

Don't remove focus indicators on TextInput and custom buttons.
Pad scroll views so the last focusable item can scroll clear of a sticky bottom bar (contentContainerStyle={{ paddingBottom: footerHeight }}).
Test with a hardware keyboard on iPad and with Switch Access on Android.

7. Trap focus in modals

WCAG 2.4.3 Focus Order (A)

When a modal opens, screen reader focus should move into it and stay there. React Native's built-in Modal handles this on both platforms. Custom overlays (a bottom sheet built from an absolutely positioned View) usually don't.

For custom overlays, hide everything behind them:

<View
  importantForAccessibility={sheetOpen ? 'no-hide-descendants' : 'auto'}  // Android
  accessibilityElementsHidden={sheetOpen}                                  // iOS
>
  <MainContent />
</View>
{sheetOpen && (
  <View accessibilityViewIsModal>   {/* iOS: ignore siblings */}
    <BottomSheetContent />
  </View>
)}

Then move focus to the sheet's heading when it opens:

const headingRef = useRef(null);

useEffect(() => {
  if (sheetOpen && headingRef.current) {
    const tag = findNodeHandle(headingRef.current);
    if (tag) AccessibilityInfo.setAccessibilityFocus(tag);
  }
}, [sheetOpen]);

8. Announce changes nobody can see

WCAG 4.1.3 Status Messages (AA)

"Item added to cart," "Saved," "3 results found." Sighted users see a toast; screen reader users hear nothing unless you announce it.

import { AccessibilityInfo } from 'react-native';

const addToCart = async () => {
  await api.addToCart(id);
  AccessibilityInfo.announceForAccessibility('Added to cart');
};

On Android you can also mark a region as live so updates are read automatically:

<Text accessibilityLiveRegion="polite">{resultCount} results</Text>

9. Support text scaling to 200%

WCAG 1.4.4 Resize Text (AA), 1.4.10 Reflow (AA)

React Native scales Text with the system font size by default. The failures come from layouts that can't handle it: fixed heights, single-line rows, and text that clips.

Don't disable scaling with allowFontScaling={false}. If a specific element genuinely can't grow (a tab bar label), cap it with maxFontSizeMultiplier={1.5} instead.
Avoid fixed heights on containers that hold text. Use minHeight.
Let rows wrap. flexWrap: 'wrap' or a column layout at large sizes.
Test at the largest accessibility size, not just the largest standard size. On iOS that's Settings → Accessibility → Display & Text Size → Larger Text.

10. Meet contrast minimums

WCAG 1.4.3 Contrast Minimum (AA), 1.4.11 Non-text Contrast (AA)

4.5:1 for body text
3:1 for large text (18pt, or 14pt bold) and for UI components like input borders, icons, and focus indicators

The usual offenders are light grey placeholder text, disabled-looking secondary buttons that aren't actually disabled, and thin icon strokes on colored backgrounds. Check both light and dark mode; a palette that passes in one often fails in the other.

Also: don't use color alone to convey meaning (1.4.1). An error field needs an icon or text, not just a red border.

11. Respect reduced motion

WCAG 2.3.3 Animation from Interactions (AAA, but widely expected)

import { AccessibilityInfo } from 'react-native';

const [reduceMotion, setReduceMotion] = useState(false);

useEffect(() => {
  AccessibilityInfo.isReduceMotionEnabled().then(setReduceMotion);
  const sub = AccessibilityInfo.addEventListener('reduceMotionChanged', setReduceMotion);
  return () => sub.remove();
}, []);

If you use Reanimated, useReducedMotion() does the same in one line. When reduce motion is on, replace slides and parallax with fades or instant transitions.

12. Don't make people re-type or memorize

WCAG 3.3.7 Redundant Entry (A), 3.3.8 Accessible Authentication (Minimum) (AA), both new in 2.2

Redundant Entry: if a user already entered their address in step 1 of checkout, prefill it in step 3 or offer "same as shipping."
Accessible Authentication: don't block password managers or paste. Set the right content types so autofill works:

<TextInput
  textContentType="emailAddress"      // iOS
  autoComplete="email"                // Android
  keyboardType="email-address"
/>
<TextInput
  textContentType="password"
  autoComplete="password"
  secureTextEntry
/>
<TextInput
  textContentType="oneTimeCode"       // iOS SMS code autofill
  autoComplete="sms-otp"              // Android
/>

Avoid CAPTCHAs that require transcribing distorted text. Passkeys, magic links, and biometrics all satisfy this criterion.

13. Keep help in the same place

WCAG 3.2.6 Consistent Help, new in 2.2 (A)

If your app offers help (a chat button, a support link, a phone number), put it in the same relative place on every screen that has it. A help icon in the header on one screen and in a settings submenu on another fails.

Testing: what to actually do

Automated tools catch maybe a third of issues. The rest needs a human with a screen reader.

Lint in CI. eslint-plugin-react-native-a11y flags missing roles, labels, and invalid states:

npm i -D eslint-plugin-react-native-a11y

{
  "extends": ["plugin:react-native-a11y/all"]
}

Test by role in unit tests. React Native Testing Library queries by role and label, so a test that can't find the button is also a screen reader that can't:

const deleteBtn = screen.getByRole('button', { name: 'Delete note' });
fireEvent.press(deleteBtn);

Run the platform tools.

iOS: Accessibility Inspector in Xcode (audit any simulator screen)
Android: Accessibility Scanner app from Google Play

Test manually, once per release, on real devices:

[ ] Navigate every core flow with VoiceOver (iOS) and TalkBack (Android), eyes closed
[ ] Every interactive element has a sensible label and role
[ ] Modals and sheets trap focus; closing returns focus to the trigger
[ ] Status changes are announced
[ ] Largest text size: nothing clips, overlaps, or disappears
[ ] Contrast passes in both light and dark mode
[ ] Every drag interaction has a tap alternative
[ ] Reduce motion is respected
[ ] Password managers and SMS code autofill work

Start with the 20% that fixes 80%

If you only have a day, do these in order:

Label every icon-only button.
Add hitSlop to every small target.
Fix text clipping at the largest font size.
Add accessibilityState to every checkbox, switch, and tab.
Announce toasts with announceForAccessibility.

That clears the majority of failures in a typical audit.

Building it in from the start

Retrofitting accessibility is far more expensive than starting with it. If you're generating new screens, RapidNative produces React Native and Expo code you own, so you can add the patterns above, lint for them, and keep them consistent as the app grows.

What's the accessibility bug you see most often in React Native apps? Mine is still the unlabeled icon button, every single time.

The Code Review Checklist for AI-Generated React Native (10 Things Agents Get Wrong)

Hugo Rus — Wed, 30 Sep 2026 06:44:46 +0000

AI-generated React Native code has a specific failure profile. It compiles. It renders. The screenshot looks right. And then a reviewer who's shipped a few apps opens the PR and finds the same ten problems they found in the last one.

That predictability is useful. If agents make the same mistakes, you can review for them mechanically, and you can stop most of them before they're written. This is the checklist I use when reviewing Claude Code, Cursor, or Codex output in Expo projects, with the fix for each and, where possible, a lint rule that catches it automatically.

1. Data fetching inside `useEffect`

The most common pattern in generated code:

useEffect(() => {
  supabase.from('notes').select('*').then(({ data }) => setNotes(data ?? []));
}, []);

No loading state, no error state, no refetch, no cache, and a race condition if the component remounts. The fix is a query library:

const { data: notes, isLoading, error } = useQuery({
  queryKey: ['notes'],
  queryFn: async () => (await supabase.from('notes').select('*')).data ?? [],
});

Catch it: an ESLint no-restricted-syntax rule that flags supabase.from inside useEffect, or a CLAUDE.md line: "All data fetching goes through TanStack Query hooks in src/queries/."

2. Secrets in `EXPO_PUBLIC_` variables

Agents fix a failing API call by moving the key to where it "works":

EXPO_PUBLIC_OPENAI_KEY=sk-...   # shipped to every user's device

Anything prefixed EXPO_PUBLIC_ is inlined into the JS bundle. Third-party keys belong in an Edge Function; the app calls the function with the user's session.

Catch it: a CI grep for EXPO_PUBLIC_.*(KEY|SECRET|TOKEN) that fails on matches, plus a deny rule in .claude/settings.json for reading .env.

3. Tables created without RLS

Generated migrations create the table and stop:

create table public.notes (...);
-- no "alter table ... enable row level security"

On mobile, RLS is the only security boundary, because the client key ships inside the binary.

Catch it: a CI query that fails if any public table has rowsecurity = false, and a deny-case test per table.

4. `any` everywhere, or no types at all

const handleSubmit = (data: any) => { ... }

Generated code reaches for any the moment a type gets inconvenient, which hides exactly the bugs TypeScript exists to catch.

Catch it: @typescript-eslint/no-explicit-any as an error, and npx tsc --noEmit in the agent's definition of done.

5. Inline styles mixed with the styling system

Half the components use NativeWind classes, half use style={{ marginTop: 12 }}, and a few use StyleSheet.create. Each one was locally reasonable; together they're unmaintainable.

Catch it: react-native/no-inline-styles from eslint-plugin-react-native, and a single line in the agent instructions naming the one system you use.

6. Lists without stable keys and without `FlashList`

{items.map((item, i) => <Card key={i} ... />)}

Index keys break reordering and deletion. A .map inside a ScrollView renders every item at once. Long lists need FlatList at minimum, and FlashList for anything that scrolls fast.

Catch it: react/no-array-index-key, and a review rule: any list that can exceed ~20 items uses a virtualized list.

7. No empty, loading, or error states

Generated screens show the happy path. First launch with no data renders a blank screen; a failed request renders nothing.

Catch it: a review checklist item, not a lint rule. Every screen that fetches needs three extra states. Ask the agent for them explicitly: "include loading, empty, and error states."

8. Keyboard covers the input

Forms work in the simulator and fail on a real device: the keyboard hides the submit button, and nothing scrolls.

Fix: KeyboardAvoidingView with behavior="padding" on iOS, or react-native-keyboard-controller for anything more than a login form.

Catch it: test every form on a physical device with the keyboard open. No lint rule saves you here.

9. Navigation imported from the wrong package

In Expo Router projects (SDK 56+), agents still import useNavigation from @react-navigation/native, which now creates a second navigation context and breaks routing.

Catch it: no-restricted-imports for @react-navigation/*, and the instruction "navigation comes from expo-router only."

10. Hardcoded strings and magic numbers

'Something went wrong' in twelve places, #3B82F6 in thirty, 1000 as a timeout with no name.

Catch it: a theme.ts and a strings.ts (or i18n setup) that exist before the agent starts, so it has somewhere to put them. Agents copy the structure they see.

The pattern behind the pattern

Look at the fixes: most of them are structure that existed before the agent wrote a line. A queries folder. A theme file. RLS in the migration template. Lint rules that fail the build. An instruction file that names the one way to do each thing.

Agents don't write bad code because they're bad at code. They write the code the codebase implies. Give them a codebase that implies good code, and the checklist mostly stops firing.

That's the thesis behind AppLighter: Expo + Supabase templates where the structure above (queries, theme, RLS migrations, lint config, agent instructions) is already in place, so Claude Code or Cursor extends a good codebase instead of inventing a mediocre one.

The checklist, copy-pasteable

[ ] No data fetching in useEffect; queries live in hooks
[ ] No secrets in EXPO_PUBLIC_; third-party keys in Edge Functions
[ ] Every new table enables RLS in the same migration
[ ] No any; tsc --noEmit passes
[ ] One styling system, no inline styles
[ ] Stable keys; virtualized lists for anything long
[ ] Loading, empty, and error states on every fetching screen
[ ] Forms tested with the keyboard open on a device
[ ] Navigation from expo-router only
[ ] Strings and tokens in strings.ts / theme.ts

What's on your list that isn't on mine? I'd bet the eleventh item is different for every team.

React Native Maps in Production: 7 Gotchas Nobody Warns You About

Hugo Rus — Wed, 23 Sep 2026 05:37:36 +0000

Every tutorial makes react-native-maps look easy. npx expo install, drop a <MapView>, done. Then you ship, and you meet the real map. The one with API keys that fail only in TestFlight, permission prompts that Apple rejects, and marker lists that turn your framerate into a slideshow.

Here are the seven things that would have saved me a week of debugging on my first production map screen.

1. The blank map is almost always a height problem

// Won't render. Parent has no explicit height.
<View>
  <MapView style={{ flex: 1 }} />
</View>

// Works.
<View style={{ flex: 1 }}>
  <MapView style={StyleSheet.absoluteFill} />
</View>

MapView needs an ancestor with a resolved height. flex: 1 inside a zero-height parent silently fails. StyleSheet.absoluteFill is the safest pattern.

2. `initialRegion` vs `region`: pick one and don't switch

Use initialRegion for uncontrolled maps where the user pans freely. Use region only if you have a genuine reason to re-center on every render. Otherwise you're fighting user gestures and the map feels broken.

3. API keys must be restricted per platform

An unrestricted "any bundle ID" key works in dev and gets rotated by Google abuse detection within a week of launch. Restrict:

iOS: by bundle identifier
Android: by package name + SHA-1 fingerprint

Do this on day 1. Rotating a key that's already in the wild is painful.

4. Location permission ordering matters

const fg = await Location.requestForegroundPermissionsAsync();
if (fg.status !== 'granted') return;
const bg = await Location.requestBackgroundPermissionsAsync();

You cannot get background permission on iOS without foreground first. And do not request permission on app launch. Ask when the user taps a "show my location" button. Apple reviewers will reject an unexplained cold prompt.

5. `Accuracy.BestForNavigation` will kill your battery

Location.getCurrentPositionAsync({
  accuracy: Location.Accuracy.Balanced,  // 👈 default for 99% of apps
});

BestForNavigation is for driving and running apps that literally need meter-level precision. It's roughly 10x the battery drain of Balanced. Apple reviewers do notice.

6. `watchPositionAsync` leaks if you don't clean it up

useEffect(() => {
  let sub: Location.LocationSubscription | undefined;
  (async () => {
    sub = await Location.watchPositionAsync(
      { accuracy: Location.Accuracy.Balanced, distanceInterval: 5 },
      (loc) => setPosition(loc.coords),
    );
  })();
  return () => sub?.remove();   // 👈 THIS line
}, []);

Forget the sub?.remove() and every screen visit adds a permanent GPS listener. Users notice the battery drain within a day.

7. Every `<Marker>` is a native view

Above roughly 200 to 300 markers on Android, frames drop. Above 2,000, iOS runs out of memory. Two fixes:

Cluster with react-native-map-clustering (a drop-in MapView replacement built on supercluster).
Bitmap markers. Set image={require('./pin.png')} instead of rendering React children. Native views for markers are cheap; React trees inside markers are expensive.

If you must render custom React markers, wrap them in React.memo and hoist all callbacks. Otherwise every pan re-renders every marker.

Bonus: expo-maps vs react-native-maps in 2026

Short version:

react-native-maps: huge community, works in Expo Go, needs a config plugin. The default choice.
expo-maps: SwiftUI and Jetpack Compose under the hood, faster startup, iOS 17+ only, no Expo Go. Good for greenfield apps.

For most teams shipping today, react-native-maps is still the safer bet, because every LLM, every Stack Overflow answer, and every AI code assistant still assumes it.

Speaking of which: the entire scaffold above (maps, permissions, markers, backend) can also be generated end to end from a prompt on RapidNative, if you'd rather skip the 400 lines of boilerplate and go straight to the differentiated part of your app.

Boilerplate That Actually Ships: What to Include (and Cut) in a 2026 React Native Starter

Hugo Rus — Wed, 23 Sep 2026 05:33:08 +0000

Why most React Native boilerplates fail past week 2

Boilerplates optimize for the wrong number. The number that matters isn't screens included. It's time-to-first-paid-user. Every extra screen, every extra library, every unused abstraction is a tax you pay on the second refactor. The boilerplates that survive past week 2 keep the surface area small and the defaults opinionated.

The five must-includes

Auth with session restore on cold start. Sign in with Apple wired, refresh tokens handled, and a password reset that doesn't 404 in production. The scaffold that skips this rebuilds it under pressure in month one.
Payments end to end. Stripe or RevenueCat, with one test charge working in TestFlight. Not a screen with a Buy button. A working flow. Payments is the plumbing every indie dev underestimates.
EAS Build + Submit wired. eas.json filled with staging and production profiles. GitHub Actions or manual submit, either works, but the pipeline must exist. If your first submission takes longer than an hour, that's a leading indicator of shipping never.
A real error boundary. react-native-error-boundary or a custom top-level catch, plus a crash-log SDK like Sentry or Bugsnag. Silent JS crashes in prod are the number one reason indie apps ship a broken v1.
OTA update channels. expo-updates with channel-level control. Push a JS bundle to a beta channel, promote to production without touching the app-store binary. This is where "faster to build" becomes "faster to fix".

The five to cut by default

The navigation grab-bag. Pick one (expo-router with typed hrefs) and delete the others. Multiple navigators in one boilerplate is a smell.
Animation libraries "just in case". Don't ship reanimated + moti + lottie + a bespoke animation hook. Include one and document why.
In-house UI kits. Every custom Button component is a maintenance burden. Use platform primitives or a maintained design-system library (Tamagui, Restyle), not a hand-rolled kit that will diverge.
Redux for a v1 app. Zustand or Jotai handles it. Redux plus Redux Toolkit plus RTK Query is 300 lines of setup before your first fetch.
The "example" screens. Delete the calendar demo, the chat demo, the map demo. They confuse new devs and drift into stale APIs.

The rename-screen test

Here's a one-minute audit for any starter you're evaluating. Rename screens/Home.tsx to screens/Dashboard.tsx. Everything that survives without manual patching (router, deep links, typegen) is a real boilerplate. Anything that needs a find-and-replace is a demo dressed up as one.

A pragmatic 2026 stack

Framework: Expo SDK 53+, expo-router with typed hrefs
State: Zustand for client, TanStack Query for server
Auth + DB: Supabase (or tinbase for local-first and self-host)
Payments: Stripe SDK + Payment Sheet
Style: Restyle or unistyles, design tokens on day one
CI: GitHub Actions + EAS Build with staging and prod profiles

The folder-deletion principle

The best RN scaffold is one you can delete a folder from. Every project ships a subset, and your job as a maintainer is to make the deletion trivial. We built RapidNative to generate React Native + Expo apps that start from these defaults. Grab it, or clone your own. The principles matter more than the repo.

Delayed Push Permissions in React Native: Why the Third-Session Prompt Wins

Hugo Rus — Wed, 16 Sep 2026 04:58:11 +0000

Prompt-on-install caps push acceptance at ~45%; a third-session gate lifts it to ~78%
Session count is a proxy: tie the prompt to a habit moment when you have one
Skip the iOS pre-permission modal (net -6pp in practice)
Already shipped? Linking.openSettings() is your only recovery path

Most React Native tutorials on push notifications skip the single decision that matters most: when to ask.

The default in every boilerplate is to prompt on install day, usually in the onboarding flow. That decision quietly caps your addressable notification audience at whatever fraction of users don't tap "Don't Allow" during the least trusting three seconds of their relationship with your app. Across the RapidNative-built apps we can see, that fraction is about 45%.

Move the prompt to after the third session — or better, tie it to a habit-forming moment — and acceptance climbs to about 78%. The change is a 3-line delta in your app entry file. This post walks through the pattern.

What "the third session" actually means

You don't need a fancy engagement model. Track sessions in AsyncStorage:

import * as Notifications from 'expo-notifications';
import AsyncStorage from '@react-native-async-storage/async-storage';

const SESSION_KEY = 'session_count';
const PROMPTED_KEY = 'push_prompted';

export async function maybeAskForPushPermission() {
  const already = await AsyncStorage.getItem(PROMPTED_KEY);
  if (already) return;

  const rawCount = await AsyncStorage.getItem(SESSION_KEY);
  const count = parseInt(rawCount ?? '0', 10) + 1;
  await AsyncStorage.setItem(SESSION_KEY, String(count));

  if (count < 3) return;

  const { status } = await Notifications.requestPermissionsAsync();
  await AsyncStorage.setItem(PROMPTED_KEY, 'true');
  return status;
}

Call maybeAskForPushPermission() from your root layout's useEffect, not from onboarding. The user sees the prompt on their third open, in a moment where they've already decided your app is worth returning to.

Why the habit-moment version is better

Session count is a proxy. The signal you actually want is "user just completed a meaningful action." Tie the prompt to the completion event instead:

async function onFirstJournalEntrySaved() {
  await AsyncStorage.setItem('has_first_entry', 'true');
  await maybeAskForPushPermission();
}

Now the permission prompt lands in the exact second the user is thinking "I could see myself using this again." Different question in the user's head. Different answer.

The iOS-specific trap: pre-permission modal

The pattern iOS teams reach for — showing your own custom "Would you like push?" modal before triggering the real prompt — has a subtle failure mode. If the user taps "Yes" on your modal and "Don't Allow" on the real one, you cannot re-prompt. iOS is one-and-done.

Skip the pre-modal unless you have data that your specific audience needs it. In our tests it dropped acceptance by 6 percentage points net, because "yes to modal + no to real prompt" was a bigger cohort than "no to modal at all."

What to do if you already shipped with prompt-on-install

You cannot re-prompt users who already denied. But you can:

Add the delayed prompt for new installs.
Build a settings page that deep-links to the iOS Settings > Notifications page for your app, so denied users can re-enable manually. Linking.openSettings() handles this.
Show the deep-link once, in-app, at a habit moment. Don't nag.

The whole thing in ~20 lines

import * as Notifications from 'expo-notifications';
import AsyncStorage from '@react-native-async-storage/async-storage';
import { Linking } from 'react-native';

const SESSION_KEY = 'session_count';
const PROMPTED_KEY = 'push_prompted';

export async function maybeAskForPushPermission(force = false) {
  if (await AsyncStorage.getItem(PROMPTED_KEY)) return;

  const count = parseInt((await AsyncStorage.getItem(SESSION_KEY)) ?? '0', 10) + 1;
  await AsyncStorage.setItem(SESSION_KEY, String(count));
  if (count < 3 && !force) return;

  const { status } = await Notifications.requestPermissionsAsync();
  await AsyncStorage.setItem(PROMPTED_KEY, 'true');
  return status;
}

// Recovery flow for users who already denied
export async function openNotificationSettings() {
  const { status } = await Notifications.getPermissionsAsync();
  if (status === 'denied') await Linking.openSettings();
}

That is the pattern. Session-count gate, tie to a habit moment if you can (pass force = true from the completion event), use Linking.openSettings() for the recovery flow.

Something like RapidNative ships this gate in its generated Expo projects by default, so if you're scaffolding a new app the prompt is already off line 3 before you've written anything.

Don't ship the 45% cap

The point of writing this up is not that it's complex. It's that this is the highest-leverage thing you can do to your push notification stack this quarter, and most React Native tutorials still show you requestPermissionsAsync() on line 3 of the app.

If you've measured acceptance before and after moving the prompt, drop a comment with your numbers. Curious whether the third-session threshold holds across categories or whether it's a journaling/fitness thing.