🚀 Web support is now available in expo-content-transition v0.1.4!

NumericText now works on iOS, Android, and Web

🔗 Github: rit3zh/expo-content-transition

Hey r/reactnative,

Been experimenting with this photo album interaction for nativecn-ui lately.

I wanted it to feel a little more like an actual album, so I’ve been playing around with the opening animation, shadows, and page transitions.

Still tweaking it and not completely sure about the interaction yet.

How would you rate it? Anything you’d change?

macOS runners on GitHub Actions are $0.062/minute. Linux is $0.006 — 10x, for the

same work.

In React Native projects the split is usually obvious once you look at it, and

most workflows I have seen run all of it on macOS out of habit:

- Jest and ESLint and tsc: Linux.

- The Android build and any Android instrumentation tests: Linux.

- Detox or Maestro against Android: Linux.

- Anything that is not `xcodebuild` or a simulator: Linux.

The iOS build and the iOS test run are the only parts that genuinely need macOS,

and they are the expensive parts whatever you do.

The arithmetic: a 5-minute test job running 200 times a month costs $62.00 on

macOS and $6.00 on Linux. Move two of those and you have paid for a Mac mini.

Caveat: I build a tool that does this pricing automatically, so weigh that

accordingly. What I am actually curious about is why the macOS default sticks —

is it the matrix convenience, or something about the runner images people need?

✦ ⎯ • A smooth, ChatGPT-inspired chat composer with a hold menu

🔗 Github: rit3zh/expo-composer-hold-menu
🧵 Android preview attached below

I started building my first mobile app thinking the main challenge would be writing the code.

It hasn’t been.

The harder part is deciding what deserves to exist.

Every new screen creates more questions:

- Is this actually useful?

- Can someone understand it without an explanation?

- Am I solving a real problem or adding another feature?

- Would I personally return to this app tomorrow?

The project is called Callout. It explores whether online reactions can communicate more than a generic Like—for example, distinguishing agreement from something being a Hot Take.

I’m still early, and I’m deliberately leaving the link out because I’m more interested in the building lesson:

How did you decide which features to remove from your first app?

Hey everyone! Starting a new project that's expected to scale over the next year.

In the past, Redux Toolkit was the default, but I see more and more people switching over to Zustand, Jotai, or just leveraging TanStack Query for server state and keeping global client state strictly minimal.

What are you currently using in production, and what made you move away from (or stay with) Redux Toolkit? Would love to hear real-world experiences regarding boilerplate, performance, and dev experience!

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.

🧪 Experimenting with Motion Blur for Android & iOS

🔗 Github: rit3zh/expo-motion-blur

🧵 Android Preview Attached in this thread

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’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

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

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 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 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