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

ChatGPT & Codex

Kontolöschung für Supabase- und Firebase-Apps, mit Codex kartiert und gebaut

Beide Stores lehnen Apps ab, bei denen man sich registrieren, aber nicht wieder gehen kann. Das Feature wirkt klein, aber eine korrekte Löschung berührt Auth, jede Collection oder Tabelle, den Dateispeicher, Abos und das Token von Sign in with Apple. Genau diese Art von querschnittlicher Änderung erledigt Codex gut, sobald es eine Bestandsaufnahme hat. Hier ist ein Workflow in zwei Durchgängen: Codex kartiert die Daten in einer schreibgeschützten Session und implementiert danach die Löschung mit Tests.

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 die Stores verlangen und was ein Reviewer anklickt

Apple (Richtlinie 5.1.1(v)): Wenn die App das Anlegen eines Kontos unterstützt, müssen Nutzer die Kontolöschung in der App starten können, und Löschung heißt: das Konto und seine Daten, kein Deaktivierungs-Flag. Ein Bestätigungsschritt ist in Ordnung. Wenn sich Nutzer mit Apple anmelden können, erwartet Apple, dass du ihre Tokens bei der Löschung über die REST-API von Sign in with Apple widerrufst. Google Play: ein Weg in der App plus eine Webseite, auf der Nutzer die Löschung beantragen können, ohne die App neu zu installieren. Deren URL trägst du im Abschnitt Datensicherheit (Data safety) der Play Console ein.

Was der Reviewer tatsächlich tut: Er registriert sich oder nutzt deinen Demo-Account, öffnet die Einstellungen, sucht nach "Konto löschen" und zieht es manchmal auch durch. Bei Google Play wird zusätzlich der Web-Link geöffnet; verlangt er einen Login oder liefert er einen 404, ist das eine Ablehnung (die Play-Ablehnung erklärt).

Warum zwei Durchgänge mit Codex: Eine Löschung scheitert lautlos. Eine vergessene Collection oder ein vergessener Storage-Ordner wirft keinen Fehler, sie bleiben einfach liegen. Erst die Daten zu kartieren und dann Code zu schreiben, macht das Ergebnis vollständig. Die Beispiele nutzen React, Express, Firebase Auth, Firestore und Cloud Storage; die Supabase-Entsprechungen stehen in der Tabelle. Der Guide zur Pflicht zur Kontolöschung behandelt dieselben Regeln für Builder ohne Coding-Agent, und der Helper isNativeApp() stammt aus dem AGENTS.md-Template.

Durchgang 1: die Daten in einer schreibgeschützten Session kartieren

Die Sandbox read-only lässt Codex Dateien lesen und harmlose Befehle wie rg ausführen, aber nichts ändern. Das hält den ersten Durchgang ehrlich: Er kann nur hinschauen.

bash
# Durchgang 1: nur Bestandsaufnahme. Codex kann lesen, suchen und antworten, aber nichts bearbeiten.
cd my-app
codex --sandbox read-only --ask-for-approval on-request

# Füge das in die Session ein:
#   Lies AGENTS.md. Finde jede Stelle, an der diese Codebasis Daten über einen
#   Nutzer speichert oder versendet: Auth-Provider, Firestore-Collections und
#   Subcollections (und das Feld, das jedes Dokument mit dem Nutzer verknüpft),
#   Cloud-Storage-Pfade, Server-Logs, Drittanbieter, die Nutzerdaten erhalten
#   (RevenueCat, Stripe, OneSignal, E-Mail, Analytics, Error-Tracking) und was
#   die Web-App auf dem Gerät ablegt (Cookies, localStorage, IndexedDB, Werte,
#   die mit writevalue:// geschrieben wurden).
#   Gib eine Markdown-Tabelle aus: Ort | Verknüpfung zum Nutzer | löschen oder behalten | Grund.
#   Markiere alles, bei dem du unsicher bist. Schlag noch keinen Code vor.

# Wenn die Tabelle stimmt, wechsle in der Session mit /permissions auf
# Schreibzugriff und bitte Codex, sie als docs/user-data-map.md zu speichern. Committe sie.

Was eine vollständige Löschung abdeckt

