changing expo fingerprint hash and preventing expo-updates

[wcastand]

What happened?

We have a build app and made some changes in a branch (no native code or dependency changes, only basic ui code) that we should be able to send to production using expo-updates.

We use expo-fingerprint as the runtimeVersion, and it doesn't let us update our production app because the fingerprint comparaison shows node_modules/uniwind has a different dependency so different fingerprint hash.

We didn't touch the package.json or anything linked to the config or uniwind version so the version should not differ and should not prevent an expo update.

the first fingerprint (production build) was done on 27/02/2026, the expo-update was done on 07/04/2026

between those 2 fingerprints events, is there any changes to uniwind pro that made the fingerprint show a diff on it? since it runs an install scripts, it's kind of hard to know exactly if something changes and what changed.

both of those build/updates use the same uniwind-pro version like i said. npm:uniwind-pro@1.0.0-rc.3

Steps to Reproduce

kind of hard to provide, not even sure what the diff is exactly eas doesn't provide much info outside of node_modules/uniwind is different.

on our side we didn't touch the deps at all so it should in theory not change and should let us do an expo-update

Snack or Repository Link (Optional)

No response

Uniwind version

npm:uniwind-pro@1.0.0-rc.3

React Native Version

0.81.5

Platforms

iOS

Expo

Yes

Additional information

• I've searched for similar issues in this repository and found none
• I am a Uniwind Pro user

EDIT:
as i can't provide a repro, since i'm a bit lost on how to do so, i mostly make the issue to figure it out and help with that, not get a solution right away (unless you have one ahah)

so happy to do some things or try to to help you figure it out if you consider it's worth investigating or if it's a "us" problem.

[jpudysz]

Hi @wcastand, thanks for the detailed report.

I investigated this and ran multiple tests with @expo/fingerprint to understand the behavior.

Findings:

I tested reinstalling the same version (1.0.1) multiple times with different scenarios:

• Fresh CDN download (no cache) x2
• Restore from local cache

All three runs produced identical fingerprints. The CDN tarball is deterministic, and expo-fingerprint returns the same hash for the same version across reinstalls.

What likely happened with rc.3:

During the RC period, I did re-upload certain version artifacts to the CDN once or twice (hotfix rebuilds without bumping the version number). I can't confirm with certainty whether rc.3 was one of them, but this is the most likely explanation. If the tarball content changed on the CDN between your production build (Feb 27) and your update attempt (Apr 7), the postinstall would download a slightly different artifact, causing the fingerprint mismatch.

This was a mistake on my side during the pre-release phase and should not happen with stable releases going forward.

Recommendation:

Uniwind Pro is now stable. The latest CLI version is 1.0.1. I'd recommend upgrading from rc.3:

"uniwind": "npm:uniwind-pro@latest"

This version is locked and won't change on the CDN. Your fingerprint should stay consistent across builds.

If you run into any other fingerprint issues after upgrading, let me know and I'll investigate further 🙏🏼

[wcastand]

oh yeah onour repo we are up to date, i was updating on each rc, just our production app was on rc3 so for doing the update we had to match that.

we plan to make a new release with the latest now since we can't update. just wanted to make sure it would not be a problem we have long term where using uniwind pro would make fingerprint never match and prevent using expo update regularly.

[jpudysz]

That makes sense. To confirm: this won't be a problem going forward. Stable releases have locked artifacts on the CDN. Once you rebuild on 1.0.1, your fingerprint will stay consistent across all future expo-update cycles as long as you stay on the same version.