WebView App Rejected Under Guideline 4.8: Fixing Google and Facebook Login Inside a WebView

WebView app rejected under Guideline 4.8: why website login buttons count

A WebView app rejected under Guideline 4.8 usually has no login code of its own. The buttons come from the website – "Continue with Google", "Log in with Facebook", perhaps "Sign in with LinkedIn". Inside the app, that web page is the app's login screen, and Guideline 4.8 applies to it like to any native screen (App Store Review Guidelines):

Apps that use a third-party or social login service (such as Facebook Login, Google Sign-In, Log in with X, Sign In with LinkedIn, Login with Amazon, or WeChat Login) to set up or authenticate the user’s primary account with the app must also offer as an equivalent option another login service with the following features:

• the login service limits data collection to the user’s name and email address;
• the login service allows users to keep their email address private as part of setting up their account; and
• the login service does not collect interactions with your app for advertising purposes without consent.

Apple defines the primary account as the one users "establish with your app for the purposes of identifying themselves, signing in, and accessing your features and associated services". If your website's Google button creates or opens that account, the rule applies. Your own email and password form next to it usually doesn't count as the equivalent option, because it gives users no way to keep their email private.

The exceptions – and how they apply to web apps

Apple lists five cases in which no additional login service is needed. Three matter for website wrappers:

• Your own sign-in only. "Your app exclusively uses your company’s own account setup and sign-in systems." If the app shows only your email, password or code login, 4.8 doesn't apply. Removing the social buttons in app mode is a legitimate fix – but users who signed up with Google need another way into the same account, such as a password reset to that email.
• Education, enterprise or business apps that require "an existing education or enterprise account". A B2B web app whose staff sign in only through their employer's Google Workspace or Microsoft directory may qualify; a consumer site with a Google button does not.
• Clients for a specific third-party service, where users must sign in to their mail, social media or other third-party account to reach their content.

The other two cover alternative app marketplaces and government or industry-backed electronic ID. If you rely on an exception, state it in one clear sentence in the Notes for Review. Our Guideline 4.8 guide covers the exceptions and the button design rules in depth.

Rejected or stuck? Talk to an App Specialist – for free.

Book a free consultation call: we look at your rejection or setup, explain the fastest way forward and tell you honestly whether you need us. Prefer to hand it off? Book our AI-powered + human-powered service and we take care of it.

Free consultation call Book our service →

Adding Sign in with Apple: web flow or native button?

Sign in with Apple meets all three criteria, and Apple's own 4.8 rejection messages point to it. A WebView app can add it in two ways:

Many teams combine both: the web flow for browsers and Android, the native sheet on iOS. Two details apply either way. Apple sends the user's name only on the first authorization (the email stays available in the identity token), so store it right away (Apple). And the Apple button must be at least as prominent as the other providers on every screen where they appear.

WebViewGold, the website-to-app product developed by our team, includes a Sign in with Apple helper: it detects the appleid.apple.com flow of your website and handles it inside the app without extra configuration, so the web route works in the wrapper too.

Google's WebView block: fixing the disallowed_useragent error

Even with Sign in with Apple in place, your Google button may simply fail in the app. Google's OAuth 2.0 policies state that "a developer must not direct a Google OAuth 2.0 authorization request to an embedded user-agent under the developer's control" (Google OAuth 2.0 Policies). A WKWebView inside your app is exactly that – and so is an in-app login pop-up with an adjusted user agent. Google answers with the error disallowed_useragent, and disguising the user agent to get past it breaks the policy instead of fixing the problem.

Google's documentation names the way out: iOS developers "should instead use iOS libraries such as Google Sign-In for iOS or OpenID Foundation's AppAuth for iOS", and websites opened in an embedded user-agent should let general links open in the operating system's default handler, with SFSafariViewController as a supported option (Google OAuth 2.0 for iOS apps). For a WebView app, that leaves these routes:

1. An authentication sheet inside the app. Start your website's Google login in Apple's ASWebAuthenticationSession, which AppAuth for iOS also uses, or in SFSafariViewController. Your server completes the OAuth flow and redirects to your app's callback with a short-lived one-time code; the app then loads a URL in the WebView that exchanges the code for your normal session cookie. The handoff is needed because these system browser views keep their cookies apart from your WebView. On Android, Custom Tabs play the same role.
2. The system browser. WebViewGold can hand an authorization URL to the browser without native code – through its googlelogin:// prefix or by sending Google's sign-in domain to Safari in its URL handling settings. The session then lives in the browser, so your callback page returns the user to the app with a deep link carrying a one-time code. This satisfies Google's policy, but mind Apple's view: linking out to the default web browser to sign in or register "provides a poor user experience and isn't appropriate" under Guideline 4 (Apple). For the App Store version, the in-app sheet is the safer choice.
3. Google Sign-In for iOS. The native SDK returns tokens to the app; your backend verifies them and creates the web session the same way.
4. No Google login in the app – your own sign-in plus Sign in with Apple.

Magic links, one-time codes and the reviewer

Passwordless sign-in is popular with web apps and awkward in a WebView app. The user requests a link, opens the email in Mail and taps it – and iOS opens the link in the default browser. Now the user is signed in in Safari while your app still shows the login screen.

