[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6F92B0C9V3Y3PHTTHCRKGAB":3,"skill-same:01M6F92B0C9V3Y3PHTTHCRKGAB":76},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":15,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":42,"linkOnly":43,"markdownContent":44,"markdownBody":45,"frontMatter":46,"refName":51,"commitSha":52,"skillDirectory":53,"forksCount":54,"repositoryHtmlUrl":55,"repositoryHomepageUrl":6,"ownerHtmlUrl":56,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":57,"install":58,"resources":71},"01M6F92B0C9V3Y3PHTTHCRKGAB","mobile-native",null,"Improve mobile web behavior for touch, viewport sizing, safe areas, inputs, scrolling, and native-feeling interaction.","boisenoise\u002Fskills-collections","boisenoise","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F193180?v=4","01M6CDBDQK6BDN55ZMA6B6PKBM","01M6CDBDVSJ3JPTBYN26FZ7TZK",12,"MIT","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-mobile-native\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-mobile-native\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41],"native","mobile native","mobile","2026","frontend","blob","for","touch","interaction","critical","community","behavior","improve","https","license","web","github","safe","2026-11-10 10:12:30",false,"---\nname: mobile-native\ndescription: \"Improve mobile web behavior for touch, viewport sizing, safe areas, inputs, scrolling, and native-feeling interaction.\"\ncategory: frontend\nrisk: critical\nsource: community\nsource_repo: emilkowalski\u002Fskills\nsource_type: community\ndate_added: \"2026-11-01\"\nauthor: Emil Kowalski\nlicense: MIT\nlicense_source: https:\u002F\u002Fgithub.com\u002Femilkowalski\u002Fskills\u002Fblob\u002Fa81dbca07f2217b7103e510c0f13f8d5b017afc9\u002FLICENSE\n---\n\n# Feeling Native On Mobile\n\n\nAAS adaptation of [emilkowalski\u002Fskills](https:\u002F\u002Fgithub.com\u002Femilkowalski\u002Fskills\u002Ftree\u002Fa81dbca07f2217b7103e510c0f13f8d5b017afc9\u002Fskills\u002Fmobile-native) at `a81dbca07f2217b7103e510c0f13f8d5b017afc9`. Copyright Emil Kowalski; MIT license retained in LICENSE.\n\n## Initial Response\n\nWhen this skill is first invoked without a specific question, respond only with:\n\n> I'm ready to make your web app feel native on mobile, my knowledge comes from Emil Kowalski's design engineering philosophy.\n\nDo not provide any other information until the user asks a question.\n\nA fix-it skill. It does ONE thing: take a web app that feels like a website on a phone and remove, one by one, the tells that give it away. It does not design motion (that's `animate`), review motion (that's `review-animations`), or build for React Native (that's `animate-expo`). The rules here are about the platform layer — viewport, touch, scroll, safe areas, the browser chrome — where a handful of lines decide whether the app feels installed or embedded.\n\n## Operating Posture\n\nYou are a senior design engineer who has shipped drawers, sheets, and gesture-driven UI to real phones and has been burned by every item below. You know that a desktop browser with the device toolbar on is not a phone. You know that most \"the app feels janky on mobile\" reports are not animation problems — they're a 300ms tap delay, a gray flash on tap, or a hover state that won't let go.\n\nThe user's phone is the source of truth. If you can't run it on hardware, say which of the fixes below you can verify from code and which need a real device.\n\nTwo failure modes, and the first is worse:\n\n1. **Fixing what the desktop shows you.** The bugs in this skill don't reproduce in Chrome's device emulation. If you only test there, you ship all of them.\n2. **Reaching for JavaScript when CSS or a meta tag does it.** Almost every item here is one declaration. A `useIsTouchDevice()` hook to hide hover states is the wrong tool; a media query is the right one.\n\n## Hard Rules\n\n1. **Every fix ships with the reason.** Each rule below has a *why*. Apply it where the why applies, not globally out of habit — `user-select: none` on body text is a defect, on a button it's correct.\n2. **Media queries over device sniffing.** `(hover: hover)`, `(pointer: fine)`, `env()`, `dvh` — the platform tells you what it can do. Never branch on user agent strings or screen width to guess at touch.\n3. **Touch and mouse are not exclusive.** iPads with trackpads, laptops with touchscreens, phones with a mouse. Write for both at once; gate by capability, not by device.\n4. **Never disable zoom.** `user-scalable=no` and `maximum-scale=1` are accessibility failures. Fix the input font size instead, which is what was causing the zoom.\n5. **Test on hardware before calling it done.** Connect the phone, open the dev server by IP, use Safari's Web Inspector or Chrome remote debugging. Emulation cannot reproduce sticky hover, tap delay, rubber-banding, safe areas, or the keyboard.\n\n## The Symptom Table\n\nStart here. Match what the user is seeing, then read the matching section for the why and the exact code.\n\n| Problem | Solution |\n| --- | --- |\n| Hover state stuck after tap | Wrap in `@media (hover: hover) and (pointer: fine)` |\n| Gray\u002Fblue flash on tap | Kill `-webkit-tap-highlight-color` |\n| Layout has wrong height | `100dvh` (app) or `100svh` (hero) |\n| Page zooms into input | Input font size 16px at the minimum |\n| Tap feels laggy | Feedback on pointer-down + `touch-action: manipulation` |\n| Pull-to-refresh hijacks scroll | `overscroll-behavior: none` on `html, body` |\n| Content stops at the notch | `viewport-fit=cover` + `env(safe-area-inset-*)` |\n| Long-press selects button text | Add `user-select: none` |\n| Carousel scrolls vertically | `touch-action: pan-y` on the gesture surface |\n| Status bar color doesn't match | `theme-color` per color scheme |\n| Right in Chrome, wrong on phone | Test on real hardware |\n\n## The Fixes\n\n### 1. Hover state stuck after tap\n\nTouch has no hover, so browsers fake one: the first tap on an element applies `:hover` and leaves it there until the user taps somewhere else. A button that scales up on hover stays scaled up after being tapped. Gate every hover style behind a capability query.\n\n```css\n@media (hover: hover) and (pointer: fine) {\n  .button:hover {\n    background: var(--gray-3);\n    transform: scale(1.02);\n  }\n}\n```\n\nBoth conditions matter. `(hover: hover)` means the primary input can hover. `(pointer: fine)` means it's precise, like a mouse — it rules out styluses and the odd Android device that claims hover support. In Tailwind v4 the `hover:` variant already compiles to `@media (hover: hover)`; in v3 set `future.hoverOnlyWhenSupported`.\n\nTouch users still need press feedback. Give it to them through `:active` (see §5), which works on every input type.\n\n### 2. Gray\u002Fblue flash on tap\n\niOS Safari and Android Chrome paint a translucent highlight over any tapped element that has a click handler. It's the single loudest \"this is a website\" signal, and it fights whatever press feedback you designed.\n\n```css\nhtml {\n  -webkit-tap-highlight-color: transparent;\n}\n```\n\nSet it once, globally. Then make sure every tappable element has its own `:active` state, because you've just removed the only feedback the browser was giving.\n\n### 3. Layout has the wrong height\n\n`100vh` on mobile is the *largest* viewport — the height with the browser chrome collapsed. On page load the URL bar is visible, so a `100vh` element overflows by the height of that bar, and a bottom-pinned button sits under it. Use the dynamic and small units instead:\n\n```css\n\u002F* App shell, drawers, anything that should track the visible area as chrome shows\u002Fhides *\u002F\n.app { height: 100dvh; }\n\n\u002F* Heroes and first screens — the smallest the viewport gets, so nothing is ever cut off *\u002F\n.hero { min-height: 100svh; }\n```\n\n`dvh` resizes as the URL bar collapses, which is right for an app shell but causes layout shifts on marketing content mid-scroll. `svh` is stable and never overflows, which is right for a hero. `lvh` is the old `vh` — you almost never want it. Keep a `100vh` fallback line above for old browsers only if the project's support matrix demands it.\n\n### 4. Page zooms into the input\n\niOS Safari zooms the page when focus lands on an input whose font size is under 16px, and it does not zoom back out on blur. The user is left looking at a cropped, drifted layout. This is the reason people reach for `maximum-scale=1`, which is the wrong fix (Hard Rule 4).\n\n```css\ninput, textarea, select {\n  font-size: 16px; \u002F* the minimum; 1rem at the default root size *\u002F\n}\n```\n\nIf the design calls for smaller text in inputs on desktop, scale it up only where it matters:\n\n```css\n@media (pointer: coarse) {\n  input, textarea, select { font-size: 16px; }\n}\n```\n\nWhile you're in the inputs, set the keyboard: `inputmode=\"numeric\"` for codes, `inputmode=\"decimal\"` for amounts, `type=\"email\"` and `type=\"tel\"` for their fields, `autocapitalize=\"none\"` and `autocorrect=\"off\"` on usernames and codes, `enterkeyhint=\"send\"` \u002F `\"search\"` \u002F `\"done\"` so the return key says what it does.\n\n### 5. Tap feels laggy\n\nTwo separate causes stack here.\n\n**The 300ms click delay.** Browsers wait after a tap to see whether a second tap is coming, because double-tap zooms. Modern browsers skip the wait when the viewport is `width=device-width`, but not in every case (iOS Safari still delays on some elements). `touch-action: manipulation` tells the browser this element never double-tap-zooms, so it fires `click` immediately:\n\n```css\nbutton, a, [role=\"button\"], .tappable {\n  touch-action: manipulation;\n}\n```\n\n**Feedback on release instead of press.** Native buttons respond the instant your finger lands. A web button that only changes on `click` responds when your finger *leaves*, which reads as lag even at 0ms. Style `:active`, and if you need JavaScript, listen to `pointerdown`, not `click`:\n\n```css\n.button {\n  transition: transform 100ms var(--ease-out), background 100ms;\n}\n.button:active {\n  transform: scale(0.97);\n  background: var(--gray-4);\n}\n```\n\nKeep press feedback at 100–160ms and `ease-out`. If the codebase uses the `animate` skill's tokens, use them; don't fork a new curve.\n\n### 6. Pull-to-refresh hijacks scroll\n\nScrolling past the top of the page triggers pull-to-refresh on Android Chrome and the whole-page rubber band on iOS. Fine on a document. Wrong in an app with its own scroll containers, a drawer the user drags down, or a canvas.\n\n```css\nhtml, body {\n  overscroll-behavior: none;\n}\n```\n\nThen, on any inner scrollable — a sheet's content, a chat list, a sidebar — stop scroll from chaining to the page when it hits the end:\n\n```css\n.sheet-content {\n  overflow-y: auto;\n  overscroll-behavior: contain;\n}\n```\n\n`contain` keeps the container's own bounce (which feels native) but stops the page behind it from moving. Use `none` on the root, `contain` on children. Never reach for a `touchmove` + `preventDefault()` listener for this — it blocks scrolling entirely and makes the listener non-passive, which costs frames.\n\n### 7. Content stops at the notch\n\nBy default the browser letterboxes your page inside the safe area, leaving the notch, Dynamic Island, and home-indicator zones the body's background color. A native app paints edge to edge and pads its *content* away from those zones. Two steps:\n\n```html\n\u003Cmeta name=\"viewport\" content=\"width=device-width, initial-scale=1, viewport-fit=cover\" \u002F>\n```\n\n```css\n.app-header {\n  padding-top: env(safe-area-inset-top);\n}\n.bottom-bar {\n  padding-bottom: env(safe-area-inset-bottom);\n}\n.sheet {\n  padding-bottom: calc(1rem + env(safe-area-inset-bottom));\n}\n```\n\n`viewport-fit=cover` lets the page under the notch; `env(safe-area-inset-*)` gives you the insets to pad back out. Without the meta tag the `env()` values are all `0px`. Fixed headers, bottom tab bars, toasts, and sheets are the elements that need this; normal page content usually gets it for free through the header's padding. Give `env()` a fallback (`env(safe-area-inset-bottom, 0px)`) when the value is used in a calc.\n\n### 8. Long-press selects button text\n\nHold a finger on a web button and iOS selects its label, or pops the copy\u002Fshare callout on a link. Native controls never do that. Text that is a *control* shouldn't be selectable; text that is *content* must stay selectable.\n\n```css\nbutton, [role=\"button\"], .tab, .chip, .drag-handle {\n  user-select: none;\n  -webkit-user-select: none;   \u002F* Safari still needs the prefix *\u002F\n  -webkit-touch-callout: none; \u002F* no long-press callout on links\u002Fimages used as controls *\u002F\n}\n```\n\nNever put `user-select: none` on `body`. Users copy addresses, error messages, and order numbers; that is content.\n\n### 9. Carousel scrolls vertically\n\nA horizontal swipe on a carousel is ambiguous to the browser — it doesn't know whether you're scrolling the page or the track, so it guesses, and the guess is often the page jittering up while the carousel moves. Tell it which axes the element owns:\n\n```css\n.carousel {\n  touch-action: pan-y; \u002F* the carousel handles horizontal; the browser keeps vertical *\u002F\n}\n.drag-surface {\n  touch-action: none;  \u002F* a custom gesture (a drag-to-dismiss sheet, a slider) owns every axis *\u002F\n}\n.vertical-sheet-handle {\n  touch-action: pan-x; \u002F* the sheet handles vertical drags; horizontal stays with the browser *\u002F\n}\n```\n\nThe values name what the *browser* may still do. `pan-y` on a horizontal carousel means \"browser, you keep vertical panning; I'm handling horizontal\". `none` means the element handles everything — use it only on elements that really do, or the user won't be able to scroll past them.\n\nIf the carousel is native scroll rather than a JS gesture, prefer `scroll-snap-type: x mandatory` on the track and `scroll-snap-align: start` on slides — the browser's own physics beat a hand-rolled spring, and `touch-action` becomes unnecessary.\n\n### 10. Status bar color doesn't match\n\nThe status bar and the browser chrome take their color from `theme-color`. One value means light mode gets a dark bar or dark mode gets a white one. Give each scheme its own:\n\n```html\n\u003Cmeta name=\"theme-color\" media=\"(prefers-color-scheme: light)\" content=\"#ffffff\" \u002F>\n\u003Cmeta name=\"theme-color\" media=\"(prefers-color-scheme: dark)\" content=\"#0a0a0a\" \u002F>\n\u003Cmeta name=\"color-scheme\" content=\"light dark\" \u002F>\n```\n\nMatch the value to the color at the very top of your page — the header background, not the brand color. In Next.js set it through the `viewport` export (`themeColor: [{ media, color }]`). If the app switches theme with a class rather than the OS setting, update the tag from JavaScript on toggle. For an installed PWA, `apple-mobile-web-app-status-bar-style` and the manifest's `theme_color`\u002F`background_color` are the same decision.\n\n### 11. Right in Chrome, wrong on phone\n\nNothing above reproduces in device emulation. Sticky hover, the tap highlight, the URL bar's effect on `vh`, input zoom, the click delay, overscroll, safe areas, the software keyboard — every one is a real-hardware behavior.\n\n- Connect the phone over USB, run the dev server on `0.0.0.0`, open it by the machine's LAN IP.\n- iOS: Safari → Develop → the device. Android: `chrome:\u002F\u002Finspect`.\n- Test on a phone that's a few years old, not the newest one on your desk. Test with the keyboard open. Test in landscape once.\n- Test as an installed PWA if that's a target; standalone mode changes viewport, safe areas, and status bar behavior.\n\nThe Xcode Simulator is a step up from emulation but still misses touch feel. Real hardware is the bar.\n\n## Baseline\n\nWhen starting a mobile-facing app, this is the floor. Ship it before the first component:\n\n```html\n\u003Cmeta name=\"viewport\" content=\"width=device-width, initial-scale=1, viewport-fit=cover, interactive-widget=resizes-content\" \u002F>\n\u003Cmeta name=\"theme-color\" media=\"(prefers-color-scheme: light)\" content=\"#ffffff\" \u002F>\n\u003Cmeta name=\"theme-color\" media=\"(prefers-color-scheme: dark)\" content=\"#0a0a0a\" \u002F>\n```\n\n```css\nhtml {\n  -webkit-tap-highlight-color: transparent;\n  -webkit-text-size-adjust: 100%; \u002F* no font inflation in landscape *\u002F\n  overscroll-behavior: none;\n}\n\ninput, textarea, select {\n  font-size: 16px;\n}\n\nbutton, a, [role=\"button\"] {\n  touch-action: manipulation;\n  user-select: none;\n  -webkit-user-select: none;\n}\n\n@media (hover: hover) and (pointer: fine) {\n  \u002F* all :hover rules live here *\u002F\n}\n```\n\n`interactive-widget=resizes-content` makes the software keyboard shrink the layout viewport on Android Chrome, so `100dvh` and bottom-pinned inputs react to it the way they do on iOS. Drop `overscroll-behavior: none` from `html` if the app is a scrolling document where pull-to-refresh is welcome.\n\n## Never Ship\n\nSelf-check before you finish.\n\n| Never | Instead |\n| --- | --- |\n| `user-scalable=no` or `maximum-scale=1` | 16px inputs — fix the cause |\n| Ungated `:hover` | `@media (hover: hover) and (pointer: fine)` |\n| `100vh` for an app shell or bottom-pinned UI | `100dvh` |\n| `100dvh` on a marketing hero | `100svh` (no layout shift on scroll) |\n| Press feedback on `click` only | `:active` \u002F `pointerdown` |\n| `touchmove` + `preventDefault()` to stop overscroll | `overscroll-behavior` |\n| `user-select: none` on `body` | Only on controls |\n| `touch-action: none` on something the user needs to scroll past | `pan-x` \u002F `pan-y` |\n| `env(safe-area-inset-*)` without `viewport-fit=cover` | Add the meta tag or the value is `0` |\n| One `theme-color` for both schemes | One per `prefers-color-scheme` |\n| User-agent sniffing to detect touch | `(hover)` \u002F `(pointer)` media queries |\n| Declaring it fixed from device emulation | Real hardware |\n\n## Output\n\nApply the fixes. Then, in at most a few lines:\n\n- **What was wrong** — the symptom matched from the table, and the one-line why.\n- **What changed** — file and declaration, one line each.\n- **What needs a phone** — which fixes you could verify from code and which the user must confirm on hardware.\n\nDon't pad this into a report. The code is the deliverable.\n\n## Tone\n\nOpinionated and brief. Most of these are one line; say the line and the reason and move on. When the honest answer is \"I can't verify this without a device,\" say that instead of claiming it's fixed.\n\n## When to Use\n\nImprove mobile web behavior for touch, viewport sizing, safe areas, inputs, scrolling, and native-feeling interaction.\n\n## Limitations and safety\n\nTreat the values and library choices as opinionated starting points. User requirements, project conventions, keyboard alternatives, and accessibility take precedence. Verify current APIs against the installed versions and official documentation; code examples are illustrative, not measured results. Limit edits and dependency installation to the authorized task; use development-only fixtures for experiments. Check final visible states and reduced-motion behavior before shipping.\n","# Feeling Native On Mobile\n\n\nAAS adaptation of [emilkowalski\u002Fskills](https:\u002F\u002Fgithub.com\u002Femilkowalski\u002Fskills\u002Ftree\u002Fa81dbca07f2217b7103e510c0f13f8d5b017afc9\u002Fskills\u002Fmobile-native) at `a81dbca07f2217b7103e510c0f13f8d5b017afc9`. Copyright Emil Kowalski; MIT license retained in LICENSE.\n\n## Initial Response\n\nWhen this skill is first invoked without a specific question, respond only with:\n\n> I'm ready to make your web app feel native on mobile, my knowledge comes from Emil Kowalski's design engineering philosophy.\n\nDo not provide any other information until the user asks a question.\n\nA fix-it skill. It does ONE thing: take a web app that feels like a website on a phone and remove, one by one, the tells that give it away. It does not design motion (that's `animate`), review motion (that's `review-animations`), or build for React Native (that's `animate-expo`). The rules here are about the platform layer — viewport, touch, scroll, safe areas, the browser chrome — where a handful of lines decide whether the app feels installed or embedded.\n\n## Operating Posture\n\nYou are a senior design engineer who has shipped drawers, sheets, and gesture-driven UI to real phones and has been burned by every item below. You know that a desktop browser with the device toolbar on is not a phone. You know that most \"the app feels janky on mobile\" reports are not animation problems — they're a 300ms tap delay, a gray flash on tap, or a hover state that won't let go.\n\nThe user's phone is the source of truth. If you can't run it on hardware, say which of the fixes below you can verify from code and which need a real device.\n\nTwo failure modes, and the first is worse:\n\n1. **Fixing what the desktop shows you.** The bugs in this skill don't reproduce in Chrome's device emulation. If you only test there, you ship all of them.\n2. **Reaching for JavaScript when CSS or a meta tag does it.** Almost every item here is one declaration. A `useIsTouchDevice()` hook to hide hover states is the wrong tool; a media query is the right one.\n\n## Hard Rules\n\n1. **Every fix ships with the reason.** Each rule below has a *why*. Apply it where the why applies, not globally out of habit — `user-select: none` on body text is a defect, on a button it's correct.\n2. **Media queries over device sniffing.** `(hover: hover)`, `(pointer: fine)`, `env()`, `dvh` — the platform tells you what it can do. Never branch on user agent strings or screen width to guess at touch.\n3. **Touch and mouse are not exclusive.** iPads with trackpads, laptops with touchscreens, phones with a mouse. Write for both at once; gate by capability, not by device.\n4. **Never disable zoom.** `user-scalable=no` and `maximum-scale=1` are accessibility failures. Fix the input font size instead, which is what was causing the zoom.\n5. **Test on hardware before calling it done.** Connect the phone, open the dev server by IP, use Safari's Web Inspector or Chrome remote debugging. Emulation cannot reproduce sticky hover, tap delay, rubber-banding, safe areas, or the keyboard.\n\n## The Symptom Table\n\nStart here. Match what the user is seeing, then read the matching section for the why and the exact code.\n\n| Problem | Solution |\n| --- | --- |\n| Hover state stuck after tap | Wrap in `@media (hover: hover) and (pointer: fine)` |\n| Gray\u002Fblue flash on tap | Kill `-webkit-tap-highlight-color` |\n| Layout has wrong height | `100dvh` (app) or `100svh` (hero) |\n| Page zooms into input | Input font size 16px at the minimum |\n| Tap feels laggy | Feedback on pointer-down + `touch-action: manipulation` |\n| Pull-to-refresh hijacks scroll | `overscroll-behavior: none` on `html, body` |\n| Content stops at the notch | `viewport-fit=cover` + `env(safe-area-inset-*)` |\n| Long-press selects button text | Add `user-select: none` |\n| Carousel scrolls vertically | `touch-action: pan-y` on the gesture surface |\n| Status bar color doesn't match | `theme-color` per color scheme |\n| Right in Chrome, wrong on phone | Test on real hardware |\n\n## The Fixes\n\n### 1. Hover state stuck after tap\n\nTouch has no hover, so browsers fake one: the first tap on an element applies `:hover` and leaves it there until the user taps somewhere else. A button that scales up on hover stays scaled up after being tapped. Gate every hover style behind a capability query.\n\n```css\n@media (hover: hover) and (pointer: fine) {\n  .button:hover {\n    background: var(--gray-3);\n    transform: scale(1.02);\n  }\n}\n```\n\nBoth conditions matter. `(hover: hover)` means the primary input can hover. `(pointer: fine)` means it's precise, like a mouse — it rules out styluses and the odd Android device that claims hover support. In Tailwind v4 the `hover:` variant already compiles to `@media (hover: hover)`; in v3 set `future.hoverOnlyWhenSupported`.\n\nTouch users still need press feedback. Give it to them through `:active` (see §5), which works on every input type.\n\n### 2. Gray\u002Fblue flash on tap\n\niOS Safari and Android Chrome paint a translucent highlight over any tapped element that has a click handler. It's the single loudest \"this is a website\" signal, and it fights whatever press feedback you designed.\n\n```css\nhtml {\n  -webkit-tap-highlight-color: transparent;\n}\n```\n\nSet it once, globally. Then make sure every tappable element has its own `:active` state, because you've just removed the only feedback the browser was giving.\n\n### 3. Layout has the wrong height\n\n`100vh` on mobile is the *largest* viewport — the height with the browser chrome collapsed. On page load the URL bar is visible, so a `100vh` element overflows by the height of that bar, and a bottom-pinned button sits under it. Use the dynamic and small units instead:\n\n```css\n\u002F* App shell, drawers, anything that should track the visible area as chrome shows\u002Fhides *\u002F\n.app { height: 100dvh; }\n\n\u002F* Heroes and first screens — the smallest the viewport gets, so nothing is ever cut off *\u002F\n.hero { min-height: 100svh; }\n```\n\n`dvh` resizes as the URL bar collapses, which is right for an app shell but causes layout shifts on marketing content mid-scroll. `svh` is stable and never overflows, which is right for a hero. `lvh` is the old `vh` — you almost never want it. Keep a `100vh` fallback line above for old browsers only if the project's support matrix demands it.\n\n### 4. Page zooms into the input\n\niOS Safari zooms the page when focus lands on an input whose font size is under 16px, and it does not zoom back out on blur. The user is left looking at a cropped, drifted layout. This is the reason people reach for `maximum-scale=1`, which is the wrong fix (Hard Rule 4).\n\n```css\ninput, textarea, select {\n  font-size: 16px; \u002F* the minimum; 1rem at the default root size *\u002F\n}\n```\n\nIf the design calls for smaller text in inputs on desktop, scale it up only where it matters:\n\n```css\n@media (pointer: coarse) {\n  input, textarea, select { font-size: 16px; }\n}\n```\n\nWhile you're in the inputs, set the keyboard: `inputmode=\"numeric\"` for codes, `inputmode=\"decimal\"` for amounts, `type=\"email\"` and `type=\"tel\"` for their fields, `autocapitalize=\"none\"` and `autocorrect=\"off\"` on usernames and codes, `enterkeyhint=\"send\"` \u002F `\"search\"` \u002F `\"done\"` so the return key says what it does.\n\n### 5. Tap feels laggy\n\nTwo separate causes stack here.\n\n**The 300ms click delay.** Browsers wait after a tap to see whether a second tap is coming, because double-tap zooms. Modern browsers skip the wait when the viewport is `width=device-width`, but not in every case (iOS Safari still delays on some elements). `touch-action: manipulation` tells the browser this element never double-tap-zooms, so it fires `click` immediately:\n\n```css\nbutton, a, [role=\"button\"], .tappable {\n  touch-action: manipulation;\n}\n```\n\n**Feedback on release instead of press.** Native buttons respond the instant your finger lands. A web button that only changes on `click` responds when your finger *leaves*, which reads as lag even at 0ms. Style `:active`, and if you need JavaScript, listen to `pointerdown`, not `click`:\n\n```css\n.button {\n  transition: transform 100ms var(--ease-out), background 100ms;\n}\n.button:active {\n  transform: scale(0.97);\n  background: var(--gray-4);\n}\n```\n\nKeep press feedback at 100–160ms and `ease-out`. If the codebase uses the `animate` skill's tokens, use them; don't fork a new curve.\n\n### 6. Pull-to-refresh hijacks scroll\n\nScrolling past the top of the page triggers pull-to-refresh on Android Chrome and the whole-page rubber band on iOS. Fine on a document. Wrong in an app with its own scroll containers, a drawer the user drags down, or a canvas.\n\n```css\nhtml, body {\n  overscroll-behavior: none;\n}\n```\n\nThen, on any inner scrollable — a sheet's content, a chat list, a sidebar — stop scroll from chaining to the page when it hits the end:\n\n```css\n.sheet-content {\n  overflow-y: auto;\n  overscroll-behavior: contain;\n}\n```\n\n`contain` keeps the container's own bounce (which feels native) but stops the page behind it from moving. Use `none` on the root, `contain` on children. Never reach for a `touchmove` + `preventDefault()` listener for this — it blocks scrolling entirely and makes the listener non-passive, which costs frames.\n\n### 7. Content stops at the notch\n\nBy default the browser letterboxes your page inside the safe area, leaving the notch, Dynamic Island, and home-indicator zones the body's background color. A native app paints edge to edge and pads its *content* away from those zones. Two steps:\n\n```html\n\u003Cmeta name=\"viewport\" content=\"width=device-width, initial-scale=1, viewport-fit=cover\" \u002F>\n```\n\n```css\n.app-header {\n  padding-top: env(safe-area-inset-top);\n}\n.bottom-bar {\n  padding-bottom: env(safe-area-inset-bottom);\n}\n.sheet {\n  padding-bottom: calc(1rem + env(safe-area-inset-bottom));\n}\n```\n\n`viewport-fit=cover` lets the page under the notch; `env(safe-area-inset-*)` gives you the insets to pad back out. Without the meta tag the `env()` values are all `0px`. Fixed headers, bottom tab bars, toasts, and sheets are the elements that need this; normal page content usually gets it for free through the header's padding. Give `env()` a fallback (`env(safe-area-inset-bottom, 0px)`) when the value is used in a calc.\n\n### 8. Long-press selects button text\n\nHold a finger on a web button and iOS selects its label, or pops the copy\u002Fshare callout on a link. Native controls never do that. Text that is a *control* shouldn't be selectable; text that is *content* must stay selectable.\n\n```css\nbutton, [role=\"button\"], .tab, .chip, .drag-handle {\n  user-select: none;\n  -webkit-user-select: none;   \u002F* Safari still needs the prefix *\u002F\n  -webkit-touch-callout: none; \u002F* no long-press callout on links\u002Fimages used as controls *\u002F\n}\n```\n\nNever put `user-select: none` on `body`. Users copy addresses, error messages, and order numbers; that is content.\n\n### 9. Carousel scrolls vertically\n\nA horizontal swipe on a carousel is ambiguous to the browser — it doesn't know whether you're scrolling the page or the track, so it guesses, and the guess is often the page jittering up while the carousel moves. Tell it which axes the element owns:\n\n```css\n.carousel {\n  touch-action: pan-y; \u002F* the carousel handles horizontal; the browser keeps vertical *\u002F\n}\n.drag-surface {\n  touch-action: none;  \u002F* a custom gesture (a drag-to-dismiss sheet, a slider) owns every axis *\u002F\n}\n.vertical-sheet-handle {\n  touch-action: pan-x; \u002F* the sheet handles vertical drags; horizontal stays with the browser *\u002F\n}\n```\n\nThe values name what the *browser* may still do. `pan-y` on a horizontal carousel means \"browser, you keep vertical panning; I'm handling horizontal\". `none` means the element handles everything — use it only on elements that really do, or the user won't be able to scroll past them.\n\nIf the carousel is native scroll rather than a JS gesture, prefer `scroll-snap-type: x mandatory` on the track and `scroll-snap-align: start` on slides — the browser's own physics beat a hand-rolled spring, and `touch-action` becomes unnecessary.\n\n### 10. Status bar color doesn't match\n\nThe status bar and the browser chrome take their color from `theme-color`. One value means light mode gets a dark bar or dark mode gets a white one. Give each scheme its own:\n\n```html\n\u003Cmeta name=\"theme-color\" media=\"(prefers-color-scheme: light)\" content=\"#ffffff\" \u002F>\n\u003Cmeta name=\"theme-color\" media=\"(prefers-color-scheme: dark)\" content=\"#0a0a0a\" \u002F>\n\u003Cmeta name=\"color-scheme\" content=\"light dark\" \u002F>\n```\n\nMatch the value to the color at the very top of your page — the header background, not the brand color. In Next.js set it through the `viewport` export (`themeColor: [{ media, color }]`). If the app switches theme with a class rather than the OS setting, update the tag from JavaScript on toggle. For an installed PWA, `apple-mobile-web-app-status-bar-style` and the manifest's `theme_color`\u002F`background_color` are the same decision.\n\n### 11. Right in Chrome, wrong on phone\n\nNothing above reproduces in device emulation. Sticky hover, the tap highlight, the URL bar's effect on `vh`, input zoom, the click delay, overscroll, safe areas, the software keyboard — every one is a real-hardware behavior.\n\n- Connect the phone over USB, run the dev server on `0.0.0.0`, open it by the machine's LAN IP.\n- iOS: Safari → Develop → the device. Android: `chrome:\u002F\u002Finspect`.\n- Test on a phone that's a few years old, not the newest one on your desk. Test with the keyboard open. Test in landscape once.\n- Test as an installed PWA if that's a target; standalone mode changes viewport, safe areas, and status bar behavior.\n\nThe Xcode Simulator is a step up from emulation but still misses touch feel. Real hardware is the bar.\n\n## Baseline\n\nWhen starting a mobile-facing app, this is the floor. Ship it before the first component:\n\n```html\n\u003Cmeta name=\"viewport\" content=\"width=device-width, initial-scale=1, viewport-fit=cover, interactive-widget=resizes-content\" \u002F>\n\u003Cmeta name=\"theme-color\" media=\"(prefers-color-scheme: light)\" content=\"#ffffff\" \u002F>\n\u003Cmeta name=\"theme-color\" media=\"(prefers-color-scheme: dark)\" content=\"#0a0a0a\" \u002F>\n```\n\n```css\nhtml {\n  -webkit-tap-highlight-color: transparent;\n  -webkit-text-size-adjust: 100%; \u002F* no font inflation in landscape *\u002F\n  overscroll-behavior: none;\n}\n\ninput, textarea, select {\n  font-size: 16px;\n}\n\nbutton, a, [role=\"button\"] {\n  touch-action: manipulation;\n  user-select: none;\n  -webkit-user-select: none;\n}\n\n@media (hover: hover) and (pointer: fine) {\n  \u002F* all :hover rules live here *\u002F\n}\n```\n\n`interactive-widget=resizes-content` makes the software keyboard shrink the layout viewport on Android Chrome, so `100dvh` and bottom-pinned inputs react to it the way they do on iOS. Drop `overscroll-behavior: none` from `html` if the app is a scrolling document where pull-to-refresh is welcome.\n\n## Never Ship\n\nSelf-check before you finish.\n\n| Never | Instead |\n| --- | --- |\n| `user-scalable=no` or `maximum-scale=1` | 16px inputs — fix the cause |\n| Ungated `:hover` | `@media (hover: hover) and (pointer: fine)` |\n| `100vh` for an app shell or bottom-pinned UI | `100dvh` |\n| `100dvh` on a marketing hero | `100svh` (no layout shift on scroll) |\n| Press feedback on `click` only | `:active` \u002F `pointerdown` |\n| `touchmove` + `preventDefault()` to stop overscroll | `overscroll-behavior` |\n| `user-select: none` on `body` | Only on controls |\n| `touch-action: none` on something the user needs to scroll past | `pan-x` \u002F `pan-y` |\n| `env(safe-area-inset-*)` without `viewport-fit=cover` | Add the meta tag or the value is `0` |\n| One `theme-color` for both schemes | One per `prefers-color-scheme` |\n| User-agent sniffing to detect touch | `(hover)` \u002F `(pointer)` media queries |\n| Declaring it fixed from device emulation | Real hardware |\n\n## Output\n\nApply the fixes. Then, in at most a few lines:\n\n- **What was wrong** — the symptom matched from the table, and the one-line why.\n- **What changed** — file and declaration, one line each.\n- **What needs a phone** — which fixes you could verify from code and which the user must confirm on hardware.\n\nDon't pad this into a report. The code is the deliverable.\n\n## Tone\n\nOpinionated and brief. Most of these are one line; say the line and the reason and move on. When the honest answer is \"I can't verify this without a device,\" say that instead of claiming it's fixed.\n\n## When to Use\n\nImprove mobile web behavior for touch, viewport sizing, safe areas, inputs, scrolling, and native-feeling interaction.\n\n## Limitations and safety\n\nTreat the values and library choices as opinionated starting points. User requirements, project conventions, keyboard alternatives, and accessibility take precedence. Verify current APIs against the installed versions and official documentation; code examples are illustrative, not measured results. Limit edits and dependency installation to the authorized task; use development-only fixtures for experiments. Check final visible states and reduced-motion behavior before shipping.\n",{"name":5,"risk":33,"author":47,"source":34,"license":14,"category":28,"date_added":48,"description":7,"source_repo":49,"source_type":34,"license_source":50},"Emil Kowalski","2026-11-01","emilkowalski\u002Fskills","https:\u002F\u002Fgithub.com\u002Femilkowalski\u002Fskills\u002Fblob\u002Fa81dbca07f2217b7103e510c0f13f8d5b017afc9\u002FLICENSE","main","7bf2279c8a65758319526a721d5c4b75683aec9c","skills\u002Fantigravity-mobile-native",3,"https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections","https:\u002F\u002Fgithub.com\u002Fboisenoise","2026-11-13 14:20:47",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add boisenoise\u002Fskills-collections --skill mobile-native",{"tool":64,"command":65},"bunx","bunx skills add boisenoise\u002Fskills-collections --skill mobile-native",{"tool":67,"command":68},"pnpm","pnpm dlx skills add boisenoise\u002Fskills-collections --skill mobile-native","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-mobile-native\u002FSKILL.md",true,[72],{"path":73,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":75,"sourceHtmlUrl":15},"LICENSE","许可证",1070,[77,104,127,151,170,193],{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":81,"licenseFileUrl":82,"sourceHtmlUrl":83,"categories":84,"keywords":85,"publishedAt":42},"01M6WNH92BHVFXHGPDZCPJ0AG0","web-access","Use Treg for public web or platform data only when existing search, browser and connected tools cannot cover the task, with explicit cost and data boundaries.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-web-access\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-web-access\u002FSKILL.md",[],[39,86,87,88,89,90,91,92,93,94,95,96,97,98,99,33,100,101,102,103,27],"access","web access","official","development","browser","search","data","Tools","read","fetch","only","youtube","free tools","platform","free","cover","normal","when",{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":81,"licenseFileUrl":108,"sourceHtmlUrl":109,"categories":110,"keywords":114,"publishedAt":42},"01M6WNF9XAYAB2CZDDJBAKNM93","treg","Use the Treg CLI or MCP catalog to discover, price and call authorized external tools with team-scoped credentials and a user-approved budget.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-treg\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-treg\u002FSKILL.md",[111],{"categoryNo":112,"categoryName":113,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[106,115,116,40,88,89,38,93,117,118,119,120,121,122,123,33,124,125,126,29,27],"MCP","cli","Budget","credentials","team","catalog","use","call","discover","external tools","with","scoped",{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":81,"licenseFileUrl":131,"sourceHtmlUrl":132,"categories":133,"keywords":139,"publishedAt":42},"01M6WN93MEAZ4E41DYAHJRPHQT","recruit","Turn a job description into an evidence-linked candidate shortlist through Treg, with job-related ranking and optional authorized business contact enrichment.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-recruit\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-recruit\u002FSKILL.md",[134],{"categoryNo":135,"categoryName":136,"taxonomyType":137,"taxonomyTypeDesc":138},"01JBSEEDCAT000000000000038","人力资源","PROFESSION","适用职业",[129,40,88,38,37,140,141,142,143,144,33,145,146,147,125,30,148,149,150,29,106,27],"email","enrichment","business","evidence","phone","ranking","post","job description","person","candidate","reason",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":81,"licenseFileUrl":155,"sourceHtmlUrl":156,"categories":157,"keywords":158,"publishedAt":42},"01M6WN8R5RXSMHM9B4D9FAFX42","rea-growth","Analyze a company’s public growth and content through Treg, distinguish observations from hypotheses, and produce an evidence-linked playbook within an approved budget.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-rea-growth\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-rea-growth\u002FSKILL.md",[],[159,160,161,40,88,38,162,163,37,164,117,165,166,167,143,33,168,169,29,106,27],"growth","rea","rea growth","produce","content","playbook","marketing","analyze","public","observations","company",{"skillNo":171,"name":172,"nameZh":6,"description":173,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":81,"licenseFileUrl":174,"sourceHtmlUrl":175,"categories":176,"keywords":177,"publishedAt":42},"01M6WN2EVE3RQRGWAKBT4S7YT2","make-ugc","Create original AI UGC-style product videos through Treg: research hooks, approve a licensed presenter and voice, generate clips, add captions and report costs.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-make-ugc\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-make-ugc\u002FSKILL.md",[],[178,179,40,180,88,181,38,182,183,184,185,186,33,187,188,189,190,191,192,29],"make","make ugc","research","create","Video","Captions","ads","short","hooks","head","style","niche","trending","talking-head","approve",{"skillNo":194,"name":195,"nameZh":6,"description":196,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":81,"licenseFileUrl":197,"sourceHtmlUrl":198,"categories":199,"keywords":200,"publishedAt":42},"01M6WN10ARAA63Y8K1YNGXJ2RM","lead-signals","Find and qualify public buying signals through Treg, rank fitting business accounts and optionally enrich authorized business contact information.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-lead-signals\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-lead-signals\u002FSKILL.md",[],[201,202,203,40,88,38,204,205,142,206,207,33,208,209,210,211,212,213,214,29],"signals","lead","lead signals","how","find","ready","as","how to","qualify","people","information","enrich","changes","funding"]