On this page
You shipped Sign in with Apple because it's the lowest-friction signup you can offer an iOS user — one Face ID prompt, no password, no email-verification round trip. Then you put the link in your Instagram bio, your TikTok bio, the link sticker on a Story, and you watched the funnel. The click-through is healthy. The signups are not. And the drop is concentrated in exactly the cohort you'd expect to convert best: warm, mobile, Apple-device traffic that came in through content they chose to watch.
What's happening is that the Sign in with Apple sheet never appears. The viewer tapped your link inside the Instagram in-app browser, your auth screen loaded inside that webview, they tapped "Sign in with Apple," and nothing usable happened — a blank popup, a redirect that dead-ends, or the SIWA flow opening in a context it can't complete. They back out. In your analytics it reads as auth-screen abandonment. It is not a UX problem with your auth screen.
the conversion problem iOS product teams face
Sign in with Apple depends on the system's authentication context — the device-level identity that lives in the real browser and the OS, not inside a sandboxed embedded webview. When a user taps your bio link from inside Instagram, TikTok, Snapchat, or Threads, the platform opens your auth page in its own in-app browser. That webview is a stripped-down WKWebView instance with its own cookie jar, restricted popup handling, and no reliable bridge to the SIWA flow that Safari and your native app rely on.
So the user who is most qualified to sail through Sign in with Apple — they're on an iPhone, signed into iCloud, Face ID armed — hits the one auth method that the in-app browser is worst at. The popup window.open SIWA tries to spawn gets blocked or orphaned. Apple's appleid.apple.com redirect lands somewhere the webview can't return from. If you've also wired Google OAuth, that frequently breaks too — Google explicitly blocks OAuth in many embedded webviews with a disallowed_useragent error. The user sees a broken auth screen and reads it as "this product is janky," not "Instagram's browser ate the handshake."
We named this problem the vanishing visitor and wrote the full mechanism explainer there. The version for product teams: the auth context that makes Sign in with Apple a one-tap signup lives in the user's real browser and the OS. Your bio link opens inside the platform's webview, which has neither. The SIWA sheet that should appear doesn't, the OAuth redirect that should round-trip doesn't, and the signup that your CAC model assumed would close silently never enters the funnel.
what this costs
You can't see this loss in your auth provider's dashboard, because the failed attempts mostly don't reach your backend — they die in the webview before a token is ever issued. What you see instead is a depressed signup rate on social-sourced traffic and a CAC that looks worse than your content actually earns. Teams who instrument it find that a large share of social-sourced iOS sessions never complete any auth method, with SIWA and Google OAuth failing at far higher rates than email signup precisely because they depend on the popup and redirect behaviors the webview suppresses.
The structural pattern is consistent across products: when in-app-browser traffic is a meaningful share of your top-of-funnel, routing it through a real-browser escape typically recovers signups in the range of what your paid-traffic conversion rate would predict, rather than the fraction the webview lets through. The honest framing is that the recoverable number scales with how much of your acquisition leans on social links and how hard your signup depends on SIWA or OAuth — but for a mobile-first product pointing Instagram traffic at a Sign in with Apple button, it is rarely small.
what linkboo does
linkboo replaces the URL in your Instagram, TikTok, Threads, or Snapchat bio (and Story link stickers, and the link in any creator or influencer post promoting your app) with a link-in-bio page — or a single direct-route link, your choice — that has the in-app browser escape flow built into every outbound click. When a user taps your linkboo URL from any in-app browser, linkboo detects the webview and immediately bounces the destination out to the user's real browser — Safari on iOS, Chrome on Android — where the system auth context lives, before your auth or onboarding page loads.
The user never sees a friction prompt and never has to know what "open in Safari" means. They tap, your page opens in Safari, they tap Sign in with Apple, the native sheet appears, Face ID confirms, they're in.
Concretely, for iOS product teams this means:
- Sign in with Apple actually renders — the SIWA sheet opens in Safari's auth context instead of dying in a blocked webview popup
- Google and other OAuth redirects round-trip cleanly — no
disallowed_useragentdead-ends from the embedded browser - Universal Links can hand off to your installed app — once you're in Safari, a Universal Link can open your native app directly instead of staying trapped in the webview
- Returning users land already authenticated — their existing session cookie lives in Safari, so they skip the login wall entirely
linkboo is also a full link-in-bio page — multiple links, themes, your logo, the things you'd expect from a Linktree or Beacons alternative — so it works as the single bio destination for your whole funnel. The escape flow is the wedge.
the destinations where iOS product teams bleed the most
Deep writeup on the specific mechanism:
- Sign in with Apple fails in the Instagram in-app browser — the missing system auth context, the blocked SIWA popup, the orphaned
appleid.apple.comredirect, and exactly how the real-browser escape restores the native sheet
If you also route to Google OAuth, magic-link, or passkey-based signups, the mechanism is identical — the webview can't complete the system-level handshake — and linkboo's escape flow applies. The full destination index is here.
why not Linktree, Beacons, or a raw bio URL?
None of them have an in-app browser escape flow. They're link-in-bio pages. When a user taps a Linktree URL from Instagram, your auth page opens inside Instagram's webview exactly as a raw URL would — the Sign in with Apple sheet still won't render, the OAuth redirect still dead-ends. Putting a generic link-in-bio page in the middle changes nothing about the auth context; the structural signup loss is identical with or without it.
If you're comparison-shopping the broader category, linkboo vs Linktree is the closest mainstream comparison.
pricing
Free up to a real volume of monthly clicks. No per-click pricing — which matters when you're routing top-of-funnel acquisition traffic and don't want a tax on every tap. The escape flow works on the free tier; it converts as well as the paid tier on the thing that actually moves signups. See plans.
adjacent pages
- /for/saas-founders — same auth-funnel leak, framed for the whole SaaS signup flow
- /for/passkey-products — passkey and WebAuthn signups, which break in webviews for the same context reason
- /for/magic-link-products — magic-link auth and the email round-trip that bounces back into the wrong browser
- /for/oauth-developers — the
disallowed_useragentproblem in depth, for teams leaning on Google/social OAuth - /for/instagram — Instagram-specific deep coverage if it's your dominant acquisition channel
The user who tapped your link wanted to sign up, and they were on the exact device Sign in with Apple is built for. Don't let Instagram's webview be the reason the sheet never appeared.