DEV Community: Lucas Martin

Every EAS Submit Failure Mode I've Hit in Six Months (and What Catches Each Pre-Submit)

Lucas Martin — Wed, 16 Sep 2026 05:23:13 +0000

eas submit succeeding tells you the upload worked. It tells you nothing about whether the store will accept it
Six failures in six months, every one of them green in the terminal and red in App Store Connect or Play Console the next morning
Each one cost roughly a calendar day, because store review and processing don't run on your clock
All six are catchable before you run submit. The checks are at the bottom

I've submitted something like forty builds through EAS this year across a handful of Expo apps. The CLI has failed on me maybe twice. The store has bounced me six different ways, and in every case the terminal said "Submitted" and I went to bed.

That gap, green CLI and red store, is the whole story. eas submit validates that your credentials work and the binary uploaded. Everything else lives in App Store Connect or Play Console, and neither of those tells you anything until a human or a batch job gets to it, usually the next day.

Here's each failure in the order I hit them, and the pre-submit check that would have caught it.

1. Wrong `ascAppId`: the build went to the wrong app

I had two apps in the same Apple team, one production and one white-label. Both eas.json files were copy-pasted. Both had the same ascAppId.

{
  "submit": {
    "production": {
      "ios": {
        "appleId": "me@example.com",
        "ascAppId": "1234567890",
        "appleTeamId": "ABCDE12345"
      }
    }
  }
}

The white-label build uploaded cleanly into the production app's TestFlight. Bundle identifier mismatch? Apple doesn't check that at upload time against ascAppId. It processed the build, attached it to the wrong app record, and I found out when a production tester asked why the icon had changed.

What catches it: compare ascAppId against the bundle identifier before submitting. The App Store Connect API gives you this in one call:

# returns bundleId for the app record ascAppId points at
curl -s -H "Authorization: Bearer $ASC_JWT" \
  "https://api.appstoreconnect.apple.com/v1/apps/$ASC_APP_ID" \
  | jq -r '.data.attributes.bundleId'

If that doesn't equal ios.bundleIdentifier in app.json, stop. I run this as the first line of a presubmit.sh now.

2. The two things only App Store Connect knows about

Two separate failures, same root cause: the store needed something the binary can't carry.

In-app purchases not attached to the version. The IAP products existed. They were approved. They weren't attached to the app version I submitted for review, because that's a checkbox on the version page in App Store Connect, not anything in the build. The reviewer opened the paywall, tapped a product, got nothing, and rejected under 2.1.

Missing export compliance. The build sat in TestFlight with a yellow "Missing Compliance" badge and wouldn't distribute externally until someone answered the encryption question. That's a manual step in the TestFlight UI on every build, unless you declare it in the binary:

{
  "expo": {
    "ios": {
      "config": {
        "usesNonExemptEncryption": false
      }
    }
  }
}

