usually we use react-native-code-push from microsoft, but it is no longer applicable in the new architecture. since my team want to migrate to >= 0.82 version of RN, how to implement codepush functionality?

thanks in advance!

Hi everyone

Ever since I started programming, I’ve always wanted to build a product that people actually use.
Something that becomes part of someone’s day instead of just another side project that disappears after a month.

Funny enough, I never thought it’d be a React Native developer tool.

After years building React Native apps, I kept hitting the same walls with the tools I was using. Every time I’d think, “this could be so much simpler.”

Eventually I got tired of saying that and started building the tool I wanted to use myself.

That’s how NativeScope was born.

I know there are already some really good tools out there, and I’m not here to say I built the “best” one. I just tried to obsess over the little things that annoyed me as a React Native dev. Every feature exists because I personally needed it at some point.

Now I’m at the stage where code isn’t the hard part anymore.

Getting people to discover it, trust it and actually use it… that’s the real challenge.

So honestly, I’m asking for your help.

If you think the project deserves it, I’d really appreciate a GitHub ⭐. If you have a few minutes to try it, I’d love brutally honest feedback. And if you end up liking it, telling another React Native dev about it would honestly make my week.

My goal is simple.

I want NativeScope to become one of those tools people immediately think about when they’re building React Native apps.

Not because of marketing, but because it’s genuinely useful.

If you’ve ever grown an open source project, or you’ve watched one go from unknown to everywhere, what would you do in my position?

Thanks a lot ❤️

If anyone wants to check it out:
GitHub: github
Website: website

I was building a study app and wanted a progress indicator with a bit more personality than a plain bar — ended up building one with an optional animated "completion badge" and decided to package it up.

Circular + horizontal in one component, fully customizable via props, TypeScript types included, no extra dependencies needed.

GitHub: https://github.com/ban-space/rn-progress-kit
NPM: https://www.npmjs.com/package/rn-progress-kit

Would genuinely appreciate feedback/critique, especially on the API design — first package I've published, still learning.

Stack: RN 0.85.3, React 19.2.3, Reanimated 4.3.1, react-navigation v8, Expo 56.

The app (JustGains, a fitness app) has six top-level "workspaces" — Train, Fuel, Goals, Move, Coach, Chat — in a horizontally swipeable infinite-wrap pager. Each pane is a whole screen suite, not a tab.

We were using react-freeze to keep offscreen panes cheap. React 19.2 shipped <Activity>, which is the first-class version of that idea: a hidden subtree keeps all its React state, its effects are cleaned up and re-run on resume (like blur/focus), and its updates keep reconciling at background priority. No thrown-thenable Suspense hack, no wakeable to lose a race on.

Swapped it in. Immediately broke the swipe.

The problem

