willfaust

iPhone Duo is the best console i've played rocket league on After playing on PS4, PS5 and Switch 2 for years, i can confidently say that the game runs way smoother, with almost zero input lag on my new iPhone Duo, and it does that while running inside a simulated Windows environment using wine. local on device, no streaming or anything. I am amazed. I used willfaust/madeira (version 0.2.0), sideloaded with a developer account for extended jit memory - works flawlessly - apart from EAC that doesn't work, so no online matches for now :(

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?

Dark Souls на iPhone: что пришлось починить в Madeira, чтобы игра с ПК вообще запустилась Я с конца сентября запускал PC‑версии Dark Souls на iPhone Air через эмулятор Madeira. Remastered теперь играется с экранным геймпадом, у Dark Souls III в тяжёлых сценах медиана выросла с примерно 20 до 36,7 FPS на экспериментальной сборке. По дороге набралось 5 принятых и 11 открытых PR в Madeira, Wine, FEX и DXMT и репозиторий со скриптами, который я теперь выкладываю. Оговорка сразу: у меня один телефон (iPhone Air на бета‑версии iOS 27.2), один тестер, то есть я, и все цифры ниже снимались на этом устройстве. Игры у меня свои, купленные. В репозитории нет ни игровых файлов, ни сейв‑редакторов, ни обхода защиты, и принимать такое я не буду. Что это за зверь Madeira запускает Windows‑программы под x64 прямо на iPhone. Внутри три слоя: FEX‑Emu переводит x86-64 в ARM64 на лету (JIT); Wine даёт игре привычный Windows API; DXMT превращает вызовы Direct3D 11 в Metal. Для JIT на неджейлбрейкнутом телефоне я пользуюсь StikDebug: встроенный помощник Madeira требует отдельный App ID, и скрипт подписи его убирает. Сам проект сильный, но «просто поставить и запустить» с тяжёлой игрой не выходит. Нужно знать, с какими правами переподписывать приложение, какие из десятков ключей конфига реально что‑то меняют и как по логу понять, чем именно всё упало. Вот эти неписаные знания я и записал, а скучное автоматизировал. Dark Souls Remastered: восемь граблей подряд Работал я с 27 сентября по 19 октября 2026-го. Каждый шаг был одинаков: один запуск, один лог, одно изменение. Лог разбирает небольшой скрипт tools/analyze-log.py: что Madeira реально приняла из окружения, в каком порядке загрузились модули, какие были исключения с регистрами, поднялись ли графика, окно и звук, чем всё закончилось. Полная таблица с причинами лежит в docs/bugs‑and‑fixes.md. Здесь расскажу про те, что запомнились. Падение при старте, c0000018. У exe фиксированная база ниже 64 МБ, а ему нужно окно по адресу 0x140000000, и оно не выдавалось. Это уже было исправлено в апстриме (Madeira #111), мне осталось его подтянуть. Падение после первых записей в код. Игра защищена слоем, который переписывает собственный код во время работы, и на этом всё падало. Причиной оказалась утечка в Wine: на пути возврата [exec-req] в ntdll для ARM64EC не вызывался leave_syscall_callback(), и флаг «мы внутри системного вызова» оставался взведённым. Исправление в одну строку, wine #18, принято. Падение в steamclient64, c0000005. Тут интереснее. Клиент Steam сужает HMODULE до 32 бит, а на iOS нельзя отобразить память ниже границы в 4 ГБ, поэтому модуль живёт по высокому адресу и после усечения указатель никуда не ведёт. Я сделал так, чтобы образу с «суженной» базой выдавалось низкое имя, а VirtualQuery сообщала свободной только ту память, которую реально можно занять. Это Madeira #385, он пока открыт. Из‑за этого моя сборка для телефона — это апстрим плюс один ещё не принятый коммит, без которого DSR падает на старте. Падение при поиске папки настроек. В Wine‑профиле C:\users<user> просто не было AppData. Папки создаются скриптом (device.py profile fix), его же вызывает apply-config.sh. Геймпад: три бага в одной цепочке Это заняло больше всего времени, потому что симптомы были разные, а виноваты были три независимых места. Игра геймпад не видит. В папке игры лежит собственный xinput1_3.dll, и загрузчик брал его вместо встроенного. Правка: загрузчик предпочитает встроенный XInput (wine #19, принят). Игра геймпад видит, но игнорирует. Окно игры не было активным, а на iOS его активировать просто некому. Теперь win32u делает главное окно процесса активным, пока оно опрашивает XInput (Madeira #149, принят). Касание мимо экранной кнопки превращалось в клик мышью. Теперь пока показана раскладка геймпада, такие касания мышью не считаются (Madeira #150, принят). Помогли две вещи: адреса возврата в диагностике и логирование цепочки нажатий клавиш. По ним и нашёлся разрыв. Такие диагностические патчи я теперь держу под рукой. Вылет через 35 секунд в меню настроек Это был собственный сторож эмулятора. Он считал обработанные записи самомодифицирующегося кода накопительно, а в меню настроек игра переписывает код каждый кадр, по семь клавиш по кругу. До порога в 2000 дело доходило как раз за полминуты, и процесс убивался. Теперь считаются только подряд идущие одинаковые сбои на потоке (Madeira #148, принят). После этих правок меня указали в Settings › Credits самой Madeira: «Controller fixes … and a crash‑guard fix». Из этой серии я вынес одно правило: проверяй, что реально загружено, а не что написано в конфиге. Размер образа и базовый адрес в логе врут реже, чем файл настроек. И второе: чистая сборка на CI лучше «сборки из того, что было». Одна моя сборка, собранная из смеси старых и новых частей, падала в signal_set_full_context, а чистая с CI — нет. Dark Souls III: от 20 до 36,7 FPS DS3 тяжелее. Steam в нём ставится изнутри Madeira (Madeira Dock) со своим аккаунтом. На заставках 60 FPS, в бою на дефолтных настройках 17–20. Дальше началась работа с измерениями. Я разбирал логи по фазам: FPS, загрузка GPU, частоты ядер, число draw‑вызовов на кадр. Парсеры лежат в tools/ds3perf/, а выводы с пометками «факт» и «версия» — в docs/perf/, там 22 заметки на русском. Телефон нагревается и режет частоты Самая неприятная находка из DS3-POWER.md. В одной из длинных сессий на первых секундах игры P‑ядра работали на 2,8 ГГц и давали около 34 FPS. Примерно на 59-й секунде включился зажим: частота ушла к 1,8 ГГц, а медиана FPS упала до 20,6. На 175-й секунде iOS объявила термальное состояние serious, и это уже ничего не поменяло. Так что любая оптимизация меряется только на горячем телефоне, иначе цифры красивые и бесполезные. Что сработало Пакеты изменений я называл по буквам. Таблица из docs/compatibility.md, медиана в тяжёлых сценах: Шаг FPS Что поменялось базовый набор C2 ~17-20 разделение пулов, без копирования образа, «осиротевшие» блокировки помечаются G1 21,5 облегчённая диагностика, синхронизация внутри процесса, быстрый путь критических секций для x64, окна записи для «горячих» страниц кода H2 36,7 повторное использование буферов и списков команд в DXMT, быстрый TLS, облегчённые SRW‑блокировки, QoS потоков по имени Для H2 в тяжёлых сценах: медиана 36,7 FPS, p10 28,8 в первые минуты 12-минутного прогона. После прогрева, когда P‑ядра сидят на 1,31 ГГц, держится 32–34 FPS. GPU при этом занят примерно на 88%, то есть упираемся теперь в него, а не в процессор. Теперь честная часть. Цифра 36,7 — это сумма нескольких изменений. Вклад каждого по отдельности я не мерил, и в каждом PR это написано прямо. На G1 был прогон на 26 минут без зависаний с медианой 21,5. Что я проверил и отбросил: MetalFX: стало хуже; pool-low: стало хуже; пропуск записей самомодифицирующегося кода с теми же байтами: бессмысленно, потому что 93% записей байты меняют. Отдельно про DXMT. Оказалось, что он создаёт около тысячи Metal‑буферов на кадр и примерно 50 раз за кадр выделяет и освобождает по 2 МБ под списки команд. Два ключа (DXMT_DYN_KEEP и DXMT_CMDLIST_KEEP_BLOCK) убирают эту суету, оба выключены по умолчанию (dxmt #42, #43). Чёрный экран и зависание в DS3 Два отдельных бага DXMT, оба описаны в DS3-CRASH.md и DS3-FREEZE.md. Чёрный экран: на запрос описания SRV для «всех мип‑уровней» DXMT отдавал MipLevels = -1. Игра берёт это число как количество уровней и выделяет по нему массив, после чего падает. Теперь возвращается разрешённое значение (dxmt #40). Зависание DS3: бэкпорт исправления из 3Shain/dxmt, где циклы маршалинга аргументов отрисовки для GS/TS не продвигались (dxmt #41). Геймпад и сохранения в DS3 я полноценно не проверял, в репозитории это написано в разделе «не тестировалось». Что в репозитории Репозиторий madeira‑kit — это обвязка вокруг цикла «сборка, подпись, установка, настройка, запуск, чтение лога, одно изменение». Тут нет форка Madeira: фиксы я отправлял апстриму, а в patches/ лежат только справочные копии. unpack.sh, swap-dll.sh, sign.sh, install.sh: распаковать сборку, подложить патченые DLL, переподписать своим сертификатом, поставить с сохранением данных приложения; doctor.sh: проверка перед запуском (телефон виден, приложение стоит, свободно не меньше 3 ГБ, копия игры на месте); apply-config.sh: загрузить madeira.cfg, прочитать обратно и сравнить, создать недостающие папки профиля; pull-log.sh и analyze-log.py: забрать лог и сразу разобрать; готовые профили для DS1 и DS3 в configs/. Минимальный путь выглядит так: git clone meshoklv/madeira-kit && cd madeira-kit cp scripts/config.example.env scripts/config.env && $EDITOR scripts/config.env scripts/unpack.sh ~/Downloads/Madeira-build.zip && scripts/sign.sh && scripts/install.sh scripts/doctor.sh scripts/apply-config.sh configs/ds1-play.cfg смахнуть Madeira, включить JIT в StikDebug, запустить игру scripts/pull-log.sh first-run sourcecraft.dev Понадобятся Mac с Xcode command line tools, iPhone по USB, сертификат и профиль для вашего bundle id и pip3 install pymobiledevice3. Entitlements на расширенную память и расширенное виртуальное адресное пространство требуют платного аккаунта разработчика. Если собираете Madeira на GitHub Actions сами, грабли описаны в docs/guide.md: LLVM только статическими библиотеками, TUNE_CPU=cortex-a78 для FEX, заглушка для ri_page_wait_time_mach. Windows‑часть DXMT этот CI не пересобирает. Чего я не знаю Скрипты в репозитории — мой рабочий конвейер, из которого я убрал личные идентификаторы. После этого я проверил синтаксис, но целиком на устройстве их не перепрогонял. Другие модели iPhone и версии iOS не проверялись, как и свежий клон репозитория на второй машине. FPS и нагрев в самой Dark Souls Remastered я не замерял, только «играется». Все цифры по DS3 — один телефон и считанные прогоны, чаще один прогон на конфигурацию. Бесплатный аккаунт разработчика может не дать нужных прав. Как помочь Если у вас другой iPhone или iPad, пришлите отчёт о совместимости: модель, версия iOS, игра, конфиг и результат. Принимаются профили с измеренными цифрами. Не принимаются кряки, файлы игр и всё, что обходит защиту. Часть кода и патчей я писал вместе с ИИ‑ассистентом (Claude) — в коммитах апстрим‑PR это видно по строке Co-Authored-By. Репозиторий: meshoklv/madeira-kit, лицензия MIT для скриптов и документов, патчи следуют лицензиям проектов, к которым они написаны. Issues и PR открыты. Заметки и новые сборки выкладываю в канале t.me. Если статья показалась полезной, звезда на репозитории поможет другим его найти. Mike Meshok

Running Dark Souls on an iPhone: what I had to fix in Madeira --- title: "Running Dark Souls on an iPhone: what I had to fix in Madeira" published: true description: "Notes from getting PC builds of Dark Souls Remastered and Dark Souls III to run on an iPhone Air through Madeira (FEX-Emu + Wine + DXMT), with the upstream fixes and measurements." tags: ios, emulation, opensource, gamedev cover_image: raw.githubusercontent.com --- Since late September I have been running PC builds of Dark Souls on an iPhone Air through the Madeira emulator. Remastered is now playable with an on-screen gamepad. In heavy scenes of Dark Souls III the median went from roughly 20 to 36.7 FPS on an experimental build. Along the way I collected 5 merged and 11 open PRs against Madeira, Wine, FEX and DXMT, plus a repository of scripts, which I'm publishing now. A caveat up front: I have one phone (an iPhone Air on iOS 27.2 beta) and one tester, me, so every number below comes from that single device. The games are my own, bought legitimately. The repository contains no game files, no save editors and no copy-protection circumvention, and I won't accept any. What Madeira is Madeira runs x64 Windows programs directly on an iPhone. It has three layers: - FEX-Emu translates x86-64 to ARM64 on the fly (JIT); - Wine provides the Windows API; - DXMT turns Direct3D 11 calls into Metal. For JIT on a non-jailbroken phone I use StikDebug. Madeira's built-in helper needs a separate App ID, and my signing script strips it. The project is strong, but "install it and run a heavy game" doesn't work out of the box. You need to know which entitlements to re-sign the app with, which of the dozens of config keys actually change anything, and how to tell from a log what went wrong. I wrote that unwritten knowledge down and automated the boring parts. Dark Souls Remastered: eight problems in a row I worked on it from September 27 to October 19, 2026. Every step looked the same: one run, one log, one change. A small script, tools/analyze-log.py, reads the log and reports what Madeira actually accepted from the environment, the module load order, exceptions with register dumps, whether graphics, window and audio came up, and how the run ended. The full table of causes is in docs/bugs-and-fixes.md. Here are the ones I remember best. Crash at startup, c0000018. The exe has a fixed base below 64 MB, but it needs a window at 0x140000000, and that range was not being handed out. This was already fixed upstream (Madeira #111), so I only had to pull it in. Crash after the first writes to code. The game is protected by a layer that rewrites its own code at runtime, and that made everything fall over. The cause turned out to be a leak in Wine: on the [exec-req] return path in ARM64EC ntdll, leave_syscall_callback() was never called, so the "we are inside a syscall" flag stayed set. A one-line fix, wine #18, merged. Crash in steamclient64, c0000005. This one is more interesting. The Steam client truncates an HMODULE to 32 bits, and iOS can't map memory below the 4 GB line, so the module lives at a high address and the truncated pointer points nowhere. I made an image with a "narrowed" base get a low-address name, and made VirtualQuery report as free only the memory that can actually be taken. That is Madeira #385, still open. Because of it, my phone build is upstream plus one unmerged commit, and without that commit DSR crashes at startup. Crash while looking up the settings folder. The Wine profile C:\users\<user> simply had no AppData. A script creates the folders (device.py profile fix), and apply-config.sh calls it too. Gamepad: three bugs in one chain This took the longest, because the symptoms differed and three independent places were at fault. 1. The game doesn't see the gamepad. The game folder contains its own xinput1_3.dll, and the loader picked it over the built-in one. Fix: the loader prefers the built-in XInput (wine #19, merged). 2. The game sees the gamepad but ignores it. The game window wasn't active, and on iOS there is nobody to activate it. Now win32u makes the process's main window active while it polls XInput (Madeira #149, merged). 3. A tap that missed an on-screen button turned into a mouse click. While the gamepad layout is shown, such taps no longer count as mouse input (Madeira #150, merged). Two things helped: return addresses in the diagnostics, and logging of the key-press chain. That is how the gap was found. I now keep such diagnostic patches around. A crash 35 seconds into the settings menu This was the emulator's own watchdog. It counted handled self-modifying-code writes cumulatively, and in the settings menu the game rewrites code every frame, cycling through seven keys. It reached the threshold of 2000 in about half a minute, and the process was killed. Now only consecutive identical failures on one thread are counted (Madeira #148, merged). After these fixes I was listed in Madeira's own Settings > Credits: "Controller fixes ... and a crash-guard fix". Two lessons from this stretch. First: check what is actually loaded, not what the config says. Image size and base address in the log lie less often than the settings file. Second: a clean CI build beats a build assembled from whatever was lying around. One of my builds, made from a mix of old and new parts, crashed in signal_set_full_context, while the clean CI one did not. Dark Souls III: from 20 to 36.7 FPS DS3 is heavier. Steam is installed from inside Madeira (Madeira Dock) with your own account. Cutscenes run at 60 FPS; in combat on default settings it was 17-20. From there it was a measurement exercise. I broke logs down by phase: FPS, GPU load, core frequencies, draw calls per frame. The parsers are in tools/ds3perf/, and the conclusions, each tagged "fact" or "hypothesis", are in docs/perf/. There are 22 notes there, in Russian. The phone heats up and clamps its clocks The least pleasant finding, from DS3-POWER.md. In one long session, the P-cores ran at 2.8 GHz for the first seconds and gave about 34 FPS. Around the 59th second a clamp kicked in: frequency dropped toward 1.8 GHz and median FPS fell to 20.6. At 175 seconds iOS reported the serious thermal state, which changed nothing further. So any optimization has to be measured on a hot phone, otherwise the numbers are pretty and useless. What worked I named the change sets with letters. This is the table from docs/compatibility.md, median in heavy scenes: | Step | FPS | What changed | |---|---|---| | base set C2 | ~17-20 | pool separation, no image copying, orphaned locks get flagged | | G1 | 21.5 | lighter diagnostics, in-process synchronization, fast path for x64 critical sections, write windows for hot code pages | | H2 | 36.7 | buffer and command-list reuse in DXMT, fast TLS, lighter SRW locks, thread QoS by name | For H2 in heavy scenes: median 36.7 FPS, p10 28.8 over the first minutes of a 12-minute run. After warm-up, with the P-cores sitting at 1.31 GHz, it holds 32-34 FPS. The GPU is about 88% busy, so now it is the bottleneck rather than the CPU. Now the honest part. The 36.7 figure is the sum of several changes. I did not measure the contribution of each one separately, and every PR says so explicitly. G1 had a 26-minute run with no hangs and a median of 21.5. What I tried and dropped: - MetalFX: got worse; - pool-low: got worse; - skipping self-modifying-code writes that have the same bytes: pointless, since 93% of the writes change the bytes. A separate note about DXMT. It turned out to create about a thousand Metal buffers per frame, and roughly 50 times per frame it allocates and frees 2 MB for command lists. Two keys (DXMT_DYN_KEEP and DXMT_CMDLIST_KEEP_BLOCK) remove that churn, and both are off by default (dxmt #42, #43). Black screen and a hang in DS3 Two separate DXMT bugs, both described in DS3-CRASH.md and DS3-FREEZE.md. - Black screen: when asked for an SRV description covering "all mip levels", DXMT returned MipLevels = -1. The game takes that number as the level count and allocates an array from it, then crashes. Now the resolved value is returned (dxmt #40). - DS3 hang: a backport of a fix from 3Shain/dxmt, where the draw-argument marshaling loops for GS/TS did not advance (dxmt #41). I have not fully tested the gamepad or saves in DS3; the repository lists this under "not tested". What's in the repository madeira-kit is tooling around the loop of build, sign, install, configure, run, read the log, change one thing. It is not a fork of Madeira: I sent fixes upstream, and patches/ only holds reference copies. - unpack.sh, swap-dll.sh, sign.sh, install.sh: unpack a build, drop in patched DLLs, re-sign with your own certificate, install while keeping app data; - doctor.sh: a pre-flight check (phone visible, app installed, at least 3 GB free, game copy present); - apply-config.sh: upload madeira.cfg, read it back and compare, create any missing profile folders; - pull-log.sh and analyze-log.py: fetch the log and analyze it right away; - ready-made profiles for DS1 and DS3 in configs/. The minimal path: git clone https://github.com/meshoklv/madeira-kit && cd madeira-kit cp scripts/config.example.env scripts/config.env && $EDITOR scripts/config.env scripts/unpack.sh ~/Downloads/Madeira-build.zip && scripts/sign.sh && scripts/install.sh scripts/doctor.sh scripts/apply-config.sh configs/ds1-play.cfg # swipe Madeira away, enable JIT in StikDebug, start the game scripts/pull-log.sh first-run You need a Mac with Xcode command line tools, an iPhone on USB, a certificate and provisioning profile for your bundle id, and pip3 install pymobiledevice3. The entitlements for extended memory and extended virtual address space require a paid developer account. If you build Madeira on GitHub Actions yourself, the pitfalls are described in docs/guide.md: LLVM as static libraries only, TUNE_CPU=cortex-a78 for FEX, and a stub for ri_page_wait_time_mach. The Windows part of DXMT is not rebuilt by this CI. What I don't know - The scripts are my working pipeline with personal identifiers removed. After that I syntax-checked them, but I did not re-run them end to end on a device. - Other iPhone models and iOS versions are untested, as is a fresh clone of the repo on a second machine. - I did not measure FPS or heat in Dark Souls Remastered itself, only "it's playable". - All DS3 numbers come from one phone and a handful of runs, mostly a single run per configuration. - A free developer account may not grant the required entitlements. How to help If you have a different iPhone or iPad, send a compatibility report: model, iOS version, game, config and result. Profiles with measured numbers are welcome. Cracks, game files and anything that bypasses protection are not. Part of the code and patches was written together with an AI assistant (Claude); in the commits of the upstream PRs this shows as a Co-Authored-By line. Repository: meshoklv/madeira-kit, MIT license for the scripts and docs; the patches follow the licenses of the projects they target. Issues and PRs are open. I post notes and new builds on Telegram at t.me. If the article was useful, a star on the repo helps others find it. Mike Meshok - github.com/meshoklv - meshoklv.github.io

Crazy fucking things happening on iOS willfaust/madeira t.co

Madeira GitHub Overview: Windows Gaming on iPhone and Its Tradeoffs madeira by willfaust: willfaust/madeira Steam Cloud workflow: github.com/willfaust/Madeira/blob/main/docs/STEAM… Madeira is an active research project that explores a unified Windows PC game library on iPhone. This overview follows the architecture from FEX-Emu, Wine ARM64EC, and DXMT through Madeira Dock’s headless Steam client, iOS process isolation, and the input paths for keyboards, mice, controllers, and touch. It also explains why APFS storage, translation overhead, thermal limits, and varying game compatibility shape the practical library. The final section covers initialization and pre-launch sync, the required “Upload saves and close Madeira” action, and conflict prompts with local backups. The examples are authored mock scenarios, not universal compatibility claims. TimeStamps: 0:00 Translation stack and the scope of the overview 0:42 From one executable to a managed game library 1:33 iOS sandbox boundaries and Madeira Dock 2:44 Keyboard, mouse, and XInput controller paths 3:56 Touch mapping, cursor state, and the on-screen gamepad 4:41 Storage limits inside the iOS sandbox 5:42 Translation overhead and compatibility tradeoffs 6:17 Steam Cloud session continuity 7:01 Explicit uploads and mobile session closure 7:37 Conflict prompts, hash mismatches, and backups 8:34 What the architecture makes possible—and where it stops 🧩 Madeira Dock turns isolated launches into a curated library model 🎮 HID, XInput, and touch controls serve different game interfaces 📦 Storage, memory, and translation overhead narrow practical compatibility ☁️ Steam Cloud continuity depends on explicit uploads and conflict choices Madeira’s central idea is architectural: combine Windows compatibility layers with a library workflow that fits iOS constraints. The tradeoff is equally clear—device limits, game-specific compatibility, and deliberate Steam Cloud session handling remain part of the experience. #Madeira #iOSGaming #PCGaming [es-US] Cinemática YNAS ynp_9ff7b7c6ca7f8489 Carga de entorno de prueba de automatización privada. Identidad del paquete: ynp_9ff7b7c6ca7f8489; salida: cinematográfica.

Introducing Porthole: run Windows PC games on iOS with controller support and a community driven game compatibility list (open source, early) **Factorio with mods running at 60 fps on a iPhone 15 Pro Max** I'm the developer. **Porthole 1.0.0** is the first public release of an iPhone/iPad app that runs Windows PC games locally. **It's built on Madeira**) (Wine, FEX-Emu, DXMT). I know a few frontends exist for it now, so here is what Porthole focuses on: - **Know before you try.** Every game shows a compatibility badge from real reports, counted per phone model *and* engine version, so an old result is never passed off as current. "Not yet tested" means nobody has reported it yet. You can see and apply the settings people used when a game ran well. - **Reporting is in the app.** A compatibility report takes under a minute. *Report a problem* sends a cleaned log (account names and public IPs removed) and you can read my answer back inside the app. - **All your stores in one place.** Steam, Epic Games, GOG and itch.io (games you own) with one shared downloads page. - **Controller-first.** The whole app works with a controller; games show FULL/PARTIAL support badges; you choose what the game sees. - **Engine work, in the open.** About 120 documented patches of my own on top of Madeira. I merge upstream regularly (212 commits in the last merge) and have taken open Madeira pull requests, credited to their authors, before they landed upstream. - **Updates on your terms:** on-device with your own certificate, rollback to any version, signed releases. No ads, no analytics, no account. - Not on the App Store: you sign and install it yourself, and it needs JIT. - No games included, nothing bypassed. You bring games you own. - Early: many games don't run; kernel anti-cheat never works. [YOU: what you've confirmed running / what fails] - iOS 18+ (tested on 26 and 27). Paid developer account or certificate service recommended; a free Apple ID works with limits. - Large parts were written with an AI assistant, then directed, reviewed and tested by me on real devices. **Links** - Release 1.0.0 - Github - Website - Discord Try it and tell me what breaks, and send a compatibility report after you play.

We're really not far from that with this: willfaust/madeira The ecosystem for running x86 games on snapdragon phones is already fairly robust. Crossover on my apple silicon mac works wonders.

@blurritolive Madeira and its pretty good mainly trying to get halo MCC working. willfaust/Madeira

@Pirat_Nation PSA for iPhone users: There is Madeira (willfaust/madeira). The setup is more involved though but it works.