Claude Code
Prüft jede Seite und Komponente gegen eine feste Checkliste, macht Screenshots in Handy- und Tablet-Breite, behebt CSS und Markup in kleinen Commits und hinterlässt dir einen wiederverwendbaren Slash-Command.
Claude Code + Design
Reviewer beurteilen eine gewrappte Web-App in Sekunden: Inhalte unter der Notch, Buttons, die zu klein zum Treffen sind, eine Seite, die zoomt, sobald man in ein Eingabefeld tippt. Nichts davon ist schwer zu beheben, und Claude Code findet es zuverlässig, sobald es eine Checkliste hat und den Screen sehen kann. Dieser Guide richtet einen Audit-Subagenten und eine Screenshot-Schleife ein und zeigt das CSS, auf das die Fixes hinauslaufen sollten, sowie die passenden WebViewGold-Einstellungen.
Ab $109 einmalig pro Plattform, oder unser Team erledigt alles ab $698.
Richtlinie 4.0 verlangt Apps, die ausgereift und einfach zu bedienen sind, und webbasierte Apps werden unter 4.2 besonders genau darauf geprüft, ob sie sich wie eine Website anfühlen. Die Probleme, die solche Kommentare auslösen, sind vorhersehbar: ein Header, der unter die Statusleiste oder die Dynamic Island rutscht, eine Tab-Leiste, die auf dem Home-Indikator sitzt, Icon-Buttons, die kleiner sind als Apples Empfehlung von 44 x 44 Punkt (Androids Material-Empfehlung liegt bei 48 x 48 dp), horizontales Scrollen auf einem kleinen iPhone, Eingabefelder, die beim Fokus zoomen, weil ihre Schrift kleiner als 16 px ist, ein Layout in voller Höhe, das wegen 100vh springt, und Menüs, die sich nur per Hover öffnen. Reviewer lassen iPhone-Apps auch auf iPads laufen, ein Layout, das in Tablet-Breite bricht, fällt also ebenfalls auf.
Jedes Problem sitzt an einer von zwei Stellen: in deinem CSS oder in den WebViewGold-Einstellungen rund um die WebView. Der Guide zu Richtlinie 4.0 erklärt die Ablehnung selbst; auf dieser Seite geht es darum, die Ursachen mit Claude Code zu finden und zu beheben, bevor ein Reviewer es tut.
Prüft jede Seite und Komponente gegen eine feste Checkliste, macht Screenshots in Handy- und Tablet-Breite, behebt CSS und Markup in kleinen Commits und hinterlässt dir einen wiederverwendbaren Slash-Command.
Bewertest die Befunde (manche sind Fehlalarme), triffst Design-Abwägungen und stellst Statusleiste, untere Leiste und Zoom-Optionen in den WebViewGold-Projekten ein.
Beweist, was kein Screenshot kann: Notch, Home-Indikator, Tastatur und Zoom-Verhalten in der echten WebView.
| Problem | WebViewGold-Einstellung | In deiner Web-App |
|---|---|---|
| Bereich der Statusleiste | iOS: statusBarBackgroundColor, statusBarTextColor und ihre Dark-Mode-Varianten oder transparentStatusBar mit autoAdjustSafeAreaInsets auf false. Android: TRANSPARENT_STATUS_BAR, blackStatusBarText | Nur wenn Inhalte hinter der Leiste gezeichnet werden: viewport-fit=cover und env(safe-area-inset-top) |
| Home-Indikator | iOS: bottombar, iPadBottombar, bottombarBackgroundColor (Safe-Area-Doku) | env(safe-area-inset-bottom) bei fixierten unteren Leisten |
| Zoom | iOS: preventZoom. Android: ENABLE_ZOOM, MAX_TEXT_ZOOM, um die Textskalierung des Systems zu begrenzen | Schriftgröße 16 px in Eingabefeldern, keine festen Breiten |
| Bounce und Link-Vorschauen | iOS: preventoverscroll (bleibt false, wenn du pulltorefresh nutzt), disablecallout | Nichts |
| Tastatur verdeckt Eingabefelder | Android: INPUT_SCROLL_HELPER | Keine fixierten Footer über Formularen; fokussierte Felder in den sichtbaren Bereich scrollen |
| Ausrichtung | iOS: orientationiphone, orientationipad. Android: PHONE_ORIENTATION, TABLET_ORIENTATION | Jede erlaubte Ausrichtung testen |

