feat(iOS, SplitView): Add an option for changing number of columns dynamically

[t0maboro]

Description

Previously, the constructor of UISplitViewController relied on a predefined number of columns, and we enforced this constraint using an assert to prevent unexpected runtime behavior when the number of children changed dynamically.

Inspired by the expo-router approach, this PR removes the static assert and introduces a more dynamic pattern: the SplitViewHost now actively monitors the number of child columns. If the number of children changes, the entire UISplitViewController is remounted to reflect the updated configuration.

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

Changes

• Added counters to monitor the number of columns and inspectors

Screenshots / GIFs

Here you can add screenshots / GIFs documenting your change.

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

Before

before.mov

After

after.mov

Test code and steps to reproduce

Run any example with SplitView and add/remove columns or inspector.

Checklist

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

[kkafar]

I don't get something here.

If the entire UISplitNavigationController is remounted (I guess it is recreated, why do we remove the assert for column count, since it is instance-wise?

I think I don't see the benefits this PR introduces. Could you give me some more context here? Maybe a video of what effect we achieve?

[t0maboro]

If the entire UISplitNavigationController is remounted (I guess it is recreated, why do we remove the assert for column count, since it is instance-wise?

The instance of SplitView is recreated when the number of columns changes. The assert is no longer necessary because there's no scenario where the number of columns can change dynamically without fully remounting SplitView. Once the UISplitNavigationController is created, the column count remains fixed for that instance.

I think I don't see the benefits this PR introduces. Could you give me some more context here? Maybe a video of what effect we achieve?

The goal of this PR is to improve the development experience. It makes it easier for developers to test different layouts (e.g. 2- or 3-column configurations) without having to rebuild the app each time. With this change, using fast refresh is enough to apply layout updates, which significantly speeds up the development workflow and makes testing layout variations much smoother (as it's presented on the 2nd video in the description).

[kkafar]

Okay, I see now.

So the assertions for column count in native code should stay, as nothing changes & the invariant must still be upheld, right?

[kkafar]

Thanks!