Hi

The reason it says it needs Chrome is that it uses a feature - the FileSystem API - that only Chrome supports (among the major browsers... Opera supports it too but we aren't counting it).

This is something that we need to store files in a virtual file system in the browser's memory, so it's persistent and it's easy to turn data into actual files when you want to download it.

Chrome on iOS, unfortunately, is not a real Chrome, but more like Safari with a UI wrapper that makes it look a bit like Chrome - but it's Safari underneath (because Apple wouldn't allow any other JS engine on their platform). Android Chrome would work though.

Saying that, I've always been interested in using WADE as an educational tool and would love to get the editor working in other browsers too... so it is going to happen eventually. We always thought that it'd be a bit awkward to make games on phones and tablets (as opposed to playing them), so that's always been pretty low priority. Do you think people would it on tablets, even writing code on iPads?

Hi Gio

I am almost certain iPads will be used a lot more for producing things (like programs or games) not just consuming. At least in schools. A lot of schools are buying iPads (instead of computers) for each pupil. Partly because it is cheaper, partly because of the mobility, camera, etc. I would say it is growing fast in Sweden.

And we also have a trend to learn programming earlier and for more of the children. Eg. by using code.org
That makes it highly interesting to teach programming with a tool like Wade Game Engine.

There are apps for game programming on iPad, eg Codea (LUA), but I would like to use javascript and get more platform independence.

I´m not the one to say how to implement Wade for iPad, but I would like it to happen...

I have heard about IndexedDB, that may help for Firefox and IE, but for iOS it looks buggy.

Yes, IndexedDB is probably what we would use on other browsers. It's a bit of a pain to use, but we've built the editor with portability in mind, so all the file system functions are in the same module, and that's the only module that we need to change. In other words, it's a bit of work but not too much.

The main problem with IndexedDB is that it has no notion of persistent storage, so when you clear your browser history, you're likely to clear anything that's stored on IndexedDB too. For this reason we're thinking that we should only support it after releasing our cloud storage module, which is something else that we're working on and that would allow you to sync your work with our cloud servers, so it doesn't get lost and you can access it across multiple devices through the same account.

If there's any interest to get the editor running on other browsers (and you're saying that there is), we can look into moving this work up the priority list.

I would vote for that! :)
(Although I do not know what lies ahead in the list :unsure: )