URL Handling API
Decide which links open inside your app, in an in-app browser tab, or in Safari — full URL handling control for iOS.
To improve user experience, it's often beneficial to customize how your app handles different types of web links. For example, social media buttons can be configured to open in the system browser or respective app, rather than within your app. WebViewGold provides flexible settings to customize URL handling for your WebView-based Android app.
Types of Links:
- External Links: Links that lead to a different domain from your app's primary domain.
- Example: If your app's domain is mydomain.com, an external link would be google.com.
- Internal Links: Links that stay within the same domain as your app.
- Example: If your app's domain is mydomain.com, an internal link would be mydomain.com/purchase.
- Special Links: Links that include special attributes, such as target="_blank".
To configure the URL Handling API, open Config.swift:
- To open all external links in Safari:
- Set
openallexternalurlsinsafaribydefaulttotrue.
- Set
- To set domains which always open in Safari (regardless of
openallexternalurlsinsafaribydefaultsetting):- Add the desired domains to the
safariwhitelistlist. - Insert another host like so: ["alwaysopeninsafari.com", "google.com", "m.facebook.com"].
- Please enter the host exactly how you link to it (with or without www, but always without http/https).
- Add the desired domains to the
- To set domains which never open in Safari (regardless of
openallexternalurlsinsafaribydefaultsetting):- Add the desired domains to the
safariblacklistlist. - Insert another host like so: ["alwaysopeninsafari.com", "google.com", "m.facebook.com"].
- Please enter the host exactly how you link to it (with or without www, but always without http/https).
- Add the desired domains to the
Open links in a tab/additional In-App-Browser
Some links, like a Terms and Conditions page, may not be significant enough to open in an external system browser yet too specific for your app's primary WebView. WebViewGold provides a creative solution for handling these links: an in-app browser tab that opens over the main WebView, providing a hybrid app and browser experience. Here's what it will look like:

Key Features of the In-App Browser Tab:
- The in-app browser tab includes an address bar and navigation buttons, offering a more browser-like experience than the primary WebView.
- Ideal for content that requires easy navigation, such as tutorials, knowledge bases, or pages with specific information.
How to Use the In-App Browser Tab in Your WebView-Based iOS App:
To open a link in the in-app browser tab, set openspecialurlsinnewtab to true format the URL in your HTML as follows:
<a href="https://www.example.com" target="_blank">Open link in an in-app tab</a>
Simply, a special link is classified as a link that has the "_blank" target attached. In a normal browser, this would make the link open in a new tab. In WebViewGold app, you can make it open in the in-app tab instead.
Please note that if the link you are using is external (has a different domain to your website like "www.google.com", for example) please also make sure that openallexternalurlsinsafaribydefault is set to false as it will override the special-external link to open in the Safari app instead.
To see how your app will handle different types of links, use the following URL as the WebView URL during testing:
Test Link: https://www.webviewgold.com/demo/testlinks.php
Note: You can also open the same domain in your desktop browser to view the source code and copy the format for your links.
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.