The full answer
Every deadline that could end your protection is stamped and held on the server: a request to end protection, the wait before it is ready, the release at the end of it and the lapse window. So is the deletion delay's wait. Your phone reads those answers and applies them, and the code that removes protection can only run from a release the server granted. Three things end on the phone itself, and none of them ends your protection: the Games wait of 72 hours, the end of a Lockdown run, and a run ended sooner after a 3 hour wait when you have no keyholder.
The split, in one line
The server decides when. The phone decides how. Everything that could end your protection is a deadline or a state on the server, and the phone's job is to keep what it was told applied and to ask again whenever it can.
That is not a description of good behaviour. It is the shape of the code: the one function that removes protection can be reached from exactly one place, and that place is a release the server granted. No timer on the phone can end your protection. Three phone clocks end one layer each.
What the server owns
The whole list, and it is short. Whether you are protected. Whether a request to end protection exists, and whether your keyholder said no or yes. The moment the wait before it is ready finishes. Whether the request is ready and whether you have ended protection. The window after a payment lapse. The wait that releases the deletion delay. And the list of gambling domains site blocking answers for.
Your phone hears about all of that in three ways, which exist so that one of them failing is not a hole: a live connection while the app is open, a silent push that nudges it to look, and a check every time you bring the app to the front. When none of them can reach the server, nothing the server holds changes, which on this product means your protection stays exactly where it was.
Why a number on the screen ends nothing
Every deadline the server holds is a stamp it wrote, and the numerals on your screen are a reading of that stamp rather than a timer of their own. Your phone never sits waiting on one. Past the deadline and with no answer from the server yet, the page deliberately reads Checking, with Protection stays on, instead of showing zeros, because a finished count is not the same fact as a granted release.
The same applies to the app itself. Deleting Fold’em does not end your protection, because protection is not stored in the app. Signing back in brings the lock back exactly as it was, never weaker, and the phone is walked through granting Screen Time and picking its apps again because those permissions belong to the device and not to your account.
The phone does keep checking its own work. On every launch and every time you bring the app to the front, it verifies that Screen Time permission is still granted and that the settings it wrote are still on the phone, and it silently writes them again if they are not. What it writes is derived from the record, not from anything the screen is showing, so the repair always follows the server rather than the other way round.
What that looks like at the one moment it matters
-
The server says the request is ready
The wait finishes on the server, not on your phone, and the server marks the request as ready, so you may end protection. Today’s card reads Ready when you are, and the last step says how long it will wait for you.
-
Nothing comes off yet
Every app you blocked is still blocked at this point, every site still blocked, the deletion delay still whatever you set. An announcement is not a release, and the phone has no instruction to act on until you give it one.
-
Your hold asks, and the server answers
Hold to end protection sends a message to the server. The server can refuse it, and does, when the request has already closed. Only when it agrees does the grant come back and the protection lift. The phone gained a gate here, never a decision.
The three things the phone ends itself
There are three, all named rather than hidden, and none of them ends your protection.
The Games wait. Turning off Games blocking, on the Lock tab, starts a 72 hour wait counted on the phone’s own clock, and at the end of it Games opens without asking the server. You can stop the wait any time with Keep Games blocked.
The end of a Lockdown run. A run holds its layers until the time it was set to end, and then the phone takes them off by itself, whether or not the app is open. It takes off only what the run added, so the phone goes back to the protection you already had and never below it.
A Lockdown run ended sooner without a keyholder. With no keyholder who uses the app, you can end a run yourself after a 3 hour wait counted on the phone, which a run with 3 hours or less left has no room for. With a keyholder, ending sooner needs their yes to your request instead, which the server records, and it ends nothing until you end the run with a hold.
All three are allowed for the same narrow reason: the server never held these switches, so there is no server decision for the phone to contradict. None of them ends your protection, and none reaches anything else: a request to end protection, the apps you picked by name, site blocking and the deletion delay all stay exactly where they were. Every other release in Fold’em still comes from the server.
Why somebody would want this arrangement in the first place is the argument of when quitting gambling did not stick, rather than a question about the server.
What this does not do
Server authority is not surveillance, and it is not a remote control. Nobody at Fold’em can end your protection for you, and neither can your keyholder: support can neither shorten a wait nor end one. It also does not reach past this phone. A second device, a laptop, a betting shop and cash are all outside it, and no amount of authority on this iPhone changes that. What it buys is narrower and worth saying plainly: the phone in your hand cannot be argued into letting you out, by you or by anyone holding it.
Write to us and a person reads it. We answer within two working days, and we would rather hear the question twice than not at all.