fix: revert "fix(iOS): proper layout calculation #339"

[szydlovsky]

Reverts #339 due to a iOS layout bug we found;
The input sometimes becomes unscrollable when it's inside a scrollable bottom sheet (@gorhom/bottom-sheet), with a KeyboardAwareScrollView (react-native-keyboard-controller) turned into a proper bottom-sheet-scrollview component.

The bug doesn't appear when testing a commit before the PR, but does happen on the exact merge commit of the said PR.

[IvanIhnatsiuk]

@szydlovsky Could you give more context on what goes wrong?

1. Is it full height input placed in the bottom sheet scroll view? If so, then the scroll breaks because it renders a UIScrollView inside another UIScrollView. Have you tried to give an exact height for one of these scroll views?
2. Could you check the layout in iOS native hierarchy and try to get the layout height value of the input?

NOTE: If you revert these changes, then please test this flow:

1. Open screen A with the enriched input
2. Type any text to make it scrollable and scroll to the end of the
3. Navigate to screen B
4. Navigate back to screen A and check the scroll position

[szydlovsky]

@IvanIhnatsiuk The bug I mentioned is pretty difficult to reproduce. I thought the issue might have been the input just hijacking the scrolling gesture, so I decided to use scrollEnabled={ false } and found some likely related issue.

See the following scenario:

We want an input that can be any size, and should always expand instead of scrolling (exactly what's needed in case of input being inside a scroll that is inside a bottom sheet), so naturally scrollEnabled={ false } and don't add any height constraints in the input's style.
We expect the input to jest freely change sizes.
However, it just stays as a one-liner.

Here's an example from the current main, example app with just removed maxHeight style prop and added scrollEnabled={ false }:

Screen.Recording.2026-02-16.at.14.42.43.mov

And here's the same setup but from the branch that reverses the PR:

Screen.Recording.2026-02-16.at.14.47.58.mov

I believe it's enough for having the PR reverted for now and outweighs just not preserving scroll position on navigation.

EDIT: if scrollEnabled={ false } is set, maxHeight also doesn't work properly. So we basically lose all the autogrow when the scroll is disabled.

[IvanIhnatsiuk]

@szydlovsky okay 🙂