I posted this in the mobile forum but couldn’t get a reply.
I have a mobile item that links to a Google spreadsheet. It works well in iOS (opens up Google spreadsheet in Safari within the app), but on Android it’s a dead link. I think this has something to do with the mobile app not correctly opening Android’s native Chrome browser, from what I understand.
I can’t seem to get this to work or find a plugin (Toolbox is not available for mobile to write javascript) that does this. Here are a few screenshots that might give you more information. This dyanmic link goes to the URL (which is an https:// address)
You’re spot on with your guess: iOS and Android handle deep-linking and standard web views completely differently. iOS’s WebKit is pretty forgiving with standard https:// URLs, but Android’s WebView often blocks external redirects unless the app explicitly instructs the device to open the system browser.
Here are the best ways to fix this so it works perfectly on Android:
1. Check Your Native Wrapper’s Documentation (Most Likely Fix)
Since you are building a mobile app, you are likely using a service to wrap your Bubble site into an APK/IPA file. Almost all of these wrappers disable standard “Open an external website” actions by default on Android to prevent the user from accidentally navigating away from the app.
Instead, they provide their own custom workflow actions or plugins.
Look in your Bubble plugins for one matching your wrapper (e.g., The BDK, Natively, GoNative/Median, etc.).
Instead of the native Bubble “Open an external website” action, look for an action provided by that plugin, usually named something like “Open Safari/Chrome”, “Open In-App Browser”, or “Open External URL”.
2. Format the URL Explicitly
Sometimes Android gets confused if the dynamic URL pulling from your database doesn’t explicitly start with the secure protocol or has trailing spaces.
Double-check that your Sheet URL field in the database definitely starts with https://.
In your Bubble expression, try adding the :trimmed operator at the end: Current item's Service Opportunity's Sheet URL :trimmed(This ensures no accidental spaces are breaking the Android intent).
3. The Target=“_blank” Workaround
If your wrapper doesn’t have a dedicated plugin action, the standard Bubble “Open external website” action sometimes fails on Android because it tries to open the link in the current window (which Android’s WebView blocks).
You can force it to open a new tab/browser by doing this:
Instead of using a workflow on a tapped group, use a standard Bubble Link element.
Style the Link element to look invisible (no text, background transparent) and place it directly over your ShortListItem A.
Set the Link’s destination to External, pass it your dynamic URL, and critically: Check the box that says “Open in a new tab”. Android’s WebView is much more likely to hand this over to Chrome.
Thank youf ro the response - but that’s just what Gemini or ChatGPT says. I already tried that. Those solutions don’t apply to the options within Bubble Mobile.
I have a published Mobile Native Android app that includes external links to regular web pages. I confirmed that there’s no issue right now with the external link properly opening in Chrome on my build.
Testing on a Galaxy S20.
Couple of things you might test:
Does a regular link have the same issue? (Maybe it’s something specifically with the spreadsheet link)
What does the link look like if you just output it? Is it definately formed correctly?
Does your app, the chrome app, or the phone OS itself need an update? All the most current versions?
It’s happening to me as well—not only on Android, but also on iOS. I haven’t been able to find a solution yet.
As a workaround, here’s what I’m doing:
Since I can’t open an external website, I created a workflow that sends the user a message containing the same link that would normally be opened by the app.
For me, it’s been a reasonable workaround because it also helps keep users engaged on WhatsApp.
I use the same approach for payment links (via WhatsApp) and for support requests. In the latter case, it creates the impression that the support team has proactively reached out to the user.
