Originally published on expo.dev/blog by Armaiz Adenwala.
This is a guest post from Armaiz Adenwala - Armaiz is responsible for the mobile app experience at Hipcamp.
…
Upgrading React Native has always been a scary task for any engineer. It requires touching unfamiliar native code, crucial libraries, and resolving breaking changes. Anything could raise an error if not tested thoroughly. Over time tools like React Native Upgrade helper eased the process and frameworks like Expo were built around making this process go smoother.
The complexity of upgrades
Unfortunately, not every React Native app is in a perfect state. It can be very difficult for a fast paced company to balance maintaining dependencies and shipping features. As a result, upgrades become a much larger endeavor. At Hipcamp, we recently faced the challenge of upgrading to New Architecture + Expo 54. With New Architecture, we had a few dozen libraries that were outdated and needed to be either upgraded or replaced.
If you have worked on React Native enough, you would know that simply bumping to the latest version is not enough. There is a large amount of time spent debugging and addressing issues. Additionally, multiple libraries could conflict with each other and you may need to find compatible versions between the two.
Luckily, this time we had already built Scout, an AI agent designed to tackle whatever task we throw at it. What would have taken an engineer weeks of tedious dependency research and version resolution, Scout handled across a few focused sessions over several days. While having an internal agent like Scout helps, we will be sharing how you can tackle React Native upgrades with pure Claude Code.
The State of the Hipcamp App pre-upgrade
We haven’t kept up with our app versioning enough outside security updates. Abandoned packages, outdated packages from 4-6 years ago, etc. We had over 100 dependencies with roughly 40 of them needing to be upgraded to support New Arch.
Given how lean our company is, we didn’t have cycles to juggle upgrades on top of regular product work. It wasn’t a cost issue, it was a time issue for us. We couldn’t justify taking an engineer off an impactful project to work on this major upgrade for a couple months.
How to scope an upgrade
Before we dive into how we accomplished this upgrade, we need to discuss the key goals of this process in order to design our prompts.
We landed on the following:
- Only focus on dependencies that are needed
- We only upgrade libraries that don’t currently support new arch / 16kb android
- Replace dependencies with an Expo equivalent
- Expo’s modules are well maintained, reliable, and popular.
- Leverage patch-package as a last resort
The upgrade workflow
We then decided how we wanted this upgrade process to go. We determined we needed to build a multi-phase approach.
We had to decide how much time/money we were willing to spend on each phase of the work. Ultimately we realized that tokens are far cheaper than having an engineer tirelessly navigate through docs, code, and Github issues. Not to mention, our engineers spent their time saved on developing product features that bring us revenue. So it was a no brainer to not let budget restrict this project.
Phase 1: Build your agent
We highly recommending building an agent like Scout internally or leverage Expo’s upgrade skill. Teach the agent your codebase, design a way to index the architecture of your codebase. We spent a day running our documenter command, /scout-document-architecture, to take notes on every aspect and detail of our app. This prevented Scout from hallucinating or missing anything.
Phase 2: Audit all of your dependencies
We sent our agent on a task to audit all of our dependencies. We recommend using an sqlite db to track everything, you can sync this db to your project management tool, or just resort to using a markdown file.
We then provided it a prompt. Here is an example of what we gave ours:
# Expo SDK 50 → 54 Dependency Audit
Audit every dependency in the app for Expo 50 → 54 upgrade compatibility.
## Context
- **Current:** Expo 50 (RN 0.73, React 18.2)
- **Target:** Expo 54 (RN 0.81, React 19.1)
- Expo 52+ enables New Architecture by default
- Expo 52+ requires 16kb Android page size support
## Research
For each dependency, you MUST:
- **Read GitHub changelogs/releases** between the Expo 50 and Expo 54 compatible versions
- **Search GitHub issues** for bugs, errors, risks, complaints
- **Read setup docs** and migration guides
- **Check for conflicts** with other dependencies in our stack
- **Check if the setup switch is risky or complex**
Then answer:
1. Can this be **replaced with an Expo module**?
2. Can this be **removed entirely**?
3. Are there **known New Arch blockers** in GitHub issues?
4. Are there **16kb page size issues** reported?
5. Does this have **peer dependency conflicts** with other deps?
6. Is the **upgrade path smooth** or does it require code changes?
7. Are there **community complaints** about recent versions?
## Subagent Strategy
- **1 subagent** for small/simple JS-only dependencies
- **5 subagents** for medium/harder native dependencies
- **10 subagents** for extreme-complexity dependencies (react-native core, reanimated, maps, firebase, sentry)
- Each subagent works on exactly ONE dependency — do not batch
## Output
- One notes file per dependency in `./dependencies/{name}.md`
- SQLite DB at `./dependencies.db` with columns: name, expo_50_version, max_version_expo_50, expo_54_version, new_arch_support, sixteenkb_support, status, type (javascript/native), change_recommendation (upgrade/remove/swap), swap_target, complexity (0-10), notes
- **Always prefer replacing with an Expo equivalent library if possible**
- Process dependencies one at a time — do not skip ahead
## References
- https://reactnative.directory/
- https://docs.expo.dev/workflow/upgrading-expo-sdk-walkthrough/
Phase 3: Review and begin the upgrade!
Then, we manually went through each upgrade item and confirmed it all looked right. We make sure its not removing libraries it shouldn’t, and pick the right alternative library if it recommended any. We highly recommend using Expo’s libraries if available as they are actively maintained and well documented.
Once complete, we sent off an agent to work on creating prs for every upgrade. For us, the initial run was 3 days of non stop upgrading. We HIGHLY recommend using subagents for every step when dealing with long running tasks. Having each dependency in its own context is critical for a reliable upgrade.
We gave it the following process:
- Pick a dependency
- Send a subagent to look at notes from previous step
- Have 1-3 subagents attempt to upgrade to the version specified
- Once complete, send reviewer subagents to review changes
- Run yarn lint, tsc, and react native bundle and address any errors that come up
- Create an EAS build for ios and android, validate that the build was successful. Address any errors that may come up
- Create a final EAS Build for ios + android
- Create a pr and add builds, manual QA steps, affected screens, and anything else
When I came back, I had numerous prs to review. It was very quick to go through all of the prs. There were of course a few prs that needed close engineer involvement, but were easy to work on as our agent already shared all of the context, docs, related Github issues, and more in the PR.
From our experience, we only had a week spent debugging some New Architecture build issues. Our entire upgrade process went from what was estimated to be 2-3 months to a couple weeks. From one quarter to a sprint. Our dependency situation was very concerning, for smaller apps you may notice even less time spent.
Of course we still had polishing but the bulk of the work was done.
Phase 4: QA, rollout, and monitoring
We wanted a very safe rollout, we required our fellow Hipcamp employees to use the app and call out bugs. We threw a QA party where people from the company joined and QA’d the app together. These are extremely productive.
We then used the slow rollout feature on iOS and Android. We released iOS first then released Android after we felt confident on iOS.
Monitoring:
It is crucial you have some form of error tracking in place. In addition, it is a good idea to integrate performance profiling into the app. There are many out there, one of which being Expo Observe - we are lucky to be participants in their private preview!
We also had our agent monitor and fix errors for us as they came through. Whether this was from the QA party or from production, our agent was able to resolve most bugs with minimal engineering involvement.
To our surprise we saw no major new errors other than a high memory usage issue that became magnified on New Architecture. In fact we saw less errors in total. We attribute this to the fact that engineers can spend time solving the complex work and throughly QA’ing while an agent works through the rest.
Conclusion
AI is changing how engineers work. The hours spent skimming documentation, racing against deadlines, and debugging obscure issues may soon be a thing of the past. This upgrade was proof that AI agents can be a reliable partner on important, challenging projects, and that the real benefit of AI-assisted engineering isn't replacing engineers but freeing them to focus on complex problems instead of toiling through tedious ones.
Top comments (0)