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

ChatGPT & Codex

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

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

SetupWebViewGold-EinstellungenDein CSSGeeignet 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.xmlKein Inset-Padding; stell sicher, dass keine Komponente einen eigenen Notch-Abstandhalter hinzufügtDie 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 Headerviewport-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 testenRandlose Header, Karten, Medien
Native Tab-LeisteiOS: showNavFooter mit FooterBar.json. Android: ENABLE_NAVIGATION_FOOTER mit res/menu/menu_drawer.xmlBlende deine eigene Web-Tab-Leiste aus, wenn isNativeApp() true ist, sonst sehen Nutzer zweiApps 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

  1. 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.

  2. 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.

  3. Selbst sortieren

    Lösche Befunde, mit denen du nicht einverstanden bist, und markiere bewusste Designentscheidungen. Zehn Minuten hier verhindern, dass Codex deine Marke "repariert".

  4. 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.

  5. 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.

  6. 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.

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.