[Pro 1.1.0 / iOS] bg-* views stuck on previous theme after OS appearance flip + react-navigation native-stack push/pop

[tobiasharth]

What happened?

On iOS, after toggling the OS appearance (Control Center light ↔ dark), some views with theme-driven Uniwind classes (most visibly bg-surface / bg-background) stay rendered with the previous theme's color until they receive any interaction (touch, scroll, layout change).

As far as I can tell from visual inspection, backgroundColor is the property that fails most consistently — text and border colors on the same view appear to update correctly in the cases I checked, but I have not exhaustively audited every property, so I can't rule out that others are affected too.

A single appearance flip is enough; rapidly flipping while navigating amplifies the rate but isn't required.

Swapping the navigation library to expo-router (with byte-identical screen content, same Uniwind classes, same Reanimated animations, same providers) eliminates the bug. The two branches in the linked repo are the comparison — react-navigation native-stack reproduces, expo-router does not.

Diagnostic via UniwindDiagnostics.onShadowTreeUpdate confirms Uniwind itself pushes the new theme values correctly (currentTheme, colorScheme, all nodes traversed). The miss appears to be on the iOS commit side — the new value reaches the shadow tree but isn't committed to the affected CALayer until a secondary trigger.

Already ruled out:

• react-native-screens freeze path (enableFreeze(false) + freezeOnBlur:false on both navigators) — still reproduces.
• StyleSheet vs className on the affected screens — no effect.

Here a short screen recording of the List → Detail → back flow with the appearance flip in step 2 — the stale bg-surface cards on the returned List screen are the clearest visual proof.

Simulator.Screen.Recording.-.iPhone.16.Pro.-.2026-04-27.at.14.04.36.mov

Steps to Reproduce

1. Check out the react-navigation-bug-repro branch of the linked repo, then pnpm install && pnpm expo prebuild && pnpm ios.
2. Open the List tab (Animated.FlatList with a sliding header overlay backed by bg-surface).
3. Toggle the iOS Simulator's appearance once via Control Center (Cmd+Shift+A — not Settings → Display).
4. Tap any card to push into Detail, then tap Back.
5. The cards on the returned List screen still render the previous theme's bg-surface color. Scrolling the FlatList or tapping a card forces a re-render and the colors snap to the correct theme.
6. Switch to the expo-router-fix-reference branch (same screens, only navigation layer differs) and repeat — bug does not reproduce.

Snack or Repository Link (Optional)

https://github.com/tobiasharth/uniwind-theme-flip-repro

Uniwind version

1.1.0

React Native Version

0.83.6

Platforms

iOS

Expo

Yes

Additional information

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

[Brentlok]

Hey, thanks for the report, really appreciate the reproduction 🙏

Looks like it's related to reanimated, we will investigate it and keep you updated

Btw. you can use tailwind classes for some animations instead of writing shared values yourself, for example:
transition-transform active:scale-96 duration-100 - for changing scale on press
transition-transform duration-200 ${isActive ? 'opacity-100' : 'opacity-0'} - for changing opacity based on state

[jpudysz]

I’ve tried to reproduce it on my macOS, but I couldn’t.

I tested it on an iPhone 16 Pro, iPhone 15, and Android SDK 35.

Hubert was able to reproduce it on his machine, but I’m not sure what the difference is.

Diagnostic via UniwindDiagnostics.onShadowTreeUpdate confirms Uniwind itself pushes the new theme values correctly (currentTheme, colorScheme, all nodes traversed).

Yeah, I spent months making this perfect. If the update looks correct, then it’s Reanimated.

I don’t want to sweep the issue under the rug, but I’ve been reporting this issue for 2 years, starting with Unistyles 3.0.

Currently, Reanimated overrides every ShadowTree commit, so even though Uniwind is doing its best, it can still be overridden by Reanimated. Unistyles has a higher error rate, and it’s extremely rare with Uniwind Pro, but still possible.

I’m currently exploring Animation Backend, released in RN 0.85.1, which is a new way of updating the ShadowTree. Reanimated is also working on it.

I hope it will fix all these issues and make both integrations blazing fast without interfering with each other.

I’ll have more updates in about a month. For now, please either:

a) remove the animation
b) re-render your view

[Brentlok]

One more thing from me - the issue disappeared completely after removing this style:

slidingStyle depends on scroll position, so I assume the more frequently the style is updated, the more likely it is to cause issues with Uniwind.

[tobiasharth]

Thanks for digging in, both of you 🙏

I want to flag one thing that might help narrow this down - I migrated my app from react-navigation to expo-router (with Reanimated worklets unchanged) and the appearance-flip bug is gone, on the same device + OS where it consistently reproduced before. That matches what I see in the repro repo: the only variable that flips reproduction on/off is the navigator.

Both branches run the exact same screens/ListScreen.tsx with:

• useAnimatedScrollHandler driving scrollY
• useAnimatedStyle + interpolate worklets producing translateY (sliding header) and opacity (small nav title cross-fade)
• The same Uniwind classNames, custom @Utility shadows, and providers

If Reanimated were the cause, the expo-router branch would reproduce too - it has the same worklets running against the same shadow tree. It doesn't.

That doesn't rule out Reanimated as a contributing factor — it may well be that react-navigation native-stack does something during/after appearance changes that interacts badly with Reanimated's commit override (extra remount? cached snapshot? something react-native-screens-specific?). But the trigger is on the navigation side.

[jpudysz]

To be honest I have no idea.

Expo Router is also using React Navigation.

If Reanimated were the cause, the expo-router branch would reproduce too - it has the same worklets running against the same shadow tree. It doesn't.

It is, you can remove reanimated view and use react navigation and it will work perfectly fine (Hubert confirmed it).

[chanphiromsok]

@tobiasharth @jpudysz I tries many version of free uniwind I see that "uniwind": "1.2.6" doesn't has this issue

[jpudysz]

This issue is for Uniwind Pro. Not related to Uniwind OSS.

I'm building experimental Animation Backend support (RN 0.85.1+), that will solve this problem.

[pedrommcarrasco]

Do we have an ETA on it @jpudysz ?

[jpudysz]

I need to experiment with Reanimated support for the Animation backend. It’s also React Native 0.85.1+ only and requires a custom build flag.

It should be available in React Native in 2–3 months without the flag. I need to check if it helps with Reanimated, so if my tests confirm it fixes the issue, it will most likely land in late June or early July.