Managing constant React Native upgrades driven by Google/Apple requirements (min SDK, Xcode/iOS SDK, 16KB page size)

[akhan-design]

Hey folks, looking for advice from teams running React Native in production at scale.

Over the last year we’ve been forced into multiple RN upgrades mainly because of platform policy/requirement changes:

Android minimum requirements pushed us to upgrade to RN 0.74.

Now we’re seeing Apple/Xcode iOS SDK minimums with an April 2026 deadline (forcing another upgrade cycle).

And recently Google introduced the 16KB memory / page size requirement, which from what I’m hearing effectively means RN 0.77+ (or at least newer toolchain + fixes), which becomes another upgrade shortly after the last one.

As Head of IT, the hard part isn’t the upgrade itself, it’s the constant unplanned upgrade cadence and resource churn: we upgrade, stabilize, then 3–4 months later we’re forced into the next one. It’s getting difficult to schedule and staff while still delivering product work.

**Questions

1. How are you handling this operationally?**

• Do you run a rolling RN upgrade program (e.g., quarterly) instead of ad-hoc upgrades?

• Do you allocate a fixed “platform compliance” budget/squad?

• Any strategies for minimizing regression risk (e2e coverage, upgrade playbooks, dependency policies)?

2. Why are these changes so aggressive lately?

• Not looking for complaints, just trying to understand the underlying drivers (security, performance, architecture/toolchain changes, ecosystem shifts).

3. For the 16KB memory/page size requirement: is there any viable mitigation on RN 0.74?

Specifically:

• Is there a patch/workaround to stay on 0.74 temporarily (toolchain flags, NDK changes, build config, selective backports)?

• We have native dependencies like Realm and others, so an immediate RN major bump isn’t trivial.

If anyone has been through this recently, I’d really appreciate concrete guidance: what worked, what didn’t, and how you plan upgrades so they’re not constant fire drills.

Thanks!
Ahmed Khan

[coolsoftwaretyler]

Hey @akhan-design - I can certainly sympathize with you, and maybe I can offer some advice.

The fundamental thing we have to work with is: shipping apps to Apple's App Store and Google Play always means we have to play by their rules and live in their world. It's the cost of doing business, and if your business has made the tradeoff to go out and ship there, well, welcome to the treadmill. Things are always changing and the best we can do is keep up with it.

As Head of IT, the hard part isn’t the upgrade itself, it’s the constant unplanned upgrade cadence and resource churn: we upgrade, stabilize, then 3–4 months later we’re forced into the next one. It’s getting difficult to schedule and staff while still delivering product work.

