# How one developer turned PureGym access into an Apple Wallet pass
A reverse-engineering write-up says the gym’s QR flow is clumsy, while its API and access model are unexpectedly easy to probe.
A long technical write-up about PureGym’s access flow has turned a routine gym-entry annoyance into a software story. The author says he reverse engineered the company’s API so he could build a working Apple Wallet pass, then documented the process with PassKit, Vapor and mitmproxy. What starts as a complaint about a slow, awkward QR-code workflow quickly becomes a lesson in how much friction people will tolerate before they start building their own tools.
The story’s opening complaint is familiar to anyone who has tried to enter a building through a mobile app. The writer describes connecting to gym Wi-Fi, waiting for the app to load, navigating through irrelevant offers and notifications, and then waiting again for the access QR code to appear. The QR code is not static either. The post says it refreshes every 60 seconds, making a screenshot useless. That is enough to make the experience feel both inconvenient and oddly theatrical.
The most striking part of the write-up is the security contrast. The author says he had been using the same 8-digit PIN at PureGym turnstiles for eight years, while the digital QR code refreshed constantly. He calls that security theatre, and the phrase fits because the app’s most visible security layer is the least convenient one while the physical keypad stays unchanged for years. The post then says the API’s authentication endpoint revealed what looked like a bare-bones setup, including a Base64-decoded credential that exposed ro.client with no meaningful secret attached.
From there, the article shifts into the mechanics of the reverse engineering. The writer says he used proxy tools to intercept app traffic, then confirmed how the API responded and when refreshes were expected. That part matters because it turns a frustration story into a technical one: the point was not just to complain, but to understand the system well enough to reproduce it in another form. The resulting pass did not depend on a static screenshot; it updated dynamically.
The Apple Wallet angle is the other half of the story. The post explains that Wallet passes are not just static cards. They can update themselves, send push notifications and react to location, which is why a gym pass can become a pass that appears when the user is near a site. The writer says he built the backend in Vapor and used silent push notifications so the QR code could update without the user doing anything. He also scraped coordinates for PureGyms across the UK so the pass could trigger near the right locations.
That mix of convenience and spectacle is part of why the write-up got attention. It is not only a reverse-engineering post; it is a demonstration of how everyday services can be remade if someone is motivated enough to inspect the API and work through the platform details. The result is a pass that reduces the entrance ritual to a wrist scan, but it also highlights how much complexity was hiding behind the original app flow.
The broader takeaway is less about gym access and more about product design. If users are willing to go through a whole technical adventure just to avoid a loading spinner, that is usually a sign that the original user experience has a problem. The write-up shows one developer solving that problem for himself, but it also shows how small access systems can reveal larger questions about security, convenience and why some digital gates feel harder to use than the physical ones they are supposed to replace.
