Ein Auth-Guard um alles
Gerüste aus Lovable, Bolt und v0 packen oft den ganzen Router in eine geschützte Route, sodass der erste Screen der App ein Login-Formular ist.
Was 5.1.1(v) sagt
Der Teil von Guideline 5.1.1 zur Account-Anmeldung besagt, dass eine App ohne wesentliche Account-basierte Funktionen Menschen die Nutzung ohne Login ermöglichen soll. Apps dürfen keine persönlichen Daten verlangen, um zu funktionieren, es sei denn, diese sind für die Kernfunktion direkt relevant oder gesetzlich vorgeschrieben. Apps, die das Anlegen eines Accounts unterstützen, müssen die Account-Löschung in der App anbieten. Und wenn die Kernfunktion nicht an ein bestimmtes soziales Netzwerk gebunden ist, müssen Menschen die App nutzen können, ohne sich bei einem einzuloggen; Profildaten abrufen, Teilen und Freunde einladen zählen nicht als Kernfunktionen.
Die übrigen Teile von 5.1.1 (Datenschutzerklärung, Zwecktexte, Datensparsamkeit) behandelt der Datenschutz-Guide zu 5.1.1. Auf dieser Seite geht es um die Login-Wand.
Was in der Ablehnungsnachricht meist steht
Die Nachricht sagt meist, dass die App von Nutzern verlangt, sich zu registrieren oder einzuloggen, bevor sie auf Funktionen zugreifen können, die nicht Account-basiert sind, und schlägt vor, diese Funktionen frei nutzbar zu machen und eine Registrierung nur für Account-spezifische Funktionen zu verlangen. Eine häufige Variante sagt, dass die App persönliche Daten wie Telefonnummer, Geburtstag oder Geschlecht verlangt, die ihre Kernfunktion nicht braucht. Eine weitere Variante betrifft Käufe: Die App erzwingt eine Registrierung, bevor man In-App-Käufe tätigen kann, die nicht Account-basiert sind.
Welche Funktionen hinter einem Login liegen dürfen
| Funktion | Account-basiert? | Hinter einem Login? |
|---|---|---|
| Einen Katalog durchstöbern, Artikel lesen, Rezepte ansehen | Nein | Nein, mach es öffentlich |
| Rechner, Umrechner, Generatoren, eine begrenzte kostenlose KI-Demo | Nein | Nein, oder eine Gast-Session |
| Favoriten, Verlauf, Synchronisierung zwischen Geräten | Ja | Ja; frag, wenn der Nutzer etwas speichert |
| Posten, Chatten, anderen Nutzern folgen | Ja | Ja |
| Bestellungen, Buchungen, Rechnungen, Team-Workspaces | Ja | Ja |
| Eine App für bestehende Mitglieder, Mitarbeitende oder Kunden eines Dienstes | Ja, der Account ist der Kern | Ja; erkläre es in den Review-Notizen und stelle einen Demo-Account bereit |
| Ein Abo, das auch im Web funktioniert | Ja, plattformübergreifend | Ja; schreib es in die Review-Notizen |
Mein iOS WebView wurde endlich genehmigt. Danke!!
Warum KI-gebaute Apps an der Login-Wand scheitern
Start-URL auf /login oder /dashboard
Die Marketingseite ist der öffentliche Teil deiner Website, also setzen viele webviewurl auf den App-Bereich, der direkt zum Login umleitet.
Registrierungsformulare, die zu viel fragen
Felder für Telefon, Geburtstag, Geschlecht und Firma, "sicherheitshalber" generiert, sind persönliche Daten, die die Kernfunktion nicht braucht.
Nur Social Login
Gibt es nur "Mit Google fortfahren", kommt ohne Social-Account niemand hinein. Ergänze E-Mail-Login oder Sign in with Apple und denk über einen Gastzugang nach.
Ergänze einen Gastzugang, ohne deine App neu zu bauen
Markiere jede Funktion als öffentlich oder nur mit Account
Geh jeden Screen durch. Meist sind Entdecken und Lesen öffentlich; Speichern, Posten, an den Account gebundene Käufe und persönliche Daten gibt es nur mit Account.
Richte die App auf eine öffentliche Startseite
Setze
webviewurlin Config.swift auf eine Seite, die ohne Login funktioniert, etwayourdomain.com/appoder/explore, nicht/login. Eine Änderung braucht einen neuen Build.Verschiebe den Auth-Guard auf die Account-Routen
Öffentliche Routen rendern für alle; nur Account-Routen leiten zum Login um (Code unten). Platziere "Anmelden" im Header oder beim ersten Speichern, nicht vor dem Inhalt.
Nutze anonyme Sessions, wo Gäste einen Zustand brauchen
Sollen Gäste Fortschritt speichern können, nutze Anonymous Sign-ins von Supabase, Anonymous Auth von Firebase oder Local Storage und wandle den Gast bei der Registrierung in einen vollen Account um, damit nichts verloren geht. Schütze anonyme Registrierungen mit einem Captcha und Row-Level Security; die Supabase-Checkliste listet die Einstellungen auf.
Kürze das Registrierungsformular
E-Mail und Passwort (oder Sign in with Apple), plus ein Name, falls du ihn wirklich brauchst. Frag alles andere später ab, wenn eine Funktion es braucht, und kennzeichne optionale Felder als optional.
Behalte Löschung und Demo-Account
Wer Account-Erstellung anbietet, muss weiterhin die Löschung in der App anbieten (Guide zur Account-Löschung), und Account-Funktionen brauchen fürs Review weiterhin einen Demo-Account (Demo-Account-Guide). Lass
deletecacheauf false, damit eingeloggte Nutzer eingeloggt bleiben.
Erst öffentliche Routen, Login nur dort, wo es zählt
Beispiel mit React Router, wie es die meisten KI-Builder erzeugen, plus eine Supabase-Gast-Session zum Speichern.
javascript
// Vorher (typisches KI-Gerüst): jede Route hinter <RequireAuth />
// <Route element={<RequireAuth />}> ...alle Routen... </Route>
// Nachher: öffentliches Entdecken, Account-Funktionen hinter dem Guard
<Routes>
<Route path="/" element={<Explore />} /> {/* kein Account nötig */}
<Route path="/recipes/:id" element={<Recipe />} /> {/* kein Account nötig */}
<Route path="/login" element={<Login />} />
<Route element={<RequireAuth />}>
<Route path="/favorites" element={<Favorites />} /> {/* Account-basiert */}
<Route path="/settings/account" element={<Account />} />
</Route>
</Routes>
// Ein Gast tippt auf "Speichern": anonyme Session starten, später upgraden
async function saveAsGuest(recipeId) {
const { data } = await supabase.auth.getSession();
if (!data.session) await supabase.auth.signInAnonymously();
await supabase.from("favorites").insert({ recipe_id: recipeId }); // user_id ist standardmäßig auth.uid()
showBanner("Gespeichert. Leg einen kostenlosen Account an, um deine Favoriten auf allen Geräten zu behalten.");
}
// Später upgraden: supabase.auth.updateUser({ email }) macht aus dem anonymen Nutzer einen dauerhaftenPrompt: Öffne die App für Gäste
Lass die KI die Umstrukturierung übernehmen, aber prüfe ihre Liste der öffentlichen und der Account-Routen, bevor sie Code ändert.
Prompt für Lovable, Bolt, v0, Cursor oder Claude Code
Strukturiere die Authentifizierung für App Store Guideline 5.1.1(v) um. 1) Liste jede Route auf und ordne sie als öffentlich (funktioniert ohne Account) oder nur mit Account (Speichern, Posten, an den Account gebundene Käufe, persönliche Daten) ein. Zeig mir die Liste, bevor du Code änderst. 2) Entferne den globalen Auth-Guard und wende ihn nur auf Routen an, die einen Account brauchen. 3) Mach / zu einer öffentlichen Startseite, die den Kerninhalt ohne Login zeigt. 4) Wenn ein Gast eine Aktion versucht, die einen Account braucht, zeig ein freundliches Sheet: "Leg einen kostenlosen Account an, um das zu speichern", mit Sign in with Apple, E-Mail-Registrierung und einer Option "Jetzt nicht". 5) Nutze Supabase Anonymous Sign-in für Gäste, die einen Zustand speichern müssen, und wandle sie bei der Registrierung ohne Datenverlust in einen dauerhaften Account um. Lass Row-Level Security auf allen Tabellen aktiv. 6) Reduziere das Registrierungsformular auf E-Mail, Passwort und einen optionalen Namen. Entferne Telefon, Geburtstag und Geschlecht, sofern keine Funktion sie braucht. 7) Behalte den bestehenden Ablauf "Account löschen" in den Einstellungen.
Antwortvorlage für das Resolution Center
Option A, wenn du die App geöffnet hast; Option B, wenn der Login wirklich unverzichtbar ist. Sei in beiden Fällen konkret. Die Vorlage bleibt auf Englisch, weil App Review Englisch liest.
Antwort im Resolution Center (wähle Option A oder B)
Hello App Review team, Thank you for reviewing [App name] [version] ([build]). [Option A: guest access added] Users can now [browse / read / use the calculator] without an account. The app opens on [Explore], and an account is requested only when a user wants to [save favorites / post / sync across devices], which are account-based features. Sign-up now asks only for email and password, or Sign in with Apple. [New build: [number].] [Option B: login is essential] [App name] is a [client portal / team workspace] for [existing customers of X / members of Y]. Every feature works on the user's own account data: [list the main features]. There is no content that could be shown without an account. Accounts are created [at sign-up in the app / by the customer's organization]. A demo account is provided in App Review Information. Account deletion is available in [Settings > Account > Delete account]. Best regards, [Name], [email]
Checkliste
- Ein neuer Nutzer erreicht jede Funktion ohne Account-Bezug, ohne sich zu registrieren.
webviewurlzeigt auf eine öffentliche Seite, nicht auf den Login-Screen.- Die Login-Aufforderung erscheint bei der ersten Account-Aktion, mit einer Möglichkeit, abzulehnen.
- Das Registrierungsformular fragt nur ab, was der Account braucht.
- Social Login ist nicht der einzige Weg hinein.
- Account-Löschung in der App und ein funktionierender Demo-Account sind vorhanden.
Häufig gestellte Fragen
Meine App ist ein Dashboard für zahlende Kunden. Brauche ich einen Gastmodus?
Nicht, wenn jede Funktion mit den eigenen Account-Daten des Kunden arbeitet. Erkläre das in den Review-Notizen und stelle einen Demo-Account bereit. Eine öffentliche Seite, die Noch-nicht-Kunden zeigt, was die App kann, ist ein schönes Extra.
Muss "Als Gast fortfahren" auf dem ersten Screen stehen?
Es gibt keine feste Platzierung. Entscheidend ist, dass ein neuer Nutzer die Funktionen ohne Account-Bezug erreicht, ohne sich zu registrieren. Eine öffentliche Startseite mit einem "Anmelden"-Button im Header ist meist die sauberste Lösung.
Darf ich vor einem In-App-Kauf einen Account verlangen?
Wenn der Kauf an den Account gebunden ist, etwa ein Abo, das auch die Webversion freischaltet, ja; schreib das in die Review-Notizen. Bei Käufen, die nur auf dem Gerät funktionieren, erwarten Reviewer, dass die Registrierung optional ist.
Ist ein reiner Google-Login ein 5.1.1(v)-Problem?
Das kann er sein: Wenn deine Kernfunktion nichts mit Google zu tun hat, müssen Menschen die App ohne Google-Login nutzen können. Gastzugang oder E-Mail-Login lösen das, und Guideline 4.8 verlangt zusätzlich Sign in with Apple oder eine ähnliche Option neben Google.
Brauchen Gastnutzer eine Account-Löschung?
Die Löschpflicht gilt für Accounts, die Nutzer anlegen. Für anonyme Sessions ist eine Option "Meine Daten löschen" in den Einstellungen gute Praxis, und sobald ein Gast zu einem vollen Account wechselt, gilt der normale Ablauf "Account löschen".
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 ansehenCloud Builder
$349 pro Lizenz, einmaliges Add-on
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.
So funktioniert der Cloud Builder Kostenlose Demo ausprobierenFull 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
Winter-Sale-Preise gültig bis 31. Dezember 2026.