At the risk of creating yet-another harmful "Considered Harmful" blog post, it's recently become more and more apparent to me that writing native code, on any platform, is a bad idea in the long run.
That's quite the inflamatory assertion, and I'm sure that if you are currently writing native code (Obj-C, C#, Swift, Java, C++), you may not like me right now. That's legit, and I don't even want to take that away from you. It's not my goal to convince you to turn your back on the technology that pays your bills and that you probably love deeply, but consider giving me just a few minutes to explain why on earth I would say such a thing.
But you already knew that.
Before I get started, let me clarify my statement: native code is bad in the long run iff you are not working on or building a platform. In other words, if you work on the UIKit team at Apple, this article is not for you. If you work on the kernel for Windows, this article is also not for you.
If you are a developer that is developing for a platform (which is most of us), listen up.
Contrary to the popular belief that OAuth has ruined everything, it's actually platforms that have ruined everything. Let's do a little time traveling.
In 2010 I was working at a startup that was building a web based music distribution platform. We had .WMA "Plays For Sure" music that you could buy and then side load to your Creative Nomad mp3 player. The iPod was already out, but we thought we had a good chance to take on iTunes since the mp3 market was stiff, and honestly, we had the relationships and thusly a more complete catalog.
Then one day, Steve Jobs walked on stage at WWDC and released the first iPhone. I remember watching that release and thinking, "It's all over." The iPhone wasn’t a phone nearly as much as it was a platform. I knew that everyone was going to get an iPhone, and that platform would dictate that their music store of choice would be iTunes.
That startup failed a mere 10 months later, and within 24 months, mobile devices were deeply embedded into culture. It was truly a revolution.
It wasn't 2 years before the landscape of Blackberry phones began to erode in traditional enterprises. It was incredible to watch. These companies were bastions of Windows, group policies, and antiquated browser versions that were guaranteed to work with their 10 year old JD Edwards systems – user experience be damned. Yet, here they were, allowing employees to bring their own devices to work and connect to email systems.
By this time, there was already a growing fragmentation in the mobile space. Not only did we get a smaller browser, which meant we had to re-think our websites yet again, but we also got new native platforms (Android) that came with native SDKs and corresponding languages. It was, in a phrase, an utter free-for-all.
And that pretty much brings us to today.
In 2016, most developers are still trying to grapple with desktop apps, web apps and if they are on top of their game, mobile web apps. Native mobile applications are like a unicorn that is mostly found only in San Francisco.
Hybrid (i.e. Cordova/Phonegap) applications are incredibly attractive since web developers can use their web knowledge and almost build a native mobile application. They key word there is "almost". Hybrid applications are good enough for a lot of scenarios, but are also inadequate for a sizable share of them. Hybrid application performance suffers as applications grow in size. Trust me, I know this all to well. We spent a lot of time trying to debunk the myths that HTML5 on mobile is too slow to be good. The honest truth is that “good enough ” just doesn’t cut it for most.
This is why many developers went back to native code in the face of mobile applications.
The very premise of this article is that native code is bad. It's bad, dear developer, because it doesn't scale across platforms. Java runs on the desktop and Android, but not iOS. C# doesn't run on iOS or Android.
"BUT WHAT ABOUT XAMARIN!?!"
Xamarin has done a great job of creating a runtime that can work on almost any platform, but there is one place where it still doesn't work, and that's the browser. Beyond that, Xamarin does a great job of normalizing the primary language and the .NET SDKs, but developers are still exposed to patterns they aren't necessarily familiar with, such as the true MVC pattern on iOS (delegates and such). Xamarin Forms is trying to fix this, but so far, it simply hasn’t been able to turn the corner. And that’s no surprise. Creating a normalized API across platforms is not for the faint of heart.
Since none of the native languages will run everywhere, developers are staring down the barrel of building their business logic in multiple languages for multiple platforms.
One solution to this problem is to try and stuff all of the business logic behind an API. This actually works moderately well up until a point, and then you began to sacrifice interactivity and responsiveness at the feet of your API which may or may not be able to scale to handle your user base, if in fact you have that glorious problem. Even if you don’t have the problem, the intermittent connected state of mobile devices means that an API may or may not be available, and it’s impossible to every know when that situation may occur.
And the creators of frameworks already know this. Facebook created React and then React Native. They did this because they know that, when developers learn React, if they can then extend that knowledge to the mobile device, it becomes a no-brainer. Facebook referred to this as, “learn once, write everywhere”.
"Write Once Run Anywhere" is, unfortunately, a pipe dream. The layout engines and strategies between mobile, desktop and the web are simply too disparate. Developers will have to build multiple UIs. That's just a fact.
The lie of a pipe dream is what gives life to the whole misbegotten mad lot of us, drunk or sober.
Header image courtesy of Eugene Zemlyanskiy