What catches it: usesNonExemptEncryption in app.json removes the compliance prompt permanently (assuming you're only using standard HTTPS, which is what the false means). For IAP, there's no config-side fix; it's a pre-submit checklist item: open the version in ASC, confirm every product is attached, then submit. Every time.

3. TestFlight external testers stopped getting builds

I had an external tester group of about thirty people. I submitted a new build, it processed, and nobody got it. The group hadn't vanished, but the build wasn't in it.

External groups don't automatically receive new builds unless "Automatic distribution" is on for the group, and each build still has to clear beta review first. I'd been manually adding builds to the group for months without realizing it, then forgot once.

What catches it: turn on automatic distribution for the group in TestFlight, once. Or, if you want it explicit, add the build to the group from the pipeline after submit using the ASC API's betaGroups/{id}/relationships/builds endpoint. Either way, don't rely on remembering.

4. Play Console blocked the release on Data Safety

The AAB uploaded. The release page showed one error: "Your Data safety section is incomplete." That section is a questionnaire about every category of data the app collects, and it has to be completed before the first production release. It's also easy to invalidate: add an analytics SDK, change your answers, or the next release is blocked again.

There are four of these gates on the Play side and none of them are in the build: Data Safety, Content Rating questionnaire, Target Audience, and the Ads declaration. Miss any one and the release button is disabled.

What catches it: open the Policy → App content page before you build, not after. Everything on that page with a "Start" or "Update" button is going to block you. New Play Console accounts also have to run a 14-day closed test with at least 12 testers before production access is granted, which isn't a submit failure so much as a submit-two-weeks-later.

5. Android `versionCode` already used

Version code 42 has already been used. Try another version code.

This one is the most CLI-adjacent of the six, and it still comes from the store, not from EAS. It happened because versionCode was set in app.json and I'd built twice without bumping it. It also happens when a build goes to internal testing and then a rebuild goes to production with the same code.

What catches it: let EAS own the number.

{
  "cli": { "appVersionSource": "remote" },
  "build": {
    "production": { "autoIncrement": true }
  }
}

With appVersionSource: remote, the version lives on EAS servers and autoIncrement bumps it per build. eas build:version:get shows you the current value if you want to sanity-check it against Play Console before submitting.

6. iOS screenshots at the wrong pixel size

App Store Connect rejects screenshot uploads whose dimensions don't match one of Apple's exact device sizes. Not "roughly a phone." Exact. My designer exported at 1284×2778 (an older 6.5" size) when the required set for the listing was 6.9" at 1320×2868. The submission was blocked on the version page until every slot was filled with the right size.

What catches it: check dimensions before uploading. On macOS:

for f in screenshots/ios/*.png; do
  sips -g pixelWidth -g pixelHeight "$f" | awk -v f="$f" 'NR>1{printf "%s ", $2} END{print f}'
done

Then compare the output against Apple's current screenshot specifications for the device sizes you're targeting. The required sizes change when new devices ship, so don't hardcode them; link to the spec page in the checklist.

The pattern

Green CLI, red store, one day each. Six days of calendar time lost to things that took under an hour to fix once I knew what they were. None of them are Expo's fault. eas submit does exactly what it says. The failures all live in the layer between the upload and the review, which nothing in the codebase can see.

The pre-submit checklist that came out of this:

ascAppId resolves to the same bundle ID as app.json
usesNonExemptEncryption set; IAP products attached to the version in ASC
TestFlight external groups on automatic distribution
Play Console App content page has zero pending items
appVersionSource: remote and autoIncrement on
Screenshot dimensions verified against Apple's current spec

Steps 1, 2 (compliance), 5, and 6 are scriptable. Steps 2 (IAP), 3, and 4 are a human opening a browser tab, which is exactly why they get skipped.

That human-in-the-browser layer is what LetsDeployIt exists for: they take Expo apps through the store side, with a person checking each of these gates, so the submit you run at 11pm is the last one. If you'd rather own it yourself, the six checks above are the whole list, at least until I hit number seven.

What's the one that got you? I've heard rumors about Play's pre-launch report flagging a crash in the sample app that isn't reachable from the real UI, but I haven't seen it myself yet.

Docker Alternatives for Local Postgres Dev: A 2026 Comparison

Lucas Martin — Mon, 07 Sep 2026 13:53:34 +0000

Podman and Colima swap the container runtime; RAM stays ~1.4-1.6 GB because the 12 containers stay
PGlite drops to ~80 MB but you rebuild auth/realtime/storage yourself
A single-process Supabase-compatible stack (Tinbase) lands at ~100 MB with the supabase-js SDK unchanged
Pick by which trade-off hurts: prod parity, laptop RAM, or SDK compatibility

Docker Desktop pricing changes and RAM overhead have pushed the "Docker alternatives" conversation from niche to mainstream. For Postgres-backed local development specifically (Supabase-style stacks, Prisma + Postgres, or any full-stack app with a real DB), the choices in 2026 are richer than they were a year ago. This is a hands-on comparison of the five approaches I tested, with real numbers on RAM, boot time, and dev ergonomics.

The setup

All measurements from a 16 GB MacBook Pro M2, same test workload: a Next.js app with 12 tables, auth, and a realtime subscription. Each backend booted cold, the app started, one user created via auth, one INSERT made against a subscribed table. RAM via docker stats (container approaches) or Activity Monitor (host processes). Boot time is wall-clock from start command to the dev server successfully querying the database. Your numbers will differ; the ratios probably won't.

Approach 1: Docker Compose + Supabase (baseline)

The standard: supabase start spins up 12 containers.

RAM: ~1626 MB across the containers
Boot: 45s cold, 12s warm
Disk: ~2.3 GB of images

supabase init
supabase start

Works out of the box, mirrors prod behavior, has the whole ecosystem behind it. The RAM cost is the price of admission.

Approach 2: Podman + Supabase

Same compose file, different runtime.

RAM: ~1580 MB
Boot: 42s cold
Disk: ~2.3 GB

brew install podman
podman machine init && podman machine start
DOCKER_HOST=unix:///tmp/podman.sock supabase start

The Docker Desktop licensing question goes away, but the RAM and boot story barely moves. Podman is a "get Docker Desktop off my machine" solution, not a "make local dev faster" solution.

Approach 3: Colima + Supabase

Colima wraps Lima for a Docker-compatible daemon with a lighter host VM.

RAM: ~1420 MB
Boot: 38s cold
Disk: ~2.3 GB

brew install colima docker
colima start --cpu 4 --memory 4
supabase start

Better than Docker Desktop on RAM, still 12 containers. The savings come from a lighter VM, not a different architecture.

Approach 4: PGlite + custom auth (no containers)

PGlite is Postgres compiled to WASM, running in-process. Great for tests and prototyping, but you build the rest of the stack yourself.

RAM: ~80 MB
Boot: ~2s
Disk: ~50 MB

import { PGlite } from '@electric-sql/pglite';
const db = new PGlite('./data');
await db.exec("CREATE TABLE users (...)");

No auth, no realtime, no storage: you build or stub each. Perfect for a solo prototype where you aren't testing the auth flow. Painful the moment you need Supabase's actual features.

Approach 5: Single-process Supabase-compatible (Tinbase)

Tinbase runs Postgres semantics plus auth, storage, realtime, and edge functions as one process that speaks the supabase-js wire protocol. It's built on PGlite under the hood, started with one command, and it's young: the project itself labels it alpha, aimed at local dev, prototypes, and embedded use rather than production.

RAM: ~100 MB
Boot: ~3s cold
Disk: ~58 MB

npx tinbase start

Then in the app, no client changes:

import { createClient } from '@supabase/supabase-js';
const supabase = createClient('http://localhost:54321', LOCAL_KEY);
await supabase.auth.signUp({ email, password });
await supabase.from('todos').insert({ title: 'hi' });

RLS policies, auth.uid(), triggers, and foreign keys behave like Postgres because underneath it is Postgres.

Summary table

Approach	RAM	Boot cold	Disk	SDK compat
Docker Supabase	1626 MB	45s	2.3 GB	Native
Podman Supabase	1580 MB	42s	2.3 GB	Native
Colima Supabase	1420 MB	38s	2.3 GB	Native
PGlite	80 MB	2s	50 MB	None (raw Postgres)
Tinbase	100 MB	3s	58 MB	Native

When to pick what

Docker Supabase: team-shared staging, maximum prod parity, when RAM isn't your bottleneck.
Podman: you specifically want off Docker Desktop for licensing; everything else stays.
Colima: same as Podman with slightly better macOS ergonomics.
PGlite: unit tests, browser-side Postgres, prototypes without auth requirements.
Tinbase: local dev where you need Supabase's actual feature set (auth, realtime, RLS) without Docker's weight. Solo work, laptop-bound teams, workshop demos.

If prod parity is non-negotiable, stay on Docker. If your laptop is the bottleneck, the single-process end of the spectrum is dramatically cheaper for equivalent SDK compatibility.

Conclusion

The RAM delta between the two ends here (1626 MB vs 100 MB) is not a marginal optimization; it's the difference between a laptop that thermal-throttles at 11am and one that doesn't. Try the swap for a week and keep Docker Compose around for when you need it. Tinbase is open source under MIT; the repo is github.com/tinbase/tinbase if you want to read the code or the caveats first.

What's your local Postgres setup, and what's it actually costing you in RAM? Run the same five-minute measurement and drop your numbers in the comments; I'll add interesting configs to the table.

Why PGlite Is Quietly Fixing the Open-Source Contributor Onboarding Problem

Lucas Martin — Fri, 04 Sep 2026 13:32:48 +0000

First-time contributors bounce off docker-compose setups; maintainers never see it happen
PGlite (WASM Postgres) makes dev setup three commands: clone, install, run
For shared local staging or CI, single-binary Postgres runtimes are the middle path
If clone-to-running takes more than 15 minutes, your project has a cliff

I watched a first-time open-source contributor try to run a Supabase-based project locally last week. They wanted to fix a small typo in the auth UI. Simple issue. Two-line PR.

Here's what actually happened:

Clone repo. Run docker-compose up.
Port 5432 in use (their local Postgres). Change to 5433.
Port 3000 in use (their Grafana). Change to 3001.
Docker Desktop asks to update. Update.
Studio container fails: outdated image. Pull.
kong container OOM-kills. Bump memory.
Auth container can't reach db. Wait for readiness probe.
Realtime container just... never starts.

45 minutes in, they closed the tab and worked on a different project.

This is not a hypothetical. It's the modal experience of a first-time contributor to any Supabase-based (or generally, any docker-compose-heavy) project in 2026.

The contributor cliff

For maintainers, the cost of this is invisible. You already have the containers cached, the ports settled, the memory bumped. docker-compose up takes 30 seconds on your machine. You never see the contributor who bounces because their laptop is 8 GB and Docker Desktop already eats 4 of them.

But the contributor cliff is real, and it's the single biggest factor in how fast a project's contributor base grows.

PGlite changes the first-commit experience

PGlite is Postgres compiled to WebAssembly. Full Postgres semantics (types, constraints, transactions, RLS, a supported extension set) running in the browser or in Node with no server to spin up. It boots in milliseconds.

For OSS projects that need Postgres in dev, PGlite is a legitimate onboarding fix. Instead of a 45-minute docker-compose adventure, the contributor experience becomes:

git clone repo
npm install
npm run dev

That's the whole thing. The dev server boots PGlite in-process, runs migrations, seeds fixtures, and the app is running against real Postgres.

Case study: a real migration

A project I contributed to recently made this shift. The prod stack is Supabase Cloud. The dev stack used to be docker-compose Supabase. Now the dev stack is PGlite for the DB + a lightweight mock for auth.

Observable results after two months:

First-time contributor merge rate: 12% → 34%
Median time-to-first-PR after clone: 4 hours → 45 minutes
Contributor questions in Discord about setup: dropped ~80%

The auth mock is the honest trade-off. It doesn't perfectly mirror Supabase's session model, so some auth-specific PRs still need the full stack. But for the 80% of PRs that touch UI, DB schemas, or business logic, the local dev experience is transformed.

When PGlite isn't enough: single-binary Postgres

PGlite is per-client. It can't back a multi-user local staging environment, and long-lived browser persistence has practical limits.

For projects that need a shared local backend (a designer and an engineer both hitting the same DB, or CI running e2e tests against persistent state), the emerging middle path is single-binary Postgres runtimes. Tinbase is one: real Postgres plus auth, realtime, and edge functions in a single executable (~58 MB, ~100 MB RAM), booting in a couple of seconds, no Docker.

The shape of the local stack becomes:

PGlite → embedded in the dev server for the fastest first-commit path
Tinbase (or similar) → for shared local staging, CI, or when features need auth/realtime that PGlite doesn't provide
Hosted Postgres → for prod

Same SQL, same wire, same auth semantics across all three tiers.

What OSS maintainers should do this quarter

Instrument your contributor drop-off. How long between clone and first successful npm run dev? If it's more than 15 minutes, you have a cliff.
Consider PGlite for dev. Even if prod is hosted Postgres, dev doesn't need to be Docker.
Document the local-dev path in the README as three commands, not thirty. If it can't be three commands, fix the tooling until it can.

The contributor experience is the product for OSS. PGlite, and the single-binary Postgres wave following it, is one of the biggest DX unlocks in years for anyone building on Postgres. Quietly, it might be the biggest OSS-growth lever of 2026.

Maintainers: how long does your project take from clone to running? Time it honestly and drop the number in the comments. Curious where the cliff actually sits across projects.

pglite vs Tinbase: different tools for different jobs

Lucas Martin — Wed, 02 Sep 2026 11:16:28 +0000

pglite: Postgres as an embeddable library (browser, Node, Bun, Deno). No network layer, no auth stack.
Tinbase: single-binary local Supabase drop-in (Postgres + auth + realtime + edge functions). Supabase-JS works unchanged.
Neither is a production database. Both make local dev, CI, and self-hosting cheaper.

The local-Postgres tooling landscape in 2026 has quietly become interesting. pglite (Supabase's WASM Postgres) has seen adoption take off. Tinbase (Shaper Studio's single-binary Supabase-compatible stack) launched recently. Docker Postgres is still the incumbent. And there's a low-grade Twitter debate about which one "wins".

Having used all three in production for different projects, I think "wins" is the wrong framing. Here's how I actually pick.

The landscape

Docker Postgres: real Postgres in a container. Well-understood. Reliable. Heavy (~500 MB image, ~200 MB RAM idle). Requires Docker itself.

pglite: Postgres compiled to WASM, embeddable in Node, browser, Bun, Deno. Under 3 MB gzipped. Perfect for scenarios where you want the SQL engine without a network layer.

Tinbase: single-file executable (~58 MB, ~100 MB RAM) that runs real Postgres plus auth, realtime, edge functions, and webhooks. Supabase-JS SDK works unchanged. Positioned as "local Supabase without Docker".

pglite's sweet spot

Use pglite when:

You need Postgres semantics in a browser (interactive SQL tutorials, in-app query playgrounds, offline-first web apps with a real DB).
You're building a Node/Bun tool that ships with an embedded DB (CLI tools, static-site generators, migration tools).
Your use case is "DB embedded in the process". You don't want networked clients, you want the SQL engine as a library.

What pglite doesn't do: it's just Postgres, so no auth, no RLS enforcement (RLS is a Postgres feature but requires role setup pglite doesn't manage for you), no realtime, no PostgREST wrapper. If you're using the Supabase SDK's .from('table').select() calls, pglite alone doesn't run those. You need to also run PostgREST or write a shim.

Real use case for us: RapidNative's marketing site has an in-browser SQL playground where visitors can query a demo schema. pglite is the entire backend for that.

Tinbase's sweet spot

Use Tinbase when:

Your production is hosted Supabase and you want your local dev to behave identically.
You want a Supabase-compatible dev environment on machines that can't spare Docker's RAM footprint (design laptops, older machines, CI runners where you're spinning up per-test).
You want to run integration tests against a real Supabase-compatible stack without paying for a hosted preview branch per PR.
You're demoing at a workshop or conference and need Postgres + auth + realtime running on a laptop with no internet.

What Tinbase doesn't do: it's not designed as a production runtime. No multi-node replication, no built-in backup infrastructure, no HA. It's optimized for local dev, CI, and single-node self-hosting.

Real use case for us: local dev + CI for a shipping mobile app. Every PR gets a spun-up Tinbase for integration tests. Contributor onboarding is git clone && tinbase start && npm test. No Docker required.

The overlap zone

Both tools can serve as "local dev Postgres for a small side project". If your app is Supabase-SDK-based, Tinbase is the shorter path. If your app talks directly to Postgres (via pg / postgres.js / node-postgres), pglite is the smaller footprint.

They're also composable. pglite for browser-side experiments in an app whose backend runs Tinbase is a legitimate architecture.

What neither replaces

Hosted Supabase in production. Both tools are local-dev, self-host, or embedded oriented. If you need multi-region replication, managed backups, or a support SLA, you're still paying Supabase (or another hosted provider). Tinbase and pglite are "local matches production behavior" tools; they're not "production" tools.

Don't run either as your prod DB for a real product. Do use both to make local dev, CI, and self-host use cases much cheaper.

Deciding: a quick rubric

"I want Postgres inside my Node/browser/Bun process" → pglite.
"I want my local dev to behave exactly like hosted Supabase" → Tinbase.
"I want the smallest possible dep for a demo" → pglite.
"I want auth + realtime + edge functions locally" → Tinbase.
"I want CI to run integration tests against a real Supabase-compatible stack" → Tinbase.
"I want a browser-based SQL playground" → pglite.

Both tools are good. The right one depends on the shape of the problem, which is usually a better answer than "the one on the frontpage of HN this week".

Curious what your local Postgres setup looks like in 2026. Drop a comment with what you're running and why.

Disclosure: I work on Tinbase. That's why the article exists. It's also why I'm confident the honest framing "here's when NOT to use us" is a stronger sales pitch than a comparison that pretends there's a single winner. Postgres tooling has always been better as an ecosystem than a competition.

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.

DEV Community: Lucas Martin

Every EAS Submit Failure Mode I've Hit in Six Months (and What Catches Each Pre-Submit)

1. Wrong ascAppId: the build went to the wrong app

2. The two things only App Store Connect knows about

3. TestFlight external testers stopped getting builds

4. Play Console blocked the release on Data Safety

5. Android versionCode already used

6. iOS screenshots at the wrong pixel size

The pattern

Docker Alternatives for Local Postgres Dev: A 2026 Comparison

The setup

Approach 1: Docker Compose + Supabase (baseline)

Approach 2: Podman + Supabase

Approach 3: Colima + Supabase

Approach 4: PGlite + custom auth (no containers)

Approach 5: Single-process Supabase-compatible (Tinbase)

Summary table

When to pick what

Conclusion

Why PGlite Is Quietly Fixing the Open-Source Contributor Onboarding Problem

The contributor cliff

PGlite changes the first-commit experience

Case study: a real migration

When PGlite isn't enough: single-binary Postgres

What OSS maintainers should do this quarter

pglite vs Tinbase: different tools for different jobs

The landscape

pglite's sweet spot

Tinbase's sweet spot

The overlap zone

What neither replaces

Deciding: a quick rubric

What App Store Reviewers Actually Do in Six Minutes

Sources and caveats

Minutes 1 to 2: install and first screen

Minutes 2 to 3: screenshots versus reality

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

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

Minutes 7 to 8: permissions and signals

What this changes

The thing reviewers actually complain about

The short version

I published my digital product's refund rate

The policy, verbatim

Why we chose this

Competitor comparison

The refund rate math

What it actually cost us

What it did not cost us

Counter-intuitive benefits

When not to do this

The part I did not expect

Full breakdown

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

Feature 1: the confirmation modal that never confirmed

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

Feature 3: the error message that blamed the user

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

A UX regression bar for AI-authored PRs

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

The four categories users whitelist

Why category beats copy

The consent conversation to have in-app

The signal every PM misses: silent delivery

Redesign around user-declared intent

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

What happens when an OTA lands

The three UX moments where OTA bites

1. Mid-session update prompt

2. Schema drift between bundle and cached state

3. Delayed adoption and support burden

The "update pending" pattern

Communicating rollbacks

When to break the invisibility rule

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

Reviewers as first-user proxies

The three demo-account failures

What to seed and why

The review-notes template

Keeping the demo account healthy across releases

1. Wrong `ascAppId`: the build went to the wrong app

5. Android `versionCode` already used