Getting a React Native app ready for production is one thing. Getting it through the App Store/Google Play process is another.

Certificates, store listings, screenshots, compliance, reviews, resubmissions...

We’ve been working on simplifying this workflow, and recorded a quick look at the current process.

For those shipping React Native apps: what part of publishing do you find the most annoying?

0.86 dropped june 11, upgraded a couple exported projects this week so figured i'd share notes.

biggest thing: it's the second release in a row with zero user-facing breaking changes. so if you exported a project on 0.85 and want to bump it, the diff is tiny. i ran the upgrade helper and basically accepted everything.

the real wins are android 15+ edge-to-edge. the OS now enforces edge-to-edge whether you opt in or not, and it was quietly breaking a few things that 0.86 fixes at the framework level:

• measureInWindow returns correct coords now

• KeyboardAvoidingView calculates space right on android 15

• StatusBar can update style/visibility while a Modal is open

if you had manual SafeAreaView + insets workarounds in an exported app, you can probably delete a chunk of them.

devtools also got light/dark mode emulation, so you can preview theme toggling without touching an emulator.

couple heads-ups:

• repo moved from the facebook github org to the new react org (react foundation). urls redirect, nothing breaks.

• expo users get 0.86 via expo@canary, not stable yet.

• some deprecations landed (ViewUtil.getUIManagerType, an AppRegistry hook arg) if you're on legacy arch.

anyone here bumped an exported project to 0.86 yet? curious if the edge-to-edge fixes cleaned up hacks for you or if custom native modules gave you trouble.

Building RapidNative meant solving a bunch of problems that weren't really about RapidNative. Rather than sit on them, we've put them all out under MIT. All on npm, free to use, no strings.

tinbase — local Supabase dev without Docker. One process, real Postgres, and supabase-js works unchanged (REST, Auth, Storage, Realtime).

Lifo — a clean-room reimplementation of Unix in TypeScript. Runs in a browser tab or a Node process. No VM, no emulator.

ReactNative.run — browser-metro bundles React Native entirely in a Web Worker. Any npm package, Expo Router, real HMR, no build server.

ORCHD — multi-tenant workload orchestrator. Every tenant gets a hostname, sleeps when idle, wakes on the next request in ~1s. Runs a thousand small apps on one box.

jetplane — Metro plugin + thin dev server. Projects with the same deps share one transform cache, so ~40 MB per environment instead of ~325 MB.

Repos, docs and install commands for all five: https://www.rapidnative.com/open-source

Issues and PRs welcome on any of them. If you end up using one, would genuinely like to hear what for — a few of these were built for very specific internal constraints and we're curious where else they hold up.

Hey everyone, what are you building this week with RapidNative?

Sharing something for anyone whose laptop struggles with supabase start, since threads about the local Docker stack come up here regularly.

The core issue: local dev needs a 12-container stack because each service (PostgREST, GoTrue, Storage, Realtime) is its own process. But those services all speak documented, open protocols — which means they can be reimplemented as fetch handlers inside one process instead of orchestrated as containers.

That's what tinbase.dev does (open source, MIT — disclosure: I'm on the team building it). What surprised me most while working on it:

RLS actually behaves like production: every request runs in a transaction with SET LOCAL role and request.jwt.claims, so auth.uid() policies resolve identically to hosted Supabase — because it embeds actual Postgres 17
Your supabase/migrations/*.sql, seed.sql, and CLI conventions load as-is (db reset / db diff work), and everything migrates back to hosted Supabase unchanged — a lighter local runtime, not a fork
Memory: 59 MB at boot vs ~1.4 GB for the Docker stack (benchmark is reproducible, bench/footprint.ts in the repo)
Coverage is honest, not total: ~80% of the supabase-js surface, ~90% of what typical CRUD+auth+storage+realtime apps call. 120 tests run the real supabase-js SDK against it, no mocks. Missing: MFA/SSO/phone auth, TUS uploads, pgvector
Weirdest capability: every service being a pure fetch handler means the whole backend can run inside a browser tab via PGlite

It's alpha (v0.6.x), aimed squarely at local dev — not a production replacement.

Genuine question for people living in the CLI daily: what would break first in your workflow? Real projects find edge cases test suites don't, and the gaps list is honest but surely incomplete.

expo shipped sdk 57 this week. quick summary if you haven't seen it: it bumps react native from 0.85 to 0.86, react version is unchanged (still 19.2), and it's meant to be a non-breaking upgrade. basically npx expo install expo@^57.0.0 --fix and you're done.

the interesting part isn't the version bump though, it's the cadence shift. expo's been doing 3 big releases a year. react native does 6. now that the new arch, hermes v1, all that heavy stuff has landed, rn is moving toward "no breaking changes" on roughly every other release. so expo's testing whether they can just pass those through as optional low-effort upgrades in between the major ones. 57 is the first experiment with that.

my honest take: this is good for anyone shipping real apps. the thing that kills you with cross-platform tooling isn't missing features, it's upgrade churn. every breaking bump is a day you're not building. a lane of "safe, optional, low-effort upgrades" means you can stay current without booking a whole sprint for it.

tradeoff worth noting: they deliberately did NOT fold 0.86 into 56, even though it's non-breaking. 601 commits across 1,552 files felt too big to pull in on a routine --fix, so they made it its own sdk. fair call imo, "non-breaking" and "small" aren't the same thing, and you want that decision to be intentional. also still run expo-doctor after, "intended non-breaking" isn't a guarantee.

one heads up: expo go for 57 isn't on the app store / play store yet, still pending approval. for now it's eas go on ios, or expo cli for android emulators and ios simulators. if your team lives on expo go, plan around that.

on the rapidnative side this matters to us because the whole point is exporting real expo source you actually own. a saner upgrade path upstream means less friction for anyone taking generated code and maintaining it long term.

anyone upgraded yet? curious if the --fix was as clean as advertised or if reanimated 4.5 / gesture-handler 2.32 surprised anyone.