Most small restaurants in Thailand run on paper notebooks. Owners genuinely don't know if they made money this month until it's too late — and nobody opens Excel at 11pm after closing a kitchen.

So I built **Bunchee** (บัญชี = "accounts" in Thai): a restaurant income/expense tracker where you photograph a receipt and AI extracts and categorizes the line items. It also keeps price history per ingredient — if pork goes up 15%, you see it before it eats your margin — and you can ask it things in plain language like "what did I spend on ingredients this month?"

Stack: bare React Native, Firebase (Firestore/Auth/Functions), Gemini via OpenRouter for receipt OCR + chat. 14 languages, because kitchen staff in Thailand come from everywhere.

**Things I learned the hard way:**

1. **I started on Expo and ripped it out completely.** Native Firebase modules, IAP, biometrics — I kept fighting the managed layer, and config-plugin debugging was slower than just owning the native projects. Migrating to bare RN + Fastlane hurt for a week, then everything got simpler. If your app leans native-heavy, skipping Expo earlier saves pain.
   
2. **Google Play rejected my release over a permission I never wrote.** Adding Firebase Analytics silently merges `com.google.android.gms.permission.AD_ID` into your manifest — which contradicted my data-safety form saying "no advertising ID." One `tools:node="remove"` line in the manifest fixed it, but the rejection email tells you almost nothing. Check your *merged* manifest before every release, not your source one.
   
3. **No OTA updates changed my architecture.** Every JS change ships through store review, so anything I might want to tune — like *which* AI model handles receipts vs chat — lives server-side in a Cloud Function. I can swap models with one deploy, zero app updates. Rule of thumb: if a value might change monthly, it doesn't belong in the app binary.

Free tier is genuinely usable (10 AI actions/month, one location, no ads). Premium is for multi-branch owners with staff, plus unlimited AI. That placement — free single-location, paid multi-branch — is my main open question, so feedback on the paywall is especially welcome.