My advice here is to turn this unplanned upgrade cadence into a planned one. Stuff usually changes every quarter or half. Apple and Google do send out advance notice (check your notifications in both dashboards - you'll usually get ~6 months heads up on big changes like this).

Block out time each quarter to do an upgrade if possible. Which brings me to my answers to your specific questions:

Do you run a rolling RN upgrade program (e.g., quarterly) instead of ad-hoc upgrades?

Yes absolutely. This is even easier if you're using a framework to ship React Native, like Expo. If you aren't right now, there are paths to move a bare React Native app to Expo. You may need to slow down (get into a framework) to speed up (get faster at upgrades).

But if you're on Expo, most upgrades are a snap. Especially with CNG. As an example, I have a PR to upgrade the Ignite boilerplate from Expo 54 to 55 (beta), and it's just some package.json updates.

Upgrades were a huge pain point in React Native's history. But continuous native generation has truly made that a thing of the past. I recommend you get on Expo and get on a quarterly update cycle. If you want to be conservative, stay one Expo SDK behind latest.

Do you allocate a fixed “platform compliance” budget/squad?

This depends. At the last product company I worked for, we didn't have a big enough team for that. But I was responsible for it as the tech lead, so I budgeted some small portion of my time to staying on top of things like console messages from the platforms, and escalating to my CEO if I needed resourcing.

These days, I do React Native consulting. Generally, the larger the client, the more likely they are to have a team dedicated to this. But even then, most big orgs can get away with a temporary team that works on it on a cadence - not every single day. I'll reiterate my advice for Expo and rolling upgrades.

Any strategies for minimizing regression risk (e2e coverage, upgrade playbooks, dependency policies)?

Yes to end-to-end coverage. You need it. Upgrade playbooks might be helpful, but with Expo it's really not that involved. You may want run the upgrade a few times to get a feel for it, and there will be some skills to learn around troubleshooting native dependencies. (My advice: go to GitHub issues for the package, then for Expo, then React Native - in that order).

I've never seen dependency policies work very well in React Native. Sometimes newer dependencies have important fixes, and sometimes they break things. That's the nature of using a lot of distributed open source. It's one of the tradeoffs you have to evaluate when relying on the npm ecosystem. Expo helps again because install --fix will give you the compatible versions of a lot of popular libraries.

Other strategies is having thorough code review and QA. Shift left what you can, and then train up your QA quite well. Use staged rollouts with Apple TestFlight, and Google Play internal tracks, and make sure you have good monitoring. Let new releases spend time in early release phases and then evaluate them before promoting.

Why are these changes so aggressive lately?

Hard to say. I think we'd have to ask Apple and Google, and they wouldn't give us a straight answer anyway. Maybe the pace of things is moving along with the very rapidly changing tech landscape? Or maybe it's just unlucky. I know it's also coming at a time that meta is making big changes with compatibility layers for the old architecture, so I think we just ended up in a bad spot here. There are so many moving pieces, I think some businesses are just ending up on the wrong end of the stick. Sorry to hear you might be one of them.

What I can say is - upgrading is worth it, and once you get over the one big gnarly upgrade, you can get on a a regular cadence and future ones will be much much easier. You won't even remember why the first one was so bad! (I am speaking from experience - I have done a few massive Expo/RN upgrades)

For the 16KB memory/page size requirement: is there any viable mitigation on RN 0.74?

I personally know people who have attempted this. I think I saw one patch out there in the Infinite Red community slack, but I don't know anyone who has been successful with it. I think it's a significant enough change that you should just bite the bullet and make the upgrade.

I hope this is helpful? Let me know if you ever want to talk shop or anything. I understand it's a frustrating position, but I promise it's fixable, and there's a world where you can turn this into a trivial concern for yourself and your organization. Might just take a bit of up front investment.

[akhan-design]

Hey @coolsoftwaretyler thanks again for taking the time to write such a thoughtful reply. I really appreciate it, and the “planned cadence” idea genuinely clicked for me.

Quick follow-up on the Expo migration piece: we’re currently on a bare React Native app with a few native dependencies (Realm and some other native modules). If you have a recommended high-level path to move toward Expo, I’d love your take.

In your experience, is the safest approach usually:

• start with “bare + Expo modules” first, then move toward CNG/managed where it makes sense, or
• aim for CNG earlier?

Also, any common gotchas you see teams hit early (build config, deep linking, background tasks, etc.)?

Thanks again. Appreciated!

[coolsoftwaretyler]

Happy to help!

If you have a recommended high-level path to move toward Expo, I’d love your take.

Continuous native generation is so good that it's worth at least spiking out, IMO. Here's what I would do:

1. Cut a spike branch
2. Install the Expo SDK
3. Delete android/ and ios/ folder
4. Run Expo prebuild
5. Attempt to run the app
6. It probably won't work.
7. Chase down all the errors

Depending on just how many native configurations you have, fixing those errors will take a variable amount of time. So time box it. If it were me, I'd dedicate at least a couple days to the effort, but of course I have no clue what your constraints are.

I've worked on a CNG migration that took a few weeks, but it was very much worth it in the end.

If you can't get it done in a time box, just stop at step 2 and get on Expo. Then take all the time you can to incrementally document and modernize the dependencies that will eventually need to move over to CNG.

Again, I really can't overstate the benefits you get from CNG. There's a cost to the first migration. And it does add some complexity if you have to write native code, but config plugins are fairly robust, and I know many large enterprise apps leverage them effectively.

It's hard for me to imagine a situation where CNG isn't worth the cost. But I don't know your specifics, and I don't want you to feel like it's all or nothing. Getting your app on Expo and incrementally adopting expo packages, documenting your native dependencies, and getting up to speed with React Native updates is going to improve your process tremendously, even without CNG.

[coolsoftwaretyler]

Also, any common gotchas you see teams hit early (build config, deep linking, background tasks, etc.)?

You're gonna want everyone to read up on Expo vocabulary (the difference between EAS build, EAS workflows, build profiles, Debug mode, Release mode, development client, Expo Update). One negative thing I'll say about Expo: they have not named their technology in a very useful way. And they have not always done a great job of cleaning up terminology in the docs as APIs change. It's worth it to have your team read the overview pages and try to get on the same page with vocabulary.

For the rest of it, the answer is: yes I've seen teams struggle with all the things you mentioned. But each team is a bit different. I think your best bet to prevent problems is to read documentation as early and often as possible, and improve your team's overall technical sophistication. Get them comfortable with debugging tools and reading GitHub. I find most of the valuable React Native information is either in the Expo docs or in GitHub issues/discussions.

The rest is software engineering like any other niche, in my experience.

[kraenhansen]

a bare React Native app with a few native dependencies (Realm and some other native modules)

And you'd probably want to find a way to migrate off Realm as well 🙈 It's unclear to me if anyone would be able to cut a release with a fix if stuff breaks in the platform vendors, like the 16KB page size update.

[rohan-h-7edge]

Hey! 👋 If you're facing this Android 16KB page size Play Store rejection with React Native, there's a detailed step-by-step guide that covers exactly how to fix this. Check it out here: https://community.7edge.com/t/react-native-android-16-kb-page-size-fix-avoid-play-store-rejection/340?u=rohanhalesh — it walks through making your native libraries 16KB page-size compliant to avoid Play Store rejection.