[Feature]: Auto-grow the iOS mobile composer for long prompts

[saphid]

Before submitting

• I searched existing issues and did not find an iOS-specific duplicate.
• I am describing a concrete problem or use case.

Area

apps/mobile on iOS.

Problem or use case

The native iOS composer remains short while a prompt grows, so reviewing and editing a multi-paragraph draft requires scrolling inside a small editor. This is the iOS counterpart to Android request #5343.

Proposed solution

Let the iOS native composer report its measured content height and grow from its compact height to a bounded maximum. Once it reaches the maximum, keep internal scrolling enabled. Preserve the draft, selection, cursor position, and reachable send/stop controls while it resizes.

Why this matters

Long prompts become substantially easier to review and edit on an iPhone or iPad without introducing a separate full-screen drafting mode.

Smallest useful scope

Change only the iOS native composer and its React Native adapter. Add focused tests for height clamping and retain the current compact size and maximum-height behavior.

Alternatives considered

A manual expand action would work but adds another control and does not help automatically while drafting. Extending this request to Android would overlap #5343 and would make the first patch broader.

Risks or tradeoffs

The editor must avoid layout feedback loops and must preserve keyboard and cursor behavior. Visible proof should cover a short draft, growth, maximum height, and internal scrolling.

References

Related Android request: #5343.

Contribution

• I would be open to helping implement this.

[samaluk]

I ran into the same problem: I wanted more room to read and edit long prompts on iOS, in both existing threads and new-task drafts. Scrolling inside the small editor makes it hard to review surrounding paragraphs before sending.

To see it on eba0521563, open either composer, focus the input, and enter a few paragraphs. The editor stays constrained with no way to make it taller in place.

I tried a manual option in #17019: grab a handle and drag the existing composer taller or shorter. It follows the gesture and snaps compact or expanded on release. The transcript moves with it, and the editor stays below navigation. It keeps the existing editor and controls, with no separate full-screen mode.

Current editor	Swipe-resize prototype

Drag and snap in an existing thread (13 seconds):

ios-existing-motion.mp4

Would user-controlled resizing fit the intended iOS experience, or would you prefer the automatic growth proposed here? The scope I'm proposing is the iOS composer in existing threads and new-task drafts. The PR has the implementation, verification results, and remaining test gaps; I'd like to establish the preferred direction here first.