DEV Community: Lucas Martin

What App Store Reviewers Actually Do in Six Minutes

Lucas Martin — Wed, 19 Aug 2026 07:16:43 +0000

App Store review is opaque by design. The guidelines run to dozens of pages, the rejection feedback is often two sentences, and there's no visibility into what the reviewer actually touched.

This is what we've been able to reconstruct: the shape of a first-pass review, minute by minute, and what each step is really checking.

A first pass is roughly six to eight minutes, bounded by reviewer throughput
Install and first screen, screenshot comparison, account create and delete, primary flow, permissions scan
The account deletion loop eats a quarter of that budget on its own
Your description sets the expectation the reviewer then tests against
Most rejections are one of these five steps failing, not a judgement about your product

Sources and caveats

Two former App Store reviewers, both contract, both departed within the last eighteen months, interviewed anonymously. Cross-referenced against our own submission log: 200+ submissions across roughly 30 apps over three years.

Treat the reviewer accounts as single-source. The patterns line up with what we see at scale, but review procedure varies over time and between reviewers, and nothing here is Apple policy.

Minutes 1 to 2: install and first screen

They install the build, launch it, and wait for the first meaningful screen.

What's being checked:

Does it crash on launch
Does it reach a functional screen in a reasonable time
Does it behave sensibly without a network connection

That last one catches people. Reviewers do sometimes kill the connection mid-launch, and an app that shows a blank screen or a raw connection error has demonstrated it has no existence independent of a server. That reads as a wrapped website even when it isn't one.

Design for it: cache the last known good state. Don't require network on first launch if you can avoid it. Ship an offline state you designed rather than one you inherited.

Minutes 2 to 3: screenshots versus reality

They open your store listing on a second device and compare each screenshot to what the app actually shows.

What's being checked:

Are these screenshots from this build
Does the UI match the listing copy
Is anything shown that doesn't exist in the app

Design for it: regenerate screenshots every release, even when the UI barely changed. Automate it. And never reuse assets from a different app, however similar, because a screenshot that appears in two listings is the kind of signal that pulls the whole submission into a slower queue.

Minutes 3 to 5: create an account, then delete it

If your app allows account creation, they create one, use it briefly, and then try to remove it.

What's being checked:

Can they sign up with a test email, without phone verification or obscure required fields blocking them
Is there an in-app account deletion flow, which Apple requires under Guideline 5.1.1
Is deletion findable quickly from a signed-in state
Does deletion actually delete, which they may verify by attempting to sign back in

This step is worth a quarter of the entire review budget, which is wildly disproportionate to how much attention it usually gets during development.

Design for it: put the delete button in Settings, one tap deep, labelled "Delete Account" rather than buried under "Manage". Confirm intent, then actually delete. And supply a test account in the review notes that has permission to do all of this.

Minutes 5 to 7: the primary flow against your own description

They read the first paragraph of your App Store description and then try to do the thing it says.

What's being checked:

Does the app do what the listing claims
Is the primary feature discoverable without help
Does a paywall or upsell block the flow the description promised

Design for it: the first sentence of your description should describe what a user can do in their first thirty seconds. If the copy promises an AI writing assistant and the first screen is a login wall, the reviewer has found a mismatch before they've evaluated anything else. If authentication is unavoidable, ship a demo mode or a reviewer bypass and say so in the notes.

This is also the step where an overwritten description costs you. Your listing sets the expectation that the next two minutes test against, and nothing else in the review is graded against a bar you set yourself.

Minutes 7 to 8: permissions and signals

A scan of what the app asks for and anything that looks off.

What's being checked:

Are requested permissions justified by what the app does
Do the usage description strings explain why
Any entitlements that don't belong in a consumer app
Any sign this is a template with placeholder content still in it

Design for it: prune permissions ruthlessly. A note-taking app requesting contacts access is a question you don't want asked. Write usage strings that name the feature: "To let you add photos to your notes" tells a reviewer something, "Photos" doesn't.

And search your build for placeholder content before submitting. Lorem ipsum and Sample Item 1 in a shipped app suggest nobody opened the screens, which is the impression that colours everything else.

What this changes

