WKWebView, viewports & keyboards

Agree who owns each part of the available space

For each page type, document the native–web boundary. Is the WebView already inside a safe area? Does the web page add its own padding? Which layer owns scrolling? Which layer changes the content region when a keyboard appears?

During debugging, record both native container dimensions and the web viewport. When the outer bounds are wrong, stacking compensating CSS values only makes the next case harder to diagnose.

For edge-to-edge web content, CSS safe-area environment variables can participate in the web layer. First confirm whether the native container has already inset the WebView, because applying the same protection in both layers can create double padding.

Dynamic viewport units are useful signals, not a device model

WebKit documents svh, lvh, and dvh; dvh represents dynamic viewport height. These are web-platform primitives, not a complete solution to every software-keyboard obstruction and not iPhone Duo-specific APIs.

Apple’s published developer Q&A identifies Viewport Segments and Device Posture as opt-in experimental features in iOS 27.1. For a Safari experiment, the answer points to Settings → Apps → Safari → Advanced → Feature Flags. Record which flags are enabled, and retain a useful responsive layout when they are off.

A successful Safari experiment does not prove that the same APIs are enabled or behave identically in your app’s WKWebView. Check the actual OS, embedding configuration and exposed APIs before using them, with a fallback for unavailable features.

Safari 27 adds scroll anchoring

Safari 27.0 supports scroll anchoring to help keep the reading position stable when content is inserted above the viewport. It is enabled by default; overflow-anchor: none opts a region out.

Test how this interacts with a Vue list’s own scroll restoration, especially during asynchronous inserts and container resizing. This is web-engine release guidance, not proof that a particular iPhone Duo WKWebView flow has passed testing.

A basic content-container example

This example demonstrates a width limit, shrinkable content, and progressive height declarations. Whether to use safe-area-inset and how to handle keyboards or overlays depends on the actual container contract; it is not a universal patch.

.content-page {
  box-sizing: border-box;
  width: 100%;
  min-width: 0;
  min-height: 100vh;
  min-height: 100dvh;
  padding: 1rem;
}

.form-content {
  width: 100%;
  max-width: 42rem;
  margin-inline: auto;
}

.form-content input {
  box-sizing: border-box;
  width: 100%;
  min-width: 0;
}

A size change is not a new business task

For a Vue page, first inspect component identity, conditional branches, and refresh logic. Moving from one column to two does not necessarily require destroying and recreating the form. Decide component lifetime separately from visual layout.

Check transitions during typing, validation, pending requests, and open dialogs. Read network activity alongside page state: a clean-looking screenshot does not prove there were no duplicate requests.

A minimum set of hybrid-page checks

These are proposed checks to execute, not results that have already passed. Pair them with the broader iPhone Duo App Testing matrix and record expected and actual behavior for each transition.

Record Safari and app-hosted WKWebView as separate environments. Include the OS/build, viewport and window, keyboard state and any explicitly enabled experimental flags. The rows below are proposed checks, not completed results.