I’ve posted a summary of the coding work I had to do to make Glulxe into an iOS interpreter. (The same work mostly applied to porting Fizmo, although details were different, obviously.)
This is long and tedious. I need a nap just from having written it.
That’s really useful. Do you have a solution for how to handle updates that break save games?
No, but I posted my separate essay on why that’s a hard problem. 
(Originally written for a thread here in early September.)
Oh yeah, I remember that. Would it be a good idea to keep the old version in the app and use that until the player restarts? At least when the update is minor.
I thought about that. Then I thought about having multiple save files, maybe some from version 1 and some from version 2, so it would be cool to automatically switch to whichever game matched the save file being loaded in.
Then I decided I was overthinking. I’ll probably just have a big switch in the game settings. If you flip the switch, the interpreter restarts – although I’ll keep both autosaves lying around so that you re-enter wherever you last were in that version.
Still requires some detail work, e.g. displaying the list of available save files. And deciding which version to boot up with. But doable.
Seems like a mostly solid plan. If the app is closed after the user has begun entering text then that would be lost right?
Shouldn’t the state of the RNG be in the Extra Glulx state?
Yes. Or rather, this will happen if the app is closed and exits.
(iOS keeps apps running in the background until memory pressure from a foreground app forces them to quit. So if you flip to another app and back, you probably won’t lose your editing state. Unless the other app is Halo or whatever.)
Ah, hm. If the VM is in deterministic mode, then yes. In nondeterministic mode, it doesn’t matter, because (assuming nothing crashes) an autosave file will only be restored once.