iDeck: bringing real Steam Big Picture to an iPhone, one compatibility bug at a time

My Steam backlog has plenty of games. My pocket has an iPhone. I've been exploring whether the two can meet without a streaming PC.

I'm maintaining iDeck, an experimental, AI-assisted project built on Will Faust's Madeira. DroidDeck inspired the handheld experience; iDeck is independent and is not its official iOS port.

The real client, on the device

iDeck runs Valve's actual Windows Steam client, including Big Picture, through Madeira's Wine/FEX/Metal runtime. Compatible PC games execute locally. This is neither a replica Steam UI nor Linux SteamOS installed on an iPhone, and translated Windows code is not magically ARM-native application code.

The README contains an on-device demo, explicitly shown at 1.5× speed. On an iPhone 15 Pro Max, genuine sign-in/Steam Guard, saved-login reuse, Big Picture library browsing and PC game startup have been observed; gameplay has also been reported by the tester. iPad is a target, not a validated device.

A surprisingly small query with a large blast radius

One startup failure illustrates why this is still research. An exact shipped WoW64 instruction wrote through a null PEB32 result at an offset of 0x480. The current-process ProcessWow64Information query used session-global state that a sibling pseudo-process could clear or replace during startup.

The isolated experimental correction resolves the calling TEB's owner and its bound WoW window instead of trusting the session-global pointer. A production-function host test under ASan/UBSan exercises concurrent WoW owners, a native owner, foreign/null legacy values and disabled gates. It does not establish that every CEF failure is fixed.

The important distinction: a successful build proves compilation. A marker in the final Mach-O establishes that the changed implementation was linked. Steam's Success/OK and BrowserReady logs establish specific runtime events. None alone establishes a visible, responsive home screen. The repository records these boundaries instead of treating every log line as a milestone.

See the architecture audit and login/transition evidence.

What is still rough

Game compatibility is limited. Startup and post-login transitions can hang. Controller enumeration is not proof that Steam or a game responds correctly; Bluetooth, return-to-Steam and long-session stability need more validation.

The public release is source-only: no ready IPA, Valve client, games, credentials or signing profiles. Runtime dependencies must be prepared separately, so a reproducible clean setup is unfinished. JIT uses Madeira's authorized pairing/debug workflow. Steam remains responsible for authentication and ownership checks.

Where contributors could help

• Reproducible dependency preparation and clean builds.
• Small isolated tests for CEF and pseudo-process lifecycle failures.
• Repeatable physical/virtual controller tests with precise device/build reports.

The project uses AI assistance for development and documentation. The runtime foundation belongs to Madeira and its contributors, plus Wine, FEX, DXMT and the other credited components. Their notices and component licensing are retained; see CREDITS, NOTICE and the distribution notes. This is not a claim of upstream endorsement.

Source, demo and current limitations. If you've worked on compatibility layers, what would make this repository easier for you to reproduce and contribute to?