Claude Code + Login
Zwei Dinge machen Logins in gewrappten Web-Apps kaputt: Google blockiert seine Anmeldeseite in eingebetteten WebViews, und Apple lehnt Apps ab, die Google-Login ohne gleichwertige datenschutzfreundliche Option anbieten. WebViewGold löst das Erste mit seinem Social Login Helper und wickelt Sign-in-with-Apple-Seiten auf iOS automatisch ab; Claude Code kümmert sich um den Web-Teil. Hier ist das Setup, das durchs Review kommt und Nutzer angemeldet hält.
Ab $109 einmalig pro Plattform, oder unser Team erledigt alles ab $698.
Google. Google verweigert OAuth in eingebetteten WebViews und zeigt „Error 403: disallowed_useragent“. Der Reviewer tippt auf den Google-Button, sieht den Fehler, und du bekommst eine Ablehnung nach Richtlinie 2.1 wegen eines kaputten Logins. Der Social Login Helper von WebViewGold behebt das: Du listest URL-Präfixe auf, die während deines Login-Ablaufs auftauchen (google_login_helper_triggers in Config.swift, GOOGLE_LOGIN_HELPER_TRIGGERS in Config.java), und sobald einer davon lädt, öffnet die App den Login in einem eigenen Fenster mit einem User-Agent, den Google akzeptiert, und kehrt danach zu deiner Web-App zurück. Dasselbe gibt es für Facebook. Details: Doku zum Social Login Helper und der disallowed_useragent-Fix.
Apple. Richtlinie 4.8 besagt: Eine App, die für das Hauptkonto einen Drittanbieter- oder Social-Login nutzt, muss auch einen gleichwertigen Login-Dienst anbieten, der die Datenerhebung auf Name und E-Mail beschränkt, Nutzern erlaubt, ihre E-Mail-Adresse privat zu halten, und sie ohne Einwilligung nicht für Werbung trackt. Sign in with Apple erfüllt alle drei Punkte und ist das, was Reviewer erwarten. Auf iOS erkennt WebViewGold appleid.apple.com und wickelt diesen Ablauf automatisch ab, ganz ohne Konfiguration. Hat deine App nur E-Mail und Passwort, greift 4.8 nicht.
Android. Apples Regel gilt nicht für Google Play, und die WebViewGold-Doku beschreibt keine Sonderbehandlung von Apple-Seiten auf Android. Teste den Web-Ablauf in deinem Android-Build; wenn er nicht durchläuft, ist es in Ordnung, den Apple-Button dort auszublenden.
| Bereich | Claude Code | Du |
|---|---|---|
| Web-App | Apple-Provider, gleichwertige Buttons, Callback-Route, Umgang mit dem Namen beim ersten Login, Provider-Flags im Profil, Regel in der CLAUDE.md | Plan und Diff prüfen, deployen |
| Apple Developer Portal und Auth-Dashboard | Schreibt SETUP-APPLE-LOGIN.md mit jedem Feld | Services ID, Key, Return-URL, Provider-Einstellungen, E-Mail-Relay, die Erneuerung des Secrets alle sechs Monate |
| WebViewGold | Listet die URL-Präfixe auf, die der Login-Ablauf durchläuft; ändert Config-Werte nur, wenn die Projekte im Repository liegen | Die Trigger-Listen bestätigen, bauen |
| Tests | Prüft den Web-Ablauf in einem Desktop-Browser | Gerätetests in TestFlight und im internen Test, „E-Mail-Adresse verbergen“ (Hide My Email), der Reviewer-Account |
| Bedarf | iOS (Config.swift) | Android (Config.java) |
|---|---|---|
| Google-Login in der App | google_login_helper_triggers, zum Beispiel accounts.google.com und accounts.youtube.com | GOOGLE_LOGIN_HELPER_TRIGGERS |
| Facebook-Login | facebook_login_helper_triggers | FACEBOOK_LOGIN_HELPER_TRIGGERS |
| Sign in with Apple | Wird automatisch erkannt (appleid.apple.com) | Nicht dokumentiert; Web-Ablauf testen |
| Eine Login-URL ans System übergeben | googlelogin:// + kodierte URL öffnet sie extern (die Session lebt dann in Safari, nicht in der App) | googlelogin:// + kodierte URL öffnet einen Chrome Custom Tab (Doku zum URL-Handling) |
| Die App im eigenen Code erkennen | useragent_iphone, useragent_ipad plus das Token WebViewGoldApp | USER_AGENT plus das Token WebViewGoldApp |
| Sessions behalten | deletecache auf false lassen | CLEAR_CACHE_ON_STARTUP auf false lassen; MANUAL_COOKIE_SYNC, wenn Cookies zu spät ankommen; HOME_URL_LOGOUT für eine Logout-URL |
Großartige Arbeit! Ich habe noch nie etwas programmiert, aber ich konnte damit arbeiten. Einfach und schnell! Auch mit großartiger Hilfe von den Erstellern!
Die meiste Zeit geht ins Apple Developer Portal; der Code ist schnell erledigt.
Aktiviere Sign in with Apple für deine App ID. Lege für den Web-Ablauf eine Services ID an (ihr Identifier wird zur OAuth-Client-ID), füge deine Domain und die Return-URL deines Auth-Providers hinzu (bei Supabase: https://YOUR-PROJECT.supabase.co/auth/v1/callback) und erstelle einen Sign-in-with-Apple-Key (.p8). Notiere dir Team ID und Key ID.
Aktiviere den Apple-Provider mit der Services ID und dem Key. Apples Client Secret ist ein signiertes JWT, das höchstens sechs Monate gültig ist, trag dir also eine Erinnerung zur Erneuerung in den Kalender ein. Füge deine Produktionsdomain zu den erlaubten Redirect-URLs hinzu; entferne Preview- und localhost-Einträge aus dem Produktionsprojekt.
Nutzer können „E-Mail-Adresse verbergen“ wählen. Damit Passwort-Resets und Belege an Adressen unter privaterelay.appleid.com zugestellt werden, registriere deine Absenderdomain oder -adresse im Apple Developer Portal unter Sign in with Apple for Email Communication.
Er ergänzt den Button, die Callback-Verarbeitung und eine Setup-Checkliste und listet die URL-Präfixe auf, die dein Login-Ablauf durchläuft, damit du die Trigger-Listen prüfen kannst.
Trag die Google-Präfixe in google_login_helper_triggers und GOOGLE_LOGIN_HELPER_TRIGGERS ein. Nutzt dein Auth-Provider eine eigene Domain, die zu Google weiterleitet, sind trotzdem die Google-Domains die richtigen Einträge.
TestFlight und interner Test, mit der Checkliste unten. Wenn du Hilfe bei der nativen Seite willst, richtet das Full Service-Team die Apps für dich ein und baut sie.
Wenn du deinen Auth-Provider oder deine Datenbank über einen MCP-Server angebunden hast, kann Claude Code die aktuellen Provider-Einstellungen selbst lesen; sonst schreibt es sie dir in die Checkliste.
Unsere Web-App läuft im Browser und in nativen iOS- und Android-Apps, die mit WebViewGold gebaut sind (der User-Agent enthält WebViewGoldApp). Wir bieten Google-Login an, deshalb verlangt Apple-Richtlinie 4.8 in der iOS-App einen gleichwertigen, datenschutzfreundlichen Login; wir ergänzen Sign in with Apple. Der native Wrapper kümmert sich bereits um die WebView-Seite: Google-Login-Seiten werden vom WebViewGold Social Login Helper geöffnet (Trigger-URL-Präfixe in Config.swift und Config.java), und auf iOS wird appleid.apple.com automatisch erkannt und abgewickelt. Füge keinen nativen Code und keine URL-Schemata für den Login hinzu. Erstelle zuerst einen Plan und implementiere nach meiner Freigabe: 1. Erkenne unsere Auth-Bibliothek (Supabase Auth, Firebase Auth, Auth.js oder Clerk) und ergänze ihren Apple-Provider für den Web-Ablauf mit unserer Produktions-Callback-URL. Keine Preview- oder localhost-Redirects. 2. Login- und Registrierungs-Screens: Sign in with Apple und Continue with Google (bzw. die offiziellen Übersetzungen in der Sprache der App) als gleichwertige Optionen mit derselben Größe und Position. Gestalte den Apple-Button nach Apples Vorgaben (schwarz oder weiß, mit dem offiziellen Text Sign in with Apple). Der Login per E-Mail und Passwort bleibt, weil der Demo-Account für das App-Review ihn nutzt. 3. Apple teilt den Namen des Nutzers nur bei der ersten Autorisierung. Wenn unsere Auth-Bibliothek ihn nicht speichert, frag im Onboarding nach einem Anzeigenamen, falls er fehlt. 4. Nutzer können „E-Mail-Adresse verbergen“ (Hide My Email) wählen. Stell sicher, dass transaktionale E-Mails an Adressen unter privaterelay.appleid.com funktionieren. 5. Speichere im Profil, mit welchen Providern sich ein Nutzer angemeldet hat, damit die Kontolöschung später Apple-Tokens widerrufen kann. Wenn die Auth-Bibliothek das Apple-Refresh-Token bei der Anmeldung herausgibt, speichere es serverseitig und verschlüsselt. 6. Liste jedes URL-Präfix auf, das der Google- und der Apple-Ablauf auf unserer Domain und den Provider-Domains durchlaufen (nutze den Playwright-MCP-Server, wenn er verbunden ist, sonst die Doku der Auth-Bibliothek), damit ich sie mit google_login_helper_triggers und GOOGLE_LOGIN_HELPER_TRIGGERS vergleichen kann. 7. Schreibe SETUP-APPLE-LOGIN.md: die Schritte im Apple Developer Portal (App ID mit Sign in with Apple, Services ID mit Domain und Return-URL, Key), die Felder in unserem Auth-Dashboard, die Allowlist der Redirect-URLs, die Registrierung für das E-Mail-Relay und einen Hinweis, dass das Apple Client Secret nach spätestens sechs Monaten abläuft. 8. Ergänze eine Regel in der CLAUDE.md: Sign in with Apple bleibt genauso prominent wie jeder andere Drittanbieter-Login und darf bei Refactorings nicht entfernt werden. Berichte die geänderten Dateien und alle offenen Fragen.
Ein Supabase-Beispiel in einer Next.js-Client-Komponente. Entscheidend sind die Gleichbehandlung beider Provider und ein einziger Produktions-Redirect; der Agent passt das an deine Auth-Bibliothek an.
// components/social-login.tsx
"use client";
import { createClient } from "@/lib/supabase/client";
// Nur der Produktions-Callback; muss in der Redirect-URL-Allowlist von Supabase stehen
const REDIRECT_TO = "https://app.example.com/auth/callback";
export function SocialLogin() {
const supabase = createClient();
const signIn = (provider: "apple" | "google") =>
supabase.auth.signInWithOAuth({ provider, options: { redirectTo: REDIRECT_TO } });
return (
<div className="flex flex-col gap-3">
{/* Gleiche Höhe, Breite und Position für beide: Richtlinie 4.8 heißt gleichwertig, nicht versteckt */}
<button
type="button"
onClick={() => signIn("apple")}
className="h-12 w-full rounded-lg bg-black text-white font-medium"
>
Sign in with Apple
</button>
<button
type="button"
onClick={() => signIn("google")}
className="h-12 w-full rounded-lg border border-gray-300 bg-white text-gray-900 font-medium"
>
Continue with Google
</button>
</div>
);
}
// app/auth/callback/route.ts tauscht den Code gegen eine Session (supabase.auth.exchangeCodeForSession)
// und leitet zur Seite weiter, von der der Nutzer kam. In der App kehrt das WebViewGold-Login-Fenster
// zu dieser URL zurück, die Session landet also in der App, nicht in Safari oder Chrome.deletecache und die Cookie-Einstellungen, bevor du deinen Code anfasst.Nein. Richtlinie 4.8 greift, wenn ein Drittanbieter- oder Social-Login das Hauptkonto anlegt oder authentifiziert. E-Mail und Passwort allein lösen sie nicht aus.
Apples Formulierung erlaubt jeden Login-Dienst mit den genannten Datenschutzeigenschaften. In der Praxis ist Sign in with Apple die Option, die Reviewer sofort erkennen, und die, die sich mit dem geringsten Aufwand verteidigen lässt.
Google erkennt eingebettete WebViews und blockiert sie mit disallowed_useragent. Der Social Login Helper öffnet diese Seiten in einem Kontext, den Google akzeptiert, und kehrt danach zu deiner App zurück.
Dort ist es optional. Es überall anzuzeigen ist konsistent für Nutzer, die das Gerät wechseln; blende es auf Android nur aus, wenn der Web-Ablauf in deinem Test-Build nicht durchläuft.
Nein. Es schreibt die Checkliste und den Code und kann Werte in Config.swift und Config.java bearbeiten, wenn die Projekte im Repository liegen. Portal-Einstellungen, Keys und Signierung bleiben bei dir.
Gleiches Ergebnis, unterschiedlich viel Arbeit auf deiner Seite. Alle drei kommen mit Genehmigungsgarantie und 24/7 Support von echten Menschen.
$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$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 ausprobieren$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.
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.