Reviewer attention is a scarce resource. Every second they spend confused moves you closer to a rejection, and there are only about four hundred of those seconds.

The account loop is disproportionate. Two of eight minutes on sign-up and deletion, for a flow most teams treat as an afterthought. If your app has accounts, that flow deserves the same care as your primary feature.

Your description is the rubric. You write it, then get tested against it. Underpromise in the listing and overdeliver in the app, not the reverse.

The thing reviewers actually complain about

Asked what frustrates them most, both said a version of the same thing: apps where you can tell nobody on the team ever used the app end to end.

The fix is unglamorous. Walk the whole thing yourself before submitting. Then hand it to someone who didn't build it and watch them try, without helping. Fix everything they get stuck on. Then submit.

The short version

Review isn't adversarial and isn't magic. It's a few hundred seconds of a person answering a small number of specific questions about your app.

Design so those questions answer themselves, and most of the rejection surface disappears.

For teams shipping repeatedly, moving screenshots, metadata, and review notes into the release pipeline rather than reassembling them each submission removes the most common source of drift between the listing and the build. That's part of what letsdeploy.it handles.

What got you rejected, and how long did it take to work out why? The gap between the rejection text and the actual cause is the part nobody warns you about.

I published my digital product's refund rate

Lucas Martin — Fri, 14 Aug 2026 07:00:50 +0000

We sell React Native templates at $79
Refund policy: 7 days, no questions asked, processed in 2 business days
Refund rate over 6 months: 3.8%
Blended cost of the policy: ~4% of gross revenue
Would ship it identically on day one again

The policy, verbatim

- 7-day money-back guarantee, no questions asked
- Window starts from the receipt date
- Email support@shaper.studio with your order ID
- Processed within 2 business days
- Excluded: requests after 7 days, third-party API costs

That is the entire policy. There is no "unless you cloned the repo" clause. There is no "unless you used support" clause. There is no cooling-off period, no store-credit-first flow, no retention pitch. If you email us the word "refund" and your order ID within seven days, you get your money back.

Why we chose this

Three arguments won:

1. The buyer cannot inspect the product pre-purchase. With source code, the demo video and screenshots are all you get until the credit card clears. A generous refund policy is the only honest way to say "verify for yourself" in a market where verification requires purchase.

2. If we are right about the product, the policy is cheap. Low refund rate = low policy cost. If we are wrong, the refund rate tells us fast. The only losing scenario is one where our product is bad, and in that scenario we deserve to lose.

3. Refund friction is negative marketing. Every "no refunds" post triggers a Reddit thread. Not being on the wrong side of that conversation is worth something.

Competitor comparison

Vendor	Window	Conditions
Applighter	7 days	None
Instamobile	Case-by-case	Bundles non-refundable, lose rights, no refund if support was used
Typical CodeCanyon	14 days	"Not as described" (unfalsifiable in practice)
Typical premium boilerplate	0 days	All sales final

The refund rate math

At $79 with a 3.8% refund rate:

per-order refund cost = 0.038 * $79 = $3.00
plus Stripe fixed fee retained on refund = $0.30
= ~$3.30 lost per paid order

For context: a Dev.to writeup last year reported ~40% refund rate at $29 vs ~4% at $79 for a similar product. Our number matches that curve. Price is a filter. Cheap templates get impulse buyers who impulse-refund.

What it actually cost us

Refunded revenue: four-figure number over six months
Stripe fixed fees: ~30¢ per refund, kept by Stripe
Support time: ~90 min/month (5 min email + 1 click Stripe)
Opportunity cost: buyers who would have taken store credit but got cash instead
Total blended cost: ~4% of gross revenue

What it did not cost us

Reddit threads: zero
Public complaints: zero
Chargebacks: zero (chargebacks are worse than refunds — fees, disputes, reputation)
Hostile support emails: zero

Counter-intuitive benefits

Refund requests are the highest-signal feedback we get. Happy customers say nothing. Refund requests come with implicit info — which template, whether they opened the docs, whether they cloned the repo. Two refunds in one week from buyers who never opened the setup docs told us the docs were too easy to miss. We fixed the onboarding email.

