DEV Community: Lucas Martin

React Native New Architecture in 2026: What Developers Need to Know

Lucas Martin — Mon, 12 Oct 2026 09:14:04 +0000

For years, "should we enable the New Architecture?" was a real question in React Native projects. In 2026 it isn't. The New Architecture is the only architecture React Native runs, the legacy code is being deleted release by release, and the JavaScript engine underneath it has been upgraded too.

If you're starting an app, you get all of this by default. If you're maintaining one that's a few versions behind, the gap is getting harder to cross the longer you wait. This post covers what the New Architecture actually is, how we got here, what it changes in your day-to-day code, and a practical checklist for upgrading.

What "the New Architecture" actually means

It's four pieces that replaced the old asynchronous bridge:

Piece	What it replaced	What it does
JSI (JavaScript Interface)	The JSON-serialized bridge	Lets JavaScript hold references to C++ objects and call them directly, without serializing messages
Fabric	The old UI manager	The new renderer: builds the UI tree in C++, supports synchronous layout and React's concurrent features
TurboModules	Legacy native modules	Native modules loaded lazily and called through JSI, synchronously when the method is sync
Codegen	Hand-written glue code	Generates the typed C++ interface between your TypeScript specs and native code at build time

Together they make React Native bridgeless: there's no message queue between JavaScript and native any more. Calls go straight through JSI.

The practical effects you'll notice:

Layout can be measured synchronously. useLayoutEffect behaves like it does on the web, so tooltips and popovers no longer flash in the wrong position for a frame.
Concurrent React works. Features like startTransition and Suspense behave as they do in React DOM.
Native modules start lazily, which helps startup time in apps with many modules.

How we got here

Release	What changed
0.76 (2024)	New Architecture enabled by default for new projects
0.82	New Architecture becomes the only runtime option; the opt-out flags are ignored
0.83	Experimental flag to strip legacy architecture code on iOS
0.84 (Feb 2026)	Hermes V1 becomes the default engine; legacy iOS code removed by default; precompiled iOS binaries by default
0.86 (Jun 2026)	More legacy APIs deprecated as part of the removal; repo moves to the `react` GitHub organization

A few details from the official release notes are worth knowing.

Hermes V1 is the default as of 0.84. If you were already on Hermes, which has been the default since 0.70, you get V1 automatically with no configuration changes.

Legacy code is actually being deleted, not just disabled. 0.84 continued removing Legacy Architecture code from both iOS and Android, building on 0.82 making the New Architecture the only runtime. On Android that release removed a list of old bridge classes outright.

The compatibility shim is still there. The release notes are explicit that apps already on the New Architecture shouldn't break, because the Interop Layer code required for compatibility remains in place. That's what lets many older libraries keep working, for now.

iOS builds got faster. 0.84 ships precompiled iOS binaries by default, which the team says significantly reduces build times. They're downloaded automatically during pod install.

0.86 kept the momentum, quietly. It has no user-facing breaking changes, deprecates ViewUtil.getUIManagerType as part of the legacy removal, and moves 0.83 to unsupported.

What this changes in your code

For most app code written in plain React and TypeScript, almost nothing. The differences show up at the edges.

1. Native module errors are synchronous now (for sync methods)

With the bridge, a native exception often got swallowed somewhere in the queue. With TurboModules, a synchronous native method that throws unwinds straight into your JavaScript call site. Wrap sync calls that depend on user input or device state:

function readSetting(key: string) {
  try {
    return MySettingsModule.getSync(key);   // sync TurboModule method
  } catch (e) {
    console.warn('Setting unavailable', key, e);
    return null;
  }
}

Async methods still return promises, so existing await and .catch() handling keeps working.

2. Codegen mismatches fail loudly

If your TypeScript spec says a prop is a string and the native implementation reads it as a number, you no longer get a silent no-op. You get a native crash at render. The fix is usually to regenerate and rebuild, but it's worth knowing that a hard crash on first render of a custom native component often points here.

3. Old timing hacks can now cause bugs

Code that wrapped layout reads in setTimeout(…, 0) or requestAnimationFrame to wait for the bridge often isn't needed any more, and occasionally causes a visible flicker now that layout is synchronous. When you touch that code, try the straightforward version first.

