Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Twine 2 on iPad

edited December 2014 in Help! with 2.0
Just tried this. It's really good.

I tried Inkle on iPad and it was slow and janky with too many CSS animations. Plus everything required several clicks to respond. Twine 2 on the other hand was neat and responsive - seemed just perfect for working on a tablet with an external keyboard.

With one massive, massive flaw.

With no way to get the story off of the iPad, I'm left with this brilliant way of working that's utterly redundant. I now have the nicest way to write IF in front of me with no way to publish the result. This is heartbreaking.

Is there something I'm missing here or is this really it?


  • What should happen when you choose Publish to File when editing a story, or use the Archive button on the story list on iOS, is that Twine creates a ZIP archive of the file and tries to open it. At least on my iPad (I'm on iOS 8.something), triggers a screen where I have the option to open the archive in Google Drive or Dropbox, which will simply copy the archive over there. Obviously a prerequisite for this is having one or more of those apps installed.

    After experimenting with things, this seemed like the one reliable method of getting a file out of iOS. I would be all about a less cumbersome method but I haven't been able to find one. Also-- testing has been basically confined to my own experience-- during the betas we did not get many bugs reported by folks on iOS, so it's totally possible there are flaws in how it works right now.

    Let me know if this works at all; sounds like it may need some more work to get the feature to where it needs to be.

    And thanks too for the compliment -- one of my big goals was to try to get a good experience on iOS/Android and it sounds like we at least made some good progress on that front.
  • Ah hah!

    Downloaded Dropbox and tried archiving again. It works! Thanks very much, this is lovely. Not really bothered how clunky it is, so long as I can save stuff out.

    One issue: I tried this in Chrome for iPad and it just gave me a failed download page. This is a bit of a shame because Twine 2 runs much faster in the iPad version of Chrome. The data isn't carried between browsers either. Let us know if a fix evolves or if there's a workaround...
  • That's weird that it works better on Chrome -- my understanding was Chrome on iOS used the same rendering engine as Safari, but hey! can't argue with reality.

    Anyway-- logged this at
  • It also ran better on Offline Pages - so I think it may be due to some unnecessary overhead that vanilla Safari runs.

    Regarding Offline Pages, they aren't executing data:application URIs. Meaning you can't export the archive from there. So what would be an excellent way to work on iPad offline is a no go for now. I've emailed their support and described the problem. Hopefully they'll get back to me with either a workaround or maybe an update.

    I'll post news if I get any.
  • Can't select text with the Shift key on iPad for some reason. Works in any normal text field but in Twine 2 it doesn't and even deselects and text you have selected.

    I basically have to manually delete anything and everything character by character. Urgh.

    I'd have submitted a bug but Bitbucket banned my account because I tried to make an account. So, um, yeah, then I sent them a bug report too.
  • @st33d
    If you are talking about the Passage Contents textarea then Twine 2 is using the CodeMirror widget to handle the editing of that text, and they have a number of open issues related to iOS.
  • Hmm. The one place we are not using CodeMirror is the passage editor (the stylesheet and script editor do, though). I don't have an external keyboard for my iPad so trying to track this down may be tricky.
  • @klembot: My mistake then, but that will make it hard for Story Format creators to add syntax highlighting.
  • Right. The eventual goal is to use it there too (along with a WYSIWYG editor if that's feasible).
  • Um. Not to be a downer, but I can't seem to load data back into the iPad browser as well.

    I recently lost all my work when I updated iOS. The browser was set to retain data from only websites visited, so now I've set it to save all data forever. An archive would have helped, but when I try to load from file it just defaults to asking for a photo from my camera folder.

    If I'm not doing something wrong here, then working on the iPad isn't viable. With no way to load data in I can't confidently work on stuff. I don't want to lose my intro again and then have to build the rest separately in chunks.

    Would it be feasible to have just a text field hidden somewhere where iPad users can copy-paste the html from a project and try to parse it? It would be ugly but it's better than working on something that might be forced to be fragmented. Is there something already like that?


    Oh, and Offline Pages got back to me. They say it's a bug that data:application URIs aren't working on their app and they will try to ship a fix soon, but of course they have to wait for app store approval. So offline on iPad should be able to be a thing.
  • Do you have something like the Dropbox or Google Drive apps installed?

    I believe that you can save/load the archive file to this apps, though I have not tested this myself.
  • greyelf wrote:

    Do you have something like the Dropbox or Google Drive apps installed?

    I believe that you can save/load the archive file to this apps, though I have not tested this myself.

    iOS doesn't handle open file links like you would expect from a desktop. Essentially it only gives you the option to take a photo or video, or import one from the library when you click said link. There is no option to "import from dropbox" or google drive so while you can write on your ipad, export to dropbox and continue on your computer, going from the computer to the ipad is pretty much impossible.

    Also it doesn't work if you copy a dropbox link for the archived file and paste it in the browser url, as it just gives you a page with the content of that html archive file. Unless the feature is somehow directly integrated with a drive or dropbox api, I don't think you'll ever be able to go from desktop to ipad.

  • One really far fetched idea does spring to mind because I've already done this in Flash:

    The png data format is broken into chunks for certain types of information. You can pretty much piggy-back a bunch of data on a png by loading it into the tEXt chunk which stores text information in a key/value pair format. There's no real limit on this as you specify the size of the chunk and anything trying to read it will skip chunks that aren't relevant. It doesn't affect the image.

    Like I said, I have code for inserting text data into pngs and extracting that data in Flash:

    So: if it's at all possible to save to the camera roll from the browser then you can load that back in. I've seen a png library for javascript out there, but of course one needs to reverse engineer the encoder to get the data back out - which was easy for me in Flash, maybe not so in javascript.

    If someone with a better knowledge of javascript can confirm it's possible to get an image in and out of the camera roll from Safari iOS, then I might give it a crack.
  • First of all, that's scary that iOS updates blow away local storage for sites. I'll do some research to see what the story is and update the wiki accordingly. At this point, I'm thinking a dedicated page for tablet issues with Twine 2 is worthwhile.

    The idea of stuffing data into PNG metadata strikes me as a really clever solution to the problem, though I wish we could keep archives in plain text for ease of extraction by third-party tools. Key question to me is whether iOS would munge metadata, perhaps in the interests of user privacy. I guess it would be possible to encode the archive in the image data itself, but that sounds... complicated.
  • One possible issue with embedding the data within a PNG's meta is that the data may contain javascript.

    Would a virus scanner see it as an attack vector?
    What would happen if the image is opened in an image viewer, would it try to run the JS.
  • Nope.

    There's the important chunks that make the image and then there's - flavour. Just extra rubbish that won't even be read unless you're specifically looking for it like animation and 3D. The tEXt chunk is commonly used just to state author information.

    The whole idea of these chunks is that you stick a label on your chunk, say how big it is and then dump your data after it. If whatever reads the png isn't interested in the chunk, it won't read it.


    iOS mangling the chunks on a png is a possibility though apparently the tEXt chunk is supposed to be copy safe.

    If this worked then unpacking a png archive to a normal one wouldn't be too much ball ache as the library would already exist in javascript.

    There's a png encoder library I've seen around:

    Modifying that to poke in the tEXt chunk is a bugger, but probably doable. Getting it out again is basically looping through the bytes to find your own handiwork - and trying to load a png as a byte array. It's nearly Christmas, we'll see how bored I get.
  • I've confirmed I can create a png, then poke-hold-save it to the camera roll. Then when I go to the archive loader in the Twine IDE, I can see that image there:

    I've verified it's still a png on my Mac. It's clunky, but it does the job.

    What is the code for the image loading button in the Twine IDE? I know it's there in the source code but I don't know where to look. Just whatever is going to get me into the camera roll is enough - and then I can build a proof of concept.
  • An easier way, at least out of my view when we take Dropbox, Google Drive etc into account, would be to support 'open from url' instead of 'open from file'. This should be pretty easy and straight forward to achieve.

    Dropbox on mobile has the capability to provide you with public links to files.
  • I like Dreamora's idea. I believe Google Drive also allows shared links. Both are "public as long as you know the URL" and can be deleted after use. That method might also work to easily update a story on one's web page, if one had an FTP client installed to upload the file back to the web page.

    I've just verified that you can create a web link to a file from the Dropbox app for iPhone (via "Copy link"). So for Dropbox at least, this would work for a mobile-only workflow.
  • Bear in mind this is an iOS thing not just a mobile thing. Android can work around the current setup very easily. The filesystem is exposed.

    A url load would be very helpful for iOS however (making it viable as a platform). And it would allow project sharing to take less steps on other platforms. You could probably end up with a nice package link to open Twine and load the archive.
  • st33d wrote:
    And it would allow project sharing to take less steps on other platforms. You could probably end up with a nice package link to open Twine and load the archive.

    Downloading a copy of a project is only one part of the issue related to project sharing, two other major parts are of course: 1. sharing your local changes and 2. synchronizing your changes with the changes done by others.
  • Has a solution to this problem been found in terms of uploading Twine files you created on the computer onto the iPad?
  • I'm using Safari and Google Drive on an iPad Air. I was hoping to use Twine for teaching English. Anyway, it almost works, but unfortunately there's one problem that makes it impossible for me to use. I can export an archive and save it to Drive. Unfortunately, I can't import the file. It's always grayed out for some reason. The two iPad zip handlers I tried also fail to open the files for some reason. Has anyone managed to use Twine on an iPad?
  • So it works with Dropbox, but not with Google Drive. Makes it a bit cumbersome for me, but not impossible.
  • Does anyone know if the creators are working on an app version of Twine yet? It would be amazing to be able to create stories on the fly, e.g. long train journeys, etc.
Sign In or Register to comment.