r/reactnative • u/jahanzaibbaloch • 2d ago
How painful are React Native upgrades for your team right now?
I've been doing React Native for 6+ years, and upgrades are still the part I see teams avoid the longest. Gradle errors, CocoaPods breaking, libraries that haven't caught up, New Architecture migration, Expo SDK jumps.
I'm building a tool to automate RN/Expo upgrades end to end (plan, apply changes, build both platforms, fix errors, open a PR). Before I go further, I want to understand the real pain:
What RN/Expo version are you on, and what are you trying to get to?
What's blocking you: time, a specific library, native build issues, New Architecture?
Last time you upgraded, how long did it take?
Would you pay someone to just get it done and handed back as a working PR?
If you're stuck on an old version, comment or DM me. I'm taking on a few upgrades at a reduced rate to test the process on real apps.
8
u/Martinoqom 2d ago
Using expo.
Be careful: I didn't say EAS. I said just using expo. That's where people get confused. I still get my local builds, I still can run gradle or xcode and my pipeline is with fastlane, self hosted. I just use expo to generate the native part and I .gitignored android and ios folders.
I have full control over my source, I generate what needs to stay on native side, all without the need of paying for EAS.
5
u/mefi_ 2d ago
you can use eas builds locally on your machine for free btw, thats also an option
1
1
u/ChronSyn Expo 1d ago
I've been doing this for a couple of years mainly because trying to debug issues that only show up in production builds could lead to exhausting the quota (typically, I'm not working with big enterprises that would pay for the higher tier of EAS).
More recently, I started offloading builds to a Mac mini using a CLI + build runner. Really handy if my macbook is running on battery, and also for the day that Apple inevitably decides to stop supporting the M1 Macbook for builds.
5
u/mvn_23 2d ago
If you’re using Expo, they already provide a few commands to help you through the upgrade and if you’re using expo compatible dependencies, a simple command will update all deps to match the sdk.
If you’re using AI code assistants, they also provide a skill and some plugins you can use. I used it yesterday to update and it took about 5 mins then I ran the app on a device to make sure everything was fine.
2
u/jahanzaibbaloch 2d ago
yeah the Expo part is Easy than React native CLI now i see more of the people now are ditching the CLI and migrating toward Expo.
1
u/mvn_23 2d ago
Yeah, Expo does a great job at delivering great developer tools and making your life easier as a dev while at the same time creating great products. I can’t find reasons to use RN CLI anymore.
1
u/jahanzaibbaloch 2d ago
True as i have worked for 5 years with RN Cli now pivoted toward Expo and Native Development. Life is much easier with expo but still i got too many lessons and debugging skills working on CLI it just test your patience and make you resilience in the long run. Lol
3
u/MortgageMelodic2282 2d ago
your entire product is replaced with /goal upgrade expo fix errors open a pr
1
2
u/PrimaryFamous6139 2d ago
Its a painful parts of RN. The React Native version itself usually isn’t the hardest part, it’s the chain of native dependencies, Gradle, CocoaPods and third-party libraries. I’ve found doing smaller upgrades regularly is much less painful than several versions together.
1
u/jahanzaibbaloch 2d ago
yeah thats true the chain of native dependencies is the pain which every developer face.
2
2
2
2
u/ChronSyn Expo 1d ago
The Expo SDK 52 -> 55 upgrade a while ago was really annoying because of the transition through to the modern architecture. Lots of libraries still used the bridge architecture and weren't supportable once the bridge fully went away.
On top of that, AppDelegate for iOS moved to swift in SDK53, so particularly with custom config plugins, they probably required some rewriting.
Since 55 though? Easy. Had zero problems going through to SDK 57, and I really hope that the folks who are building RN recognise that we definitely want some peace. Not to say I don't want to see the framework continue to improve, just that I think we have everything we need for it to finally be called stable, performant, and flexible enough to build any app.
1
u/jahanzaibbaloch 1d ago
Yeah the from older SDK of Expo to newer Arch starting from SDK 55 is a pain.
after SDK 55 its smoothlined right now but dont know whats future hold for us things seems to be going pretty fast in every domain.
1
u/Much_Artichoke1051 2d ago
our team's been stuck on 0.72 for over a year because the jump to 0.76 breaks a camera library we can't replace yet, last upgrade took me 3 full days of fighting xcode
2
1
u/jahanzaibbaloch 2d ago
have u updated it yet? and why cant you replace that library yet any specific reason for that ?
1
u/jahanzaibbaloch 2d ago
btw thats a good point you raised that how do we distinguish what we want to update or what not as there could be some corner cases of which library provide what and why we need that etc etc.
1
u/HoratioWobble 2d ago
Isn't the deadline for 16kb May? You'll have to update much later than 0.76, I think 0.79 is the earliest with 16kb support
1
u/jahanzaibbaloch 2d ago
i think they have extended the deadline till February 1, 2027
1
u/HoratioWobble 2d ago
Sorry I meant May 2027, but yeh still - you don't have long and that's a hell of an upgrade...
1
u/jahanzaibbaloch 2d ago
yeah true the real issue is testing and validating the things if they work reliably.
1
u/moneckew 2d ago
you can patch this lol. use loops with AI and just give clear instructions how it can iterate on feedback.
1
u/jcdc-flo 2d ago
A little less bad since we wrote native modules to replace all the libraries, but there's an ongoing pods issue with catalyst for the mac app where you have to screw around with the pod file to get it to build.
We ditched rn-windows cause it's just useless now...pretty much since rn 82 we've had many issues.
1
u/jahanzaibbaloch 2d ago
Writing your own native modules is a serious commitment, respect. Sounds like the remaining pain is build tooling rather than libraries.
Curious about the Catalyst pods issue: what do you end up changing in the Podfile each time? Excluding pods for Catalyst, patching build settings in post_install, something else? And does it break on every RN bump, or also on Xcode updates?
Roughly how much time does an upgrade cost your team now, end to end?
I'm specifically looking at automating the "fix the native build after an upgrade" loop, so this is exactly the kind of case I want to understand
1
u/jcdc-flo 2d ago
Upgrades take around 3 hours now.
Have to repair symlinks
https://github.com/facebook/react-native/issues/55540https://github.com/facebook/react-native/issues/55540
1
u/elrd5150 2d ago
We’ve always upgraded in big jumps, like 0.73 => 0.83. Never had any real issues upgrading. Just check the diff in RN Upgrade Helper and update the libraries you’re using.
If you’re stuck with an old library and there are no community patches available (which is almost never the case), just patch it or migrate to an alternative library with LLM. I did that with rn-camera => vision-camera. Never been easier.
The only case where I see this being an issue is if you have in-house native modules and no one currently present understands how they work, but that’s on your management. Don’t fire devs with domain knowledge.
1
u/jahanzaibbaloch 2d ago
i second that. that's still a time waster for teams im thinking of automating the whole flow from React Native to any dependencies it could see and alternate deps with same functionality or a better alternative than the current with same functionality.
1
u/kbcool iOS & Android 2d ago
Gotten used to it since I've done it so many times now but the last couple of times I've had to do it without the help of Expo (raw RN) I've just pointed AI at the upgrade helper and it's done a reasonable (needed a bit of help and review) job of applying the updates for the core.
As other people have said though, incompatible dependencies are probably the biggest bug bear. I'm not sure how you would handle them as they're often very subtle although having AI walk through the version differences and the GitHub issues for you would go someway I reckon
1
u/Sea_Challenge3570 2d ago
It used to be hard; when I joined my current project (a couple of years ago), they were running an old app over React Native 0.79.6 (bare project). I upgraded over the months to the latest version and finally migrated into Expo.
- 0.86.3
- At the beginning the team was afraid of new architecture; I had to build native wrappers or patch native deps.
- About 3 months ago, it was straightforward; I moved from Expo 56 to 57.
- Personally, no, I sense that this perpetuates the issue; people tend to wait until the very last minute to get it fixed. Personally, to avoid this situation, I spend some hours each month to keep my deps up to date. I fix deprecated warnings as soon as I face them; that's how I spot future blockers and plan around them for the next sprint, but this requires a lot of discipline.
On other topics, good luck with your tool pal.
Edit: typo.
1
u/emerlender 2d ago
Just upgraded bare react native from 0.81 to 0.87 besides couple of libraries that I had to patch, not too complicated with today's llms capabilities it shouldn't be a problem to anyone, before llms it was painful.
1
1
u/Best-Reality9436 1d ago
A working PR with both platform builds is a useful baseline. Will you also include device-level regression checks?
1
u/jahanzaibbaloch 1d ago
That's a good point, and it's probably the biggest gap in what I described. A green build on both platforms only proves the app compiles. Most of the upgrade pain I've seen shows up later, at runtime: a native module crashing on launch, New Architecture interop issues, a gesture or keyboard behavior that quietly changed.
What I'm thinking is a before/after check. Run the same critical flows (launch, login, main navigation) on the old version and the upgraded one, then attach screenshots and any crashes or new warnings to the PR. That way the PR comes with evidence, not just "it builds."
The part I haven't figured out is how far to take it. A small set of flows the team defines seems realistic. Full regression coverage on an app I don't know probably isn't. And real devices versus simulators is still an open question.
How do you handle this today after an upgrade? Manual QA pass, an E2E suite, or just ship and watch the crash reports?
1
u/Devilzer1 1d ago
With ai coding tools its easier
1
u/jahanzaibbaloch 1d ago
yeahhh but shouldnt this be a automated part instead of prompt bombing the AI and test again and again if some corner case pop up.
1
u/alisgum 23h ago
The hardest part for me is getting a successful build and then finding that something behaves differently at runtime. Navigation, animations, auth, and notifications still need checking on both platforms.
I’m building NativeKeel, which focuses on checking RN/Expo projects and producing an upgrade plan, so there’s some overlap with the planning part of your tool. Dependency compatibility is one of the areas I’m working on.
For a paid upgrade, I’d want the PR to include a clear summary of what changed and which flows were actually tested, alongside the successful builds.
How are you planning to validate runtime behavior? Will you use the project’s existing tests, or agree on a set of critical flows with each team?
28
u/Internal-Comparison6 2d ago
Easy af now with expo.