Generous refunds pre-qualify buyers. "Seven days is plenty" = the buyer we want. "Seven days isn't enough" = the buyer who will not evaluate the code for months, will not ship, and will not be happy regardless.

The support inbox stays calm. "I want a refund" as a two-word conversation instead of a negotiation drops the emotional temperature. Vendors with strict policies deal with disputes, chargebacks, and public complaints. Generous refunds head off most chargebacks before they start.

When not to do this

Product under $30: impulse buyers push refund rate toward 40%. Fix: raise the price or tighten the policy.
Real marginal cost per unit: source code is zero marginal cost, so we can absorb 3.8%. Physical goods cannot.
Value fully consumed in the refund window: video courses need anti-abuse (e.g., >50% watched voids the refund) or refund rate approaches 100%.
Cannot deliver the turnaround: a 7-day policy that takes 30 days to process is worse than no policy at all.

The part I did not expect

The policy changed how we write marketing. When the buyer can call your bluff with one email and their money, you stop reaching for weasel words. Every landing page, every screenshot, every code excerpt has to hold up under "would this survive the refund window?" It is the closest thing to product-market fit pressure I have felt in a bootstrapped business.

Full breakdown

Full write-up with the internal numbers, the policy design tradeoffs, and the exact refund-request template we use: on the Applighter blog.

What Users Actually Feel When Your AI-Generated Code Is 'Fine': A UX Autopsy of 3 Shipped Features

Lucas Martin — Wed, 29 Jul 2026 04:26:33 +0000

AI-generated code is often technically correct and experientially broken — it solves the ticket, and the ticket rarely describes the feeling.
Three real examples: a confirmation modal with no friction (14 accidental account deletions), a naked payment spinner (−4.1% completion), and an error message that blamed the user (2x refund requests).
Three prompt clauses — emotional stakes, latency honesty, blame avoidance — caught ~70% of these before review.
A 4-item UX regression checklist for AI-authored PRs, none of which a linter can catch.

Three features shipped last quarter that passed every automated check, got merged by senior engineers, and quietly dragged our activation rate down by 6 percentage points before we caught it.

All three were AI-generated. None had a bug in the traditional sense. Here's what actually went wrong.

The uncomfortable truth: most AI-generated code is technically correct and experientially broken. The model doesn't know what a user feels at 11pm on a phone with 40% battery trying to check out. It writes the code that solves the ticket. The ticket almost never describes the feeling.

Feature 1: the confirmation modal that never confirmed

Ticket: "Add a delete-account button in settings with a confirmation modal."

What shipped:

<Dialog>
  <DialogTitle>Delete account?</DialogTitle>
  <DialogDescription>
    This action cannot be undone.
  </DialogDescription>
  <DialogFooter>
    <Button variant="outline" onClick={close}>Cancel</Button>
    <Button variant="destructive" onClick={deleteAccount}>Delete</Button>
  </DialogFooter>
</Dialog>

Technically perfect. Passed a11y checks. Matched the design system. Support tickets over the next three weeks: 14 users accidentally deleted their accounts.

What was missing: the type-your-username-to-confirm friction step. GitHub does it. Stripe does it. Every consequential delete flow on the internet does it. The model wrote what the ticket asked for, and the ticket didn't ask for friction — because the PM assumed "confirmation modal" implied it. It doesn't. To a model, a confirmation modal is exactly two buttons.

User interviews afterward:

"I thought Cancel was the red one because it was the destructive action."

"My thumb just... hit it. I don't even remember reading the modal."

The fix was 8 lines. The lesson was bigger: the model needs the emotional stakes in the prompt, not just the functional requirements.

Feature 2: the loading state that stole 800ms of trust

Ticket: "Add a loading spinner while the payment processes."

Shipped code, paraphrased:

{isProcessing ? <Spinner /> : <Button onClick={pay}>Pay $49</Button>}

Technically correct. But what the user saw:

Click "Pay $49"
Button disappears, spinner appears
~1.2 seconds of a spinning circle with no context
Success screen

We A/B tested it against this:

{isProcessing ? (
  <div className="flex items-center gap-2 text-sm text-muted-foreground">
    <Spinner />
    <span>{stage}</span>
  </div>
) : <Button onClick={pay}>Pay $49</Button>}

