Published on 4/19/2016

I’ve been privileged to recently be part of a Unity project at Global Kinetic. Game development and the intricacies specific to that discipline is something I really enjoy, but it also reminded me about my philosophy of first principles and native code development.

Cross-platform these days is almost a bandwagon, again. Five or so years ago when XBox Live Indie pushed the indie-game development scene pretty hard, Unity was already the market leader with the ability to compile C#, JS and other code files to Java, Objective C and other native forms for many different target platforms. Everyone and their sibling was churning out iPhone and Android games faster than the journalists could punch out reviews. Lately there is a surge in Xamarin with Microsoft’s acquisition and license free inclusion of it in Visual Studio. Unity has also recently announced their partnership with Microsoft and we’re all hoping that this will serve to catch them up with the latest version and features of C# through IL2CPP and unlink the ball and chain that is the outdated Mono. So are these two cross-platform suits now the ultimate development space for a second time? Is something like Phonegap even still relevant?

First though, let’s consider why cross-platform. What are the benefits? For the most part, business owners and sponsors are immediately sold on the idea of develop once, launch everywhere. It’s billed as cheaper and more cost-effective. This is essentially the only reason cross-platform is ever considered.

As for problems, probably the biggest technical one is the notion of least common denominator. And even though this is also a problem with implementations of technologies like OpenGL, I’m not referring to platform-independent tech here, since my second point is not applicable to platform independence in general.

Let’s be clear, when you go cross platform you are making yourself dependant on something over which you have no control - the black box that is the cross compiler. Why is this a problem? Firstly, the developers of said black box is also looking at their own profitability and efficiency, and they will support only that which they can support on all their target platforms. Straight off the bat you miss out on exclusive platform features. Secondly, OS and platform updates introduce and change features, and your cross compiler will never immediately be ready with support for these changes. Unless you’re writing a very basic application, you’ll need to leverage off of some of the latest platform enhancements or OS/SDK updates. This is when your cross compiler of choice starts coming up short, having not yet implemented certain (or the latest) features of this SDK, or entry points in that API. At best you will need to plug in native platform code to make use of the specific or latest SDK features to solve your problem. At worst you have to wait for an update for the cross platform compiler before the issue can be resolved.

There are other differences too, like JIT vs AOT for instance, but let’s move on to one of the most important aspects of software development - the people.

If you’re a small company or startup you’ll have a small dynamic team who’s amped for success at all costs. That’s fine, and your app or game will do ok in its first year or two coming off a Xamarin or Unity base while you’re still in the “launch early, fail often” phase. But what if you’re an established development house with teams of platform developers? Are you going to force them into C# dev? Or reduce them to simply producing XML layout files and only let them out to code native every now and then when it necessitates you? That’s both demoralizing for the devs and disingenuous with regards to the sustainable skills rhetoric at every company meeting; certainly every one of those platform devs will eventually resign. And then when the next bandwagon comes by you have no-one to turn to when you need platform developers again.

I feel that selling your whole organisation out to cross platform is incredibly short-sighted, and though it might be cheaper and more efficient early on, the longer term effects of rehiring, reskilling, basic troubleshooting and losing an effective grooming and mentoring culture is far higher, but too easily discounted in the excitement of jumping onto this latest bandwagon.

This post was co-authored with Slyfox.