Rich no-app fallback
When the native app isn't installed, Hero+ links land on a beautiful fallback page — a preview of the destination, a big "open in the app" button, and a browser escape hatch — instead of a bare web redirect.
Rich no-app fallback
Every Zippy link tries to spring the right native app first. But sometimes the app just isn't there — a TikTok link on a phone with no TikTok, a Spotify drop on a fresh device. That's the fallback moment, and it used to be a shrug: dump the visitor on the bare web URL and hope for the best.
Not anymore. On Hero and up, that moment gets a page worth landing on.
When a visitor sees it
Only when the app-open fails. The flow:
- A visitor taps your short link on mobile.
- Zippy fires the deeplink to spring the native app.
- App installed? It opens. The visitor never sees anything else — same as always.
- App not installed? Instead of bailing to a raw web URL, the visitor lands on a clean, fast fallback page hosted by Zippy.
Desktop visitors and platforms with no native app skip straight to the web destination, same as before. The fallback page only exists for the one moment it's useful.
What's on the page
- A preview card of your destination — title, description, and image pulled from the destination's own OG tags, so the visitor sees what they're about to open, not a mystery URL.
- A big "Open in the app ⚡" button — one tap re-fires the deeplink. Half the time the first attempt fizzled because of an in-app browser or a slow wake-up; the second tap lands.
- A "Continue in browser" link — no app, no problem. One tap goes to the plain web destination.
- On links that carry Zippy branding, a small "zipped with Zippy" footer.
The page is served fresh every time (never cached, never indexed by search engines) — it's a hand-off, not a landing page you have to maintain.
Sidekick vs. Hero
| Plan | No-app behavior |
|---|---|
| Sidekick | Bails straight to the bare web URL. Functional, zero frills. |
| Hero & Legend | Lands on the rich fallback page — preview card, retry button, browser link. |
Upgrading flips the behavior on your existing links automatically. Nothing to re-create.
Your link never changes
The short link and its QR code are untouched. The fallback page lives on Zippy's cloud at
its own address (/f/<slug>) and the engine simply hands visitors there when the app-open
comes up empty. Printed QR codes, bio links, old posts — everything you've already shared
keeps working, it just fails prettier now.
Notes
- The fallback composes with everything else on the link: audience routing resolves the right destination first, UTM tracking tags stay on it, and a password gate still comes before anything else.
- The preview card uses the destination's OG tags. If the destination has thin or missing tags, the page still works — the button and browser link don't depend on the preview.
- The "Open in the app" button picks the right store-flavored deeplink for the visitor's device (iOS vs. Android) automatically.
Read more
- Blog: When the app isn't there, Zippy catches the fall
- Changelog: Rich fallback page
- What the page can ask for while it's there: email capture.