Eine Prompt-Bibliothek für Codex: in acht Aufgaben von der Web-App zur App-Store-fertigen App

Prüfe diese Web-App auf den Einsatz in einer nativen iOS- und Android-WebView und behebe, was du findest. Checkliste: meta viewport mit width=device-width und viewport-fit=cover; kein horizontaler Overflow zwischen 320px und 1024px; Tippflächen von mindestens 44x44px; fixe Header, Footer und Bottom Sheets mit env(safe-area-inset-top) und env(safe-area-inset-bottom) gepolstert; Eingabefelder mit einer font-size von 16px oder mehr; keine Bedienelemente, die nur per Hover funktionieren; Bilder mit expliziten Abmessungen, um Layout-Verschiebungen zu vermeiden; gut lesbarer Kontrast. Kein Redesign; nimm die kleinsten Änderungen vor, mit denen die Prüfung bestanden wird. Schließe mit einer Tabelle der geprüften Seiten und dessen, was du auf jeder davon geändert hast.

Lege zwei echte Routen an, /privacy und /terms, als gut lesbare Seiten (keine Modals), verlinkt aus dem Footer und dem Einstellungs-Screen. Erzeuge die Datenschutzerklärung aus dem, was diese Codebasis tatsächlich tut: Durchsuche package.json, die API-Routen und die Namen der Umgebungsvariablen und liste jeden Drittanbieterdienst auf, der Nutzerdaten erhält (Datenbank, Auth, E-Mail, Analytics, KI-Anbieter, Zahlungen, Push-Benachrichtigungen). Verwende die Platzhalter [FIRMA], [ADRESSE] und [E-MAIL] für die rechtlichen Angaben. Nimm Abschnitte zu erhobenen Daten, Zweck, Speicherdauer, Kontolöschung, Kindern, Kontakt und dem Datum der letzten Aktualisierung auf. Halte die Sprache einfach. Erfinde keine Verarbeitung, die der Code nicht durchführt.

Implementiere die Kontolöschung so, wie sie der App Store (Richtlinie 5.1.1) und Google Play verlangen. 1) Einstellungs-Screen: ein Button 'Konto löschen' mit einem Bestätigungsdialog, der erklärt, dass die Löschung endgültig ist. 2) Eine serverseitige Funktion, die für den authentifizierten Nutzer alle ihm gehörenden Zeilen löscht und danach den Auth-Nutzer selbst, mit Admin-Zugangsdaten ausschließlich auf dem Server. 3) Nach Erfolg: abmelden und einen Bestätigungs-Screen zeigen. 4) Eine öffentliche Seite /delete-account, die die Schritte in der App erklärt und einen E-Mail-Kontakt für Nutzer anbietet, die die App nicht mehr haben. 5) Ein Satz zur Löschung in /privacy. Schreib einen Test für die Serverfunktion, wenn das Projekt ein Test-Setup hat.

Mach jeden Screen, der Daten lädt, robust. Für jeden Fetch und jede Query: ein Ladezustand, ein Leerzustand mit einer hilfreichen Meldung, ein Fehlerzustand mit einem Button zum erneuten Versuchen und ein Timeout, damit die UI nie hängen bleibt. Ergänze eine globale Error Boundary mit einer Aktion zum Neuladen statt eines weißen Screens. Beobachte navigator.onLine und zeige einen Offline-Banner, der verschwindet, sobald die Verbindung zurück ist. Verschlucke Fehler nicht stillschweigend; logge sie über den bestehenden Logger. Liste jeden Screen auf, den du angefasst hast.

Lege src/lib/platform.ts an, das isNativeApp() exportiert; die Funktion gibt true zurück, wenn navigator.userAgent den Marker MYAPPNATIVE enthält (die native App setzt diesen User-Agent). Dann, wenn isNativeApp() true ist: Blende den Cookie-Banner aus, wenn er rechtlich nicht vorgeschrieben ist, blende Banner wie 'Lade unsere App herunter' und 'In der App öffnen' aus, blende den Desktop-Header und die Footer-Navigation zugunsten der Bottom-Navigation in der App aus und ersetze externe Links zur Marketing-Website durch Routen in der App. In normalen Browsern bleibt alles unverändert. Verwende kein reines CSS-Ausblenden für etwas, das das Laden von Daten beeinflusst.

Unsere App bietet Google-Login an. Apples Richtlinie 4.8 verlangt eine gleichwertige, datenschutzfreundliche Option, also ergänze Sign in with Apple über unseren Auth-Provider (prüfe, welchen der Code nutzt: Supabase, Firebase, Auth.js oder Clerk). Füge den Button nach Apples Vorgaben für Benennung und Platzierung hinzu, in derselben Größe und Prominenz wie den Google-Button. Behandle den Fall des ersten Logins, bei dem Apple den Namen nur einmal liefert, verknüpfe die Apple-Identität mit einem bestehenden Konto mit derselben E-Mail, wo der Provider das unterstützt, und schreib die Konfiguration auf Provider-Seite, die ich selbst vornehmen muss (Service ID, Key, Redirect-URL), in SETUP.md. Der Login per E-Mail und Passwort muss weiter funktionieren.

In der nativen App müssen digitale Produkte über In-App-Käufe verkauft werden. Finde jede Stelle, an der ein Abo, Credits oder ein Premium-Feature verkauft werden. Wenn isNativeApp() true ist, ersetze den Stripe-Checkout durch eine Navigation zu revenuecat://purchase?external_id=USER_ID&product=PRODUCT_ID, wobei USER_ID unsere Nutzer-ID ist und PRODUCT_ID aus einer Config-Map mit den RevenueCat-Produkt-IDs stammt. Ergänze im Einstellungs-Screen die Links 'Käufe wiederherstellen' (restoreinapppurchases://) und 'Abo verwalten' (cancelinapppurchase://), nur in der nativen App. Entitlements muss unser Server über den RevenueCat-Webhook vergeben, niemals der Client. Behalte Stripe für Browser-Nutzer. Zeige in der nativen App niemals Preise mit externen Zahlungslinks.

Ergänze ein Opt-in für Push-Benachrichtigungen, das im richtigen Moment fragt. Die native App fragt nicht beim ersten Start; stattdessen zeigst du, nachdem der Nutzer [erste sinnvolle Aktion, z. B. das erste Projekt anlegen] abgeschlossen hat, eine kurze Erklärung in der App, welche Benachrichtigungen er bekommt, mit einem Button 'Aktivieren', der zu registerpush:// navigiert, wenn isNativeApp() true ist, und einer Option 'Jetzt nicht', die wir uns merken. Navigiere im Einstellungs-Screen zu checkNativePushPermissions:// und lies die injizierte Variable nativePushEnabled (kurz pollen, sie wird asynchron gesetzt), um den aktuellen Status anzuzeigen. In Browsern blendest du das Feature komplett aus. Füge keinen Service Worker für Web-Push hinzu.