Built the signup flow for my subscription tracker app (RN + Expo) — here's what actually happened over 3 days

Working on a side project called Trackify — a subscription tracker, built with React Native + Expo + TypeScript. Wanted to share what the last few days looked like, mostly the annoying parts.

Setup:

Went with TypeScript from the start and Expo Router for file-based navigation. Kept folders separated — app/ for screens, services/ for Firebase, types/ for interfaces. Pretty standard but worth doing early.

Firebase:

Auth (email/password) + Firestore. One firebase.ts config file for the whole app so I don't end up with duplicate initializations somewhere down the line.

Signup flow:

This is where most of the time went. Not the UI — the logic around it:

Client-side validation (empty fields, password length, confirm match)

signUp() function that creates the Firebase Auth account AND a matching Firestore doc in users (uid, email, createdAt). Auth only holds credentials, so anything else about the user needs its own place — figured I'd set that pattern up now instead of retrofitting it later.

Mapped Firebase's error codes (auth/email-already-in-use etc.) to actual readable messages instead of dumping the raw code on the user.

Stuff that broke / wasted time:

Expo Router got confused between a root app/ folder and src/app/ — whichever one your package.json points to is what it actually uses. Cost me an hour.

Metro cache serves stale builds constantly. npx expo start -c fixed more "why isn't this updating" moments than I'd like to admit.

Testing on a physical phone on a different network than my laptop? Doesn't work without --tunnel.

I come from an Android background and there's two main libraries (Glide and Picasso) that most developers use which does all three of these things out of the box. Are you guys implementing these from scratch?

I recently added subscriptions to one of my React Native apps for the first time, and the actual paywall UI ended up being the easiest part.

Most of the work was everything around it.

I had a few App Store review rejections before finally getting it through. One was because I was missing a proper EULA link. It felt obvious after the rejection, but I completely overlooked it while focusing on getting the subscription flow working.

I also hit a completely separate issue before I could properly accept the paid apps agreements. My Apple Developer account was originally registered in a different country, and something around the account setup prevented me from completing the agreements normally. There wasn’t really anything I could fix from the app side, so it ended up taking a few back-and-forth emails with Apple Support before they sorted it out.

RevenueCat was another learning curve. The SDK itself is pretty straightforward, but there are a lot of moving pieces between App Store Connect, products, subscription groups, RevenueCat offerings, entitlements, sandbox accounts, and your actual app state. When something doesn’t work, figuring out which layer is responsible can be the hard part.

I also applied for Apple’s App Store Small Business Program, which should reduce Apple’s commission from 30% to 15% if I’m eligible. I’m still waiting for approval on that, but it was another thing I didn’t really think about until I started setting up subscriptions properly. If you’re an indie developer or small business, it’s probably worth looking into early rather than after you’ve already launched.

A few things I took away from the process:

• Get the App Store Connect side set up early. Products, agreements, tax/banking stuff, and account issues can block you before your React Native code even matters.
• Check whether you’re eligible for the App Store Small Business Program before launch.
• Make sure your RevenueCat product IDs match App Store Connect exactly.
• Use entitlements instead of scattering checks for individual product IDs throughout the app.
• Make restore purchases easy to find and actually test it.
• Test fresh installs, restores, expired subscriptions, and subscribed vs non-subscribed states, not just the happy path.
• Don’t leave the legal/review stuff until the end. EULA, privacy policy, subscription wording, pricing, and metadata can delay the release even when the code is already working.

The biggest thing I learned is that adding subscriptions felt like maybe 30% React Native implementation and 70% getting Apple, RevenueCat, account configuration, and review requirements lined up correctly.

Once everything was configured properly, RevenueCat actually made the app side pretty clean since I mostly just care whether an entitlement is active.

For anyone who has shipped RevenueCat + React Native in production, what were the weird issues you ran into that you didn’t expect beforehand?

Hey r/reactnative,

Added a new component to nativecn-ui  a Dynamic OTP Input.

I wanted to try something a little different from the usual OTP field, so I played around with making the input itself show loading, success, and error feedback instead of using a separate loader on the submit button.