// stage cycles: "Contacting your bank..." → "Confirming payment..." → "Almost done..."

The staged labels don't reflect what's happening in the backend at all — they're just paced text. Result: completion rate on the payment step went up 4.1%. Users who felt informed didn't bounce; users who watched a naked spinner did.

The model didn't know a spinner is a UX cliff. It knew a spinner was the canonical solution for a loading state. Those are different things.

Feature 3: the error message that blamed the user

Most AI-generated error handling has this shape:

try {
  await createOrder(input);
} catch (e) {
  toast.error("Invalid input. Please check your details and try again.");
}

Every word in that message pushes the failure onto the user. "Invalid input." "Check your details." "Try again."

One user in a session recording:

"I checked. Twice. It's not my card. Forget this." (closes tab)

The actual error, from the server logs: our idempotency key collided because they'd clicked the button twice in 300ms. Nothing was invalid. The order had gone through on their first click.

Rewrite:

try {
  await createOrder(input);
} catch (e) {
  if (e.code === "idempotency_conflict") {
    toast.info("Looks like this went through already — refreshing your order list.");
    await refetchOrders();
    return;
  }
  toast.error(
    "Something on our end didn't work. Your card wasn't charged. Try again or ping support — we'll fix it."
  );
}

Two things changed: we handled the specific error case the model glossed over, and the generic fallback puts the blame on us, not the user, while telling them their card is safe. Refund requests on that flow dropped by half.

What the model can't feel — and how to compensate in the prompt

The pattern across all three: the model wrote sufficient code, not humane code. It optimizes for spec-completion, and specs are a lossy compression of what a good product feels like.

What we added to our prompts:

Emotional-stakes clause: "This flow is a delete action. Real users will lose real data if they mis-click. Design the friction accordingly."
Latency-honesty clause: "Any async call over 400ms must show a labelled progress indicator, not a naked spinner. Prefer 3 pacing labels over a single 'Loading...'."
Blame-avoidance clause: "Error messages must not use 'Invalid', 'Wrong', or 'You'. They must state what won't happen (charge, save, send) and what the user can do next."

Those three lines in a system prompt caught roughly 70% of the UX regressions we'd been finding in review after the fact.

A UX regression bar for AI-authored PRs

We now run every user-facing AI PR through a 4-item checklist before merge:

Every destructive action has a friction step proportional to its consequence.
Every async op over 400ms has a labelled progress state, not just a spinner.
Every error message names what won't happen and offers a next step.
Every empty state has a first-run tip, not just "No items yet."

None of these are things a linter can catch. They're things a person who's watched 50 hours of user-session recordings can catch. Until the model has watched those recordings too, that person stays in the loop — but the checklist makes them 4x faster.

If you're building a new SaaS and don't want to relearn these the hard way, most of the patterns above — typed-confirm modals, paced loading states, human error copy — are the kind of thing a mature template bakes in by default. The Applighter starters ship with them because they were extracted from exactly this kind of production autopsy.

Which of the four checklist items would your last AI-authored PR have failed? Mine was the naked spinner — twice.

The 4 Notification Categories Users Actually Whitelist (Based on 60 App Interviews)

Lucas Martin — Wed, 29 Jul 2026 04:11:00 +0000

Users whitelist only four notification categories: someone they know did something involving them, a thing they explicitly set up, a transaction they're expecting, and a time-critical alert from a system they trust.
Everything else — feature announcements, recommendations, streaks, re-engagement, promos — gets muted within two weeks.
Users pattern-match to category, not copy. Better push copy optimizes the wrong variable.
Per-category in-app consent (not one system prompt) moved opt-in from 41% to 73% and dropped 30-day mute rate from 34% to 9% in one test.

Over the last six weeks I interviewed 60 people about their phone's notification settings. I asked each to open Settings → Notifications, scroll through every app, and tell me the story behind why each one was on, off, or set to silent delivery.

The pattern was sharper than I expected. Users don't allow or block push app-by-app. They do it category-by-category — and they only tolerate four specific categories. Everything else gets muted within two weeks.

The four categories users whitelist

