fix(iOS, SplitView): Remove tracking presentation layer in favor of sync state update

[t0maboro]

Description

This code was originally added to mitigate issues with jumping content during transitions. By observing the presentation layer, we were able to send intermediate column size updates, which helped with making smoother animation.

However, with the current ability to send immediate updates, it seems that it now works well with the native SplitView transition. As a result, we can remove the previously added logic, which was initially introduced in: #3073

How it appears to work now:

How it appeared to work with DisplayLink:

Having the final frame set immediately, we can rely on the native animation (which implementation is a mystery for us). Still, it seems that we're following the same path as natively, where I also observed that the final frame is set at the beginning of the animation. This model appears to work similarly to the Android version. For example, when animating the keyboard, we can read the target value on animation start https://developer.android.com/develop/ui/views/layout/sw-keyboard#:~:text=onStart%20is%20called,the%20view%20properties. It seems that setting intermediate frames, following the presentation layer, might be slightly delayed for the value we read in comparison to the value that is currently drawn.

Fixes https://github.com/software-mansion/react-native-screens-labs/issues/496

Changes

• Removed logic related to observing presentation layer for sending asynchronous state updates.

Screenshots / GIFs

Here you can add screenshots / GIFs documenting your change.

You can add before / after section if you're changing some behavior.

Before

497769228-ff8df4c8-e0a6-46d5-a797-44f099f5968a.mov

After

after.mov

Test code and steps to reproduce

I went through SplitView examples, having synchronous updates in SplitView and additionally sync updates for Stack v4 #3282 . I focused on testing that there's no regression with pressables.

Checklist

• Included code example that can be used to test this change
• Ensured that CI passes

[t0maboro]

It looks like the investigation above wasn't correct, because removing displayLink is causing a new issue with layouting texts and components with borders. Moving this PR to draft for further investigation, but it seems that we may need a completely different approach.

[t0maboro]

After further investigation, I've concluded that, as for now, I'm not able to propose a better solution for SplitView. Synchronous updates bring our flow closer to the native implementation, significantly improving our main goal, which is achieving a truly native feeling, while displayLink is providing some delay in every single scenario (as we're updating the frame which is drawn or is about to be drawn and we have no guarantee that the Yoga layout will be computed fast enough to do not lose frames from the presentation layer).

That said, I'm aware that there are some side effects to the proposed approach, such as text layout behavior and limited support for non-uniform borders or Image components with width: 100% style in React Native. These issues seem unavoidable for now, as they stem from deviations from the native flow.

After performing the additional round of testing, I believe this is currently the most appropriate way to handle transitions. Therefore, I'm reopening this PR for further review.