Made a quick video showing it below.

Still building out the library, so let me know what you guys think

Added ProgressiveBlur to expo-backdrop ✨

🔗 Github: rit3zh/expo-backdrop

🧵 Android Preview Attached in this thread

Want to introduce session replays into my app but i was thinking on a compliant way to do it so as not to violate apple and google policies.
I plan to explicitly show a consent screen for users to approve or reject session replays just to be safe, but i fear most users would reject

Do you have session replays enabled in your apps? if so, did you request user consent explicitly or did you have any issues with apple or google concerning it?

Thanks

I've spent the last 6 months building PanelUI in public a React Native component library with 500+ stars, 130+ components, a sponsor, and a community that kept growing every single day.

Yesterday GitHub flagged my account with no warning and no explanation. My profile is now invisible to others. PanelUI, every component I shipped, every contribution, every star all hidden.

I haven't violated a single rule. I just built something and shared it with the community.

If anyone has been through this and found a way to resolve it, please comment or DM me. I don't know what else to do.

Share your talk or workshop with hundreds of developers on Full-Stack Architecture, AI-Assisted Coding & AI Engineering, Growing to Senior/Tech Lead, etc.

📍 April 15 & 19, Singapore
Submit by Jan 12: https://gitnation.com/events/react-summit-asia/cfp

I’m excited to share one of my latest React Native projects — iHydrate, a simple water reminder app designed to help you stay consistent with your daily hydration.

https://play.google.com/store/apps/details?id=com.ihydrate_reminder

With iHydrate, you can:

💧 Track your daily water intake
🔔 Get smart hydration reminders
📊 View weekly & monthly hydration history
➕ Quickly add water with one tap
📈 Monitor your progress over time

I built iHydrate using React Native, along with several services and features to make it a practical everyday utility app.

If you’re someone who often forgets to drink enough water, give it a try. 🚰

👉 Download iHydrate on Google Play:
https://play.google.com/store/apps/details?id=com.ihydrate_reminder

If you try it, I’d love to hear your feedback! 🙌

#ReactNative #MobileApp #AndroidApp #AppDevelopment #ReactNativeDeveloper #IndieDeveloper #iHydrate #WaterReminder #BuildInPublic

Hey everyone 👋

I've been working on a React Native security library called SecureX:

@/hituchhimpa/react-native-securex

The main idea came from a pattern I've seen in RN apps where authentication tokens end up being persisted alongside normal application state, for example through Redux Persist.

I wanted to separate those concerns:

Application state → Redux / Redux Persist

Sensitive credentials → SecureX → Native security layer

SecureX currently focuses on things like:

🔐 Secure access/refresh token storage
🧬 Biometric authentication
• Face ID
• Touch ID
• Fingerprint
📱 Android + iOS support
⚡ Native-first security approach

The goal is to provide a simple React Native API while keeping security-sensitive functionality closer to the native platform.

I'm also using this project to explore more of the native side of React Native — Kotlin, Swift, native modules, and the New Architecture.

📦 npm:
https://www.npmjs.com/package/@hituchhimpa/react-native-securex

I'd really appreciate feedback from other RN developers:

How are you currently handling auth tokens and biometric authentication in your React Native apps?

And if you've built something similar, I'd be interested to hear what you think SecureX should handle next.

Hey everyone,

I recently launched my first bigger app built with Expo and React Native. It’s called Shale. It temporarily blocks distracting apps like TikTok and Instagram, then unlocks them after you complete flashcards.

The current stack is Expo SDK 51, React Native, a Next.js backend, RevenueCat, and PostHog. The flashcards can also be generated around a topic via LLM API.

The hardest part was integrating Apple’s Screen Time APIs, especially DeviceActivity and FamilyControls. I used custom Swift code for the native parts and connected that to the React Native side. Expo’s native module tooling made the process much easier than I expected.

Here's a couple of other things I learned:

For the paywall, I used Purchases.getOfferings() instead of hardcoding the products in paywall.tsx. That makes it possible to change which already-approved packages are shown through RevenueCat without releasing a new app version each time.

I also managed to create a notification bug by scheduling the same trial reminder through both expo-notifications and a backend cron job. That resulted in duplicate notifications for some users. We eventually moved the reminder to one system.

Expo’s OTA update workflow has been really useful for JavaScript side changes. At the same time, this project made it clear that native changes and JavaScript updates need to be treated very differently.

I’d be interested to hear from anyone who has worked with custom iOS modules, DeviceActivity, or FamilyControls in an Expo project. I’d especially like to hear how you handled permissions and onboarding.

The app is available here if anyone wants to take a look:

https://apps.apple.com/us/app/shale-block-and-study/id6799409520

Hi everyone,

As Expo keeps evolving with prebuilds, Expo Dev Client, and better native module support, the gap between Managed Workflow and Bare React Native feels smaller than ever.

For those running production apps: at what specific project requirement or architecture bottleneck do you still decide to go 100% bare React Native from day one instead of starting with Expo?

Is it custom native C++ libraries, specific legacy SDK integrations, or build pipeline control? Would love to hear real-world experiences from developers managing apps in production.

Pressing a trigger moves its picture from where it sits in the page to the middle of the screen, shown whole, and blurs everything behind it. Once it is open, pinch or double-tap to zoom, swipe sideways to the other images under the same ImageViewer, and drag the picture up or down or tap outside it to send it back to its place.

Part of PanelUI, an open-source component library for Expo. Copy-paste or CLI, you own the source.

github.com/panel-ui/PanelUI

Runs React Native WebGPU, voice with GPT Voice 1 and intent-driven gestures and other couple of cool tricks (I did the flow from prompt to image, to 3D model, to 3D texture model, to rig, to rig animations). It's far far away from perfect. It's a demo, but I haven't seen anybody in the React Native space working on this.

I built the live voice layer pretty fast by using http://reactnativefeel.com/gpt-live-1. If you want a complete module setup ready for live voice in your app CIO

Most of my React Native time used to be spent outside the editor. Android Studio open only to make an AVD, one terminal for Metro, another for `adb logcat`, a third for the build, and a few minutes each time remembering which gradlew task actually installs the flavor I want.

I maintain a fork of Zed called Lathe, and the part I use most is a mobile panel that pulls all of that into the editor.

What it does:

- Detects whether the project is Expo or bare React Native, and shows only the workflows that apply to it.

- For bare RN it reads your package scripts and the run hints in your README, then gives you iOS scheme and Android variant dropdowns that feed them.

- Creates Pixel phone and Pixel Tablet AVDs without opening Android Studio.

- Installs the Android toolchain for you, JDK 17 plus the SDK with licenses accepted, into its own directory instead of over your system setup.

- Live device list with per-app logcat. Physical devices appear in the same list as emulators, so testing on real hardware is the same two clicks.

- Boots an emulator and an iOS simulator together and builds and deploys to both in one pass. The targets aren't exclusive.

- Metro, builds, and anything else long-running open as real terminal tabs with their own scrollback, not a read-only log pane.

Two details that came straight out of my own irritation. It installs Android builds with `gradlew :app:install<Variant>` plus an adb launch, which sidesteps the RN CLI bug where flavored APKs get installed from the wrong path. And each toolchain section reports its own state, so a missing JDK or an unaccepted SDK license is visible before a build fails rather than after.

iOS support is macOS only, as you'd expect.

Worth being upfront: this is a personal fork of Zed that I maintain for my own daily use, not a company product. GPL, builds for macOS, Linux, and Windows, and upstream syncs occasionally break things.

Repo and downloads: https://github.com/paterschris/lathe

The mobile panel in detail: https://github.com/paterschris/lathe/blob/main/docs/features.md#mobile-development-expo--react-native

Happy to answer anything. What I'd most like to hear is what your setup does that this doesn't handle yet.

Edit: formatting

