Skip to content
WebViewGold Vibe Coding to App Store
English
Get WebViewGold

Bolt + link handling

External links and URL handling in your Bolt app

On the web, a link to Stripe, Google login, WhatsApp or your help center just works. Inside an app every link needs a destination: the app itself, an in-app browser tab, Safari or Chrome, or another app such as Mail, Phone or WhatsApp. Get it wrong and users end up stranded on a third-party page with no back button, logged in in the wrong place, or paying in a browser while the app waits.

From $109 one-time per platform, or let our team do it all from $698.

  • Approval guarantee – or money back within 14 days
  • No coding needed
  • One-time payment, free updates
  • 24/7 human support
  • Made in Germany since 2014 · ISO 27001

Where each kind of link should open

LinkBest destinationWhyHow in WebViewGold
Your own domainThe app (main WebView)This is your appInternal links stay in the app
Stripe Checkout, payment links, 3-D Secure, PayPalThe app (main WebView)The success URL returns to your domain with the session intactKeep external links in the app (option 0), or list these hosts as never-browser exceptions (safariblacklist, BROWSER_BLACKLIST)
Google and Facebook loginSocial Login HelperGoogle blocks embedded WebViews; the helper runs that step in an accepted login window and returnsgoogle_login_helper_triggers / GOOGLE_LOGIN_HELPER_TRIGGERS; Android also offers the googlelogin:// prefix for a Chrome Custom Tab
Terms, help center, docs, blog on other domainsIn-app tabAddress bar and close button; the app stays underneathalwaysOpenInInAppTab / ALWAYS_OPEN_IN_INAPP_TAB, or target="_blank" with the special-link option set to 1
WhatsApp (wa.me), Instagram, YouTube, X, TikTokTheir app or the system browserUsers are logged in there, not in your WebViewsafariwhitelist / BROWSER_WHITELIST
mailto:, tel:, sms:Mail, Phone, MessagesSystem schemes, handled by the phoneUse standard links; WebViewGold hands them to the system
App Store and Google Play linksThe store appUpdates, ratings, your other appsapps.apple.com and play.google.com on the always-external list

Prompt for Bolt

Paste this into Bolt to implement the web-app side. Review the result, publish, then test inside the WebViewGold app.

Prompt to paste into Bolt
This app will run inside the WebViewGold native wrapper (its user agent contains "WebViewGold"). Fix outbound links for the app without breaking the Bolt preview:
1. Create isNativeApp() and use it in the checkout flow: inside the app, redirect to the Stripe Checkout URL with window.location.href; outside the app, keep the current behavior.
2. Point the Stripe success_url and cancel_url to the deployed production domain, not to the preview.
3. After returning from checkout, re-read the subscription from Supabase instead of trusting URL parameters.
4. Open documentation, help and legal pages on other domains with target="_blank".
5. Render phone, email and WhatsApp buttons as tel:, mailto: and https://wa.me/ links.
6. Output a list of every external host the app links to, grouped by checkout, login, social, help and stores.

WebViewGold has allowed us the shortest and most efficient time-to-market ever possible from among all the other app platforms we have ever tried during the past 5 years. I don’t know why I hadn’t discovered you sooner, but I am really, really glad I did. Currently nearing 6000 app downloads on both iOS App Store & Google Play Store without any problem!

Antonio Davila · CodeCanyon

Three link classes and the switches that control them

Internal links

Same domain as your configured host. They load in the main WebView, which is why the start URL should be your production domain. Test the subdomains you use for auth, checkout or the API explicitly; whether they count as internal depends on the host you configured.

External links

Every other domain. Option 0 keeps them in the app. iOS can send them to Safari with externalLinkHandlingOptions = 2; Android adds 1 (in-app tab) and 2 (system browser) for EXTERNAL_LINK_HANDLING_OPTIONS. Per-host lists override the default: safariwhitelist, safariblacklist and alwaysOpenInInAppTab on iOS, BROWSER_WHITELIST, BROWSER_BLACKLIST and ALWAYS_OPEN_IN_INAPP_TAB on Android.

Special links