4. Your debugger changed

React Native DevTools is the debugger: press j in the Metro terminal and a Chrome DevTools-based window attaches to Hermes on your device. Remote JS debugging (running your code in Chrome's V8) is gone, which also removes a whole class of "works only when the debugger is attached" bugs. If your Metro terminal went quiet after an upgrade, your console.log output moved to the DevTools console.

Libraries: the real migration work

Your own code is rarely the blocker. Dependencies are.

Check every native dependency against the React Native Directory (reactnative.directory), which marks New Architecture support for each library. For each one, you'll land in one of three buckets:

Supports the New Architecture. Upgrade to the current version.
Works through the Interop Layer. It runs, but it's living on borrowed time as legacy code is removed. Look for an alternative or an upstream fix.
Unmaintained, doesn't work. Replace it. In 2026 there's almost always a maintained alternative, often an Expo module.

Common categories to check first: navigation, gesture and animation libraries, maps, camera, video, in-app purchases, and anything with a custom native UI component.

An upgrade checklist

If you're on a version older than 0.82, this is the order that usually goes smoothest:

[ ] Audit native dependencies against the React Native Directory and upgrade or replace the ones without New Architecture support
[ ] Upgrade React Native in steps, using the community Upgrade Helper to diff native files between versions, rather than jumping several majors at once
[ ] If you use Expo, upgrade one SDK at a time and run npx expo-doctor and npx expo install --check after each step
[ ] Check your Node version before upgrading; 0.84 requires Node.js 22.11 or later
[ ] Rebuild native projects from scratch (npx expo prebuild --clean, or clean Pods and Gradle caches) instead of trusting cached builds
[ ] Test custom native modules and components first; that's where Codegen and threading issues show up
[ ] Remove setTimeout layout workarounds you added for the bridge, and retest those screens
[ ] Wrap sync TurboModule calls that can fail in try/catch
[ ] Run release builds on real devices, not just debug builds in a simulator; many New Architecture issues only appear in release mode
[ ] Watch crash reporting closely for the first release after the upgrade, with source maps uploaded so stack traces are readable

Should you upgrade now?

If you're on 0.82 or later, you're already on the New Architecture. The remaining upgrades are mostly smooth, and staying current keeps you inside the supported window: each release moves an older one to unsupported.

If you're still on an older version, the honest answer is that it doesn't get easier. Every release removes more legacy code, and every month more libraries drop support for the old architecture. Start with the dependency audit. That alone tells you whether the upgrade is a week of work or a quarter.

Shipping an RN app in 2026 means shipping on Fabric and bridgeless by default. If you want to see what that generated code looks like without wiring any of it up yourself, RapidNative generates RN + Expo projects targeting the current stack from a prompt.

If you've migrated a real app to 0.82, I'd be curious what broke for you. Drop it in the comments.

EAS Submit in 2026: What It Automates, What It Doesn't, and the Release Pipeline That Covers Both

Lucas Martin — Thu, 08 Oct 2026 14:59:49 +0000

eas submit is one of the best things in the Expo toolchain. One command takes a production build and uploads it to App Store Connect or Google Play, from macOS, Linux, or Windows. No Xcode, no Transporter, no Play Console upload dialog.

It's also the source of a very common misunderstanding: "I ran eas submit, so my app is submitted." Not quite. EAS Submit uploads your build. Getting it in front of users still involves a handful of steps that live in the store consoles, and those are where first launches stall.

This post covers both halves: how to set up EAS Submit properly for iOS and Android (including a recent change most older tutorials get wrong), and a clear map of what it doesn't do, so you can plan for it.

What EAS Submit does

iOS: uploads your .ipa to App Store Connect. The build appears in TestFlight after processing, usually 10 to 15 minutes. You don't need a Mac.
Android: uploads your .aab to a Google Play track (internal by default) and can roll it out, leave it as a draft, or publish to production, depending on your submit profile.
Automation: runs the same way locally, in EAS Workflows, or in any CI with an EXPO_TOKEN.

Setting up iOS

1. Bundle identifier and a production build

{
  "expo": {
    "ios": { "bundleIdentifier": "com.yourcompany.yourapp" }
  }
}

eas build --platform ios --profile production

2. A submit profile with your App Store Connect app ID

Create the app record in App Store Connect first. Then add its ID to eas.json:

{
  "submit": {
    "production": {
      "ios": {
        "ascAppId": "1234567890"
      }
    }
  }
}

You'll find the ID in App Store Connect → your app → App Information → Apple ID (a number, not your email).

3. An App Store Connect API key (for anything automated)

Interactive eas submit can prompt for your Apple ID. CI and workflows can't, so set up an API key once:

eas credentials --platform ios
# production → log in → App Store Connect: Manage your API Key
#            → Set up your project to use an API Key for EAS Submit

If you prefer to manage the key yourself, set ascApiKeyPath, ascApiKeyIssuerId, and ascApiKeyId in the submit profile instead.

4. Submit

eas submit --platform ios --profile production

Setting up Android

1. Package name and an `.aab`

{
  "expo": {
    "android": { "package": "com.yourcompany.yourapp" }
  }
}

eas build --platform android --profile production

The default production profile produces an Android App Bundle (.aab), which Google Play requires. An .apk profile is useful for installing on devices but can't be submitted.

2. Create the app in Play Console

EAS can't create the app record. Click Create app in Play Console and choose the package name.

3. A Google Service Account key

EAS needs a service account key to upload on your behalf. Create one (Expo links a step-by-step guide from its docs), then upload it:

eas credentials --platform android
# production → Google Service Account → Upload a Google Service Account Key

4. A submit profile

{
  "submit": {
    "production": {
      "android": {
        "track": "internal",
        "releaseStatus": "draft"
      }
    }
  }
}

track picks where the build lands: internal, alpha (closed testing), beta (open testing), or production.
releaseStatus: "draft" uploads without rolling out, so you can review and release in Play Console.

5. Submit

eas submit --platform android --profile production

The change older tutorials get wrong

For years, every Expo guide said the same thing: you must upload your first Android build manually in Play Console before EAS Submit will work. Expo's current docs say otherwise. On a first submission, the default eas submit works out of the box and creates the app's first release on the internal testing track, as long as the app exists in Play Console and EAS has your service account key.

The app stays in draft status in Play Console until you finish the store listing and setup tasks. Which brings us to the other half.

Build and submit in one step

eas build --platform all --profile production --auto-submit

--auto-submit hands each finished build to EAS Submit using the submit profile with the same name.

Automate it with EAS Workflows

Workflows are YAML files in .eas/workflows/. This one builds both platforms on every push to main, sends iOS to TestFlight, and uploads Android to your configured track:

# .eas/workflows/release.yml
name: Release

on:
  push:
    branches: ['main']

jobs:
  build_ios:
    name: Build iOS
    type: build
    params:
      platform: ios
      profile: production

  build_android:
    name: Build Android
    type: build
    params:
      platform: android
      profile: production

  testflight:
    name: Send to TestFlight
    needs: [build_ios]
    type: testflight
    params:
      build_id: ${{ needs.build_ios.outputs.build_id }}

  submit_android:
    name: Submit to Google Play
    needs: [build_android]
    type: submit
    params:
      profile: production
      build_id: ${{ needs.build_android.outputs.build_id }}

Run it manually the first time:

eas workflow:run release.yml

The testflight job can also share the build with internal and external tester groups. If you'd rather use GitHub Actions or another CI, run eas submit there with an EXPO_TOKEN set.

What EAS Submit doesn't do

Here's the part that surprises people. After a successful eas submit, these steps still stand between your build and the public:

On iOS

Step	Where
Submit the build for App Review	App Store Connect
Store listing: name, subtitle, description, keywords, screenshots	App Store Connect
App Privacy details (the "nutrition label")	App Store Connect
Age rating questionnaire	App Store Connect
Demo account for the reviewer, if login is required	App Review Information
Beta App Review for external TestFlight testers (first build)	Automatic, but it's a queue
Responding to rejections	Resolution Center

EAS gets the binary into TestFlight. Sending it to App Review is still a step you take in App Store Connect.

On Android

Step	Where
Store listing, screenshots, feature graphic	Play Console
Data Safety form	Play Console
Content rating questionnaire	Play Console
Target audience, ads declaration, app access	Play Console
Account deletion web link (if users can sign up)	Data Safety form
12 testers for 14 days in closed testing (new personal accounts)	Play Console + your testers
Applying for production access	Play Console
Promoting a release to production	Play Console, or `track: "production"` once allowed

The closed-testing requirement is the long one: new personal developer accounts must keep at least 12 testers opted in for 14 continuous days before production opens up. EAS can upload to the closed-testing track (track: "alpha") on every build, but the 14 days are calendar days.

A release pipeline that covers both halves

Put together, a realistic first launch looks like this:

Day 1: create both app records; set up the ASC API key and Google service account key; add submit profiles.
Day 1: first eas build --auto-submit. iOS lands in TestFlight; Android lands on the internal track.
Days 1–3: recruit Android testers; switch the Android profile to track: "alpha" so every build goes to closed testing.
Days 2–5: fill in listings, screenshots, privacy details, Data Safety, ratings, and the demo account.
Day 5 onward: submit iOS for App Review from App Store Connect.
Day 17 onward: apply for Google Play production access, then promote.

After launch, the pipeline is fully automatic: every merge to main builds, uploads, and lands in TestFlight and your Play track, and you promote from there.

Common EAS Submit errors

"No suitable application records were found" (iOS): the bundle ID doesn't match an app in App Store Connect, or ascAppId is wrong.
Version code or build number already used: set "cli": { "appVersionSource": "remote" } and "autoIncrement": true on the production build profile so EAS increments for you.
Service account permission errors (Android): the service account needs access to the app in Play Console's Users and permissions.
CI can't authenticate with Apple: interactive Apple ID login doesn't work in CI. Use the App Store Connect API key.

The short version

EAS Submit removes the upload step from your release. It doesn't remove the store consoles. Set up the API key and service account once, automate builds and uploads with a workflow, and put the listing, privacy, testing, and review steps on your calendar from day one.

If you'd rather hand off the console half (listings, privacy forms, Data Safety, testers, and the review back-and-forth), LetsDeployIt handles App Store and Google Play submission end to end.

What's the step that surprised you most on your first release?

Google Play's 12-Tester Rule: The 21-Day Plan That Passes the First Time

Lucas Martin — Wed, 30 Sep 2026 06:52:14 +0000

You finished the app. You paid the $25 for a Google Play developer account. You uploaded the build. And then Play Console told you production is locked until 12 testers stay opted in to a closed test for 14 continuous days.

Most solo developers hit this wall the day they think they're done, and most of them fail the first attempt: not because the rule is hard, but because the clock has rules nobody told them about. This is the plan I give people so they pass once.

The rule, precisely

Developers with personal accounts created after November 13, 2023 must run a closed test with at least 12 testers who have been opted in continuously for at least 14 days. Google originally required 20 testers and reduced it to 12 on December 11, 2024.

Three details that fail people:

Continuous means continuous. A tester who opts in, tests for fewer than 14 days, and opts out doesn't count. If they opt out and back in, the 14 days restart.
All 12 have to overlap. The 14-day window starts when the twelfth tester is opted in, not when the first one is.
Passing the numbers isn't approval. When you apply, Google asks questions about your test, and reviewers can reject applications for insufficient testing engagement.

Organization accounts (registered with a D-U-N-S number) are exempt. For a solo developer, though, forming a company just to avoid testing costs more time and money than the test itself.

Why 12 is the wrong number to aim for

Testers get busy. Someone opts out on day 9 to free up storage. Someone's phone breaks. If you recruit exactly 12, one dropout resets everything.

Recruit 18 to 20. Tell every one of them, explicitly: stay opted in for the full 14 days, even if you stop using the app. That sentence prevents more failures than anything else in this article.

The 21-day plan

Day 0: Set up the track.
In Play Console → Testing → Closed testing, create a track, upload your AAB, and fill in the store listing, content rating, Data Safety form, and privacy policy URL. Google won't publish a closed-test release with an incomplete listing, and every day you spend fixing that is a day the clock isn't running.

Days 0–3: Recruit 18–20 real people.
The best sources, in order:

Friends, family, coworkers with Android phones
Your existing audience: newsletter, Discord, LinkedIn, a "help me launch" post
Communities built for this: r/AndroidClosedTesting and similar tester-swap groups where developers test each other's apps

Collect their Google account emails. Add them to the tester list on the track, or create a Google Group and add the group.

Day 3: Confirm all 12+ are opted in.
Send the opt-in link. Then check the track's tester count in Play Console. The 14-day clock starts when the twelfth person is in, so don't assume; verify.

Days 3–17: Keep them engaged.
Google looks at engagement, not just enrollment. Ship at least one update during the window (a real one: a fix or a small feature) so testers have a reason to open the app. Send a short message on day 1, day 7, and day 13: "Thanks, please stay opted in until [date]."

Day 17: Apply for production access.
Play Console shows an "Apply for production" button once the requirement is met. The application asks how you recruited testers, what feedback you got, and what you changed. Answer honestly and specifically: "12 friends and 6 members of a tester community; feedback on onboarding copy and a crash on Android 12; fixed both in build 1.0.3." Vague answers get rejected.

Days 17–21: Wait for review.
Approval usually takes a few days. Once granted, you can release to production and use open testing for future betas.

What not to do

Don't buy fake testers. Emulators, bot accounts, and "12 testers for $10" services risk permanent account suspension, and you lose the $25, the app, and the ability to open a new account.
Don't start the clock before your listing is complete. A rejected closed-test release doesn't count toward anything.
Don't assume a second app skips this. Play Console shows the requirement per app for affected accounts; plan for it every time until you see otherwise in your console.
Don't recruit exactly 12. See above.

The pre-flight checklist

[ ] Personal account created after Nov 13, 2023? (If yes, this applies.)
[ ] Store listing, content rating, Data Safety, and privacy policy complete
[ ] AAB uploaded to a closed testing track
[ ] 18–20 testers recruited with Google account emails
[ ] All testers told: stay opted in for 14 days
[ ] Tester count in Console ≥ 12 before you start counting days
[ ] At least one update shipped during the window
[ ] Specific answers drafted for the production access application

If you'd rather not run this yourself

The 14 days can't be shortened, but everything around them can be handled: the listing, the Data Safety form, the track setup, the tester coordination, and the application. That's what LetsDeployIt does for AI-built and indie apps: done-for-you App Store and Google Play submission, including the closed-testing gate.

If you've been through this already: what got your testers to stay opted in for the full two weeks? I've seen everything from pizza to a shared leaderboard, and I'm curious what actually worked.

Self-Hosting Supabase Won't Save You Money on Local Dev (and What Will)

Lucas Martin — Mon, 28 Sep 2026 13:40:03 +0000

Every few weeks someone in a Supabase Discord asks the same question: "Should I self-host to save money?"

The answer depends on which problem they're actually trying to solve. About half the time, what they mean is "the hosted free tier is too small for my side project." The other half, they mean "I want to run this on my laptop without paying for a cloud project." Those are different problems, and self-hosting only solves one of them.

This post is the honest breakdown: what self-hosted Supabase really is, when it's the right call, and why for local dev and previews you probably want something much smaller.

What "self-hosted Supabase" actually means

Supabase is not one server. The official self-hosting path is Docker Compose, and it starts PostgreSQL plus ten services around it: PostgREST, GoTrue for auth, Realtime, Storage, Studio, the API gateway, the Supavisor pooler, imgproxy, the meta service, and the edge runtime. Eleven containers, and a quiet instance idles at around 2 GB of RAM before the database has a working set.

Then there's the part the quickstart glosses over: the default .env ships demo secrets and a dashboard password literally named this_password_is_insecure_and_should_be_updated. Every key has to be regenerated before you put real data in it. After that you own TLS termination, SMTP for auth emails, backups that you've actually tested restoring, and image upgrades across all eleven services.

None of that is a criticism. It's a full production backend, and self-hosting it is a real, supported path. Supabase's own docs frame it as suitable for small-to-medium production workloads. But it's ops work, and it's community-supported rather than covered by a support plan.

When self-hosting is the right call

Data residency. You need the database in a specific jurisdiction or on hardware you control.
Cost at scale. Once you're paying for compute add-ons, a dedicated box can be cheaper, if you have someone to run it.
Extensions or config the hosted platform doesn't allow.
You already run infrastructure and adding eleven containers to it is Tuesday.

If none of those apply, the hosted platform's free tier and $25/mo Pro plan are almost always cheaper than the hours you'll spend on Compose.

When self-hosting is the wrong tool

Here's the case that trips people up: you want a backend on your laptop, in CI, or per preview environment.

Self-hosting doesn't help there. You'd be running the same eleven containers, just on your own machine, which is exactly what supabase start already does. On a 16 GB laptop it's tolerable. On the 8 GB machine most students and indie devs actually own, it's the reason they stop before writing a line of app code. And in CI, spinning up that stack on every pull request is the slowest job in the pipeline.

This is a different problem from production hosting, and it wants a different shape of solution: not "run all of Supabase yourself," but "run enough of Supabase, in one process, wherever you are."

The third option: one process

That's what tinbase is. An open-source (MIT), Supabase-compatible backend that runs as a single process with no Docker:

npx tinbase start

That boots embedded native Postgres 17 with RLS, plus REST (PostgREST grammar), Auth (GoTrue-shaped), Storage, Realtime, in-process Edge Functions, and a Studio-style dashboard. The official @supabase/supabase-js works unchanged. It reads your existing supabase/migrations/*.sql and supabase/seed.sql.

The numbers from the README, against the Docker-based local stack:

	Supabase local (Docker)	tinbase (native engine)
Processes	12 containers	2
RAM at boot	~1.4 GB	~59 MB
Cold boot	~1 min	~2 s

There's also a WASM engine (PGlite) that runs the whole backend inside a browser tab, and an ultralight pure-JS engine for previews. Same handlers, different database underneath.

What tinbase is not

This is the part I'd rather say now than have you find out later.

tinbase is alpha, built for local dev, CI, prototypes, and embedded use. It is not a self-hosted Supabase and not a production database. Specifically:

Single connection. Writes serialize. Fine for one developer or one preview; not for concurrent users.
Coverage is roughly 80% of the supabase-js surface. MFA, SSO, phone auth, and pgvector aren't there yet. The gaps are listed in the repo's coverage table.
Realtime DELETE events aren't filtered per row the way INSERT and UPDATE are.
Edge Functions with npm: or jsr: imports still need bundling.

If your question is "how do I host my production Supabase myself," tinbase is the wrong answer. Use Docker Compose, regenerate every secret, set up backups, and read the self-hosting docs twice.

The decision, compressed

You want to…	Use
Ship to production with zero ops	Supabase hosted
Ship to production on your own hardware or region	Self-hosted Supabase (Docker Compose)
Run a backend on a laptop, in CI, or per preview	tinbase (or `supabase start` if RAM is no object)
Run a backend inside a browser tab	tinbase WASM engine

The migration files are the same across all four rows. That's the whole point: develop against the small one, deploy to the big one, and never edit app code in between.

Try it

npx tinbase start

Source, roadmap, and the coverage table are on GitHub. If you hit a supabase-js call that doesn't work, open an issue; those reports are what move the table.

Which row are you in? I'm curious how many people asking "should I self-host" are actually in row three.

The Privacy Policy Trap: The App Store Rejection Nobody Warns You About

Lucas Martin — Wed, 23 Sep 2026 05:49:18 +0000

The two rejections that eat your first submit

Two data-safety rejections show up more than everything else combined on first submissions:

Your Privacy Policy URL loads but doesn't mention the data types you listed in App Store Connect. The reviewer clicks your policy, ctrl-F's for "email" or "device identifier", finds nothing. Held.
You claim "Data Not Linked to You" for analytics while your SDK sends a persistent device ID. Any default install of Firebase, Amplitude, or RevenueCat lands here.

Both are 30-minute fixes. Both cost a full review cycle. The whole game is eliminating them before you submit.

Match the policy verbatim to the Connect form

Apple's data-safety reviewer isn't reading your policy. They're diffing it against the table you filled in App Store Connect. So the policy needs to be structured the same way:

One row per data type
Three columns: what, why, third parties
Language that maps 1:1 to the Connect field names ("Product Interaction", "Device or Other IDs", "Coarse Location")

Legalese from a generic policy generator won't match. Rewrite it as a table.

Build-time drift check

Drift between what your app actually collects and what your Connect form declares is the number one hold reason. Catch it in CI:

# .github/workflows/data-safety.yml
- name: Data-safety drift check
  run: |
    python scripts/data_safety_diff.py \
      --ios-plist ios/App/Info.plist \
      --android-manifest android/app/src/main/AndroidManifest.xml \
      --connect-declared connect-data-safety.yml

A 40-line script parses your Info.plist and AndroidManifest.xml permission lists and compares them against a connect-data-safety.yml committed alongside the app. Any drift means a red build. You never submit a mismatch again.

Notes for Reviewer is the field that unblocks you

Reviewers spend about 90 seconds on your submission. The field they actually read is Notes for Reviewer. Use it to answer the three questions they always ask:

Test credentials to log in. Real, working, not disabled.
Personal vs device data. One sentence: "We collect X for Y purpose; SDK Z sends a device ID, which is why we declare Data Linked."
IAP unlocks. What the tester sees after purchase.

Skip these and you get held. Include them and your review cycle gets a day shorter.

The one toggle that fixes 40%

In App Store Connect > App Privacy > Data Collection: if any SDK (analytics, ads, crash reporting) sends a device ID or IP, you must declare "Data Linked to You" for that category. Not "Not Linked".

This single toggle is where 40% of the data-safety rejections we've seen land. Get it right on the first submission and you save two review cycles.

What passes vs what gets held

Passes:

Table-format policy matching Connect verbatim
A static /privacy page, indexed on your marketing site
Notes for Reviewer with real test creds and a data explanation
ATT prompt shown after a value-explaining action, using Apple's exact string, with a deny path that doesn't paywall

Held:

Legalese policy from a generic generator
ATT prompt on splash
"Data Not Linked" claim with any device-ID-collecting SDK
Missing Notes for Reviewer

The fastest wins

If you're prepping an App Store submission this week: match your Privacy Policy table to Connect verbatim, add the drift check to CI, and write Notes for Reviewer for real. We built LetsDeployIt to automate this pipeline for indie teams, but the checklist matters more than the tool.

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.

DEV Community: Lucas Martin

React Native New Architecture in 2026: What Developers Need to Know

What "the New Architecture" actually means

How we got here

What this changes in your code

1. Native module errors are synchronous now (for sync methods)

2. Codegen mismatches fail loudly

3. Old timing hacks can now cause bugs

4. Your debugger changed

Libraries: the real migration work

An upgrade checklist

Should you upgrade now?

EAS Submit in 2026: What It Automates, What It Doesn't, and the Release Pipeline That Covers Both

What EAS Submit does

Setting up iOS

1. Bundle identifier and a production build

2. A submit profile with your App Store Connect app ID

3. An App Store Connect API key (for anything automated)

4. Submit

Setting up Android

1. Package name and an .aab

2. Create the app in Play Console

3. A Google Service Account key

4. A submit profile

5. Submit

The change older tutorials get wrong

Build and submit in one step

Automate it with EAS Workflows

What EAS Submit doesn't do

On iOS

On Android

A release pipeline that covers both halves

Common EAS Submit errors

The short version

Google Play's 12-Tester Rule: The 21-Day Plan That Passes the First Time

The rule, precisely

Why 12 is the wrong number to aim for

The 21-day plan

What not to do

The pre-flight checklist

If you'd rather not run this yourself

Self-Hosting Supabase Won't Save You Money on Local Dev (and What Will)

What "self-hosted Supabase" actually means

When self-hosting is the right call

When self-hosting is the wrong tool

The third option: one process

What tinbase is not

The decision, compressed

Try it

The Privacy Policy Trap: The App Store Rejection Nobody Warns You About

The two rejections that eat your first submit

Match the policy verbatim to the Connect form

Build-time drift check

Notes for Reviewer is the field that unblocks you

The one toggle that fixes 40%

What passes vs what gets held

The fastest wins

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

1. Package name and an `.aab`

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

5. Android `versionCode` already used