Do it yourself
$109 per platform, one-time
The WebViewGold license: a finished Xcode or Android Studio project. Paste your URL, set name and icon, switch on features, build and submit. Free updates forever.
See plans on the main pageWhy logins fail in review, and what fixes each failure
Google. Google refuses OAuth inside embedded WebViews and shows "Error 403: disallowed_useragent". The reviewer taps Continue with Google, sees the error, and you get a guideline 2.1 rejection for a broken login. WebViewGold's Social Login Helper fixes it: you list URL prefixes that appear during your login flow (google_login_helper_triggers in Config.swift, GOOGLE_LOGIN_HELPER_TRIGGERS in Config.java), and when one loads, the app opens the login in a dedicated window with a user agent Google accepts, then returns to your web app. The same exists for Facebook. Details: Social Login Helper docs and the disallowed_useragent fix.
Apple. Guideline 4.8 says an app that uses a third-party or social login for the primary account must also offer an equivalent login service that limits data collection to name and email, lets users keep their email private and does not track them for advertising without consent. Sign in with Apple meets all three and is what reviewers expect. On iOS, WebViewGold detects appleid.apple.com and handles that flow automatically, with no configuration. If your app only has email and password, 4.8 does not apply.
Android. Apple's rule does not apply to Google Play, and the WebViewGold docs describe no special handling for Apple pages on Android. Test the web flow in your Android build; if it does not complete, hiding the Apple button there is acceptable.
What Claude Code does and what you do
| Area | Claude Code | You |
|---|---|---|
| Web app | Apple provider, equal buttons, callback route, first-login name handling, provider flags on the profile, CLAUDE.md rule | Review the plan and the diff, deploy |
| Apple Developer portal and auth dashboard | Writes SETUP-APPLE-LOGIN.md with every field | Services ID, key, return URL, provider settings, email relay, the six-month secret renewal |
| WebViewGold | Lists the URL prefixes the login flow passes through; edits Config values only if the projects are in the repository | Confirm the trigger lists, build |
| Testing | Checks the web flow in a desktop browser | Device tests in TestFlight and internal testing, Hide My Email, the reviewer account |
Which setting belongs to which problem
| Need | iOS (Config.swift) | Android (Config.java) |
|---|---|---|
| Google login inside the app | google_login_helper_triggers, for example accounts.google.com and accounts.youtube.com | GOOGLE_LOGIN_HELPER_TRIGGERS |
| Facebook login | facebook_login_helper_triggers | FACEBOOK_LOGIN_HELPER_TRIGGERS |
| Sign in with Apple | Detected automatically (appleid.apple.com) | Not documented; test the web flow |
| Hand a login URL to the system | googlelogin:// + encoded URL opens it externally (the session then lives in Safari, not in the app) | googlelogin:// + encoded URL opens a Chrome Custom Tab (URL handling docs) |
| Detect the app in your code | useragent_iphone, useragent_ipad plus the token WebViewGoldApp | USER_AGENT plus the token WebViewGoldApp |
| Keep sessions | Leave deletecache false | Leave CLEAR_CACHE_ON_STARTUP false; MANUAL_COOKIE_SYNC if cookies arrive late; HOME_URL_LOGOUT for a logout URL |
Great work! Never coded anything but managed to work with this. Easy and fast! Also with great help from the creators!
Setup in the right order
Most of the time goes into the Apple Developer portal; the code is quick.
Apple Developer portal
Enable Sign in with Apple on your App ID. For the web flow, create a Services ID (its identifier becomes the OAuth client ID), add your domain and the return URL of your auth provider (for Supabase:
https://YOUR-PROJECT.supabase.co/auth/v1/callback), and create a Sign in with Apple key (.p8). Note the Team ID and Key ID.Auth provider
Enable the Apple provider with the Services ID and the key. Apple's client secret is a signed JWT that is valid for at most six months, so put a renewal reminder in your calendar. Add your production domain to the allowed redirect URLs; remove preview and localhost entries from the production project.
Email relay
Users can choose Hide My Email. To deliver password resets and receipts to privaterelay.appleid.com addresses, register your sending domain or address under Sign in with Apple for Email Communication in the Apple Developer portal.
Run the Claude Code prompt
It adds the button, the callback handling and a setup checklist, and lists the URL prefixes your login flow passes through so you can check the trigger lists.
WebViewGold triggers
Put the Google prefixes into
google_login_helper_triggersandGOOGLE_LOGIN_HELPER_TRIGGERS. If your auth provider uses a custom domain that redirects to Google, the Google domains are still the ones to list.Build and test
TestFlight and internal testing, with the checklist below. For a hand with the native side, the Full Service team sets up and builds the apps for you.
The Claude Code prompt
If you connected your auth provider or database through an MCP server, Claude Code can read the current provider settings itself; otherwise it writes them into the checklist for you.
Paste into Claude Code
Our web app runs in browsers and inside native iOS and Android apps built with WebViewGold (the user agent contains WebViewGoldApp). We offer Google login, so Apple guideline 4.8 requires an equivalent privacy-focused login in the iOS app; we will add Sign in with Apple. The native wrapper already handles the WebView side: Google login pages are opened by the WebViewGold Social Login Helper (trigger URL prefixes in Config.swift and Config.java), and on iOS appleid.apple.com is detected and handled automatically. Do not add native code or URL schemes for login. Plan first, then implement after my approval: 1. Detect our auth library (Supabase Auth, Firebase Auth, Auth.js or Clerk) and add its Apple provider for the web flow with our production callback URL. No preview or localhost redirects. 2. Login and sign-up screens: Sign in with Apple and Continue with Google as equal options with the same size and position. Style the Apple button per Apple guidelines (black or white, the words Sign in with Apple). Email and password login stays, because the App Review demo account uses it. 3. Apple shares the user name only on the first authorization. If our auth library does not store it, ask for a display name during onboarding when it is missing. 4. Users may choose Hide My Email. Make sure transactional email works for privaterelay.appleid.com addresses. 5. Record on the profile which providers a user signed in with, so account deletion can revoke Apple tokens later. If the auth library exposes the Apple refresh token at sign-in, store it server-side and encrypted. 6. List every URL prefix the Google and Apple flows pass through on our domain and the provider domains (use the Playwright MCP server if it is connected, otherwise the auth library documentation), so I can compare them with google_login_helper_triggers and GOOGLE_LOGIN_HELPER_TRIGGERS. 7. Write SETUP-APPLE-LOGIN.md: Apple Developer steps (App ID with Sign in with Apple, Services ID with domain and return URL, key), the fields in our auth dashboard, the redirect URL allowlist, the email relay registration and a note that the Apple client secret expires after at most six months. 8. Add a rule to CLAUDE.md: Sign in with Apple stays as prominent as every other third-party login and must not be removed in refactors. Report the changed files and any open questions.
The login buttons the agent should end up with
A Supabase example in a Next.js client component. The point is the equal treatment of both providers and one production redirect; the agent adapts it to your auth library.
typescript
// components/social-login.tsx
"use client";
import { createClient } from "@/lib/supabase/client";
// Production callback only; must be listed in the Supabase redirect URL allowlist
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">
{/* Same height, width and position for both: guideline 4.8 means equivalent, not hidden */}
<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 exchanges the code for a session (supabase.auth.exchangeCodeForSession)
// and redirects to the page the user came from. Inside the app, the WebViewGold login window
// returns to this URL, so the session lands in the app, not in Safari or Chrome.Verification checklist on devices
- TestFlight build: Continue with Google opens the login window, completes, and you land in the app signed in. No disallowed_useragent error.
- Sign in with Apple: the Apple sheet or page appears, Hide My Email is offered, and you return signed in. Try once with a fresh Apple Account to see the first-login name handling.
- Kill the app and reopen it: you are still signed in. If not, check
deletecacheand cookie settings before touching your code. - Sign out and sign in with the other provider using the same email: the account linking behaves the way your auth settings say (same account or separate account, but never an error page).
- Android internal testing build: Google login completes. The Apple flow either completes or the button is hidden on Android.
- The reviewer demo account still signs in with email and password on both platforms.
- Send a password reset to a Hide My Email address: it arrives.
Pitfalls
- Missing trigger prefixes. If the login window never opens, the URL that loads during your flow is not in the trigger list. Start the flow in a desktop browser and note every redirect.
- Using googlelogin:// on iOS. It opens the login outside the app, so the session ends up in Safari. Prefer the Social Login Helper triggers inside the app.
- An Apple button that looks secondary. Smaller, below the fold or styled as a text link is not equivalent. Reviewers check this visually.
- The six-month secret. When the Apple client secret expires, Apple logins fail with a generic error. Renew it before the date, not after the first support email.
- Redirects to preview URLs. An OAuth redirect to a preview deployment works in testing and fails in production. Keep one production callback.
- Forgetting deletion. Apple expects tokens to be revoked when an account is deleted. The account deletion guide builds that step.
Frequently asked questions
Do I need Sign in with Apple if I only have email and password?
No. Guideline 4.8 applies when a third-party or social login sets up or authenticates the primary account. Email and password alone does not trigger it.
Does it have to be Sign in with Apple?
Apple's wording allows any login service with the listed privacy features. In practice Sign in with Apple is the option reviewers recognize instantly, and it is the least effort to defend.
Why does Google login work in Safari but not in my app?
Google detects embedded WebViews and blocks them with disallowed_useragent. The Social Login Helper opens those pages in a context Google accepts and returns to your app afterwards.
Should Sign in with Apple appear on Android and the website?
It is optional there. Showing it everywhere is consistent for users who switch devices; hide it on Android only if the web flow does not complete in your test build.
Can Claude Code configure the Apple Developer portal?
No. It writes the checklist and the code, and it can edit Config.swift and Config.java values if the projects are in the repository. Portal settings, keys and signing stay with you.
Three ways to get your app into the stores
Same result, different amount of work on your side. All three come with the approval guarantee and 24/7 human support.
Cloud Builder
$349 per license, one-time add-on
No Mac, no Xcode, no Android Studio: configure in the browser, we build both apps in the cloud and hand them to App Store Connect and the Play Console.
How the Cloud Builder works Try the free demoFull Service
$698 per platform $798
Send us your URL and icon. Our team configures, builds and delivers your app within 72 hours, white-label, with source projects. Both platforms for $1,158.
Full Service details Powered by
Winter Sale prices valid until December 31, 2026.