Why the iOS Sandbox Kills Classic Poker-Bot Architectures

A walkthrough of the three things a bot needs from the OS — and the three ways iOS refuses to give them.

If you're coming from the homepage, you already know the bottom line: a classic poker bot needs to read another app's screen, drive its inputs, and run for hours in the background. iOS denies all three. This page is the longer version — what specifically Apple disallows, and why those denials are structural rather than accidental.

1. There is no accessibility-API equivalent

On Android, the technology that makes most modern poker bots possible is the Accessibility Service. It exists so screen readers and assistive tech can see and interact with any app. Bots use it because it's the only sanctioned way for one app to observe and tap another app's UI. It's a public API, documented, and you can ship a bot that uses it without rooting the device.

iOS has nothing like this. The closest things on the Apple side are VoiceOver, which is system-internal and not exposed to third-party apps, and UI Automation / XCTest, which only works against your own apps under your own signing identity and only in a development context. There is no public, shipping-app entitlement that lets you, the bot author, inspect or drive a different app's UI. Not for accessibility, not for testing, not for anything.

2. Background execution is on a budget

Even if you somehow got your bot's brain onto the device — say, as a coprocessor that talks to a server — you'd want it to keep running while the poker app is in the foreground. iOS broadly does not allow that for unrelated apps. Background modes exist (audio, location, VoIP, background fetch, background processing), and each one is narrow, audited at App Store review, and budgeted by the OS. The system can suspend or terminate your app at any time to free memory or save battery, and "I'm running an automation engine" is not a background mode you can declare.

The practical result: a "bot app" on iOS that you minimize will, within seconds to minutes, stop being a process you can rely on. The watchdog kills it, you have no recourse, and the user sees nothing.

3. App Store review will not ship this

Suppose, hypothetically, that you wrote a self-contained poker app — your own client, your own bot logic, all in one binary — to dodge the inter-app problem. You still have to get it through App Store review. The Guidelines are explicit about gambling: real-money gambling apps need a developer entitlement that requires legal registration with each jurisdiction, geofencing, age-gating, and operator licensing. A self-built poker client without those things gets rejected. A self-built bot for someone else's poker client gets rejected harder — that's automation against a third-party service, which violates the Guidelines on multiple counts.

TestFlight does not save you. TestFlight builds also go through review (a lighter one, but a review). And TestFlight is capped at 10,000 testers per app — a structural ceiling that, combined with the review, is incompatible with the way "download and run" software gets distributed at scale.

The structural part

People sometimes ask whether Apple might loosen this stuff in a future iOS, the way the EU's DMA enforcement opened up sideloading in Europe. Realistically: no. Sideloading lets you install an app outside the App Store; it doesn't grant new system permissions to the app once installed. The sandbox is older than the store, deeper than the store, and is the single feature Apple sells to enterprise IT and to parents. It is not going to grow a permission shaped like "let this app drive other apps and run forever."

Which leaves us with the next page: what actually works on iOS — the narrow stack of things you can do without fighting the sandbox.