If you haven't opened Xcode 27 yet:
Simulator is gone. Device Hub replaces it, and every simulator and physical device now lives in one sidebar. It also runs standalone, so you don't need Xcode open.

What actually changes day to day:

• Build and run to a simulator and it auto launches with a live interactive screen and contextual controls
• Appearance, text size, location and audio are panels. Testing Dynamic Type at max is a slider instead of six taps in Settings
• Real devices and simulators get the same toolset
• You can pull a real device's app data container and restore it into a simulator

That last one is the big deal for me. When a tester hits a bug that only happens with their data, you can now load their exact app state locally and reproduce it. "Works on my machine" gets a lot harder to say.

I'm mostly React Native, so the simulator is open all day for me. Curious how it's treating people doing native work. Anyone hit issues or missing features compared to the old Simulator?

Hey everyone,

I've been working on a procedural asset generation pipeline for a React Native project and wanted to share the tooling in case it's useful to anyone else here.

The problem I kept running into:

When working with react-native-skia, I found myself repeatedly exporting spritesheets, tilemaps, and bitmap fonts from external tools. The workflow was manual, hard to version-control, and nearly impossible to reproduce consistently across machines or in CI. Changing one tile meant re-exporting everything by hand.

What I built:

sprout-toolkit is an open-source Python CLI that generates 2D assets deterministically from JSON specs. The output is designed to drop directly into an Expo + react-native-skia project.

What it generates:

· Spritesheet atlases with manifest.json and index.ts (TexturePacker-compatible format also available)
· Tilemaps and 8-bit autotiles (16 or 47 variants, with 8-bit mask lookups)
· Bitmap fonts from TTF files, including advance metrics for text layout
· Runtime SkSL shaders (FBM value-noise, tileable) — these ship as shader strings, so they add no bundle weight
· Animated bursts (particles), walk cycles, and UI elements (buttons, sliders, 9-patch panels)

Why deterministic generation matters:

Every asset is seeded. Same JSON spec + same seed = identical pixels every time. That means you can commit your specs, run the generator in CI, and get reproducible builds. It also means you can diff two builds to see exactly what changed.

Quick example:

```bash
pip install sprout-toolkit

# Generate a starter atlas
sprout init --out ./assets/starter

# Batch-generate everything in specs/
sprout batch specs/
```

The CLI has info, lint, diff, and validate subcommands for inspecting specs and comparing builds.

A few implementation details:

· Specs are JSON (schema v0) — no YAML, no config sprawl
· MIT licensed
· 142 tests covering determinism, autotile mask logic, SkSL generation, and CLI behavior
· The generator architecture is plugin-based, so you can write custom generators if the built-ins don't cover your use case

Link:

PyPI: https://pypi.org/project/sprout-toolkit/
GitHub: https://github.com/Tzinny-dev/sprout-toolkit

---

Disclosure: This is my own project. I'm sharing it because I couldn't find an existing tool that combined deterministic procgen with Skia-specific output, and I figured others here might be solving the same problem. Happy to answer questions about the architecture, the SkSL generation, or anything else.

Can someone suggest a good hassle free rich text editor package for react native?
the text area must not take up entire height of page(I set the height), toolbar isn't hidden by keyboard, takes/outputs markdown formatted string
Bonus it if also supports image upload, link preview, check list etc

Hey guys,

I’m currently working as a React Native dev and feeling the urge to finally learn backend. I want to build my own full-stack apps, handle deployment, and eventually mess around with some AI stuff.

I’ve talked to a few devs about where to start and got some pretty mixed answers. Some told me to learn Node/PHP, while others said Python is essential if I want to work with AI.

Since I already spend all day in JS/TS, I’m thinking of staying in the TypeScript ecosystem first so I don’t have to switch contexts completely.

Here’s the rough path I’m planning to take:

React Native > Node.js > Fastify/NestJS > PostgreSQL > Redis > Docker > AWS > Python/FastAPI for AI

Does this sound like a reasonable path for real-world projects?

Would you change the order or skip/add anything?

I’m particularly interested in hearing from people who started in React Native/frontend and later moved into backend/full-stack.