OrtFirebase (Express-API)Supabase
Auth-NutzergetAuth().deleteUser(uid) mit firebase-admin, als letzter Schrittsupabase.auth.admin.deleteUser(id) in einer Edge Function mit dem Service-Role-Key, als letzter Schritt
DatenbankrecursiveDelete() für das Nutzerdokument und seine Subcollections, plus Abfragen auf Besitzer-FelderFremdschlüssel auf auth.users mit on delete cascade oder explizite Löschungen vor dem Auth-Aufruf
DateiengetStorage().bucket().deleteFiles({ prefix: "users/UID/" })Den Ordner des Nutzers auflisten, dann storage.from(bucket).remove(paths)
Sign in with ApplerevokeAccessToken(auth, token), nachdem sich der Nutzer erneut mit Apple authentifiziert hat; Firebase speichert keine Apple-TokensNicht automatisch. Apples Widerrufs-Endpoint braucht ein Token aus dem Login; lass Codex prüfen, was dein Ablauf bereitstellt, und die Lücke markieren
Store-AbosDu kannst sie nicht für den Nutzer kündigen. Sag das im Dialog und biete cancelinapppurchase:// an; optional den RevenueCat-Kunden serverseitig löschenGenauso
Push, E-Mail, AnalyticsDie Einträge der Push-Geräte löschen, den Kontakt aus deinem E-Mail-Tool entfernen, die Lösch-API jedes Anbieters nutzenGenauso
Das Gerätreset:// lässt WebViewGold Cookies und Cache löschen; überschreibe alles, was mit writevalue:// gespeichert wurde, denn das übersteht das Leeren des CachesGenauso

WebViewGold hat uns die kürzeste und effizienteste Time-to-Market ermöglicht, die jemals möglich war, verglichen mit allen anderen App-Plattformen, die wir in den letzten 5 Jahren ausprobiert haben. Ich weiß nicht, warum ich euch nicht schon früher entdeckt habe, aber ich bin wirklich, wirklich froh, dass ich es getan habe. Wir nähern uns derzeit fast 6000 App-Downloads im iOS App Store & Google Play Store ohne Probleme!

Antonio Davila · CodeCanyon

Durchgang 2: der Implementierungs-Prompt

Starte eine frische Session mit codex --sandbox workspace-write --ask-for-approval on-request, damit die Datenkarte die maßgebliche Quelle ist und nicht das vorherige Gespräch. Für Supabase ersetzt du Schritt 3 durch eine Edge Function, die das JWT prüft, Storage-Objekte entfernt, sich auf kaskadierende Fremdschlüssel verlässt und auth.admin.deleteUser aufruft.

In Codex einfügen (workspace-write, Freigaben auf Anfrage)
Lies AGENTS.md und docs/user-data-map.md. Implementiere eine Kontolöschung, die App-Store-Richtlinie 5.1.1(v) und Google Plays Richtlinie zur Kontolöschung erfüllt. Stack: React-Frontend, Express-API, Firebase Auth, Firestore, Cloud Storage. Diese Web-App läuft auch in nativen iOS- und Android-Apps, die mit WebViewGold gebaut sind; nutze isNativeApp() für Verhalten, das nur in der App gilt.

1. Einstellungen > Konto > Konto löschen. Ein Bestätigungs-Sheet erklärt, was gelöscht wird, was wir wie lange aufbewahren (laut Datenkarte) und dass Store-Abos von Apple oder Google abgerechnet werden, bis sie gekündigt sind. Hat der Nutzer ein aktives Store-Abo und ist isNativeApp() true, zeige einen Button "Abo verwalten", der zu cancelinapppurchase:// navigiert.
2. Kürzlicher Login: Antwortet der Server mit recent-login-required, authentifiziere erneut. Nutzer mit dem Provider apple.com authentifizierst du immer erneut mit OAuthProvider("apple.com"), liest das Access Token mit OAuthProvider.credentialFromResult und rufst vor dem Server-Aufruf revokeAccessToken(auth, token) auf.
3. DELETE /api/account in Express: Prüfe das ID-Token mit checkRevoked, verlange auth_time innerhalb der letzten 5 Minuten und lösche dann in dieser Reihenfolge: Storage-Dateien unter users/{uid}/, jeden Firestore-Ort aus der Datenkarte (recursiveDelete für Subcollections, inklusive pushDevices), den Stripe-Kunden und, wenn die Datenkarte es vorsieht, den RevenueCat-Kunden (hinter einem Feature-Flag, Secret aus der Umgebung) und zuletzt den Auth-Nutzer. Jeder Schritt muss gefahrlos wiederholbar sein, falls der Request auf halbem Weg scheitert.
4. Nach Erfolg: abmelden, und wenn isNativeApp() true ist, zu reset:// navigieren, damit WebViewGold Cookies und Cache löscht; im Browser localStorage leeren. Dann einen Abschieds-Screen zeigen.
5. Öffentliche Seite /delete-account, die ohne Login funktioniert: Sie erklärt die Schritte in der App und bietet ein Antragsformular (E-Mail-Adresse) für Leute, die die App nicht mehr haben. Anträge landen in einer Collection deletionRequests und lösen eine E-Mail an [Support-Adresse] aus.
6. Ergänze /privacy um einen kurzen Abschnitt zu Löschung und Aufbewahrung.
7. Tests: Nutze die Firebase-Emulatoren, falls das Projekt sie schon verwendet, sonst Mocks. Die Löschung entfernt jeden Ort aus der Datenkarte, ein zweiter Aufruf bewirkt nichts, und ein veraltetes Token wird abgewiesen.
Melde die geänderten Dateien, die URL für die Play Console und was ich konfigurieren muss.

