Ein mobiler UI-Audit mit Codex für WebViewGold-Apps: Safe Areas, Touch-Targets und die Details, die Reviewern auffallen
Ablehnungen nach Richtlinie 4.0 und Ein-Sterne-Bewertungen kommen oft von denselben paar Pixeln: ein Header unter der Notch, eine Tab-Leiste hinter dem Home-Indikator, ein winziger Schließen-Button, ein Eingabefeld, das beim Antippen die Seite zoomt. Codex findet die meisten davon in deinem Code und belegt die Fixes in einem Headless-Browser, während ein paar WebViewGold-Einstellungen entscheiden, wem die Safe Area gehört. Hier ist der Audit als wiederholbarer Workflow.
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
9:41
Deine App
Deine AppJetzt auf dem Smartphone
App Store · Google Play Freigegeben
Was der Reviewer mit deinen Screens macht
Das App-Review installiert den Build auf aktueller Hardware, oft auf einem iPhone mit Dynamic Island und zusätzlich auf einem iPad, denn WebViewGold-Apps laufen auf dem iPad, solange du sie nicht einschränkst (iPad-Support für gewrappte Web-Apps). Der Reviewer tippt sich mit dem Daumen durch die Hauptabläufe, nicht mit der Maus. Alles, was unter der Statusleiste verschwindet, ein Button, der drei Versuche braucht, ein Formular, das hineinzoomt und gezoomt bleibt, oder eine Seite, die seitlich scrollt, wirkt wie "das ist eine Website", und die Ablehnung zitiert meist Richtlinie 4.0 Design oder 2.1 (die 4.0-Ablehnung erklärt). Google verbucht dieselben Probleme unter fehlerhafter Funktionalität.
Das Ziel des Audits ist absichtlich unspektakulär: Nichts überlappt die System-UI, jedes Bedienelement lässt sich bequem antippen, keine Seite scrollt bei 320 Pixeln seitlich, Eingabefelder lösen keinen Fokus-Zoom aus, und die Statusleiste passt im hellen und dunklen Modus zu deinem Header.
Entscheide zuerst, wem die Safe Area gehört
Setup
WebViewGold-Einstellungen
Dein CSS
Geeignet für
WebViewGold hält den Inhalt in der Safe Area (Standard)
iOS: autoAdjustSafeAreaInsets bleibt true; färbe die Leisten mit statusBarBackgroundColor und den Bereich des Home-Indikators mit bottombar und bottombarBackgroundColor (es gibt Varianten für den Dark Mode). Android: TRANSPARENT_STATUS_BAR false, die Leistenfarbe kommt aus colorPrimaryDark in style.xml
Kein Inset-Padding; stell sicher, dass keine Komponente einen eigenen Notch-Abstandhalter hinzufügt
Die meisten Apps, am wenigsten Arbeit
Deine Web-App zeichnet randlos (edge to edge)
iOS: transparentStatusBar true und autoAdjustSafeAreaInsets false. Android: TRANSPARENT_STATUS_BAR true, blackStatusBarText passend zu deinem Header
viewport-fit=cover plus env(safe-area-inset-top) und env(safe-area-inset-bottom) an fixierten Headern, Tab-Leisten und Sheets; Android auf einem Gerät testen
Randlose Header, Karten, Medien
Native Tab-Leiste
iOS: showNavFooter mit FooterBar.json. Android: ENABLE_NAVIGATION_FOOTER mit res/menu/menu_drawer.xml
Blende deine eigene Web-Tab-Leiste aus, wenn isNativeApp() true ist, sonst sehen Nutzer zwei
Apps mit drei bis fünf Hauptbereichen
Durchgang 1: ein schreibgeschützter Headless-Audit
codex exec führt Codex ohne die interaktive Oberfläche aus; --sandbox read-only heißt, dass es jede Datei lesen, aber keine ändern kann, und -o speichert seine finale Antwort in einer Datei. Führe es im Root des Repositorys aus. Der zweite Befehl ist optional und zeigt Codex, was das Gerät zeigt: -i hängt Screenshots an den Prompt an.
bash
# Durchgang 1: Codex liest, ändert nichts, und die CLI speichert den Bericht.
codex exec --sandbox read-only -o ui-audit.md "Lies AGENTS.md. Diese Web-App läuft in
nativen iOS- und Android-WebViews (WebViewGold). Prüfe jede Route und jede gemeinsame
Layout-Komponente und ERSTELLE NUR EINEN BERICHT, bearbeite nichts. Für jeden Befund:
Datei:Zeile, Schweregrad (blocker, major, minor), was auf einem Handy kaputtgeht, und
der kleinste Fix. Prüfe:
- viewport meta: width=device-width, initial-scale=1, viewport-fit=cover
- fixierte oder sticky Elemente am oberen oder unteren Rand und wie sie mit Safe Areas umgehen
- interaktive Elemente kleiner als 44x44 CSS-px oder näher als 8px beieinander
- Schriftgröße von input, select und textarea unter 16px (Fokus-Zoom auf iOS)
- Menüs, Tooltips und Aktionen, die nur per Hover funktionieren
- 100vh-Layouts, horizontaler Overflow unter 360px Breite, feste Pixelbreiten
- Modals und Sheets ohne sichtbaren Schließen-Button
Schließe mit einer Übersichtstabelle nach Schweregrad."
# Optional: Geräte-Screenshots aus TestFlight oder dem internen Test anhängen
codex --sandbox workspace-write -i iphone-home.png,ipad-settings.png "Diese Screenshots
stammen aus dem TestFlight-Build. Ergänze alles, was hier sichtbar ist und in ui-audit.md fehlt."
Großartige Möglichkeit, eine Web-App in eine native App zu verwandeln! Schnelle Umsetzung und ein toller Weg, Apps in die App Stores zu bringen, ohne eine komplett native App entwickeln zu müssen!
Kevin Joling · FlightConnections & TrainConnections · Trustpilot
Durchgang 2: ein Playwright-Check, der es dauerhaft repariert hält
Code zu lesen findet die meisten Probleme; ein Browser beweist die Fixes. Der Fix-Prompt unten bittet Codex, diesen Test hinzuzufügen, und es lohnt sich, ihn in der CI zu behalten. Er ist absichtlich streng: Rechne mit ein paar Fehlalarmen, etwa bei Inline-Textlinks oder Checkboxen, und lass Codex sie zur geprüften Allowlist hinzufügen, statt die Schwellenwerte zu lockern.
javascript
// tests/mobile-ui.spec.js (run: npx playwright test tests/mobile-ui.spec.js)
import { test, expect } from "@playwright/test";
const ROUTES = ["/", "/login", "/settings", "/projects/demo"];
const WIDTHS = [320, 375, 430, 768]; // small phone, phone, large phone, iPad portrait
const ALLOW = ["a.inline-link", "input[type=checkbox]"]; // reviewed exceptions
for (const width of WIDTHS) {
for (const route of ROUTES) {
test(route + " at " + width + "px", async ({ page }) => {
await page.setViewportSize({ width, height: 860 });
await page.goto(route);
// 1. No sideways scrolling
const overflow = await page.evaluate(
() => document.documentElement.scrollWidth - window.innerWidth);
expect(overflow, "horizontal overflow in px").toBeLessThanOrEqual(0);
// 2. Tap targets of at least 44 x 44 CSS px
const small = await page.$$eval("a, button, [role=button], [role=tab], select",
(els, allow) => els
.filter((el) => !allow.some((sel) => el.matches(sel)))
.filter((el) => { const r = el.getBoundingClientRect();
return r.width > 0 && (r.width < 44 || r.height < 44); })
.map((el) => (el.getAttribute("aria-label") || el.textContent || el.tagName)
.trim().slice(0, 40)),
ALLOW);
expect(small, "tap targets under 44px").toEqual([]);
// 3. No iOS focus zoom: form fields at 16px or more
const tiny = await page.$$eval("input, select, textarea",
(els) => els.filter((el) => parseFloat(getComputedStyle(el).fontSize) < 16).length);
expect(tiny, "form fields under 16px").toBe(0);
});
}
}
Der Fix-Prompt
Starte eine interaktive Session mit codex --sandbox workspace-write --ask-for-approval on-request. Die Installation von Playwright und seinem Browser braucht Netzwerkzugriff, deshalb bittet Codex an dieser Stelle um Freigabe; erteile sie oder installiere Playwright vorher selbst. Behalte Option A oder B aus der Tabelle und lösche die andere.
Nach dem Audit in Codex einfügen
Lies AGENTS.md und ui-audit.md. Behebe jeden Befund der Stufen blocker und major mit der kleinsten Änderung, die funktioniert. Gestalte nichts neu, benenne keine Komponenten um und ändere keine Farben, außer ein Befund verlangt es.
Safe Areas (behalte eine Option, lösche die andere):
A) WebViewGold hält den Inhalt in der Safe Area (autoAdjustSafeAreaInsets bleibt true in Config.swift). Füge kein Safe-Area-Padding hinzu; entferne stattdessen alle Notch-Abstandhalter-Komponenten.
B) Wir zeichnen randlos (transparentStatusBar = true und autoAdjustSafeAreaInsets = false in Config.swift, TRANSPARENT_STATUS_BAR = true in Config.java). Füge viewport-fit=cover hinzu und gib fixierten Headern, Tab-Leisten und Bottom Sheets ein Padding von max(ihrem normalen Padding, env(safe-area-inset-top)) bzw. env(safe-area-inset-bottom).
Regeln:
- Interaktive Elemente mindestens 44x44 CSS-px. Vergrößere die Trefferfläche mit Padding oder einem ::before-Pseudoelement; skaliere keine Icons. Halte 8px Abstand zu Nachbarelementen.
- input, select und textarea mit 16px oder mehr. Füge nie maximum-scale oder user-scalable=no hinzu.
- Ersetze 100vh durch 100dvh und behalte davor eine 100vh-Zeile als Fallback.
- Interaktionen, die nur per Hover funktionieren, bekommen eine Entsprechung per Tippen.
- Wenn die App ein helles und ein dunkles Theme hat: Wenn sich das Theme ändert und isNativeApp() true ist, navigiere zu statusbarcolor://R,G,B mit der Header-Farbe, damit die native Statusleiste folgt.
- Wenn wir die native Tab-Leiste von WebViewGold aktivieren (showNavFooter auf iOS, ENABLE_NAVIGATION_FOOTER auf Android), blende unsere Web-Tab-Leiste aus, wenn isNativeApp() true ist.
Füge dann Playwright hinzu (frag vor der Installation), eine playwright.config mit baseURL auf npm run dev und tests/mobile-ui.spec.js, das horizontalen Overflow, Tippflächen und die Schriftgröße in Formularen auf [liste deine Hauptrouten auf] bei 320, 375, 430 und 768 px prüft. Lass den Test laufen, bis er grün ist. Aktualisiere zum Schluss ui-audit.md mit drei Listen: behoben, bewusst nicht behoben (und warum), braucht einen Gerätetest.
Der Audit-Workflow
Festlegen, wem die Safe Area gehört
Wähle eine Zeile aus der Tabelle und setze sie in den WebViewGold-Projekten um (die iOS-Docs zur Safe Area behandeln die untere Leiste). Entscheide das zuerst, denn jeder CSS-Fix hängt davon ab.
Den schreibgeschützten Audit ausführen
Durchgang 1 erzeugt ui-audit.md mit Datei, Zeile, Schweregrad und dem vorgeschlagenen Fix für jeden Befund. Im Repository ändert sich nichts.
Selbst sortieren
Lösche Befunde, mit denen du nicht einverstanden bist, und markiere bewusste Designentscheidungen. Zehn Minuten hier verhindern, dass Codex deine Marke "repariert".
Die Fix-Session ausführen
Füge den Fix-Prompt ein, dann /review und git diff. Der Playwright-Test muss grün sein, bevor du deployst.
Auf echter Hardware ansehen
TestFlight auf einem iPhone mit Notch und einem iPad, interner Test auf einem kleinen Android-Handy mit Gestennavigation und großer Systemschrift. Mach von allem Merkwürdigen einen Screenshot und gib ihn mit codex -i zurück. Der kostenlose App-Store-Readiness-Check fängt die Grundlagen auf URL-Ebene ab.
Die Leitplanke behalten
Lass den Playwright-Test in der CI und ergänze die AGENTS.md um eine Review-Regel für neue zu kleine Tippflächen, damit das Codex Code Review Rückschritte in künftigen Pull Requests meldet.
Checkliste für Geräte
Der Text der Statusleiste ist im hellen und dunklen Modus lesbar; wenn sich die Header-Farbe mit dem Theme ändert, ruft die App statusbarcolor://R,G,B (oder statusbartextcolor://white / black) auf, damit die Leiste folgt (Dynamic-UI-API).
Nichts liegt unter der Dynamic Island oder der Notch, nichts hinter dem Home-Indikator, und Bottom Sheets halten den Gestenbereich frei.
Jedes Bedienelement funktioniert beim ersten Tippen mit dem Daumen: Icon-Buttons, Schließen-Buttons, Tabs, Listenzeilen.
Das Antippen eines Eingabefelds zoomt die Seite nicht, und das fokussierte Feld bleibt über der Tastatur sichtbar (auf Android kann INPUT_SCROLL_HELPER helfen).
Eine große Systemschrift auf Android zerschießt keine Layouts; begrenze die Textskalierung mit MAX_TEXT_ZOOM, wenn sich ein Layout nicht dehnen kann.
iPad in beiden Ausrichtungen: kein in die Breite gezogenes Handy-Layout mit endlosen Zeilenlängen.
Bounce und Pull-to-Refresh verhalten sich wie gewollt: preventoverscroll auf iOS entfernt den Gummiband-Effekt, für pulltorefresh muss es ausgeschaltet sein, Android nutzt ENABLE_PULL_REFRESH.
Die Zurück-Geste auf Android geht eine Seite zurück und verlässt die App nur dort, wo du es erwartest (EXIT_APP_BY_BACK_BUTTON_HOMEPAGE, EXIT_APP_DIALOG).
Fixes, die neue Probleme schaffen
Doppeltes Padding: Inset-Padding im CSS, während WebViewGold die WebView ebenfalls in der Safe Area hält. Es darf nur einen Zuständigen geben.
Den Fokus-Zoom mit maximum-scale=1 oder user-scalable=no abwürgen. Das blockiert auch den Pinch-Zoom für Menschen, die ihn brauchen; korrigiere stattdessen die Schriftgröße. WebViewGold bietet auf iOS preventZoom, aber überleg es dir gut, bevor du es nutzt.
Vollbild-Layouts mit 100vh, die am Ende höher sind als der sichtbare Bereich. Nutze 100dvh mit 100vh als Fallback.
Icons hochskalieren, um auf 44 Pixel zu kommen. Vergrößere die Trefferfläche mit Padding; das Design bleibt gleich.
Hover-Menüs, die mit einer längeren Hover-Verzögerung "repariert" werden. Touch kennt kein Hover; sie brauchen eine Tipp-Aktion.
Den Audit zum Redesign ausufern lassen. Der Prompt verlangt die kleinste Änderung; halte Codex im Review daran fest.
Häufig gestellte Fragen
Verlangt Apple Touch-Targets von 44 mal 44 Punkt?
Apples Human Interface Guidelines empfehlen mindestens 44 mal 44 Punkt, Material Design empfiehlt 48 mal 48 dp, und WCAG 2.2 setzt 24 mal 24 CSS-Pixel als Minimum. Reviewer messen nicht nach, aber sie merken, wenn Bedienelemente mehrere Versuche brauchen. Peile 44 unter iOS und 48 unter Android an.
Kann Codex meine App sehen?
Es liest deinen Code und kann sich Bilder ansehen, die du anhängst: Starte Codex mit -i und einem Screenshot aus TestFlight oder von einem Android-Gerät und bitte es, den Screenshot mit dem Code zu vergleichen. Diese Kombination findet Probleme, die keine der beiden Methoden allein erwischt.
Brauche ich env(safe-area-inset-*) überhaupt?
Nur wenn deine Web-App randlos zeichnet, mit transparenter Statusleiste und ausgeschalteter Safe-Area-Anpassung von WebViewGold. Mit der Standardbehandlung sitzt die Seite bereits in der Safe Area; prüfe nur auf einem Gerät mit Notch, dass keine Komponente einen zweiten Abstandhalter hinzufügt.
Warum zoomt meine App, wenn ich ein Eingabefeld antippe?
iOS zoomt in Formularfelder mit einer Schriftgröße unter 16 CSS-Pixeln hinein. Setze inputs, selects und textareas auf 16px oder mehr, dann verschwindet der Zoom, ohne dass du den Pinch-Zoom abschalten musst.
Sollte der Audit bei jedem Pull Request laufen?
Der Playwright-Test schon, er ist günstig. Den schreibgeschützten Codex-Audit lohnt es sich vor jeder Store-Einreichung oder nach einem größeren Redesign zu wiederholen, und eine Review-Regel in der AGENTS.md lässt das Codex Code Review neue Probleme dazwischen melden.
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.
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.
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.
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.