What each link does
| Link | Behaviour |
|---|---|
about.html, #/settings | Navigates inside the app; back returns |
https://other-site.com | Loads inside the app (online only); back returns to your page |
target="_blank" or window.open() | Opens a full-screen pop-up window over the app; back closes it |
tel: mailto: sms: geo: market: intent: whatsapp: | Pro: opens the dialler, mail app, Maps… · Free: shows an error page |
wa.me, api.whatsapp.com, t.me, m.me, play.google.com, maps.google.com, maps.app.goo.gl | Pro: opens WhatsApp, Telegram, Messenger, Play Store or Maps · Free: loads the website inside the app |
"Loads inside the app" is usually what you want for your own pages and often not for anyone else's: a user reading a news article inside your app has no address bar and may not realise they left. Keep external links to a minimum, and for app-style actions prefer the link forms in the last row, which Pro hands off to the right app.
Contact buttons that just work
<a href="tel:+15551234567">Call us</a>
<a href="mailto:hello@example.com?subject=Order%2042">Email</a>
<a href="https://wa.me/15551234567?text=Hi%21">WhatsApp</a>
<a href="https://maps.google.com/?q=Eiffel+Tower">Directions</a>On a Pro build each of these opens the phone's own app. On a free build, prefer the https:// forms (wa.me, maps.google.com), which at least load a working page instead of an error.
Downloads
The app has no download manager. A link with the download attribute, a blob: or data: URL generated by your code, or a server response with Content-Disposition: attachment does nothing visible. Workarounds, by use case:
- Letting the user keep some text or data — show it on screen with a Copy button (
navigator.clipboard.writeText). - Sending a generated file to someone — upload it to your server and share the resulting https link via
mailto:or wa.me. - Exporting app data for backup — sync it to your backend, or show it as JSON the user can copy.
- Images — the WebView has no long-press "save image" menu. Show the image full-screen so the user can take a screenshot, or share its hosted https URL.
PDFs and printing
Android WebView cannot display PDF files, and window.print() does nothing. For documents the user reads, render them as HTML pages in the ZIP, or use PDF.js (bundled) to draw them on a canvas. For receipts and tickets, an HTML page designed for the phone screen beats a PDF anyway.
Pop-ups and OAuth windows
window.open() opens a separate full-screen WebView. Simple pop-ups (a terms page, a help article) behave as expected; payment and sign-in flows that depend on the pop-up talking back to its opener may not complete, and many providers refuse embedded WebViews outright (see sign-in methods). Prefer redirect-based flows, and test every third-party pop-up on a device before relying on it.