Der Code, nach dem du im Diff suchst

Zwei Dateien tragen die Logik. Die Reihenfolge auf dem Server zählt: erst die Daten, zuletzt der Auth-Nutzer, damit ein gescheiterter Request einfach wiederholt werden kann. Der Client übernimmt den Apple-Widerruf, weil Firebase keine Apple-Tokens aufbewahrt und sich der Nutzer ohnehin erneut authentifizieren muss.

javascript
// server/routes/account.js (Express + firebase-admin)
import express from "express";
import { getAuth } from "firebase-admin/auth";
import { getFirestore } from "firebase-admin/firestore";
import { getStorage } from "firebase-admin/storage";

export const accountRouter = express.Router();
const OWNED = [["projects", "ownerId"], ["comments", "authorId"], ["pushDevices", "uid"]]; // from docs/user-data-map.md

accountRouter.delete("/api/account", async (req, res) => {
  const idToken = (req.get("Authorization") || "").replace(/^Bearer /, "");
  let user;
  try {
    user = await getAuth().verifyIdToken(idToken, true); // true = reject revoked tokens
  } catch {
    return res.status(401).json({ error: "unauthenticated" });
  }
  if (Date.now() / 1000 - user.auth_time > 300) {
    return res.status(403).json({ error: "recent-login-required" });
  }
  const uid = user.uid;
  const db = getFirestore();

  await getStorage().bucket().deleteFiles({ prefix: "users/" + uid + "/" });
  for (const [name, field] of OWNED) {
    const owned = await db.collection(name).where(field, "==", uid).get();
    for (const doc of owned.docs) await db.recursiveDelete(doc.ref);
  }
  await db.recursiveDelete(db.collection("users").doc(uid));
  await getAuth().deleteUser(uid); // last: everything above is safe to re-run
  res.status(204).end();
});

// src/lib/deleteAccount.js (client, Firebase JS SDK)
import { OAuthProvider, reauthenticateWithPopup, revokeAccessToken } from "firebase/auth";
import { isNativeApp } from "./platform";

export async function deleteAccount(auth) {
  const user = auth.currentUser;
  if (user.providerData.some((p) => p.providerId === "apple.com")) {
    const result = await reauthenticateWithPopup(user, new OAuthProvider("apple.com"));
    const credential = OAuthProvider.credentialFromResult(result);
    await revokeAccessToken(auth, credential.accessToken); // Apple 5.1.1(v)
  }
  const res = await fetch("/api/account", {
    method: "DELETE",
    headers: { Authorization: "Bearer " + (await user.getIdToken(true)) }
  });
  if (res.status === 403) throw new Error("recent-login-required");
  if (!res.ok) throw new Error("delete-failed");
  await auth.signOut();
  if (isNativeApp()) window.location.href = "reset://"; // WebViewGold clears cookies and cache
}

Der Workflow von Anfang bis Ende

  1. Kartieren

    Führe Durchgang 1 in der schreibgeschützten Sandbox aus, korrigiere die Tabelle selbst (Codex kann nicht wissen, welche Daten du aus steuerlichen oder rechtlichen Gründen behalten musst) und committe docs/user-data-map.md.

  2. Bauen

    Führe Durchgang 2 in einer frischen Session aus. Fordere /review an, bevor du die Änderungen übernimmst, und lies die Server-Route Zeile für Zeile gegen die Datenkarte.

  3. Konfigurieren

    Trage die öffentliche URL /delete-account im Abschnitt Datensicherheit der Play Console ein. Erwähne Löschung und Aufbewahrung in deiner Datenschutzerklärung (was die Erklärung braucht).

  4. Verifizieren

    Arbeite die Checkliste unten mit einem Wegwerf-Konto auf einem TestFlight-Build und einem internen Test-Build ab.

  5. Den Demo-Account schützen

    Reviewer löschen ihn womöglich. Leg ihn vor jeder Einreichung neu an und schreib in die Review-Notizen, dass sie gern ein frisches Konto anlegen dürfen, um die Löschung zu testen. Mehr zum Release-Weg im Codex-Workflow-Guide.

