Improving iOS Webview Input Experience for Webview Engineers

In a community service, input wasn't just a simple form element—it was the core interaction that shaped the experience of posts, comments, and chat. However, in iOS Webview, the default behavior of the screen shifting upward when the keyboard appears frequently disrupted the input flow, which led to an ongoing effort to solve this problem.

The first approach attempted was detecting the resize event on visualViewport to readjust the layout. We tried shrinking the wrapper by the height of the keyboard and using window.scrollTo(0, 0) to restore the original position, but since iOS pushed the screen up first before the restoration kicked in, flickering and jittering occurred.

The second approach was changing to a method that tracked visualViewport.offsetTop and moved the wrapper together by the amount it had shifted. This was better than the first attempt, but slight shaking remained as the position kept being corrected while the keyboard was rising, and it wasn't stable when quickly switching between inputs either.

The third attempt was a method of separating Fake Input and Real Input. Touching the visible readOnly input would give focus to an input positioned off-screen, avoiding the push itself by ensuring iOS had nothing to scroll toward. However, since value, selection, and placeholder had to be continuously synchronized, maintenance costs grew as features like textarea auto-height, mentions, and emoji were added.

The final solution chosen was the opacity trick. At the moment of touch, the input's opacity is set to 0 to block iOS's automatic scroll-into-view, and once the keyboard has fully risen, the opacity is restored to 1.

• Only one input is maintained, eliminating state synchronization complexity.
• The input is preemptively hidden before focus, preventing iOS from pushing the page.
• It's shown again after the keyboard opens, creating a natural input experience.

This approach isn't an official API and is fairly hacky, but it was the most practical answer for pages where writing is the core function. In the end, what mattered wasn't whether the approach was orthodox, but whether users could use the service without inconvenience—and the conclusion reached was that if a better method emerges, it can be improved again then.