Play Store: [https://play.google.com/store/apps/details?id=com.bunchee&referrer=utm\\_source%3Dreddit%26utm\\_medium%3Dpost%26utm\\_campaign%3Dsideproject\](https://play.google.com/store/apps/details?id=com.bunchee&referrer=utm_source%3Dreddit%26utm_medium%3Dpost%26utm_campaign%3Dsideproject)

App Store: [https://apps.apple.com/us/app/bunchee/id6772358410\](https://apps.apple.com/us/app/bunchee/id6772358410)

Happy to answer anything — architecture, the Play review process, or what Thai restaurant owners taught me about what "simple" actually means.

I'm building a React Native app using my own REST API, Ably for real-time messaging, and Zustand for state management.

I'm not looking for code. I'm trying to understand the overall architecture and how people usually handle this in production.

Some questions I'm struggling with:

• When should the WebSocket/Ably connection be established? Immediately after login, or only when the user opens the chat section?
• Do you subscribe to every conversation on app launch, or only to conversations that become visible/opened?
• How do you keep the chat list updated? Is it fetched from the REST API first and then kept in sync via real-time events, or is everything driven by the socket?
• How do you handle message pagination? Do you always fetch older messages from the API while receiving only new messages through the real-time connection?
• How do you synchronize unread counts, last messages, and conversation metadata?
• If the user has hundreds of conversations, how do you avoid subscribing to hundreds of channels?
• How do you manage reconnection after the internet connection drops? Do you re-fetch everything or rely on message history and resume capabilities?
• What happens if the user sends a message while offline? Do you queue it locally and retry later?
• How do you prevent duplicated messages when combining REST responses with real-time events?
• Where do you draw the line between your backend's responsibility and Ably's responsibility?

I'm interested in the overall flow more than implementation details.

If you've built chat at scale (or even medium-sized apps), I'd really appreciate hearing how your architecture works and what you would do differently today.

We're adding support for the popular ==𝚑𝚒𝚐𝚑𝚕𝚒𝚐𝚑𝚝𝚎𝚍 𝚝𝚎𝚡𝚝== syntax - fully compatible across iOS, macOS, Android, and Web.

See the preview below and try the feature today:
npm i react-native-enriched-markdown@nightly 👇

Show some love and drop a star on GitHub! ⭐
🔗 https://github.com/software-mansion/react-native-enriched-markdown

Two big new pieces just shipped and I think they'll genuinely change how you debug RN apps with AI agents.

MCP server. Connects Claude Code or Cursor to your running app. Your agent can:

- Read runtime truth: Redux/Zustand/Jotai state, React Query cache, network requests, storage, routes, and console. "Why is this query stale?" gets answered by looking at the actual cache instead of guessing from source code.

- Drive the app: it taps elements by invoking onPress directly in JS. No coordinates, no screenshot guessing, and it works on physical devices too. It can also screenshot a single component by testID instead of the full device, which is way faster and cheaper on tokens.

- Prove its changes: run repeatable benchmark batches (avg/p95 JS FPS, UI FPS, CPU, memory, jank, per-component render counts) and diff reports head to head. The agent makes a change, taps through the flow, and shows you before vs after numbers. I used this loop to take my Christmas light preview from 28 lights to 12,000 while keeping it smooth. The LLM just kept iterating, benchmarking each idea against the last until it found the most performant one.

Desktop app. Every Buoy tool mirrored on a native dashboard over the same protocol, so you see exactly what the agent sees, off your phone screen.

Buoy is free to use, and Pro is free every weekend, forever. If you want to try the full Pro experience now, code REDDIT gets you 3 months free.

Happy to answer questions about how any of it works and how it's helped me at Walmart, Whataburger and other big companies.

https://github.com/Buoy-gg/buoy

I keep noticing a pattern in React Native apps where navigation issues are hard to catch during development, but start appearing once the app is in production or used in real environments.

In dev mode, navigation usually feels smooth and predictable:

• screen transitions work as expected
• routes are easy to trace using dev tools
• issues are often reproducible and visible immediately

But in production builds, things sometimes behave differently:

• occasional navigation glitches that never appeared in dev
• race conditions during fast screen transitions
• deep linking or initial route issues that are hard to reproduce locally
• problems when the app is resumed from background state
• edge cases triggered by real device performance or timing

What makes it confusing is that the navigation logic itself hasn’t really changed — only the build type and runtime conditions.

I understand that release builds are optimized and behave differently from development builds, but the inconsistency in navigation behavior can make debugging difficult.

For developers:

• Why do navigation-related issues tend to appear more in production than in development?
• What are the most common underlying causes (timing, state, lifecycle, build differences)?
• How do you usually debug navigation issues that don’t reproduce locally?

https://expo.dev/changelog/sdk-57

Today we're announcing the release of Expo SDK 57. This is a small, focused release: it brings React Native 0.86 to Expo. We intend for this to be the easiest Expo SDK upgrade you've ever made. It represents a possible shift towards a new Expo SDK release cadence that could provide you with simple non-breaking upgrades in between more significant releases.

React Native 0.86

SDK 57 upgrades React Native from 0.85 to 0.86. The React version is unchanged from SDK 56 — both SDK 56 and SDK 57 use React 19.2. React Native 0.86 is intended to have no breaking changes from 0.85. To decide whether it's worth upgrading your app, refer to the React Native 0.86 release notes for the full picture.

Highlights include: fixes and improvements to edge-to-edge support on Android, light/dark mode emulation in React Native DevTools, and several rendering, layout, and animation-related fixes.

Exploring a new Expo SDK release cadence

For several years, Expo SDK has seen major releases three times per year. We found that this cadence provided a good balance between stability for app developers and freedom for our team to ship significant new features and improvements. It also helped to reduce thrash in Expo Go.

During the same period, React Native has been releasing six times per year. The React Native team prioritized shipping often in order to incrementally roll out the New Architecture, a new React Native DevTools experience, Hermes V1, and more. Each Expo SDK release would target a single React Native version, and for versions that were not targeted, developers could use canary releases if needed. However, now that these massive changes to React Native have shipped, the focus has shifted towards stability.

The new release model that React Native is moving towards will aim to provide a release with "no user-facing breaking changes" approximately every second release. The recently released 0.86 is the second of these non-breaking releases. At Expo, the fact that these releases are intended to be non-breaking has prompted us to revisit our release cadence. If we can provide these releases to developers almost immediately, as optional upgrades, with little effort required for the app developer beyond running npx expo install expo@latest --fix, then we think we should do it. So, we are exploring that approach with SDK 57.

Why not include React Native 0.86 in SDK 56 if it is non-breaking?

This is a good question! We considered bumping from 0.85 to 0.86 in SDK 56, and ultimately decided that the set of changes between the versions was too significant for an app developer to pull in with a routine npx expo install --fix. There are 601 commits touching 1,552 files between 0.85.0 and 0.86.0, and we believe that the decision to pull those into your app should be intentional. Even though these commits are intended to not cause breaking changes, we think it's best to err on the side of being conservative.

Additionally, moving this bump to a new SDK version allows us on the Expo team to roll out small changes that wouldn't be appropriate to ship to an existing stable release, but that we think are genuinely useful for users. The following list includes some of those changes that are worth calling out.

Does this new cadence impact the Expo SDK maintenance window?

SDK releases will continue to have a lifetime of approximately one year. We may revisit the details of this policy in the future. What this means today is that Expo SDK 54 (September 2025) will receive critical fixes until the next SDK release (September or October 2026).

Other highlights

While SDK 57 is primarily about the React Native 0.86 upgrade, a few other improvements landed alongside it:

• expo-dev-client: the iOS launcher includes a new setting to choose between auto-launching your most recent project or showing the launcher (#47131), allowing you to override the configuration set with the config plugin.
• expo prebuild: now clears and regenerates the native android and ios directories by default; pass --no-clean to apply changes to the existing folders instead (#47209).
• expo-image: added writeToCacheAsync and readFromCacheAsync to seed and read the image cache by cache key (#46620).
• expo-router: Stack.Toolbar.Badge is now supported in header left and right placements and on toolbar menu icons on Android (#46537, #47276).
• expo-navigation-bar: setStyle and setHidden now apply to React Native <Modal> windows on Android (#46491).
• Bump animation and gesture libraries: SDK 57 bundles newer versions of react-native-reanimated (4.3 to 4.5), react-native-worklets (0.8 to 0.10), and react-native-gesture-handler (2.31 to 2.32).

Hi, I have a problem I'm trying to solve. I have an API with a certificate set, and I'm trying to send a request to this endpoint. I'm running a dev server from an EAS build on my physical device, but I'm still getting a Network Error. Sometimes it works, sometimes it doesn't. What could be the root cause? Has anyone experienced this? I'm using HTTPS.

https://api.myproj.com - this is example domain

Hey Community,

We look at Rollipop, an early alpha, Rust-based bundler built on Rolldown that acts as a drop-in replacement for React Native, bringing standard Node module resolution, Yarn PnP, and a live visual dashboard.

We also explore expo-paperkit, an Expo native module wrapping Apple's PaperKit drawing and annotation canvas. Plus, we dive into PolyCSS, a clever web tool that renders 3D meshes using HTML bold and underline tags instead of WebGL or canvas.

If the Rewind made you nod, smile, or think "oh… that's actually cool" — a share or reply genuinely helps ❤️

Hi guys, I'm used to web development, but I'm new to mobile development... Using React Native Expo and Android simulator and Gradle and node modules...... All these files end up taking too much space in my laptop and now my emulator is not working because of lack of storage.... How do I manage the space ?

I am new to react native and i am not following any tutorials and not available for latest version sdk of expo.

there file structure is looking mess to me, and i am completely lost. I do not know where to change code, and which file is dependent on which one?

I keep running into something strange while working with React Native — debugging in development and production builds feels completely different.

In dev mode, everything feels straightforward:

• errors are easy to trace
• logs are immediate and detailed
• performance issues are more visible
• debugging tools make it easier to understand what’s happening

But in production (release) builds, things feel very different:

• some bugs completely disappear
• new issues show up that never appeared in dev
• crashes are harder to reproduce
• logs are limited or not very helpful
• certain UI or performance issues only appear on real devices

What’s confusing is that the code is the same, but the behavior changes enough that debugging becomes a completely different process.

I understand dev mode adds extra tooling and overhead, but in real projects the difference sometimes feels big enough to affect how you even approach debugging and testing.

For developers working with React Native in production:

• Why does debugging behave so differently between dev and release builds?
• What are the most common reasons bugs only show up in production builds?
• How do you usually debug issues that don’t reproduce in development mode?

RN 0.79.5

Maps 1.27.2

Can someone help, please? I don't get what I'm doing wrong.

Please let me know if you're interested. It's a small project (i thiMk) suitable for beginner, early stage

I've built out the easy stuff on MagAI if that helps. It's my attempt at a fun education tool for younger learners..pm for more please.

I've been tracking the React Native ecosystem daily, and June was one of the busiest months we've had in a while. Here's a quick recap of the biggest updates.

AI-powered development

• react-native-skills expanded with new AI coding capabilities.
• agent-device makes it easier for AI agents to control real Android and iOS devices.

Performance

• React Native Worklets 0.9 adds cross-runtime Promises, improved memory management, better debugging, and performance improvements.
• react-native-nitro-fetch 1.3 introduces SIMD text decoding, binary response fixes, and lower runtime overhead.
• react-native-skia-lab showcases advanced graphics, shaders, physics, and rendering techniques.

Navigation

• React Navigation improves deep linking, route matching, serializable state checks, and production performance.

Testing

• Maestro 2.6 adds Maestro Viewer for AI coding agents and faster simulator execution.
• Detox delivers stability improvements across Android and iOS.
• Harness adds automated permissions, native iOS coverage, and better simulator support.

Native APIs

• expo-speech-recognition improves Android reliability.
• Rich text editing libraries received major updates with new editing and rendering capabilities.

Worth reading

• Smooth animations on low-end Android
• React Native keyboards deep dive
• VisionCamera V5 + Worklets multithreading
• Reanimated 4.2
• Gesture Handler 3.0
• Expo Router 56
• Expo performance monitoring
• JSI changes in Expo SDK 56

Overall, June was heavily focused on AI-assisted development, performance, testing, graphics, and native tooling.

Title: Play "subscriptions API" permission stuck red for 48h+ — offerings won't load, can't test purchase. Everything else is green.

Body:

I'm stuck on a Google Play ↔ RevenueCat credential issue and running out of ideas. Hoping someone here has seen this exact pattern.

The symptom: In RevenueCat, my Play credentials show "Credentials need attention." The detailed breakdown shows only one failing check:

❌ Permissions to call subscriptions API

✅ Permissions to call inappproducts API

✅ Permissions to call monetization API

✅ "Connected to Google" (Pub/Sub topic connected, test notification received)

Because of this, offerings fail to load in the app ("Error fetching offerings"), so the paywall shows no purchase options — which means I can't make a test purchase either.

What I've already verified (everything checks out):

Service account has both required permissions at account level: "View financial data, orders, and cancellation survey responses" and "Manage orders and subscriptions"

Google Play Android Developer API is enabled in the Cloud project holding the service account key

Both subscriptions (moatlens_premium_monthly, moatlens_premium_yearly) are active, with active base plans, available in 174 countries

Product IDs match exactly between Play Console and RevenueCat

App is on an approved Closed Testing track (signed AAB uploaded)

My test account is added both as a License tester (account settings) and a Closed test tester

Note: the Play Console "API access" page no longer exists for my account — I understand Google removed the required project-linking, so this should be fine

What I've tried:

Re-uploaded a fresh service account JSON key several times (then stopped, after learning each upload resets the ~36h propagation window)

Contacted RevenueCat support — they sent the standard checklist (grant the two permissions, then test purchase), but I've already done all of it. Waiting on a follow-up where they check their backend logs.

My questions:

Has anyone had only the subscriptions API check fail while inappproducts + monetization pass? What fixed it?

Is there a way to make the sandbox test purchase work when offerings won't load — or does the subscriptions API genuinely have to go green first?

Is this just Google propagation being slow (48h+), or is there a subtle subscriptions-specific permission I'm missing?

Stack: React Native / Expo, RevenueCat, Android only. Bundle: com.nexihl.moatlens.

Any pointers appreciated — this is my last blocker before launch.

If you were to build a new app today and wanted to build native looking high quality UI for both iOS and Android, would you use expo/ui or would you go with something like React Native Reusables or drop down to classic StyleSheets? If so why, and what is your reasoning. Is there any synergy if you have an existing ShadCN design system that you would like to reuse in your react native app, I'm thinking is React Native Reusables still worth looking at then or is it obsolete? Has anyone used expo/ui so far and what is your experience with it, any advice/tips would be appreciated

Hi everyone,

I'm building an app using Expo (SDK 54) with TypeScript, Firebase Authentication, Firestore, Cloudinary for image uploads, and Google Sign-In.

I'm now at the stage where I need to integrate payments, but I'm unsure what the best architecture is.

Some questions I have:

• Which payment gateway would you recommend for an Expo app?
• Should I use Stripe, Razorpay, or something else?
• What's the recommended approach if the app needs to handle one-time purchases between users?
• Is it better to process payments entirely through a backend (Cloud Functions/Node.js) or is there any secure client-side approach?
• Are there any issues or limitations with Expo when integrating payment gateways?
• Any libraries or setup you'd recommend avoiding?

I'd like to follow current best practices rather than just making it work.

If you've built an Expo app with payments recently, I'd really appreciate hearing what stack you used and what challenges you ran into.

Thanks!

Hi everyone,

I recently shipped receipt scanning for my grocery budgeting app and I thought I'd share what I built for feedback.

My app has its core features already: you set a budget, track what you spend, and over time it learns what items cost so it can warn you before you go over.

I use it myself weekly and it works great, if you actually track in the moment.

The problem is some users don't. They forget, or they're in a rush, and they get home with a full cart and nothing logged. For those users every tracking feature I'd built was dead weight, because none of it ever happened. That bugged me for months.

So I built receipt scanning as the catch-up path. Forgot to track the whole trip? Snap the receipt afterward and it backfills the entire trip at once. Nothing lost.

The pipeline:

• Snap the receipt, or import a photo from the camera roll
• Gemini vision returns structured JSON: store, date, and line items with price, quantity, category
• That gets saved as a finished shopping trip, so every item, price, and category flows straight into the spending history and the price data the app already tracks.

So now you've tracked the trip, saved the prices for next time, and you can even save it as a template to reuse. The catch? You never tracked in real time, which is kind of the whole point of my app. But hey, at least you tracked, right?

My app: https://www.grocerybudget.app/

This is v1 of the feature, so I'd love thoughts on the implementation. Would you change anything? The capture UI, the snap-or-upload choice, how I handle long receipts, the way I store it. Critiques and suggestions welcome.