ChatGPT & Codex
Two things break login in a wrapped web app: Google refuses OAuth inside embedded WebViews, and Apple rejects apps that offer Google without a privacy-friendly equivalent. WebViewGold handles the first natively and detects Sign in with Apple automatically on iOS; Codex makes the web side match. This guide uses Firebase Auth on an Express-hosted app, the stack where redirect details matter most.
From $109 one-time per platform, or let our team do it all from $698.
The goal is three login options that work inside the iOS and Android apps exactly as they do on the web: email, Google and Sign in with Apple, all ending in the same Firebase session inside the WebView, and still there after the app is closed and reopened.
The reviewer's test is short. They tap Google; if Google answers with "Error 403: disallowed_useragent", the app is broken (Guideline 2.1). They look for an Apple option next to Google; if it is missing, Guideline 4.8 asks for a login option that limits data to name and email and lets people hide their address, which in practice means Sign in with Apple. Apps that only use their own email or magic-link accounts are exempt, which is a legitimate way out (Guideline 4.8 in detail).
Background on the Google error is in the disallowed_useragent fix, and every login option is collected on the Google login and Sign in with Apple hub.
Google blocks OAuth in embedded WebViews. When a URL from google_login_helper_triggers (Config.swift) loads, WebViewGold opens the login in a dedicated window with a user agent Google accepts and returns to your app afterwards; Android has the same list as GOOGLE_LOGIN_HELPER_TRIGGERS in Config.java, plus Facebook lists. Sign in with Apple (appleid.apple.com) is handled automatically on iOS. See the social login docs.
Safari and other WebKit views block third-party storage, which breaks Firebase redirect sign-in while authDomain still points to PROJECT.firebaseapp.com. Firebase's redirect best practices list several fixes; for an app on Express, the clean one is a reverse proxy for /__/auth/ on your domain and authDomain set to that domain.
A Services ID with your domain and the return URL https://app.example.com/__/auth/handler (your domain, because of the proxy), a Sign in with Apple key and your Team ID, all entered in Firebase's Apple provider.
Google Play has no Sign in with Apple rule. Show the button on Android only if your users expect it, and test that redirect on a device; WebViewGold's automatic Apple handling is documented for iOS.
Add this below the runtime context in your AGENTS.md. It blocks the three things agents tend to do when login fails in a WebView: change the user agent, open OAuth in a new window, or quietly remove Google from the iOS build.
## Authentication (Firebase Auth inside WebViewGold)
- Providers: email/password, Google, Apple. Google and Apple buttons live in one
component (src/components/SocialButtons.tsx) with equal size and prominence.
- Every sign-in call goes through src/lib/auth.ts. Inside the native app
(isNativeApp()) use signInWithRedirect, which Firebase recommends on mobile;
keep the method in one constant so we can switch to popup after device tests.
Desktop browsers may use signInWithPopup.
- authDomain is our own domain (app.example.com). Express proxies /__/auth/* to
PROJECT_ID.firebaseapp.com as a transparent reverse proxy. Never point
authDomain back to firebaseapp.com.
- Google inside the app works through WebViewGold's Social Login Helper
(google_login_helper_triggers / GOOGLE_LOGIN_HELPER_TRIGGERS). Do not change the
user agent, do not open OAuth URLs with window.open, do not use googlelogin://
unless explicitly asked.
- Sign in with Apple (appleid.apple.com) is handled by WebViewGold on iOS.
- Apple shares the name only on the first sign-in: write displayName to users/{uid}
immediately. Expect @privaterelay.appleid.com addresses.
- auth/account-exists-with-different-credential: ask the user to sign in with the
existing method, then linkWithCredential. Never create a second account silently.
My iOS WebView is finally approved. Thanks!!
Run it in the web app repository with codex --sandbox workspace-write --ask-for-approval on-request. It changes code only; everything you have to click in the Apple and Firebase consoles lands in a setup file for you.
Read AGENTS.md, especially the Authentication section. Our app uses Firebase Auth with email/password and Google. Apple rejected the iOS build under Guideline 4.8, and Google login fails inside the app on some devices with disallowed_useragent. Fix the web side; I handle the Apple Developer and Firebase consoles and the WebViewGold config.
1. Add Sign in with Apple with new OAuthProvider("apple.com") and the scopes email and name, routed through src/lib/auth.ts. The button follows Apple's design guidelines (black or white, Apple logo, "Sign in with Apple") and has the same size and prominence as the Google button.
2. Inside the native app (isNativeApp()), use signInWithRedirect and handle getRedirectResult on app start, including errors, with a visible message instead of a silent failure. Keep the popup flow for desktop browsers. Put the method choice in one constant.
3. Make authDomain our own domain: add an Express reverse proxy that forwards /__/auth/ to https://PROJECT_ID.firebaseapp.com (a transparent proxy, not a redirect; keep paths, query strings and cookies). Read PROJECT_ID and the auth domain from environment variables.
4. On the first Apple sign-in, write displayName and email to users/{uid} if they are empty.
5. Handle auth/account-exists-with-different-credential with a linking flow: explain which method the account uses, sign in with it, then linkWithCredential.
6. Write SETUP-AUTH.md with what I must configure: the Apple Services ID with domain app.example.com and return URL https://app.example.com/__/auth/handler, the key and Team ID for Firebase, the authorized domains in Firebase, and the WebViewGold settings to check (google_login_helper_triggers in Config.swift, GOOGLE_LOGIN_HELPER_TRIGGERS in Config.java, deletecache off).
7. Tests: unit tests for the linking flow, the redirect error handling and the proxy route with a mocked upstream. Do not call Google or Apple.
Report the changed files and a device test matrix for iOS and Android.These are the documented defaults. Extend the lists only if your login passes through other Google or Facebook hosts (start the login in a desktop browser and watch the redirects). On Android, the same prefixes go into GOOGLE_LOGIN_HELPER_TRIGGERS and FACEBOOK_LOGIN_HELPER_TRIGGERS in Config.java.
// Config.swift: Social Login Helper triggers (documented defaults)
var google_login_helper_triggers: [String] = ["https://accounts.google.com", "https://accounts.youtube.com"]
var facebook_login_helper_triggers: [String] = ["https://m.facebook.com", "https://www.facebook.com"]
// Sign in with Apple (appleid.apple.com) needs no trigger: WebViewGold handles it on iOS.
// Keep sessions across launches: leave deletecache and deletecacheonexit off,
// or users are logged out every time they open the app.
// Custom user agent (useragent_iphone / useragent_ipad): append your marker to the
// default string instead of replacing it.Enable Sign in with Apple on the App ID, create a Services ID, register app.example.com and the return URL https://app.example.com/__/auth/handler, create a Sign in with Apple key, and note the Key ID and Team ID.
Enable the Apple provider (Services ID, Team ID, Key ID, private key) and Google. Add app.example.com to the authorized domains.
Paste the prompt, then run /review in the CLI and read git diff. Check the proxy first: it must forward, not redirect, and it must not touch other routes.
Open https://app.example.com/__/auth/handler in a browser. It should be served from your domain rather than return a 404 or bounce to firebaseapp.com.
Confirm the trigger lists, keep deletecache off on iOS and CLEAR_CACHE_ON_STARTUP off on Android, and if you set a custom user agent, append to the default string. On Android, HOME_URL_LOGOUT can point to your logout URL to clear login cookies.
Run the matrix below on TestFlight and an internal testing track. In the review notes, list the login options and give the reviewer an email demo account (the Codex release workflow covers the rest of the submission).
authDomain left on firebaseapp.com. The redirect completes, but the app often ends up back on the login screen with no user.googlelogin:// as the default. It hands the login to the system browser on iOS and to a Chrome Custom Tab on Android, so the session lives outside your WebView unless your redirect brings it back. Keep it for edge cases (Android URL handling docs).Not on iOS: the appleid.apple.com flow is detected and handled automatically. You configure Apple in your Apple Developer account and in Firebase, and add the button to your web app.
No. Google Play has no such rule. Many apps show it on both platforms for consistency; if you do, test the flow on an Android device before release.
Start with redirect on your own authDomain, which Firebase recommends for mobile. Keep the choice in one constant so you can switch to popup if a device test shows a problem, and retest both platforms after any change.
No. OAuth needs real provider accounts, and the Codex sandbox has no network access by default. Codex can test the linking logic, the error messages and the proxy route with mocks; the real logins belong in your device matrix.
The WebViewGold side is identical. In Supabase you enable the Apple provider with the Services ID and a client secret generated from your key (Apple limits it to six months, so plan the rotation), and the callback URL is your Supabase project's auth callback. There is no authDomain proxy to build.
Same result, different amount of work on your side. All three come with the approval guarantee and 24/7 human support.
$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 page$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 demo$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.
App Store & Google Play approval guarantee – or your money back within 14 days
Rather hand it over? Full Service: we configure, build and deliver within 72 hours, from $698 per platform. Questions? Chat with us 24/7.
Refunds are granted under the conditions listed in our FAQ: a non-content rejection by Apple and/or Google, claimed within 14 days after purchase.