IOS App

[logodab1340]

I need an IOS app for this emulator, please?

[techomancer]

@danifunker
Do you think it is feasible? Thats whole another UI project probably.
Some iOS devices may be powerful enough to run iris.
Also form factor is a bit of an issue, irix on touchscreen would be rather limited. One could connect keyboard and mouse to ipad but then it is like desktop or macbook.

[danifunker]

High level: We can't use eGUI (iris-gui) so I would need to put together a different GUI, and we would have to drop camera support. I also need to investigate CHD support (this might be very useful as storage on iOS devices can be pretty limited).

Otherwise I think it might kind of be do-able.

I don't have a tablet anymore, but I can probably try seeing how far I can get with my phone as well. Let me continue my investigation and update accordingly.

[danifunker]

Follow-up with an actual plan, after digging through the tree.

TL;DR: feasible, and less scary than it looks — but it's an iPad app, not an iPhone app. The emulator core is basically iOS-ready today. The cost is a new UI, not new emulation.

Why it's more feasible than it looks

Two things usually kill an iOS emulator port, and we've already paid for both:

1. No JIT on iOS — doesn't matter to us. iOS never grants dynamic-codesigning to App Store apps, which is exactly what makes UTM SE so slow. But our Mac App Store build already force-sets IRIS_NO_JIT=1 (iris-gui/src/main.rs:111), because the App Sandbox SIGKILLs Cranelift's non-MAP_JIT pages — that kills both the MIPS JIT and the REX3 draw-shader JIT. The build we already ship is interpreter-only. iOS costs us nothing we haven't already given up. And the interpreter with opcode fusion sits in the ~90 MIPS range on an M-series host, which is roughly real-Indy territory; an M-class iPad should land close.

2. The GUI display path already needs zero OpenGL. iris-gui/src/framebuffer.rs defaults to CaptureRenderer → SwCompositor → packed RGBA Vec<u8>, with GL only behind IRIS_GUI_GL=1. That buffer goes straight into a Metal texture with no changes to the emulator.

Also in our favour: aarch64 is already a first-class host (src/platform.rs), only 11 files in the tree carry target_os cfgs and they're all peripheral, and the NFS server lives entirely in the NAT with zero host sockets (src/nfsudp.rs) — which matters a lot on iOS, where you can't run a daemon at all.

Plan

Phase 0 — make the core compile for aarch64-apple-ios. Mostly cfg-gating: src/lib.rs:78-83 unconditionally exports ui / gl_compositor / headless_gl, which drags glutin+glow+winit into the library. Drop camera (nokhwa's AVFoundation backend is macOS-only), ultra64 (POSIX shm), pcap. Widen cow_disk's clonefile cfg from target_os = "macos" to Apple generally. Deliverable: cargo build --target aarch64-apple-ios -p iris green, plus a headless boot-to-PROM test.

Phase 1 — FFI seam. Build the core as a staticlib and expose a thin C API around what iris-gui/src/handle.rs already does: the Cmd/Evt channels plus the FrameSink. That file is already a clean core/UI boundary — it's close to pre-shaped for FFI.

Phase 2 — CHD on iOS. To @techomancer's storage point, this matters more here than on desktop. Current status: libchdman-rs's prebuilt downloader only recognizes *-apple-darwin / *-unknown-linux-gnu / *-pc-windows-msvc and hard-errors on anything else, and the crates.io package doesn't vendor the MAME sources. So iOS needs a from-source build from the upstream git checkout. The build script uses cc, which cross-compiles to Apple targets cleanly, so this looks like plumbing rather than a research problem — but it's unproven, and I'd want an aarch64-apple-ios static lib actually in hand before promising CHD. update I am now baking in prebuilds for iOS devices both for hardware and simulator for libchdman-rs will be in 0.288.11.

Phase 3 — SwiftUI/Metal shell. Framebuffer view, on-screen keyboard + trackpad overlay, hardware keyboard/mouse passthrough, and a Files-based importer for disk images (UIDocumentPicker replaces rfd). This is the bulk of the calendar time. I'm not porting the egui config UI — the config screens get rewritten native.

Phase 4 — lifecycle & power. iOS suspends the app and freezes all ~9 emulator threads, so we need clean pause/resume and guest timekeeping that survives the gap (snapshots give us the primitives). --features idle-pause and the REX3 idle parking stop being optional — on battery they're the difference between usable and a hand warmer.

Phase 5 — submission. Guideline 4.7 was revised in Aug 2024 to explicitly cover PC emulators, and UTM SE ships on the iOS App Store, so the category is allowed. 2.5.2 (self-contained, everything stays in the container) is the design constraint, and it's the same one we already satisfy on MAS. Users supply their own media, exactly as today.

The form factor question

@techomancer you're right and I won't pretend otherwise. IRIX at 1280×1024 on a phone is a tech demo, not a usable system. iPad + hardware keyboard and trackpad is the real target — and yes, that's "basically a laptop," but it's a laptop people already carry.

I don't have a tablet at the moment, so I'd be validating on a phone: I can prove the core runs, but I can't really prove it's pleasant. My suggestion is that I take Phases 0–2 as far as they go — those are all in-tree Rust changes that are worth having regardless — and we re-evaluate before anyone commits to Phase 3. That's where the real cost is.

[danifunker]

@logodab1340 should I continue this investigation considering this will be stuck as an iPad app?

[logodab1340]

@danifunker Sure. :)

[danifunker]

I haven't looked into this any further. I'm trying to tie up some of my other projects. Let me set the expectations so that I will probably look into this after VCFMW, I'm trying to get my other projects in order to show off there.

[techomancer]

I dont think this is a pressing issue ;-)