• Universal links fix this. Add the Associated Domains entitlement with applinks: and your domain, and host an apple-app-site-association file in your site's .well-known directory over HTTPS without redirects (Apple). Taps on your sign-in links then open the app, which loads the link in its WebView and receives the session there.
• One-time codes typed into the app avoid the round trip entirely.
• Reviewers can't open your inbox. Provide a demo account that signs in with a password or a fixed code for that account, mention it in the notes and keep it valid – App Store Connect asks for demo accounts that don't expire. Our 2.1 Information Needed guide has the details.

Note the link to 4.8: email links and codes from your own system are your company's own sign-in, so an app that offers only those needs no additional login service.

Hide My Email: make private relay addresses work

Users who choose Hide My Email share an automatically generated address – for example ending in @privaterelay.appleid.com – that forwards to their real inbox (Apple). Website backends often stumble over it:

• Don't ask for a "real" address after sign-up; that undermines the private-email criterion of 4.8.
• Register your sending domains with Apple and authenticate outbound mail with SPF, or your emails won't reach relay addresses.
• Plan for duplicates. Someone who signed up with Google using their real address and later uses Sign in with Apple with a relay address gets a second account. Offer account linking in the settings instead of merging by email.
• Key users on Apple's stable user identifier, not on the email address – users can stop the forwarding for your app at any time.

Account deletion and token revocation

Every account your login creates must also be deletable inside the app under Guideline 5.1.1(v), and two login duties come with it. Apple says apps that support Sign in with Apple should revoke user tokens with the Sign in with Apple REST API when an account is deleted. And 5.1.1(v) requires the app to "include a mechanism to revoke social network credentials and disable data access between the app and social network from within the app" – relevant whenever your Google or Facebook connection does more than sign the user in.

In a WebView app the deletion page usually lives on your website: link to it directly from the app's account area and run the revocation on your server. Details are in our 5.1.1(v) article for WebView apps and the account deletion guide.

The shortcut: WebViewGold for the native parts, appsubmitter.io for review

Most of the work above sits at the seam between website and app – where a ready-made native shell saves time. WebViewGold gives you an Xcode project that you own, with the relevant pieces as configuration:

• the Sign in with Apple helper for the Apple flow of your website,
• universal links and deep links for magic links and login callbacks,
• Face ID and Touch ID for quick, secure re-entry after the first sign-in,
• the googlelogin:// handoff and URL handling to pass Google's login to the system browser – keeping Apple's Guideline 4 caveat above in mind,
• a custom user agent purely for app detection, so your login page can show the right providers in app mode.

An in-app authentication sheet for Google is native code that goes into the same project as custom work. WebViewGold is a one-time purchase, and no tool can promise an approval.

appsubmitter.io then handles the submission: a demo account App Review can actually use, review notes that explain your login options or exception, App Privacy details and the conversation with App Review in your own developer account. Code changes such as a native Google flow are discussed and quoted upfront. Book the iOS service or talk through your login setup in a free consultation call.

Template: how to reply to App Review

Adapt this template to your situation. Keep it factual, short and specific – and only claim what you have actually changed.

Hello App Review Team,

Thank you for reviewing [App name] (version [x.y], build [build number]) and for your feedback regarding Guideline 4.8 - Login Services.

Our app displays the login of our website [domain]. We have made these changes for all app users:

1. Sign in with Apple is now offered on [the login and sign-up screens], next to the [Google / Facebook] button and at the same size.
2. Sign in with Apple requests only name and email. Users who choose Hide My Email can complete sign-up without entering another address.
3. [Google sign-in now runs in a system authentication session instead of the in-app WebView.] / [Social login has been removed from the app; users sign in with our own account system or Sign in with Apple.]

To test: install build [build number], tap "Sign in with Apple" on [screen] and complete the flow with any Apple Account. Our demo account for the email login is [username] / [password]. A screenshot of the updated login screen is attached.

Best regards,
[Your name]
[Company]

Checklist before you resubmit

• Every screen of your website that offers Google, Facebook or another social login also offers Sign in with Apple in the app.
• The Apple button is at least as large and visible as the other providers, on iPhone and iPad.
• Google sign-in no longer runs inside the WKWebView or an in-app pop-up but in an authentication sheet or the Google SDK – or not at all.
• The session from any external sign-in is handed back to the WebView with a short-lived one-time code.
• Magic links and login callbacks open the app through universal links.
• A Hide My Email user can finish onboarding without entering another email address.
• Your sending domains are registered for the private email relay and pass SPF.
• Users are keyed on Apple's stable identifier, and accounts can be linked instead of duplicated.
• Account deletion revokes Sign in with Apple tokens and works from inside the app.
• The demo account signs in with a password or fixed code and does not expire.

Frequently asked questions

Sources and further reading

• Apple – App Store Review Guidelines, 4.8 Login Services
• Google – OAuth 2.0 Policies (embedded user-agents)
• Google – OAuth 2.0 for iOS & Desktop Apps (disallowed_useragent)
• Apple – Configuring your webpage for Sign in with Apple
• Apple – Communicating using the private email relay service
• Apple – ASWebAuthenticationSession
• Apple – Supporting associated domains
• Apple – Offering account deletion in your app

Store policies and third-party products change regularly – always check the current versions. This article is independent advice and not affiliated with or endorsed by Apple, Google or any other company or product mentioned; all trademarks belong to their owners. WebViewGold and appsubmitter.io are made by our team at jocapps GmbH.