Mit einer gut optimierten Version Ihrer Web-App können Sie innerhalb von wenigen Minuten eine beeindruckende mobile App erstellen. Zusätzlich dazu ist der Kundenservice sehr nett und hilfsbereit! Ich kann WebViewGold nur empfehlen :-)
Subagenten sind Markdown-Dateien mit einem kurzen Frontmatter in .claude/agents/; du kannst sie auch interaktiv mit /agents anlegen. Dieser hier liest und berichtet nur, kommt deiner Haupt-Session bei Änderungen also nie in die Quere.
---
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.Ein Nachmittag für eine typische App; danach hält ein Slash-Command den Aufwand klein.
Füge den Playwright-MCP-Server mit claude mcp add playwright npx @playwright/mcp@latest hinzu und prüfe ihn mit /mcp. Der Agent kann dann deine Preview-URL öffnen, den Viewport ändern und Screenshots machen. Das ist eine Desktop-Browser-Engine, nicht die WebView auf einem Handy, und sie simuliert keine Notch; sie findet also Overflow- und Größenprobleme, aber keine Safe-Area-Probleme.
Leg die Datei oben unter .claude/agents/mobile-ui-auditor.md ab und committe sie, damit alle, die Claude Code im Repository nutzen, dasselbe Audit bekommen.
Nutze den Prompt unten. Lies den Bericht, bevor irgendein Fix beginnt; Fehlalarme (ein 40-px-Button in einer größeren Tippfläche ist in Ordnung) erkennst du schneller als der Agent.
Ein Commit pro Schweregrad. Sobald das Muster klar ist, wechsle mit Shift+Tab in den Accept-Edits-Modus und prüfe am Ende das Diff.
Baue für TestFlight und den internen Test und geh die Checkliste unten durch. Wenn du keinen Mac hast, erstellt der Cloud Builder beide Test-Builds aus dem Browser.
Ersetze die Routenliste durch deine echten Screens, auch die hinter dem Login. Der letzte Schritt hinterlässt dir einen Slash-Command für jede künftige Änderung.
Nutze den Subagenten mobile-ui-auditor, um src/app und src/components zu prüfen. Nutze dann den Playwright-MCP-Server, um https://preview.example.com zu öffnen und ganzseitige Screenshots von /, /login, /dashboard, /settings und der Paywall in 320, 375, 390, 430, 768 und 1024 px Breite zu machen (melde dich mit unserem Testkonto an; frag mich nach dem Passwort, wenn du es brauchst). Vergleiche die Screenshots mit dem Audit-Bericht und ergänze alles, was nur auf dem Screen sichtbar ist: überlappende Elemente, abgeschnittener Text, horizontales Scrollen, Buttons, die zu dicht beieinander liegen. Zeig mir den zusammengeführten Bericht und warte auf mein Go. Fixe dann in dieser Reihenfolge: blocks review, looks broken, polish, ein Commit pro Gruppe. Regeln für die Fixes: - Safe Areas mit env(safe-area-inset-top) und env(safe-area-inset-bottom) über CSS-Variablen in globals.css; viewport-fit=cover im Viewport-Meta-Tag. - Tippflächen von mindestens 44 x 44 px; vergrößere die Trefferfläche lieber mit Padding, statt die Icons größer zu machen. - Inputs, Selects und Textareas mit 16 px Schriftgröße. - min-height 100dvh mit 100vh als Fallback für Screens in voller Höhe. - Hover-Effekte nur innerhalb von @media (hover: hover). - Deaktiviere den Zoom nicht global und fass die WebViewGold-Konfiguration nicht an. Lege zum Schluss .claude/commands/mobile-check.md an: einen Slash-Command, der den Subagenten mobile-ui-auditor nur auf die Dateien im aktuellen git diff ansetzt und den Bericht ausgibt.
Leg fest, wer für die Safe Area zuständig ist. Entweder hält WebViewGold Inhalte aus den Bereichen von Statusleiste und Home-Indikator heraus (der Standard plus bottombar), oder dein CSS übernimmt das, mit transparentStatusBar an und autoAdjustSafeAreaInsets aus. Beides zu mischen ergibt auf manchen Geräten doppelte Abstände und auf anderen gar keine.
/* app/globals.css
Viewport-Meta-Tag: <meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover">
Ohne viewport-fit=cover ist env(safe-area-inset-*) immer 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); }
}orientationipad Drehen erlaubt. Siehe iPad-Support.MAX_TEXT_ZOOM.darkModeStatusBarTextColor auf iOS).disablecallout an ist.preventZoom oder ENABLE_ZOOM nur, wenn deine App das wirklich braucht.Es ist eine Empfehlung aus Apples Human Interface Guidelines, keine nummerierte Review-Richtlinie. Reviewer lehnen aber Apps ab, die schwer zu bedienen sind, und winzige Tippflächen sind der schnellste Weg dorthin.
Ein Prompt funktioniert einmal. Der Subagent hält die Checkliste im Repository, läuft in einem eigenen Kontext, damit er deine Haupt-Session nicht zumüllt, und der Slash-Command macht daraus eine Gewohnheit nach jeder UI-Änderung.
Weil manche Befunde Fehlalarme sind und manche Fixes mit deinem Design kollidieren. Den Bericht vorher zu lesen dauert Minuten und erspart dir, ein großes Diff zurückzunehmen.
Die Unterstützung in einer Android-WebView hängt von der Systemversion ab und davon, wie die App hinter den Systemleisten zeichnet. Teste es auf einem Gerät und behalte ein Fallback-Padding für die App, wenn du TRANSPARENT_STATUS_BAR einschaltest.
Meistens ja. Erkenne die App über das User-Agent-Token WebViewGoldApp und blende Marketing-Navigation, Cookie-Walls und App-Download-Banner aus; der Guide zu eigenem CSS und JS zeigt die Möglichkeiten.
Gleiches Ergebnis, unterschiedlich viel Arbeit auf deiner Seite. Alle drei kommen mit Genehmigungsgarantie und 24/7 Support von echten Menschen.
$109 pro Plattform, einmalig
Die WebViewGold-Lizenz: ein fertiges Xcode- oder Android-Studio-Projekt. URL einfügen, Name und Icon setzen, Features einschalten, bauen und einreichen. Kostenlose Updates für immer.
Pakete auf der Hauptseite ansehen$349 pro Lizenz, einmaliges Add-on
Kein Mac, kein Xcode, kein Android Studio: Du konfigurierst im Browser, wir bauen beide Apps in der Cloud und übergeben sie an App Store Connect und die Play Console.
So funktioniert der Cloud Builder Kostenlose Demo ausprobieren$698 pro Plattform $798
Schick uns deine URL und dein Icon. Unser Team konfiguriert, baut und liefert deine App innerhalb von 72 Stunden, White-Label, inklusive Quellprojekten. Beide Plattformen für $1,158.
Full-Service-Details Powered byWinter-Sale-Preise gültig bis 31. Dezember 2026.
App Store & Google Play Genehmigungsgarantie – oder Geld zurück innerhalb von 14 Tagen
Lieber abgeben? Full Service: Wir konfigurieren, bauen und liefern innerhalb von 72 Stunden, ab $698 pro Plattform. Fragen? Chatte mit uns – 24/7.
Erstattungen erfolgen zu den in unseren FAQ genannten Bedingungen: eine nicht inhaltsbedingte Ablehnung durch Apple und/oder Google, geltend gemacht innerhalb von 14 Tagen nach dem Kauf.