fix freeze boundary

[noma4i]

Description

Move DelayedFreeze inside AnimatedScreen.

Currently, the freeze boundary wraps the native screen host. During rapid tab switches, this can prevent native props such as activityState, z-index, and pointer-event updates from reaching the native screen while it is frozen. Freezing only the screen content preserves the intended content-freezing behavior while keeping the native host responsive to navigation state changes.

Changes

• Moved DelayedFreeze from around AnimatedScreen to its children.
• Kept the AnimatedScreen props and native event wiring outside the freeze boundary.
• Did not change the public API.

Test plan

Use the following minimal example, then tap Toggle screen state repeatedly:

import React, { useState } from 'react';
import { Button, View } from 'react-native';
import {
  enableFreeze,
  Screen,
  ScreenContainer,
} from 'react-native-screens';

enableFreeze(true);

export function App() {
  const [activityState, setActivityState] = useState<0 | 2>(2);

  return (
    <View style={{ flex: 1 }}>
      <Button
        title="Toggle screen state"
        onPress={() =>
          setActivityState((currentState) =>
            currentState === 2 ? 0 : 2,
          )
        }
      />
      <ScreenContainer style={{ flex: 1 }}>
        <Screen activityState={activityState} freezeOnBlur>
          <View style={{ flex: 1 }} />
        </Screen>
      </ScreenContainer>
    </View>
  );
}

Expected result: the native screen host receives every activityState update while its children remain frozen when inactive.

Checklist

• Included code example that can be used to test this change.
• For visual changes, included screenshots / GIFs / recordings documenting the change.
• For API changes, updated relevant public types. Not applicable - no public API changes.
• Ensured that CI passes.

[noma4i]

Maybe it's a bad idea. Who knows

[kligarski]

Hi, @noma4i. Thanks for the PR.

Interaction between the screen and freeze is a very delicate topic. In order to consider this PR we would need:

1. a detailed motivation what are the use cases for the change (why do we need the props to be passed while screen is frozen?)
2. a thorough test plan to ensure no breaking changes in behavior or new bugs are introduced across both platforms (Android, iOS), different scenarios (regular screens, modals), is the event delivery the same as before, ...

Also, as we're currently actively developing v5 of the library, our capacity to review and test such a significant change is limited and it's unlikely that this PR is going to land.