Across 60 interviews, people named the same four types of notification as ones they actively want:

1. Someone I know did something involving me. A message, a comment, a mention, a friend joining, a family member sharing a photo. Nearly everyone said they never mute these.

2. A thing I explicitly set up. Alarm, reminder, calendar event, medication, workout time. The rare exceptions had turned these off in the app itself, not in system settings.

3. A transaction I'm expecting. Delivery updates, ride arrival, payment confirmation, booking status. Widely kept on, though several used silent delivery to soften the interruption.

4. A time-critical alert from a system I trust. Bank fraud alert, security code, appointment 15 minutes out, flight delay. Trust was the load-bearing word — several people had disabled these for specific apps that had cried wolf.

Every other category — feature announcements, personalized recommendations, streak reminders, re-engagement, promos, content updates — got muted, disabled, or in a few cases triggered an uninstall.

Why category beats copy

The standard growth advice is "write better push copy." A/B test the emoji, tighten the CTA, personalize with the user's name.

That optimizes the wrong variable.

The interviews were unambiguous: users don't parse notification copy before deciding whether to keep push on. They pattern-match to the category. Once your app has sent two notifications from a category they don't want, they mute the whole app — no matter how good the copy was.

So the design question isn't "how do we write a compelling notification?" It's "how do we ensure every notification we send falls into one of the four whitelisted categories?"

The consent conversation to have in-app

The iOS system dialog is a blunt instrument: one yes/no for all future notifications. What users actually want is category-level consent — which iOS supports through notification categories, but almost no app uses well.

The pattern I now recommend:

import * as Notifications from 'expo-notifications';

type Category = 'social' | 'reminders' | 'transactions' | 'security';

async function setupNotificationCategories() {
  await Notifications.setNotificationCategoryAsync('social', [
    { identifier: 'reply', buttonTitle: 'Reply', options: { opensAppToForeground: true } },
  ]);
  await Notifications.setNotificationCategoryAsync('reminders', []);
  await Notifications.setNotificationCategoryAsync('transactions', []);
  await Notifications.setNotificationCategoryAsync('security', []);
}

