Feeling Native On Mobile

Feeling Native On Mobile fixes the platform behaviors that make a web application feel awkward on a phone. Its scope is touch feedback, viewport sizing, safe areas, inputs, scrolling, and browser chrome. It matches a visible symptom to a targeted declaration or meta setting and explains why that fix belongs at that location.

The skill favors platform capabilities over device guesses. Hover and pointer media queries support mixed-input devices without treating touch and mouse as mutually exclusive. It avoids user-agent sniffing and screen-width assumptions, and prefers CSS or metadata over a JavaScript hook when the browser already exposes the required capability.

Use it for stuck hover styles, tap flashes, laggy feedback, hidden bottom controls, input zoom, scroll chaining, notch collisions, or mismatched status-bar colors in a mobile-facing web app. Animation design, animation review, and React Native construction are assigned to separate companion skills.

Fixes are applied only where their rationale holds. Text selection can be disabled for controls but must remain available for content. Root overscroll suppression suits application shells with independent scroll regions; a scrolling document where refresh is welcome can retain it. Disabling user zoom is prohibited, and desktop device emulation is insufficient evidence that phone behavior is fixed.

Inputs are the web application, a mobile symptom, its existing styling and viewport setup, and target hardware or PWA context. The deliverable is code with a brief explanation of the matched cause, changed file and declaration, and any verification that still needs a phone.

Hover rules are gated with hover and fine-pointer capability checks, while active states provide press feedback for all input types. Removing the browser's tap highlight requires replacement feedback on every tappable control. Press feedback begins on pointer-down rather than release and uses short timing, around 100-160ms, extending existing motion tokens where present. The touch-action: manipulation declaration addresses delayed clicks without suppressing user zoom.

Viewport guidance distinguishes dynamic application height from stable introductory content. Application shells and drawers use 100dvh; heroes use 100svh to avoid mid-scroll resizing as browser chrome changes. An application shell can use:

.app { height: 100dvh; }

A legacy 100vh fallback is reserved for support matrices that require it. The baseline also includes interactive-widget=resizes-content so Android Chrome's keyboard can resize the layout viewport and bottom-pinned controls can respond.

Input text stays at least 16px where iOS focus zoom would occur. Relevant inputmode, type, autocapitalize, autocorrect, and enterkeyhint settings align the software keyboard with codes, amounts, addresses, telephone numbers, and the intended return-key action.

For application scrolling, overscroll-behavior: none on the root can prevent unwanted page refresh or bounce, while contain on inner scrolling regions prevents chaining without removing their own bounce. A touchmove handler with preventDefault is avoided because it can block scrolling and create a non-passive listener.

Edge-to-edge layout combines viewport-fit=cover with safe-area inset padding on headers, bottom bars, toasts, and sheets. Insets need the viewport setting, and calculations can include fallback values. Selection and long-press callouts are disabled selectively on interactive controls, never indiscriminately on the body.

Gesture surfaces declare which browser pan axis remains available: a horizontal custom carousel can preserve vertical browser panning, while a vertical handle can preserve horizontal panning. Full touch-action suppression is reserved for surfaces that genuinely own every axis. A native-scroll carousel instead uses scroll snapping and browser physics.

Browser chrome colors match the page's upper surface separately for light and dark schemes. Next.js viewport exports, JavaScript theme toggles, and installed-PWA manifest or status-bar settings receive corresponding guidance. Baseline styling also addresses unwanted text inflation in landscape.

Verification uses Safari Web Inspector for iOS or Chrome remote debugging for Android, with a phone connected to the development server over the local network. Checks include older hardware, the keyboard open, landscape, and installed-PWA mode when supported. The skill distinguishes code-inspected changes from hardware-confirmed behavior and asks for visible-state and accessibility checks before shipping.