Claude Code
Reads every page and component against a fixed checklist, takes screenshots at phone and tablet widths, fixes CSS and markup in small commits and leaves you a reusable slash command.
What reviewers see in the first minute
Guideline 4.0 asks for apps that are refined and easy to use, and web-based apps get extra scrutiny under 4.2 for feeling like a website. The issues that trigger those comments are predictable: a header that slides under the status bar or Dynamic Island, a tab bar sitting on the home indicator, icon buttons smaller than Apple's 44 x 44 point guidance (Android's Material guidance is 48 x 48 dp), horizontal scrolling on a small iPhone, inputs that zoom on focus because their font is smaller than 16 px, a full-height layout that jumps because of 100vh, and menus that only open on hover. Reviewers also run iPhone apps on iPads, so a layout that breaks at tablet width shows up too.
Each issue lives in one of two places: your CSS or the WebViewGold settings around the WebView. The guideline 4.0 guide explains the rejection itself; this page is about finding and fixing the causes with Claude Code before a reviewer does.
What Claude Code does and what you do
You
Judge the findings (some are false positives), decide design trade-offs, and set the status bar, bottom bar and zoom options in the WebViewGold projects.
A real phone
Proves what no screenshot can: the notch, the home indicator, the keyboard and the zoom behavior inside the actual WebView.
Native settings vs your CSS
| Issue | WebViewGold setting | In your web app |
|---|---|---|
| Status bar area | iOS: statusBarBackgroundColor, statusBarTextColor and their dark mode variants, or transparentStatusBar with autoAdjustSafeAreaInsets false. Android: TRANSPARENT_STATUS_BAR, blackStatusBarText | Only if content draws behind the bar: viewport-fit=cover and env(safe-area-inset-top) |
| Home indicator | iOS: bottombar, iPadBottombar, bottombarBackgroundColor (safe area docs) | env(safe-area-inset-bottom) on fixed bottom bars |
| Zoom | iOS: preventZoom. Android: ENABLE_ZOOM, MAX_TEXT_ZOOM to cap system text scaling | 16 px input font size, no fixed widths |
| Bounce and link previews | iOS: preventoverscroll (keep false if you use pulltorefresh), disablecallout | Nothing |
| Keyboard covering inputs | Android: INPUT_SCROLL_HELPER | Avoid fixed footers over forms; scroll focused fields into view |
| Orientation | iOS: orientationiphone, orientationipad. Android: PHONE_ORIENTATION, TABLET_ORIENTATION | Test every orientation you allow |
With a good optimized version of your web app you can have a stunning mobile app within a couple of minutes. Additionally to that the customer service is very nice and very helpful! I can just recommend WebViewGold :-)
The audit subagent
Subagents are Markdown files with a short frontmatter in .claude/agents/; you can also create one interactively with /agents. This one only reads and reports, so it never fights with your main session over edits.
markdown
---
name: mobile-ui-auditor
description: Audits pages and components for problems in the native iOS and Android WebView apps (safe areas, tap targets, overflow, input zoom, viewport units). Use after UI changes and before every store submission.
tools: Read, Grep, Glob, Bash
---
You audit a web app that also ships as iOS and Android apps built with WebViewGold
(WKWebView / Android WebView). You report problems; you do not edit files.
Check every page and shared component for:
1. Safe areas: the viewport meta includes viewport-fit=cover if content draws behind
the status bar; fixed or sticky top bars use env(safe-area-inset-top); bottom bars,
tab bars, floating buttons and toasts use env(safe-area-inset-bottom).
2. Tap targets: interactive elements at least 44 x 44 CSS px (icon buttons, close
buttons, checkboxes, links in dense lists) with at least 8 px between them.
3. Overflow: nothing wider than the viewport at 320 px; long words, tables, code
blocks and images are constrained.
4. Inputs: font-size of at least 16 px on input, select and textarea; correct type,
inputmode and autocomplete attributes on login and checkout forms.
5. Viewport units: 100vh on full-height layouts (use 100dvh with a 100vh fallback).
6. Hover-only UI: menus, tooltips or actions that need :hover to be reachable.
7. Desktop leftovers: sidebars without a mobile variant, Download our app banners,
builder badges, cookie walls shown inside the app.
8. Dark mode: contrast of text and backgrounds if the app supports dark mode.
Output a table: file, line, issue, check number, suggested fix. Group by severity:
blocks review, looks broken, polish. End with the three fixes that matter most.The audit loop
One afternoon for a typical app; afterwards a slash command keeps it cheap.
Give Claude Code eyes
Add the Playwright MCP server with
claude mcp add playwright npx @playwright/mcp@latestand check it with/mcp. The agent can then open your preview URL, resize the viewport and take screenshots. It is a desktop browser engine, not the WebView on a phone, and it does not simulate notches, so it finds overflow and sizing problems but not safe-area ones.Save the subagent
Put the file above into
.claude/agents/mobile-ui-auditor.mdand commit it, so everyone who runs Claude Code in the repository gets the same audit.Run the audit and the screenshot pass
Use the prompt below. Read the report before any fix starts; you will spot false positives (a 40 px button inside a larger tap area is fine) faster than the agent.
Fix in small commits
One commit per severity group. Once the pattern is clear, switch to accept-edits mode with Shift+Tab and review the diff at the end.
Check on real devices
Build for TestFlight and internal testing and go through the checklist below. If you have no Mac, the Cloud Builder produces both test builds from the browser.
The audit-and-fix prompt
Replace the route list with your real screens, including the ones behind login. The last step leaves you a slash command for every future change.
Paste into Claude Code
Use the mobile-ui-auditor subagent to audit src/app and src/components. Then use the Playwright MCP server to open https://preview.example.com and take full-page screenshots of /, /login, /dashboard, /settings and the paywall at 320, 375, 390, 430, 768 and 1024 px width (sign in with our test account; ask me for the password when you need it). Compare the screenshots with the audit report and add anything only visible on screen: overlapping elements, cut-off text, horizontal scrolling, buttons too close together. Show me the combined report and wait for my go. Then fix in this order: blocks review, looks broken, polish, one commit per group. Rules for the fixes: - Safe areas with env(safe-area-inset-top) and env(safe-area-inset-bottom) through CSS variables in globals.css; viewport-fit=cover in the viewport meta. - Tap targets at least 44 x 44 px; enlarge the hit area with padding rather than making icons bigger. - Inputs, selects and textareas at 16 px font size. - min-height 100dvh with a 100vh fallback for full-height screens. - Hover effects only inside @media (hover: hover). - Do not disable zoom globally and do not touch the WebViewGold configuration. Finally create .claude/commands/mobile-check.md: a slash command that runs the mobile-ui-auditor subagent only on files changed in the current git diff and prints the report.
The CSS the fixes should converge on
Pick one owner of the safe area. Either WebViewGold keeps content out of the status bar and home indicator areas (the default plus bottombar), or your CSS does it with transparentStatusBar on and autoAdjustSafeAreaInsets off. Mixing both gives double gaps on some devices and none on others.
css
/* app/globals.css
Viewport meta: <meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover">
Without viewport-fit=cover, env(safe-area-inset-*) is always 0. */
:root {
--safe-top: env(safe-area-inset-top, 0px);
--safe-bottom: env(safe-area-inset-bottom, 0px);
--tabbar-height: 64px;
}
.app-header { position: sticky; top: 0; padding-top: var(--safe-top); }
.tab-bar {
position: fixed; left: 0; right: 0; bottom: 0;
height: calc(var(--tabbar-height) + var(--safe-bottom));
padding-bottom: var(--safe-bottom);
}
main { padding-bottom: calc(var(--tabbar-height) + var(--safe-bottom) + 16px); }
.screen { min-height: 100vh; min-height: 100dvh; }
input, select, textarea { font-size: 16px; }
.icon-button { min-width: 44px; min-height: 44px; display: inline-grid; place-items: center; }
@media (hover: hover) {
.card:hover { box-shadow: 0 4px 16px rgb(0 0 0 / 0.12); }
}Verification checklist on real devices
- iPhone with Dynamic Island: header text and buttons sit below the island in every screen; the tab bar sits above the home indicator, in portrait and in any landscape mode you allow.
- Small iPhone (SE size): no horizontal scrolling anywhere, including tables and long email addresses.
- iPad: the layout uses the width sensibly, and rotation does not break it if
orientationipadallows rotation. See iPad support. - Tap every icon button with your thumb, not a fingertip: no misses, no accidental neighbors.
- Focus each input: no zoom on iOS; the keyboard does not cover the submit button on Android.
- Android with the largest system font size: the layout survives, or you cap it with
MAX_TEXT_ZOOM. - Dark mode on: status bar text is readable (
darkModeStatusBarTextColoron iOS). - Long-press a link: no browser-style preview if
disablecalloutis on.
Pitfalls
- Missing viewport-fit=cover. Your env() padding silently evaluates to 0 and the audit looks green.
- Trusting screenshots for safe areas. Desktop browser engines do not emulate the notch or home indicator. Only a device proves those.
- Killing zoom instead of fixing fonts. Zoom is an accessibility feature. Fix the 16 px input size first; use
preventZoomorENABLE_ZOOMonly if your app truly needs it. - Sticky hover states. On touch screens, :hover styles stay applied after a tap. Wrap them in a hover media query.
- Fixing the web and forgetting the shell. A white status bar over a dark app is a WebViewGold color setting, not a CSS bug. Check the table above before asking the agent.
Frequently asked questions
Is 44 px a hard App Store rule?
It is Apple's Human Interface Guidelines recommendation, not a numbered review guideline. Reviewers reject apps that are hard to use, though, and tiny tap targets are the fastest way to get there.
Do I need a subagent, or is a prompt enough?
A prompt works once. The subagent keeps the checklist in the repository, runs in its own context so it does not clutter your main session, and the slash command makes it a habit after every UI change.
Why not let the agent fix everything in one pass?
Because some findings are false positives and some fixes conflict with your design. Reviewing the report first takes minutes and saves you from reverting a large diff.
Does env(safe-area-inset-*) work on Android?
Support inside an Android WebView depends on the system version and on how the app draws behind the system bars. Test it on a device, and keep a fallback padding for the app if you switch on TRANSPARENT_STATUS_BAR.
Should I hide website parts like the footer inside the app?
Usually yes. Detect the app via the WebViewGoldApp user agent token and hide marketing navigation, cookie walls and app download banners; the custom CSS and JS guide shows the options.
Three ways to get your app into the stores
Same result, different amount of work on your side. All three come with the approval guarantee and 24/7 human support.
Do it yourself
$109 per platform, one-time
The WebViewGold license: a finished Xcode or Android Studio project. Paste your URL, set name and icon, switch on features, build and submit. Free updates forever.
See plans on the main pageCloud Builder
$349 per license, one-time add-on
No Mac, no Xcode, no Android Studio: configure in the browser, we build both apps in the cloud and hand them to App Store Connect and the Play Console.
How the Cloud Builder works Try the free demoFull Service
$698 per platform $798
Send us your URL and icon. Our team configures, builds and delivers your app within 72 hours, white-label, with source projects. Both platforms for $1,158.
Full Service details Powered by
Winter Sale prices valid until December 31, 2026.