async function requestConsentForCategory(category: Category) {
  const stored = await getStoredPreferences();
  if (stored[category] === 'denied') return;

  // In-app modal that explains what this category is
  const wantsIt = await showCategoryConsentModal({
    title: labelFor(category),
    example: exampleFor(category),
    frequency: frequencyFor(category),
  });

  await savePreference(category, wantsIt ? 'granted' : 'denied');

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

The in-app modal does the real work. It shows a concrete example of the notification the user would receive, states roughly how often ("a few times per week," not "occasionally"), and lets them opt in per category rather than for everything at once.

One app I tested this with saw opt-in rise from 41% to 73% by moving from a single system prompt to contextual per-category prompts. More importantly, 30-day mute rate dropped from 34% to 9%.

The signal every PM misses: silent delivery

iOS's "Deliver Quietly" lets users keep receiving your notifications but hide them from the lock screen and Notification Center. It's a soft mute — chosen when someone wants the app's data but not the interruption.

Most PMs don't track it, because iOS doesn't report it. But you can infer it: if a user's open rate on pushes drops to near-zero while their app opens stay steady, they've likely moved you to Deliver Quietly.

Segment those users. They're one bad broadcast away from a full mute or uninstall. For them, cut sends by 60–80% and fire only category 1 and 3 notifications (people-related and transactional). I've seen apps recover full-delivery status this way for a meaningful share of the quietly-delivered segment.

Redesign around user-declared intent

The biggest shift from these interviews: the notifications users keep are tied to intent they expressed inside the product. They set the reminder. They ordered the food. They followed the person. They asked the bank to alert on fraud.

The notifications they mute are tied to intent the product declared on their behalf. "We think you'd love this new feature." "We noticed you haven't opened us in a week." "Here's a personalized recommendation."

So the implication is concrete: for every notification your app sends, you should be able to trace it back to a specific in-app action the user took that constitutes consent for this notification. If you can't, it belongs in the mute pile. If you can, you're building the trust that keeps push on for the lifetime of that user.

A practical way to enforce this: require a sourceAction field on every notification in your schema — a machine-checkable link back to the user action that authorized the send. It's an annoying constraint at first. Then it becomes the reason your app is still on the lock screen six months in, when competitors have been muted.

Run the interviews yourself. Ten users, thirty minutes each. You'll come back with a notification strategy your PM would never sign off on — and your users will actually welcome.

I write more about building this kind of thing into React Native apps over at RapidNative.

Which of the four categories does your app mostly send? And have you ever caught yourself sending from the mute pile?

What OTA Updates Feel Like for Your Users (and Why It Matters)

Lucas Martin — Wed, 22 Jul 2026 10:29:07 +0000

Default Expo behaviour applies updates silently at cold start. That's only good UX if app state doesn't change between bundles.
Three places OTA bites: mid-session update prompts, schema drift between bundle and cached state, and delayed adoption creating support burden.
Fix schema drift by tagging AsyncStorage writes with a _schemaVersion and migrating or evicting at startup.
Expose the current bundle ID in Settings → About so support can diagnose "which bundle are you on?" in one question.
The technical update should be invisible. The experiential update never should be.

Every React Native OTA update tutorial focuses on the developer experience: eas update, done.

What almost nobody writes about is what happens on the user's phone when your OTA lands, and how that experience shapes whether they stay in the app or bounce.

Let's walk through it.

What happens when an OTA lands

Default Expo behaviour with checkAutomatically: "ON_LOAD":

User opens the app. Native shell launches, splash screen shows.
In parallel, the update client checks your server for a new bundle. If found and downloaded within fallbackToCacheTimeout (default 0ms — i.e. never wait), it's applied immediately.
If the timeout hit first, the cached (previous) bundle loads. The new bundle downloads in the background and is applied on next launch.

The user sees nothing. That's the design goal.

But "nothing" is only good UX if the state of the app doesn't change between the two bundles.

The three UX moments where OTA bites

1. Mid-session update prompt

You set checkAutomatically: "ON_ERROR_RECOVERY" thinking you'll only update after a crash. What you actually get: a user deep in a task, the app crashes, your OTA client fetches a new bundle — and now they're looking at a re-launched app with lost context.

Better pattern: ON_LOAD (cold start only) plus an explicit in-app "Update available — restart to apply" banner for warm-session updates.

2. Schema drift between bundle and cached state

Your new bundle expects user.profile.avatarUrl. Users upgrading from an old bundle have user.avatar in cache. Crash on first render.

Solution: version your cache schema. AsyncStorage writes should include a _schemaVersion tag, and new bundles migrate or evict old-schema data at startup.

3. Delayed adoption and support burden

A user emails "this feature is broken." You check the latest bundle — it's fixed. But they're on a bundle from three weeks ago, because they never re-opened the app long enough to complete the background fetch.

Solution: expose the current bundle ID in Settings → About. Support can ask "what does it say?" and immediately know whether they need to force an update.

The "update pending" pattern

import * as Updates from 'expo-updates';
import { useEffect, useState } from 'react';

export function useUpdatePending() {
  const [pending, setPending] = useState(false);

  useEffect(() => {
    const sub = Updates.addListener((event) => {
      if (event.type === Updates.UpdateEventType.UPDATE_AVAILABLE) {
        setPending(true);
      }
    });
    return () => sub.remove();
  }, []);

  return pending;
}

Then in your app shell:

const pending = useUpdatePending();

return (
  <>
    {pending && <UpdateBanner onRestart={() => Updates.reloadAsync()} />}
    <YourApp />
  </>
);

Show the banner unobtrusively — top of screen, dismissible. Let the user restart when they're ready.

Trust beats speed.

Communicating rollbacks

If you roll back a bundle, users who had the bad one for ten minutes may have taken some action in that window started a form, attempted a payment. They come back and the UI has changed under them.

For any rollback that touched user-visible state, ship a small in-app notice:

We reverted an update from an hour ago. If you saw errors, they should be resolved now.

Radical honesty. Most users appreciate being told rather than left confused.

When to break the invisibility rule

For truly major changes — new navigation, a redesigned home screen — an OTA that silently swaps things is worse than a store update with release notes.

Consider gating major UX changes behind an in-app "What's new" modal, even if the code shipped via OTA weeks earlier.

The whole point of OTA is that the technical update is invisible. The experiential update never should be.

If you're starting a React Native project and want the update pipeline wired from day one, RapidNative generates Expo apps with EAS Update already configured.

What's your OTA horror story? Mine was schema drift a cached object shape that crashed every returning user on first render.

Your App Store Reviewer Is a User — Design the Demo Account Like a Usability Test

Lucas Martin — Wed, 15 Jul 2026 12:48:14 +0000

Your App Store reviewer is functionally your first real user — same 30 seconds of first impression, but they can reject you.
Three demo-account failures trigger rejections: an empty account, a broken account (stale credentials), and a geofenced account.
Seed the demo account with 10–20 realistic entries, one in-progress state, and completed onboarding.
Add a review-notes walkthrough so the reviewer knows exactly what to test.
Re-seed automatically before every submission — demo accounts decay.

Most indie devs think of the App Store reviewer as a QA person: they check that the app builds, opens, doesn't crash, complies with guidelines, and passes review. That's incomplete.

The reviewer is also, functionally, your first real user. They have the same 30 seconds of first-impression time as anyone who downloads the app. If your demo account puts them in an empty state with no context, they judge the app the same way a real user would — and they can reject.

Reviewers as first-user proxies

From the reviewer's side, the process looks like this: they open your listing, install the app, launch it, and try to use it as if they'd downloaded it themselves. If your app requires auth, they use the demo account you provided.

If that demo account lands them on a blank home screen with no data, they have no way to evaluate whether the app "works."

Rejections in this category read as "your app did not have enough functionality to review" or "we could not test the primary features." Both are UX rejections dressed up as review outcomes.

The three demo-account failures

Failure 1: the empty account. The reviewer logs in and sees a blank feed, an empty list, or a "no results yet" state. There's nothing to interact with, so they can't evaluate the app's real behavior.

Failure 2: the broken account. The demo account has stale credentials, the password was rotated, or the account was disabled. The reviewer gets "invalid password" and can't proceed.

Failure 3: the geofenced account. The demo account requires a specific location, phone number, or region that the reviewer's environment doesn't match. The app looks broken through no fault of its logic.

All three are preventable with about 90 minutes of prep.

What to seed and why

Your demo account should contain, at minimum:

10–20 realistic entries in your primary data model (posts, tasks, contacts — whatever your app centers on).
One realistic "in-progress" state — a partially filled form, a saved draft, a bookmarked item.
Onboarding fully completed — the reviewer shouldn't have to walk through your welcome flow.
At least one "friend" or connection with plausible data, if the app has social features.

The goal is simple: when the reviewer opens the app, they should see something that looks like a real user's screen, not an empty state.

The review-notes template

In App Store Connect's review notes, include a block like this:

Demo account:
  Email:    reviewer@yourapp.com
  Password: <one-time-use password>

This account is pre-seeded with realistic data.
All primary features are accessible without in-app purchase.
Contact: your-email@yourapp.com if any issues.

Walkthrough (in case anything is unclear):
  1. Sign in with the credentials above
  2. The home screen shows your recent [items]
  3. Tap [primary CTA] to try the [key flow]
  4. Long-press [item] to see the [secondary flow]

A walkthrough like this cuts review times noticeably — the reviewer knows exactly what to test and how.

Keeping the demo account healthy across releases

The most common failure here is decay: the demo account drifts over time. New features get added that need new seed data. Passwords get rotated. The account gets used for real dev testing and its state wanders.

What works:

Automated re-seeding before each submission — a script that clears and reseeds the account.
A checklist item in your release process: "verify demo account signs in and shows expected data."
Never use the demo account for actual dev work — keep it review-only.

Takeaway

A polished demo account with seeded data plus a clear walkthrough is one of the highest-leverage things you can do for review outcomes. Treat the reviewer as a one-shot usability test — you have five minutes to convince them the app works.

If you'd rather not hand-build all this from scratch, RapidNative generates React Native + Expo apps with seed data and demo states you can point straight at a reviewer.

What's the most avoidable App Store rejection you've hit? Drop it in the comments.