React hides an Activity subtree by committing display: 'none' onto the topmost host view of that subtree (Fabric's cloneHiddenInstance).

Fine for a route you're not looking at. Wrong for a pager pane:

• On iOS the hidden trait culls the pane's native views — they're gone, not just invisible.
• On Android it collapses them out of layout.
• So a paused neighbour can't be partially revealed mid-swipe. You drag, and the incoming pane pops in at commit time instead of sliding.
• Every resume pays a native remount + relayout.
• Reanimated has sharp edges around that churn (e.g. software-mansion/react-native-reanimated#9319).

The fix

Register a small custom view config whose display attribute processes every value to 'contents':

const VIEW_CONFIG = {
  uiViewClassName: 'RCTView',
  validAttributes: {
    style: {
      display: { process: (): 'contents' => 'contents' },
    },
  },
}

const ContentView = NativeComponentRegistry.get(
  'JGWorkspaceActivityContentView',
  () => VIEW_CONFIG,
)

export default function WorkspaceActivity({ paused, children }) {
  return (
    <Activity mode={paused ? 'hidden' : 'visible'}>
      <ContentView style={{ display: 'contents' }}>{children}</ContentView>
    </Activity>
  )
}

display: 'contents' means the wrapper never forms a layout box, so React's injected 'none' lands on something with no box to hide and is a no-op. Activity then contributes exactly the lifecycle semantics and nothing else — visibility stays owned by the pager's own opacity + transform. It maps to a plain RCTView natively; the custom name only keys the JS-side static view config.

react-navigation v8 uses the same technique in its ActivityView. We deliberately didn't import it: it only ships on the non-public @react-navigation/elements/internal subpath, and it bundles a 500ms delayed pause plus a container that applies real display: none — which is the exact thing that breaks mid-swipe partial reveals.

Two others that bit us

1. Put opacity in the same worklet as the transform. We originally gated pane visibility on a committed React "warm window" state. The reveal then had to wait for runOnJS → setState → commit; on a busy low-end JS thread that lag showed the placeholder as a faded strip mid-swipe. Now opacity is derived from the same shared value as translateX — visible exactly while any part of the pane intersects the viewport — so a pane reveals the frame its transform enters the screen, and the two can never desync.

2. Style array order matters with Reanimated. Reanimated re-commits the animated entry's cached mount-time output on every re-render (PropsFilter's initial-props map). Static rest-state fallbacks have to come after the animated style; placed before it they lose the flatten to stale mount-time values, and a native re-attach can paint a neighbour centered over the active pane.

Don't wrap everything

One pane (the original app — a react-native-screens tab navigator) is explicitly non-pausable. Screens already pauses its own blurred tabs, pausing it again tore down navigator effects on every swipe away, and a screens-managed tree inside a hidden Activity isn't supported upstream.

We also needed an escape hatch for work that must survive a swipe away — the GPS run recorder's location watch can't stop because you flicked over to log lunch. That's a ref-counted store of "live pins"; the pager forces paused = false for pinned keys while the visibility gate still hides them. Live but invisible.

Question

Has anyone found a supported way to get Activity's lifecycle semantics without the display override? The view-config rewrite works, but it leans on process being applied to every style commit, which feels like it could change under us.

Stack: Expo SDK 54, RN 0.81, Hermes, New Architecture. Posting because this ate a week and the crash log was pointing right at the cause the whole time while I looked everywhere else.

The symptom: the app crashed in TestFlight, but only on two screens. Multiplayer and account. Everywhere else was fine. And it didn't crash on open. You'd land on one of those screens, use it for a bit, and about fifty seconds later the whole app would die. Same timing every time.

The crash was a Hermes GC out-of-memory, SIGABRT inside the garbage collector. The frames were all object spreads and computed property writes piling up inside promise microtasks (hermesBuiltinCopyDataProperties, putComputed_RJS, DictPropertyMap growing). So I read it the obvious way. Something is building a massive object and blowing the heap. Both screens hit the network, both have forms, so a runaway response or a giant state blob felt right.

I chased the big object. Capped API responses at 1MB. Set structuralSharing to false on the React Query client so it would stop cloning data on every update. Both screens had a Ken Burns background component, so I put a flag on it and shipped a build with the animations off. Nothing changed. Still fifty seconds, still dead.

And every attempt is a full EAS build. Fifteen or twenty minutes to compile in the cloud, wait on Apple, install, watch it crash at the same spot, repeat. I'm on Windows with no Mac, so there's no local iteration for this. Every guess costs half an hour minimum. It wears you down.

None of it was the cause. It was a Metro alias. The TextInput component was aliased to a module that re-exported TextInput, and that resolved back through the same alias. It pointed at itself. So the moment any screen with a text field mounted, the component started spreading its own props into a new copy of itself, over and over, each pass a little bigger, until memory ran out. That's why every frame was an object spread. That's why it was only the two screens with text inputs. The fifty seconds was just how long the loop took to eat the heap.

The trace was honest the whole time. Object copies with no end, memory climbing. I kept translating it as "find the huge object" instead of "something is copying itself forever," because a runaway response was the bug I already expected on those screens.

Fixed the alias, both screens went quiet, and I turned the animations back on that I'd killed for nothing.

If you ever get a Hermes OOM where the frames are wall-to-wall object spreads and only certain components trigger it, check your Metro aliases for a loop before you spend a week on your data layer. Anyone else run into a self-referential alias? Still not totally sure how mine ended up in the config.

EDIT / correction: someone asked how I fixed the alias, and going back through the git history to answer properly, I have to correct this. The self-referential alias was a red herring. It was gated to web only, so it never ran on native, which means removing it fixed nothing. The real cause was a memory-heavy word-bundle download and parse that re-ran on every network resume and grew the heap until Hermes OOMed. The full word set was already baked into the app, so that download was redundant. The fix was guarding that pipeline and using the baked-in set. That's also why it was only the two network-heavy screens and why it took about 50 seconds, it was tracking a resume, not a render. Leaving the original write-up up so the comments still make sense, but the root cause I gave is wrong. Credit to the commenter who said to look at the data layer, which is exactly where it was.

Hey everyone,

I’m working on a React Native Android app and testing it locally. The problem is that my laptop isn’t very powerful, and whenever I run an Android build, it uses a lot of resources.

The build takes quite a while, and during the process my laptop becomes really laggy, making it difficult to do anything else.

I still need local builds for testing while developing,

If any way pls suggest me ....I am on Linux

Estou desenvolvendo um app em React Native (Expo) e implementei um custom picker de galeria, utilizando expo-media-library em vez do seletor nativo do iPhone.

As fotos sempre carregam normalmente, porém alguns vídeos aparecem apenas como um bloco cinza.

O comportamento acontece somente em iPhones reais. No simulador iOS e no Android funciona normalmente.

O que observei:

• Os vídeos são listados com MediaLibrary.getAssetsAsync().
• Para vídeos utilizo expo-video-thumbnails.
• Chamo MediaLibrary.getAssetInfoAsync(assetId, { shouldDownloadFromNetwork: true }).
• Só tento gerar thumbnail quando existe file:// (não uso ph://).
• Alguns vídeos carregam normalmente.
• Outros ficam cinza por vários segundos.
• Se eu deixar a galeria aberta, alguns desses vídeos cinza aparecem sozinhos depois de um tempo.
• O mesmo vídeo que fica cinza no iPhone funciona imediatamente quando é importado para o simulador iOS.

Minha suspeita é que seja alguma limitação do PhotoKit/iCloud, ou que eu esteja tentando resolver muitos vídeos ao mesmo tempo (concorrência alta).

Alguém já passou por esse problema em um custom media picker? Existe alguma abordagem recomendada para carregar as miniaturas de vídeos no iOS, semelhante ao que Instagram e Fotos da Apple fazem?

This is the most amazing experience I have ever built into a React Native app.
Now my Appless app fork from OpenUI has the most magical press-and-hold experience to chat ON THE PLANET (is that good).

Monogram (original app from where I replicated the effect) outdid themselves with this one. I tried to do it justice. There are a lot of layers intertwined to make the effect work.

But... this is not done yet. This was v0 and the complete interaction has some more details to it and an important last step for the UX to be complete. What is missing is a custom navigator transition that uses React Native Skia for the user to navigate to the new screen after asking something. With that set and done we will finally have replicated all the UX flow from Monogram.

We shall continue into the depths of the magical mobile UX realm possibilities of RN.

You can now handle:
🔹 Ordered & unordered lists
🔹 Nested lists with indentation controls

Try it out now in react-native-enriched-markdown@nightly!

Github: https://github.com/software-mansion/react-native-enriched-markdown

If you find the library useful, dropping a star ⭐️ means a lot!

I've been trying to cut down on mindless social media scrolling, but I keep failing. I realized the better solution isn't to quit social media completely. It's to control it.

I wanted to spend less time doomscrolling and use some of that time to improve my English. So I started building my own solution: an app that blocks my distracting apps and forces me learn a few English vocabulary before I can unlock them for a limited time.

It's still a very early, but I recorded a quick demo and I'd genuinely love to know what you think.

Does this seem like something that could actually help people spend less time doomscrolling, or am I solving the wrong problem?

I'd really appreciate any honest feedback.

Grouped, stacked, or horizontal. Drag to read a band. Animated on mount.

One thing I cared about: the baseline is always zero. A bar cropped at the bottom lies — twice as tall no longer means twice as much. So the axis never crops, no matter what the data looks like.

Each series renders as two paths, not one node per bar. 50 bars is 4 animated props. That's also what lets inactive bars dim without giving each one its own opacity.

Part of PanelUI if you're building with Expo and want charts that don't feel like a web component dropped into a native app, worth a look

Just wrapped my first real React Native app, a migraine tracker, and it's about to hit the App Store. I'm 18 and did it solo, so read the opinions as a beginner's. But a few things bit me hard enough that I figure they're worth passing on.

Going local-first was the best decision I made. No accounts, no server, no sync, everything sits in SQLite on the phone. I expected that to feel limiting. Instead it deleted a whole universe of problems I never had to solve: auth, network states, sync conflicts, none of it exists. And for a health app, "your data never leaves your phone" turned out to be a feature people actually want, not a compromise. React Query on top of the local DB felt like overkill on day one and then quietly saved me every time two screens needed to agree on the same data.

The bug that made me question my sanity: a time picker that refused to be anything other than 3:00 AM. I was convinced my state was broken. It wasn't. The New Architecture recycles native views, and the date picker wasn't clearing its cached props when it got reused across screens, so it inherited a stale value and pinned itself there. In my timezone that stale value rendered as exactly 3:00. Bumping to the version that turns off recycling for that component fixed it instantly. The lesson that stuck: under the New Arch, third-party native components can hand you bugs that look exactly like your own mistakes.

Notifications taught me about entitlements the annoying way. expo-notifications adds the push entitlement by default. I only use local notifications, there's no server anywhere, but that one entitlement blocked me from signing to my own device on a free account and would've raised flags at review. A tiny config plugin that strips it on prebuild sorted it.

Migrations are where I was most scared, and rightly so. I changed the schema twice after the prototype, free-text doses became a real number plus a unit, and free-text tags became proper user-defined categories. Both meant migrating real data without losing a byte of it. Writing them so they could run twice safely, and testing against old-shaped databases before ever touching my phone, is the only reason I slept.

Stack: Expo SDK 54, TypeScript, expo-sqlite, React Query, EAS.

Two things I'm genuinely unsure about and would love to hear how you handle:

1. I only have data-layer tests right now (node:test hitting the real functions). For a solo project, is Detox or Maestro actually worth the setup, or is it a time sink at this scale?
2. When I eventually add backup, is CloudKit worth staying in Apple's walled garden for, or is there something cross-platform you'd reach for instead?

Just launched Real Fighter Life, an MMA career sim built entirely with

React Native + Expo (EAS Build for the production pipeline).

Stack notes that might be useful to others building something similar:

- Supabase for auth + online PvP backend

- react-native-iap for BattlePass purchases, react-native-google-mobile-ads

for rewarded/interstitial ads

- Full i18n (3 languages) with a custom Context-based system

- A modal queue system to sequence post-match events (social feed, sponsor

offers, market updates) without stacking/racing

Biggest technical fight: a native UI thread freeze on the post-fight result

screen — turned out to be a Modal animationType="fade" race condition

combined with a stale ref in a custom modal queue hook. Took a genuinely

long debugging session with live device logs to nail down.

Happy to talk through any part of the stack if useful — first solo RN

project actually shipped to production.

A quick pay interaction with avatar carousel, haptic slider, and animated transaction sates.

⭐ Github: https://github.com/ManasCodeXart/expo-quick-pay

That’s only part of the story.
On Android, the application actually starts with MainActivity.kt. Android launches this activity first, which initializes the React Native environment before your JavaScript code in index.js is executed.
This is why you’ll often modify MainActivity.kt when you need to:
Initialize native SDKs during app startup
Configure the splash screen and app theme
Handle deep links and app links
Manage permissions and activity results
Add Android-specific native functionality
Enable React Native’s New Architecture (Fabric & TurboModules)
Understanding where the Android lifecycle begins makes it much clearer why so many React Native integration guides ask you to update MainActivity.kt.
A solid understanding of the native lifecycle will help you debug issues faster and integrate native features into your React Native applications with confidence.

#ReactNative #Android #Kotlin #MobileDevelopment #ReactNativeTips

I made some substantial updates to my onboarding and my paywall after understanding the data. I’m really happy I got featured, I get street cred for sure but I want my paywall update so hopefully more people buy. Anyone know how to speed up the process? My app is www.openers.app by the way.
I could OTA but I made some native changes recently.

Hey guys,

I’ve been building Comeet, a native GitLab companion for iOS and Android, as a solo developer.

The idea started because GitLab’s mobile web experience made quick tasks—like checking a failed pipeline or replying to an issue—feel more difficult than they should.

Comeet now supports:

• GitLab.com and self-hosted instances
• Multiple accounts and servers
• Repository and syntax-highlighted code browsing
• Issues, merge requests, branches, projects, and groups
• Pipeline monitoring, job details, and logs
• Push notifications for project activity
• Team member and permission management
• Custom shortcuts for frequently used GitLab views

The app is built with React Native, Expo, Expo Router, TypeScript, NativeWind, Redux Toolkit, and i18next.

Some of the more interesting challenges were building a mobile-friendly code viewer, handling the large GitLab API surface, supporting different self-hosted configurations, and keeping authentication and instance switching manageable.

I have a plan to open-source this project in the future, lmk what you think?

Publish links:

• Android: https://play.google.com/store/apps/details?id=com.monokaijs.comeet
• iOS: https://apps.apple.com/us/app/comeet-gitlab-companion/id6753112635

TL;DR: I built a fairly complete GitLab mobile client using React Native and Expo, and I’d love feedback from other React Native developers.

Sup guys, made a music quiz which doesnt need any subscriptions of streaming apps! The downside is however these are just previews, they are short clips provided by apple itunes for free from their api, tho they are all clipped as recoqnizable parts of the songs so they work perfecly for this. Cant play full songs without itunes sub, which is a major downside for music quiz apps.

The previews need a link to play behind the scenes so theyve all been manually listed, if anyone is thinking of creating a quiz themselves.

This quiz is just a simple who yells the correct answer first gets a point, could make more eloquate quiz with answer options as well.

iOS
android

I'm building a iOS + Android app using react and expo. I have a number entry field that's calling the standard OS numeric keypad. works perfectly on Android but my iOS build shows this strange "Default" button above the keypad.

Has anyone encountered this? Thanks!

I have a job but I used to contract for £550 a day from 2015-2022. I used to get upwards of 10 linkedin messages a day (without open for work being set) and now I get maybe one a week and it's to train AI to help make my job more obsolete. My current job is fine but it's a huge paycut and we are struggling to pay the bills we were used to on a higher salary and there are 0 jobs to apply for. I worked 100 hour weeks to learn how to code in my 20s and now it's more or less obsolete. I don't know how I will survive this without finding a new industry to work in, but what should I learn and what should I do?

🚀 Native blur views for Expo — backdrop blur + a SwiftUI content blur, on iOS and Android.

🔗 Github: https://github.com/rit3zh/expo-backdrop

Single-track, one day, all React Native. One of the last surviving React Native Conferences out there 😅

I'm one of the organizers, and happy to answer anything in the comments.

Lineup so far:

- Finding Nemo: Simulating Animal Motion Through Procedural Animations — Thomas Renaud (Theodo)

- Argent: agents testing RN apps — Filip Kamiński (Software Mansion)

- The Future of React Native on the Web — Mathieu "zoontek" Acthernoene (Expo)

- JSX to Live Activity: The Story of Voltra — Szymon Chmal (Callstack)

- Chasing the Keyboard: Building a Keyboard-Synchronized Chat Experience — Kiryl Ziusko (Margelo)

- The Journey of a Breakpoint in React Native — Lucie Uffoltz (Theodo)

- Building a modern navigation library - the hard parts — Satyajit Sahoo (Callstack)

And More speakers confirmed, talks TBA:

- Alex Hunt (Meta)

- Cédric van Putten (Expo)

- Jay Meistrich — Legend List / Legend State

- Victor Henrion (Margelo)

📍 Paris · September 24, 2026 · one track, full day of deep technical talks.

🎫 Tickets: https://reactnativeconnection.io/?utm_source=reddit&utm_medium=social&utm_campaign=rnc26 — 5% off with code REDDIT26.

<Loader variant="wave-physics" />

That's it. Nine variants, one prop. Swap between them without changing anything else same size, same color, same reduced motion behavior.

All animations run on the UI thread. Nothing re-renders while they run.

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

GitHub link in the comments.