jonasechterhoff

A few comments (Disclaimer: I work at Unity): -As others said, with Unity, you get a full game engine cross compiled to JavaScript/WASM, which has more overhead then simply rendering an image by other means (like img tag). -We don't officially support mobiles for the Unity WebGL build target, because we believe that the platform (browsers and hardware) is not yet ready for this use case (running a full game engine compiled to the web) yet. That said, you might get better results with simpler engines which do support mobiles. -WASM support on iOS is currently broken, so this probably would not work regardless of engine used: https://bugs.webkit.org/show_bug.cgi?id=181781#c4 (Try making a JavaScript release build instead)

Correct - we draw all the UI ourselves. Yet, we did indeed have a lot of dependencies on Carbon APIs for all sorts of different things like handling rendering into windows or fullscreen contexts, getting images from WebCams, input, etc. We had to rewrite quite a bit of that code to move to 64-bit. A problem with that is that often the replacement APIs have only been introduced in more recent OS X versions (which have always been trying to keep long backward compatibility with old systems), which means that in several places we had a choice of maintaining two separate code paths or dropping functionality in 32-bit. Or releasing 64-bit versions later when we could safely drop backwards compatibility with old OS X versions. This was not the biggest reason for us to take long to support 64-bit, but it was one.

Disclaimer: I work for Unity. -As for 64 bit support, the biggest problem for that with Unity is all the dependencies to third party technologies we integrate. We've managed to get all those resolved for the Runtime part (Mac/Windows/Linux standalone players) a while ago (we've been adding 64 bit versions of those during the 3.x and 4.x release cycles), which meant getting Mono, PhysX, FMOD, Substance, etc all working on 64 bit. For the editor, however, there are a lot more third party libraries involved (such as a web browser engine for the asset store), not all of which had 64 bit versions to start with. So there were a lot of dependencies to resolve, which is why this took time. Good news is, we have all this working in 5.0, which will be out later this year.

-For the new GUI, we are not going to fix this only in Unity 5, but already in Unity 4.6, which should be out really soon.

-About the "JavaScript" misnomer, I agree that that was a bad decision in retrospect, though it is not trivial to change at this point.