Prüf es so, wie ein Reviewer es tun würde

  • Ein Testkonto mit Daten an jedem Ort aus der Datenkarte (ein Projekt, ein Kommentar, eine hochgeladene Datei, ein Push-Gerät).
  • In der App löschen: Der Nutzer ist aus Firebase Authentication verschwunden, und kein Firestore-Dokument und keine Storage-Datei dieses Nutzers bleibt übrig.
  • Ein Testnutzer mit Sign in with Apple sieht deine App nach der Löschung nicht mehr unter den Apps mit "Mit Apple anmelden" in den Einstellungen seines Apple-Accounts.
  • Die App kehrt in einen sauberen ausgeloggten Zustand zurück; erneutes Öffnen stellt die alte Session nicht wieder her.
  • Die Seite /delete-account öffnet sich ohne Login in einem privaten Browserfenster, und das Antragsformular kommt an.
  • Die Lösch-Route zweimal aufzurufen oder nach einem simulierten Fehler auf halbem Weg endet im selben sauberen Zustand.

Stolperfallen

  • Deaktivieren statt löschen. Ein Flag deleted: true ist keine Löschung im Sinne von 5.1.1(v).
  • Löschungen im Client über Security Rules. Die sind konstruktionsbedingt unvollständig (keine Admin-Rechte, kein Auth-Nutzer, keine Referenzen anderer Nutzer); erledige das auf dem Server.
  • Den Auth-Nutzer zuerst löschen. Scheitert der Request danach, bleiben die Daten verwaist zurück, und niemand kann sich mehr authentifizieren, um die Arbeit abzuschließen.
  • Popups in der App. Wenn sich reauthenticateWithPopup in der WebView danebenbenimmt, nutze reauthenticateWithRedirect und lies das Ergebnis mit getRedirectResult.
  • Abos vergessen. Das Löschen des Kontos stoppt die Abrechnung im App Store oder bei Google Play nicht; sag das dem Nutzer, bevor er bestätigt.
  • Eine Seite /delete-account hinter einem Login oder ein Service-Role-Key im Client-Code bei Supabase. Beides fällt schnell auf.

Häufig gestellte Fragen

Ist eine Karenzzeit erlaubt?

Ja. Du kannst die endgültige Löschung für einen kurzen Zeitraum später einplanen (zum Beispiel 14 Tage), wenn du das in der Bestätigung und in der Datenschutzerklärung sagst, und den Nutzer durch erneutes Anmelden abbrechen lassen. Die Löschung selbst muss trotzdem stattfinden.

Kann ich stattdessen die Firebase-Extension Delete User Data nutzen?

Sie ist eine gute Basis: Sie löscht konfigurierte Firestore-Pfade und Storage-Dateien, wenn der Auth-Nutzer gelöscht wird. Du brauchst trotzdem den Button in der App, den Widerruf des Apple-Tokens, die öffentliche Antragsseite und eine Prüfung, ob ihre Konfiguration zu deiner Datenkarte passt.

Muss die Antragsseite im Web automatisch löschen?

Nein. Google Play verlangt eine Möglichkeit, die Löschung außerhalb der App zu beantragen. Ein Formular, das einen Antrag erzeugt, den du dann bearbeitest, ist in Ordnung, solange du ihn tatsächlich in der angegebenen Zeit bearbeitest.

Muss ich auch Daten in RevenueCat und Stripe löschen?

Lösche oder anonymisiere, was du nicht aufbewahren musst. Für Zahlungsdaten können gesetzliche Aufbewahrungsfristen gelten; liste in der Datenschutzerklärung auf, was du behältst und warum. Store-Abos zu kündigen bleibt Sache des Nutzers.

Soll Codex dafür Zugriff auf meine Produktionsdatenbank bekommen?

Nein. Codex schreibt den Code und die Tests gegen Emulatoren oder Mocks; die Löschung in der Produktion führst du über die deployte Route aus. Halte Produktions-Zugangsdaten aus Agenten-Sessions und Cloud-Umgebungen heraus.

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.