Links with target="_blank" (on Android also links ending in #). specialLinkHandlingOptions and SPECIAL_LINK_HANDLING_OPTIONS: 0 main WebView, 1 in-app tab, 2 browser. On Android a newtab: prefix forces a single link into that behavior. For links that are special and external, Android follows the special-link setting, while on iOS externalLinkHandlingOptions = 2 still sends them to Safari, so keep it at 0 if you want the in-app tab.

Set up link handling for a Bolt app

About 15 minutes with a link inventory, then a test on real phones.

  1. List every outbound link in your Bolt app

    Click through or search the code: checkout and billing portal, login providers, social profiles, support chat, legal pages, store badges, mailto: and tel: links, maps. Note the destination for each using the table above.

  2. Set the default

    For most apps: keep external links in the app (option 0 on both platforms) and route the exceptions. Sending all external links to the browser breaks payment and login redirects that must come back to the app.

  3. Add the exceptions

    Social apps, WhatsApp and store links to safariwhitelist (iOS) and BROWSER_WHITELIST (Android); terms, docs and the help center to alwaysOpenInInAppTab and ALWAYS_OPEN_IN_INAPP_TAB; payment and auth hosts to the never-browser lists if your default is the browser. Enter hosts exactly as you link to them, without https://.

  4. Turn on the login helper

    Add https://accounts.google.com to google_login_helper_triggers (iOS) and GOOGLE_LOGIN_HELPER_TRIGGERS (Android). Do not simply send Google to Safari: the session would end up in Safari, not in the app (the disallowed_useragent fix).

  5. Treat digital purchases separately

    Stripe for physical goods and real-world services can stay in the app. For subscriptions or credits used inside the app, Apple expects In-App Purchase (Guideline 3.1.1) and Google expects Play Billing, outside the regional exceptions, so hide that checkout inside the app (Stripe vs In-App Purchase).

  6. Test every link type

    Load https://www.webviewgold.com/demo/testlinks.php as a temporary start URL to see how each kind of link behaves, then tap every outbound link of your real app on an iPhone and an Android phone, including a full test payment.

A typical starting configuration

Values only: keep the syntax that the lines in your Config.swift and Config.java already use. On Android, ALWAYS_OPEN_IN_INAPP_TAB takes URL prefixes; the other lists take hosts.

text
// Config.swift (iOS)
externalLinkHandlingOptions  = 0     // external links stay in the app
specialLinkHandlingOptions   = 1     // target="_blank" opens the in-app tab
safariwhitelist              = ["wa.me", "api.whatsapp.com", "www.instagram.com", "apps.apple.com"]
alwaysOpenInInAppTab         = ["help.yourdomain.com", "docs.yourdomain.com"]
google_login_helper_triggers = ["https://accounts.google.com"]

// Config.java (Android)
EXTERNAL_LINK_HANDLING_OPTIONS = 0
SPECIAL_LINK_HANDLING_OPTIONS  = 1
BROWSER_WHITELIST              = ["wa.me", "api.whatsapp.com", "www.instagram.com", "play.google.com"]
ALWAYS_OPEN_IN_INAPP_TAB       = {"https://help.yourdomain.com", "https://docs.yourdomain.com"}
GOOGLE_LOGIN_HELPER_TRIGGERS   = {"https://accounts.google.com"}

The link bugs vibe-coded apps ship with

  • Checkout in the browser. Stripe opens in Safari or Chrome, the payment succeeds, the success page loads in the browser and the app still shows the unpaid state. Keep checkout in the app, or bring the return URL back with Universal Links (see the deep-link guide).
  • Checkout in a pop-up. Code that opens checkout with window.open or target="_blank" becomes a special link, so the success page loads in the in-app tab instead of the app. Navigate with window.location.href instead.
  • A billing portal link for digital plans in the iOS app. Outside the regional exceptions, Apple can read it as steering away from In-App Purchase (Guideline 3.1.1). Show it on the web only.
  • A third-party page with no way back. iPhones have no back button. Anything that is not your app belongs in the in-app tab or another app.
  • WhatsApp, Instagram or map links loading their website inside the app, often behind a login wall. Send those hosts to the system so the real app opens.
  • Everything opens in Safari. An app that keeps leaving itself feels like a bookmark, which is the impression behind many Guideline 4.2 rejections.

Frequently asked questions

Why does my Stripe checkout lose the session in the app?

Usually because checkout opened in Safari or Chrome: the payment works, but the success URL loads in the browser, where the user is not logged in. Keep checkout.stripe.com in the main WebView (option 0 for external links) and navigate with window.location.href, so the redirect lands back in the app.

Do mailto:, tel: and WhatsApp links work inside the app?

mailto:, tel: and sms: links are handed to Mail, the phone app and Messages. For WhatsApp, add wa.me and api.whatsapp.com to the always-external list (safariwhitelist, BROWSER_WHITELIST) so the WhatsApp app opens instead of the WhatsApp website inside your app. Test each on a real phone.

What is the in-app tab?

A browser view that opens over your app with an address bar and navigation buttons. Users read the page and close it to return exactly where they were. It is the right place for terms, help articles and other third-party content.

Can I open all external links in Safari or Chrome?

You can (externalLinkHandlingOptions = 2 on iOS, EXTERNAL_LINK_HANDLING_OPTIONS = 2 on Android), but then add every payment, login and API host to the never-browser exceptions (safariblacklist, BROWSER_BLACKLIST), or redirects meant for your app will land in the browser.

Can the iOS app link to my web pricing page?

For digital goods, Apple generally does not allow buttons or links to external purchases. Exceptions exist for specific regions, such as the US storefront after the 2025 court order and the EU alternative terms, and they change. Check the current text of Guideline 3.1.1 in App Store Connect before relying on one.

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.

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 page

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 demo

Full 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 WeSetupYourWebViewApp

Winter Sale prices valid until December 31, 2026.

Ready to ship your Bolt app?

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.