Your guest portal still fails on an iPhone. There has been a standard fix since 2020, and your infrastructure probably is not using it.
The fix is RFC 8908, the Captive Portal API. The network hands the client device a URL to a small JSON API, and the device asks plainly: am I captive, where is the portal, how much time do I have left. It gets a real answer instead of an inference.
The old way is a hack, and we have all been living with it. The device fires a probe at a known URL, the network hijacks the response, and the device guesses. That breaks under HSTS, it produces the "connected, but nothing loads" ticket, and it never tells the device anything about session state. As more of the web pins HTTPS, the hack degrades further.
Now the trap that burns people. Three of the biggest names in enterprise Wi-Fi each ship a proprietary thing called some variant of "Captive Portal API," and none of them is RFC 8908.
Cisco Meraki's "Captive Portal API" is EXCAP, its own external splash API. Ubiquiti ships an External Hotspot API. Aruba's captive portal API is its XML API for external user management.
All three are real, documented, useful APIs. None of them gives a client device the standardized captive and seconds-remaining state that RFC 8908 defines. When a vendor says "Captive Portal API," ask WHICH one.
The asymmetry is the actual story. The client half of this standard shipped years ago: Apple since 2020 with iOS 14 and macOS Big Sur, and Android 11. The infrastructure half is carried almost entirely by open source and smaller vendors. MikroTik serves the API. openNDS has served it since v9.5.0. Those are the implementations I can point you to as of July 2026, and I have not found a major enterprise WLAN platform that documents serving it. Absence of documentation is not proof of absence.
If your vendor documents one, send me the link and I will update this.
Your users' phones are ahead of your infrastructure.
Here is the cheap win you can take today. Option 114 is defined to carry your RFC 8908 API URL. On any platform that lets you set custom DHCP options, point it at your portal page over TLS instead. Even with no RFC 8908 API server behind it, current Apple and Android clients will still open that URL, which beats leaving them to the canary probe. It is a workaround, not the standard, and it works today.
Captive Portals Suck! They will keep sucking as long as the network makes the client guess.
If you have already set option 114 on a production guest network, what changed on the iPhones?