Social Media Login Helper (Google, Facebook & Apple)
Make Google, Facebook, and Apple OAuth logins work reliably inside your iOS WebView app with the built-in social login helpers.
Google, Facebook, and other OAuth providers restrict logins from embedded WebViews (e.g., Google's "disallowed_useragent" error). The Social Login Helper built into WebViewGold makes these logins work reliably inside your iOS app — without changing your website's login flow.
How It Works:
You define URL prefixes that appear during the login flow of your web app. As soon as one of these trigger URLs loads, WebViewGold opens the login in a dedicated popup login window with an adjusted user agent that the OAuth provider accepts. After a successful login, the flow returns to your web app automatically. Sign in with Apple (appleid.apple.com) is detected and handled automatically — no configuration needed.
Configuration:
Open Config.swift and define the trigger URL prefixes for your login flow:
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"]
google_login_helper_triggers— URL prefixes that load during a Google login on your website.facebook_login_helper_triggers— URL prefixes that load during a Facebook login on your website.
To find the right trigger URLs, start your website's login flow in a desktop browser and note which URLs the OAuth redirect goes through.
Open an Auth URL in the External Browser:
As an alternative approach, you can hand over a login URL to the system browser explicitly (the session then lives in the browser, not in the app):
window.location.href = "googlelogin://" + encodeURIComponent("https://accounts.google.com/o/oauth2/v2/auth?...");
WebViewGold decodes the URL after the googlelogin:// prefix and opens it externally.
When to Use the Helper:
Try the simpler options first — in many cases they already solve login issues:
- Open the login domain in an in-app browser tab or external browser via the URL Handling API (e.g.,
specialLinkHandlingOptions,safariblacklist). - Set a Custom User Agent (
useragent_iphone/useragent_ipad).
If the login still fails in-app, the Social Login Helper triggers are the recommended solution.
SDK-style implementation notes
Treat this feature as a native capability exposed to your web layer: keep your production website or PWA as the source of truth, then use the documented WebViewGold configuration flags, URL commands, and JavaScript bridge calls to opt in to native iOS behavior only where it adds value. This approach keeps your codebase maintainable because the same web application can serve browsers, WebViewGold for iOS, and the other WebViewGold platforms with minimal conditional logic.
For reliable results, prefer HTTPS endpoints, stable route names, explicit success/error states in your UI, and small JavaScript helper functions that wrap native calls. For example, a web app built with jQuery Mobile, Lovable, Base44, Bolt, WordPress, Bubble, a custom React/Vue/Angular stack, or static HTML can expose a single button or event handler that triggers the native WebViewGold API while still showing a graceful browser fallback.
- Recommended integration pattern: detect the app context, call the WebViewGold API, then update your web UI after the native callback or route change.
- Testing checklist: validate the feature on a real device or packaged build, verify permissions and store review text, and confirm that browser-only users still receive a useful fallback.
- SEO benefit: keep feature pages, route titles, and structured content indexable on your website while WebViewGold delivers the native app shell for iOS users.