If your end-redirect is set to an Instagram or Facebook page, some guests will see it load successfully while others won't. This isn't caused by Wireless Social or a misconfiguration on your account, it's a device-level restriction that affects all captive portals. If reliable delivery of your post-connection content matters, redirect to a standard website page instead of a Meta-owned page.
What's actually happening
When a guest connects to your WiFi, their device opens a small browser window known as the captive portal browser - on iPhones, this is the Captive Network Assistant. Your guest signs in, and Wireless Social then redirects them to whichever URL you've set as the end-redirect.
Up to that point everything works the same regardless of the destination. The issue starts when the destination page itself tries to open the Instagram or Facebook app on the device rather than displaying as a web page. Meta-owned pages frequently attempt this handoff, and the captive portal browser on iOS and some Android builds blocks app launches from within that environment.
The block is intentional. It's there to stop a malicious WiFi network from launching, for example, a banking app and trying to interact with it before the user has fully joined the network. The trade-off is that legitimate handoffs to Instagram and Facebook get caught up in the same restriction.
Why it works sometimes and not others
This is the part that often causes confusion, because the behaviour isn't consistent. Whether the app handoff is triggered depends on the specific Meta page being loaded, the device's operating system version, and the state of the captive browser at that moment. You might visit a venue, get redirected to their Instagram page, and have it load perfectly, then visit another venue with the same setup and find it doesn't. We see the same thing across our customer base.
Reliable alternatives to Meta pages
If reaching guests with content after they've connected is important to your marketing, set the end-redirect to a standard web page rather than a Meta-owned page. A few options that work reliably:
A page on your own website - your homepage, a current promotion, a booking page, or a what's on page. This is the most reliable option and gives you full control over what guests see.
A landing page that includes links out to your Instagram, Facebook, TikTok and other channels. This way you still surface your social presence, but the initial redirect lands on a page that won't trigger the app-launch restriction.
A third-party link aggregator, such as Linktree or Beacons, which behaves like a regular web page and won't attempt an app handoff.
Frequently asked questions
Is this a bug on Wireless Social's side?
No. Our service successfully completes the redirect - the restriction kicks in afterwards, at the device level, when the destination page tries to invoke an app. We have no way to override device-level captive portal behaviour.
Will this be fixed in a future update?
This is a deliberate security measure controlled by Apple and Android manufacturers - it is not expected to change. The reliable path forward is to redirect to a page that doesn't try to launch an app.
Does this affect other social platforms?
The same underlying restriction applies to any destination that tries to launch a native app from inside the captive portal browser. In practice, we see it most often with Facebook and Instagram because they aggressively prompt users to open content in the app. Most other destinations behave as standard web pages and aren't affected.
Can you change my end-redirect for me?
You can edit your end-redirect via the Wireless Social platform; but get in touch with our support team or your account manager if you need any assistance.
The redirect worked for one guest but not another - is it reliable?
Unfortunately not in a way you can rely on. The same redirect can succeed for one guest and fail for another on a similar device. If a guest reports it didn't work, that report is still valid even if others had no issue.