Choosing a Tech Stack for a Multiplayer Action Game: Part 3 – The Apps

Ok, we’ve made it to the end of this Tech Stack article series – or the beginning of the end anyway. In part 1, I discussed why I chose Elixir for the backend, and in part 2 I talked about why I’m using plain old JavaScript for the web frontend. All that’s left now is to choose how we’re going to build the mobile apps.

The Problem is Duplication. The Problem is Duplacation Duplication.

I don’t want to write two different code bases that do ostensibly exactly the same thing. As a matter of fact, I think it’s a load of malarkey that I can’t just use my browser js, pack it in a native app wrapper, and send it to the App Store. Have I fallen through a wormhole which has left me stuck in 2010 or something? How is this still a problem?!

Questions for another day I suppose. The unfortunate fact is, this is still very much a problem that must be dealt with. The most obvious solution is to just write my frontend code two more times – once in Objective C for iOS and once in Java for Android. This triples the size of my frontend code base which increases the opportunities for bugs to show up. Boo!

On the other hand, writing in native languages will guarantee that my app is relatively small and fast. There are also mature and widely-used development environments and deployment pipelines, so I would (theoretically) have no trouble developing and compiling my app.

An Abundance of Alternatives, a Dearth of Good Ones

The flavor of the month for write-once-deploy-everywhere frameworks is of course React Native. Other popular options include Cordova, Xamarin, PhoneGap, Ionic, and Titanium. They all have similar but slightly different target audiences.

Right off the bat, I’m leaning toward either React Native or Xamarin, since they both compile down to native code, and let’s face it, using native elements makes for the best apps. The problem is regardless of which framework I choose, I think the game code itself will have to be rewritten into native (using Quartz for iOS and maybe Core Graphics for Android).

Since that is the case, I’d really only be using one of these frameworks for like 2 or 3 screens, a couple modals, and a menu. Is the added complexity worth it? Also, I’d have to take into consideration how difficult is it to integrate a fully native component into the framework (if it’s even possible).

Why Not Use Unity?

I have a sinking feeling that I might be asking myself this question over and over again. Why oh why didn’t I just use Unity? Unity makes is pretty simple to deploy your game to any platform from just one code base. Learning to use Unity has its own overhead, but perhaps it would have been worth it.

I guess my main reason for bypassing Unity is they stopped supporting their web player. Even the fact that they had a web player in the first place is kind of off putting. I mean, my ActionScript 3 skills aren’t opening any doors for me anymore, are they? Unity is transitioning to WebGL, but it would basically translate the C# code I wrote in Unity to C++, then again to JavaScript and WebGL… This does not sound like a recipe for stability or performance.

Notable Mentions

Apparently, according to this article, Dropbox writes some logic code in C++ then shares the .dll files across their iOS and Android apps. That’s pretty cool. Instead of abstracting on top of native code, they went down a level. Smart.

In this Ars Technica article, they explain how Google created a tool called J2ObjC which translates Java to Objective C (not Swift). They open sourced the tool in an effort to promote Android-first development. This tool is not meant for any UI, platform-specific translation though.

And the Winner Is…

Given the added size and complexity of using a framework compared to the relative simplicity of what I’d be using them for, I think the best option forward is to write two native apps and hope for the best.

Leave a Reply

Your email address will not be published. Required fields are marked *