Tiered WiFi Access for Gyms: What We Built (and What iOS Made Us Rethink)

Most WiFi projects for gyms start and end the same way: a password on the wall, shared with everyone, changed occasionally when someone complains. The gym we worked with recently had a more interesting ask — they wanted their WiFi to know what kind of member you were.

White card, Black card, or Platinum. Three membership tiers. Three different experiences. And they wanted the whole thing to feel like one tap inside their member app.

Here's what we built, what we learned, and what the production version looks like.

What the gym wanted

The brief was clear: a member opens the app, taps a button, and gets online. No passwords, no staff interaction, no friction. Speed and data limits should match their membership tier automatically:

| Membership | Download | Upload | Data / day | Session | |---|---|---|---|---| | White Card | 1 Mbps | 2 Mbps | 1 GB | 60 min | | Black Card | 2 Mbps | 5 Mbps | 3 GB | 60 min | | Platinum Card | 5 Mbps | 10 Mbps | 5 GB | 60 min |

The longer-term goal was to put this inside the gym's existing member app as a native component — not a link to an external page.

What we built

We built a working proof-of-concept: a three-tier portal where each membership card generates a real voucher code, live, tied to that tier's speed and data settings on the gym's Reyee network hardware.

In the demo, all three cards are shown side by side so the gym could compare tiers at once. In production, a member only ever sees their own button — not a choice of three.

The flow looks like this:

Member taps their button in the app
A code is generated instantly, tied to their tier
Member connects to the gym's guest WiFi
Member enters the code at the portal
They're online — at their tier's speed and data limits, enforced by the hardware

The code generation is fast. The backend integration talks directly to the Reyee/Ruijie voucher system, which is where the actual enforcement lives. The app is the front door; the hardware is the bouncer.

The wall we hit: why "silent connect" isn't possible

The original ask included the possibility of connecting a member silently — tap the button and just be online, no code, no portal step. We looked hard at this. It isn't achievable on modern phones, for reasons worth understanding.

MAC address randomisation. Both iPhones and Android phones now randomise their MAC address on every network connection. This is a deliberate Apple and Google privacy feature. For a pre-authorisation approach to work, our system would need to know the phone's real hardware address in advance and whitelist it on the router. Phones won't reveal that address reliably, and even if they did once, it changes on subsequent connections.

Apps can't join WiFi on a user's behalf. iOS and Android both restrict this explicitly. The user always has to select a network themselves. An app cannot silently instruct the OS to join a specific WiFi network.

The sequencing problem. The button gets tapped while the member is still on cellular or their home WiFi — before their phone has touched the gym's network at all. There's nothing to grant access to yet.

The captive portal expects a voucher. The network hardware's guest system is built to intercept a device when it first tries to load a webpage, then present a portal. Pre-clearing an unknown device bypasses the flow the hardware is designed around.

We designed around all of this, not through it. The voucher code approach works with the hardware's existing system, requires no special phone permissions, and functions identically on every device.

What we did instead

We made the code appear instantly — that's the part we could control.

The member still does the one unavoidable step: selecting the gym WiFi. But once they're on it, entering the code is quick, and the session is live within seconds. The latency isn't in the code generation (that's fast); it's in the phone joining a new network, which is a platform constraint we can't remove.

For a gym context, this is a reasonable trade-off. Members visit regularly, they know the network name, and connecting once takes under ten seconds. The friction is low. The tier enforcement is real.

What the production version looks like

The proof-of-concept has one obvious gap: there's no membership verification. Anyone could tap any tier. The production integration closes that.

The app supplies the tier, not the member. When a logged-in member opens the WiFi screen, the app already knows their card type. It sends that tier to the voucher request — the member never sees a dropdown or makes a choice.

Verification happens server-side. The voucher request goes through the gym's own backend before it reaches our system. That way the tier can't be spoofed by manipulating what the app sends.

One button per member. The final UI is a single button — "Connect to gym WiFi" — with no visible tier information. The tier is handled invisibly.

Packaged as a drop-in component. The whole flow is built to slot into a member profile screen or home dashboard. The gym's development team gets an endpoint to call and a component to place — they don't need to know how the voucher system works underneath.

What this means for other operators

Gyms are an obvious fit for tiered WiFi, but the model applies anywhere membership or loyalty tiers exist. A hotel with standard and premium rooms. A co-working space with hot-desk and dedicated memberships. A golf club with visitor and member access.

The hardware to support this — Reyee, Ruijie, MikroTik — is already in place at most professionally-managed venues. The voucher system it runs on is built for exactly this kind of tiered access. What's usually missing is the bridge between the membership system and the network hardware.

That bridge is what we build.

If you're running a venue with a loyalty programme, a membership card, or a tiered service model — and your guest WiFi doesn't know the difference between your best customers and a first-time visitor — get in touch. It's a more straightforward integration than it sounds.