Claude Code + login
Hay dos cosas que rompen el inicio de sesión en las apps web envueltas: Google bloquea su página de acceso dentro de los WebViews integrados, y Apple rechaza las apps que ofrecen login con Google sin una opción equivalente que proteja la privacidad. WebViewGold resuelve lo primero con su Social Login Helper y gestiona automáticamente en iOS las páginas de Sign in with Apple; Claude Code se ocupa de la parte web. Esta es la configuración que pasa la revisión y mantiene a los usuarios con la sesión iniciada.
Desde $109 de pago único por plataforma, o deja que nuestro equipo lo haga todo desde $698.
Google. Google rechaza OAuth dentro de los WebViews integrados y muestra "Error 403: disallowed_useragent". El revisor toca Continuar con Google, ve el error y recibes un rechazo por la directriz 2.1 por un login roto. El Social Login Helper de WebViewGold lo soluciona: enumeras los prefijos de URL que aparecen durante tu flujo de login (google_login_helper_triggers en Config.swift, GOOGLE_LOGIN_HELPER_TRIGGERS en Config.java) y, cuando se carga uno de ellos, la app abre el login en una ventana dedicada con un user agent que Google acepta y después vuelve a tu app web. Lo mismo existe para Facebook. Detalles: documentación del Social Login Helper y la solución para disallowed_useragent.
Apple. La directriz 4.8 dice que una app que usa un login de terceros o social para la cuenta principal también debe ofrecer un servicio de login equivalente que limite la recogida de datos al nombre y al correo electrónico, permita a los usuarios mantener su correo en privado y no los rastree con fines publicitarios sin su consentimiento. Sign in with Apple cumple las tres condiciones y es lo que esperan los revisores. En iOS, WebViewGold detecta appleid.apple.com y gestiona ese flujo automáticamente, sin ninguna configuración. Si tu app solo tiene correo electrónico y contraseña, la 4.8 no se aplica.
Android. La regla de Apple no se aplica a Google Play, y la documentación de WebViewGold no describe ningún tratamiento especial para las páginas de Apple en Android. Prueba el flujo web en tu compilación de Android; si no se completa, es aceptable ocultar allí el botón de Apple.
| Área | Claude Code | Tú |
|---|---|---|
| App web | Proveedor de Apple, botones equivalentes, ruta de callback, gestión del nombre en el primer login, proveedores registrados en el perfil, regla en CLAUDE.md | Revisar el plan y el diff, desplegar |
| Portal de Apple Developer y panel de autenticación | Escribe SETUP-APPLE-LOGIN.md con todos los campos | Services ID, clave, URL de retorno, ajustes del proveedor, relay de correo, la renovación del secreto cada seis meses |
| WebViewGold | Enumera los prefijos de URL por los que pasa el flujo de login; edita los valores de Config solo si los proyectos están en el repositorio | Confirmar las listas de activadores, compilar |
| Pruebas | Comprueba el flujo web en un navegador de escritorio | Pruebas en dispositivos con TestFlight y pruebas internas, Ocultar mi correo, la cuenta para el revisor |
| Necesidad | iOS (Config.swift) | Android (Config.java) |
|---|---|---|
| Login de Google dentro de la app | google_login_helper_triggers, por ejemplo accounts.google.com y accounts.youtube.com | GOOGLE_LOGIN_HELPER_TRIGGERS |
| Login de Facebook | facebook_login_helper_triggers | FACEBOOK_LOGIN_HELPER_TRIGGERS |
| Sign in with Apple | Se detecta automáticamente (appleid.apple.com) | No documentado; prueba el flujo web |
| Pasar una URL de login al sistema | googlelogin:// + URL codificada la abre fuera de la app (la sesión queda entonces en Safari, no en la app) | googlelogin:// + URL codificada abre una Chrome Custom Tab (documentación sobre gestión de URLs) |
| Detectar la app en tu código | useragent_iphone, useragent_ipad más el token WebViewGoldApp | USER_AGENT más el token WebViewGoldApp |
| Conservar las sesiones | Deja deletecache en false | Deja CLEAR_CACHE_ON_STARTUP en false; MANUAL_COOKIE_SYNC si las cookies llegan tarde; HOME_URL_LOGOUT para una URL de cierre de sesión |
¡Gran trabajo! Nunca tuve que usar código para nada, pero logré trabajar con esto y tener mi App lista. ¡Fácil y rápido! ¡También con gran ayuda de los creadores!
La mayor parte del tiempo se va en el portal de Apple Developer; el código es rápido.
Activa Sign in with Apple en tu App ID. Para el flujo web, crea un Services ID (su identificador será el client ID de OAuth), añade tu dominio y la URL de retorno de tu proveedor de autenticación (en Supabase: https://YOUR-PROJECT.supabase.co/auth/v1/callback) y crea una clave de Sign in with Apple (.p8). Apunta el Team ID y el Key ID.
Activa el proveedor de Apple con el Services ID y la clave. El client secret de Apple es un JWT firmado que vale como máximo seis meses, así que pon un recordatorio de renovación en tu calendario. Añade tu dominio de producción a las redirect URLs permitidas y quita del proyecto de producción las entradas de preview y localhost.
Los usuarios pueden elegir Ocultar mi correo. Para que los restablecimientos de contraseña y los recibos lleguen a las direcciones de privaterelay.appleid.com, registra tu dominio o dirección de envío en Sign in with Apple for Email Communication en el portal de Apple Developer.
Añade el botón, la gestión del callback y una checklist de configuración, y enumera los prefijos de URL por los que pasa tu flujo de login para que puedas comprobar las listas de activadores.
Pon los prefijos de Google en google_login_helper_triggers y en GOOGLE_LOGIN_HELPER_TRIGGERS. Si tu proveedor de autenticación usa un dominio propio que redirige a Google, los dominios que debes incluir siguen siendo los de Google.
TestFlight y pruebas internas, con la checklist de abajo. Si quieres ayuda con la parte nativa, el equipo de Full Service configura y compila las apps por ti.
Si conectaste tu proveedor de autenticación o tu base de datos mediante un servidor MCP, Claude Code puede leer por sí mismo la configuración actual del proveedor; si no, la escribe en la checklist por ti.
Nuestra app web se ejecuta en navegadores y dentro de apps nativas de iOS y Android creadas con WebViewGold (el user agent contiene WebViewGoldApp). Ofrecemos login con Google, así que la directriz 4.8 de Apple exige un login equivalente centrado en la privacidad en la app de iOS; vamos a añadir Sign in with Apple. El envoltorio nativo ya se encarga de la parte del WebView: las páginas de login de Google las abre el Social Login Helper de WebViewGold (prefijos de URL activadores en Config.swift y Config.java), y en iOS appleid.apple.com se detecta y se gestiona automáticamente. No añadas código nativo ni esquemas de URL para el login. Primero haz un plan y, tras mi aprobación, implementa: 1. Detecta nuestra librería de autenticación (Supabase Auth, Firebase Auth, Auth.js o Clerk) y añade su proveedor de Apple para el flujo web con nuestra URL de callback de producción. Nada de redirecciones a preview ni a localhost. 2. Pantallas de login y de registro: Sign in with Apple y Continue with Google (o sus textos oficiales en el idioma de la app, como "Iniciar sesión con Apple" y "Continuar con Google") como opciones equivalentes, con el mismo tamaño y la misma posición. Da estilo al botón de Apple según las directrices de Apple (negro o blanco, con el texto Sign in with Apple o su traducción oficial). El login con correo y contraseña se mantiene, porque lo usa la cuenta demo de App Review. 3. Apple comparte el nombre del usuario solo en la primera autorización. Si nuestra librería de autenticación no lo guarda, pide un nombre visible durante el onboarding cuando falte. 4. Los usuarios pueden elegir Ocultar mi correo. Asegúrate de que el correo transaccional funciona con las direcciones de privaterelay.appleid.com. 5. Registra en el perfil con qué proveedores inició sesión cada usuario, para que la eliminación de cuenta pueda revocar después los tokens de Apple. Si la librería de autenticación expone el refresh token de Apple al iniciar sesión, guárdalo en el servidor y cifrado. 6. Enumera todos los prefijos de URL por los que pasan los flujos de Google y de Apple en nuestro dominio y en los dominios de los proveedores (usa el servidor MCP de Playwright si está conectado; si no, la documentación de la librería de autenticación), para que pueda compararlos con google_login_helper_triggers y GOOGLE_LOGIN_HELPER_TRIGGERS. 7. Escribe SETUP-APPLE-LOGIN.md: los pasos en Apple Developer (App ID con Sign in with Apple, Services ID con dominio y URL de retorno, clave), los campos de nuestro panel de autenticación, la lista de redirect URLs permitidas, el registro del relay de correo y una nota de que el client secret de Apple caduca como máximo a los seis meses. 8. Añade una regla a CLAUDE.md: Sign in with Apple se mantiene tan visible como cualquier otro login de terceros y no debe eliminarse en las refactorizaciones. Informa de los archivos cambiados y de las preguntas abiertas.
Un ejemplo con Supabase en un componente de cliente de Next.js. Lo importante es el trato equivalente de ambos proveedores y una única redirección de producción; el agente lo adapta a tu librería de autenticación.
// components/social-login.tsx
"use client";
import { createClient } from "@/lib/supabase/client";
// Solo el callback de producción; debe figurar en la lista de redirect URLs permitidas de Supabase
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">
{/* Misma altura, anchura y posición para ambos: la directriz 4.8 exige equivalente, no escondido */}
<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 intercambia el código por una sesión (supabase.auth.exchangeCodeForSession)
// y redirige a la página de la que venía el usuario. Dentro de la app, la ventana de login de WebViewGold
// vuelve a esta URL, así que la sesión queda en la app, no en Safari ni en Chrome.deletecache y los ajustes de cookies antes de tocar tu código.No. La directriz 4.8 se aplica cuando un login de terceros o social crea o autentica la cuenta principal. El correo y la contraseña por sí solos no la activan.
La redacción de Apple admite cualquier servicio de login con las características de privacidad indicadas. En la práctica, Sign in with Apple es la opción que los revisores reconocen al instante, y la que menos esfuerzo cuesta defender.
Google detecta los WebViews integrados y los bloquea con disallowed_useragent. El Social Login Helper abre esas páginas en un contexto que Google acepta y después vuelve a tu app.
Allí es opcional. Mostrarlo en todas partes resulta coherente para los usuarios que cambian de dispositivo; ocúltalo en Android solo si el flujo web no se completa en tu compilación de prueba.
No. Escribe la checklist y el código, y puede editar los valores de Config.swift y Config.java si los proyectos están en el repositorio. Los ajustes del portal, las claves y la firma siguen siendo cosa tuya.
El mismo resultado, con distinta cantidad de trabajo por tu parte. Las tres incluyen la garantía de aprobación y soporte humano 24/7.
$109 por plataforma, pago único
La licencia de WebViewGold: un proyecto de Xcode o Android Studio listo para usar. Pega tu URL, define nombre e icono, activa funciones, compila y envía. Actualizaciones gratuitas para siempre.
Ver planes en la página principal$349 por licencia, complemento de pago único
Sin Mac, sin Xcode, sin Android Studio: configura en el navegador, compilamos ambas apps en la nube y las entregamos a App Store Connect y a Play Console.
Cómo funciona el Cloud Builder Prueba la demo gratuita$698 por plataforma $798
Envíanos tu URL y tu icono. Nuestro equipo configura, compila y entrega tu app en 72 horas, en marca blanca y con los proyectos fuente. Ambas plataformas por $1,158.
Detalles del Full Service Con tecnología de
Precios de la Oferta de invierno válidos hasta el 31 de diciembre de 2026.
Garantía de aprobación en App Store & Google Play – o te devolvemos el dinero en 14 días
¿Prefieres delegarlo? Full Service: configuramos, compilamos y entregamos en 72 horas, desde $698 por plataforma. ¿Preguntas? Chatea con nosotros 24/7.
Los reembolsos se conceden bajo las condiciones indicadas en nuestras FAQ: un rechazo por motivos ajenos al contenido por parte de Apple y/o Google, reclamado dentro de los 14 días posteriores a la compra.