Zum Inhalt springen
WebViewGold Vibe Coding in den App Store
Deutsch
WebViewGold holen

Claude Code + Design

Ein Mobile-UI-Audit mit Claude Code: Safe Areas, Tippflächen und die Details, die Reviewern auffallen

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.

  • Genehmigungsgarantie – oder Geld zurück innerhalb von 14 Tagen
  • Kein Programmieren nötig
  • Einmalzahlung, kostenlose Updates
  • 24/7 Support von echten Menschen
  • Made in Germany seit 2014 · ISO 27001

Was Reviewer in der ersten Minute sehen

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.

Was Claude Code übernimmt und was du machst

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.

Du

Bewertest die Befunde (manche sind Fehlalarme), triffst Design-Abwägungen und stellst Statusleiste, untere Leiste und Zoom-Optionen in den WebViewGold-Projekten ein.

Ein echtes Handy

Beweist, was kein Screenshot kann: Notch, Home-Indikator, Tastatur und Zoom-Verhalten in der echten WebView.

Native Einstellungen vs. dein CSS

ProblemWebViewGold-EinstellungIn deiner Web-App
Bereich der StatusleisteiOS: statusBarBackgroundColor, statusBarTextColor und ihre Dark-Mode-Varianten oder transparentStatusBar mit autoAdjustSafeAreaInsets auf false. Android: TRANSPARENT_STATUS_BAR, blackStatusBarTextNur wenn Inhalte hinter der Leiste gezeichnet werden: viewport-fit=cover und env(safe-area-inset-top)
Home-IndikatoriOS: bottombar, iPadBottombar, bottombarBackgroundColor (Safe-Area-Doku)env(safe-area-inset-bottom) bei fixierten unteren Leisten
ZoomiOS: preventZoom. Android: ENABLE_ZOOM, MAX_TEXT_ZOOM, um die Textskalierung des Systems zu begrenzenSchriftgröße 16 px in Eingabefeldern, keine festen Breiten
Bounce und Link-VorschaueniOS: preventoverscroll (bleibt false, wenn du pulltorefresh nutzt), disablecalloutNichts
Tastatur verdeckt EingabefelderAndroid: INPUT_SCROLL_HELPERKeine fixierten Footer über Formularen; fokussierte Felder in den sichtbaren Bereich scrollen
AusrichtungiOS: orientationiphone, orientationipad. Android: PHONE_ORIENTATION, TABLET_ORIENTATIONJede 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 :-)

Julian Koch · Mitbegründer von DuelDonkey · CodeCanyon

Der Audit-Subagent

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.

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.

Die Audit-Schleife

Ein Nachmittag für eine typische App; danach hält ein Slash-Command den Aufwand klein.

  1. Gib Claude Code Augen

    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.

  2. Den Subagenten speichern

    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.

  3. Audit und Screenshot-Durchlauf starten

    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.

  4. In kleinen Commits fixen

    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.

  5. Auf echten Geräten prüfen

    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.

Der Audit-und-Fix-Prompt

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.

In Claude Code einfügen
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.

Das CSS, auf das die Fixes hinauslaufen sollten

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.

css
/* 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); }
}

Checkliste auf echten Geräten

  • iPhone mit Dynamic Island: Header-Text und Buttons liegen auf jedem Screen unterhalb der Island; die Tab-Leiste sitzt über dem Home-Indikator, im Hochformat und in jedem Querformat, das du erlaubst.
  • Kleines iPhone (SE-Größe): nirgends horizontales Scrollen, auch nicht bei Tabellen und langen E-Mail-Adressen.
  • iPad: Das Layout nutzt die Breite sinnvoll, und Drehen macht es nicht kaputt, falls orientationipad Drehen erlaubt. Siehe iPad-Support.
  • Tippe jeden Icon-Button mit dem Daumen an, nicht mit der Fingerspitze: keine Fehltreffer, keine versehentlich getroffenen Nachbarn.
  • Fokussiere jedes Eingabefeld: kein Zoom auf iOS; auf Android verdeckt die Tastatur den Absende-Button nicht.
  • Android mit der größten Systemschriftgröße: Das Layout hält, oder du begrenzt sie mit MAX_TEXT_ZOOM.
  • Dark Mode an: Der Text der Statusleiste ist lesbar (darkModeStatusBarTextColor auf iOS).
  • Drück lange auf einen Link: keine Vorschau wie im Browser, wenn disablecallout an ist.

Stolperfallen

  • Fehlendes viewport-fit=cover. Dein env()-Padding ergibt stillschweigend 0, und das Audit sieht grün aus.
  • Bei Safe Areas Screenshots vertrauen. Desktop-Browser-Engines emulieren weder Notch noch Home-Indikator. Das beweist nur ein Gerät.
  • Zoom abschalten, statt Schriften zu fixen. Zoom ist eine Bedienungshilfe. Behebe zuerst die 16-px-Größe in Eingabefeldern; nutze preventZoom oder ENABLE_ZOOM nur, wenn deine App das wirklich braucht.
  • Hängende Hover-Zustände. Auf Touchscreens bleiben :hover-Styles nach dem Antippen aktiv. Pack sie in eine Hover-Media-Query.
  • Das Web fixen und die Hülle vergessen. Eine weiße Statusleiste über einer dunklen App ist eine Farbeinstellung in WebViewGold, kein CSS-Bug. Schau in die Tabelle oben, bevor du den Agenten fragst.

Häufig gestellte Fragen

Sind 44 px eine harte App-Store-Regel?

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.

Brauche ich einen Subagenten, oder reicht ein Prompt?

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.

Warum den Agenten nicht alles in einem Durchgang fixen lassen?

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.

Funktioniert env(safe-area-inset-*) auf Android?

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.

Sollte ich Website-Teile wie den Footer in der App ausblenden?

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.

Drei Wege, deine App in die Stores zu bringen

Gleiches Ergebnis, unterschiedlich viel Arbeit auf deiner Seite. Alle drei kommen mit Genehmigungsgarantie und 24/7 Support von echten Menschen.

Selbst machen

$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

Full Service

$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 by WeSetupYourWebViewApp

Winter-Sale-Preise gültig bis 31. Dezember 2026.

Bereit, deine App zu veröffentlichen?

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.