Part 1: The road to cross platform frameworks
Why do we want to make ‘cross-platform’ frameworks ? The story starts from before the advent of mobile development.
These ‘cross-platform’ frameworks. Why do they even exist ? Because mobile development is already hard, even if you had to do it just for one platform, but then you have two.
iOS and Android have become what Windows and Mac were (are?) in the PC world. Windows for the masses, Mac for the rich folks or the developers. Volume sales come via Windows, niche high-price sales come from Mac. You can’t afford to not make an app for either Android or iOS if you are a serious mobile product.
(Interestingly, why are Microsoft and Google a step behind Apple? Because they each got one end of the duopoly on mobile and desktop, while Apple got the other end in both. Whatever is the next generation platform (VR/AR? Home Voice boxes ?), if either Microsoft or Google can pick up one end of the duopoly on it, they can get level with Apple.
Write Once, Run Anywhere ? That and other unkeepable promises . . .
Java promises write once, run anywhere. And kind of keeps that promise. The operating phrase being “kind of”. Everyone likes making fun or WORA. Some say it is write once, run away, while others prefer the other phrase called write once, debug everywhere.
There are a lot of problems, like Apple having it’s own Java with it’s own native UI implementation, and Oracle being a MAJOR ASS-FUCKING-HOLE and screwing up licenses, usage rights and creating a the whole fuckjob of Oracle JDK, plus OpenJDK plus IcedTea, and then recently J2ME, J2SE, J2EE, or it’s new version, Jakarta, leading to a boquet of software whose name, definitely look like they were picked up at a beach side cafe in Indonesia.
Trivia: Java files start with 0xCAFEBABE. So the cafe in Indonesia thing? Yeah, how Java was actually named is very close to that.
Anyway I digress. Java was not the first, but the first major (major as in > 50% of all software developers knowing the language type major) language to take an aim on WORA. Did it work out? It in fact did. More than 3 billion devices use Java (the installer proudly proclaims). And during the early 2000’s a whole lot of desktop apps were made in Java. Even today it is difficult to find a reasonable person to have an OS without some version of JRE installed on it.
Modern day’s write once, run anywhere desktop development revolves around a similar promise made by Electron. Those good developers at Github, wanted to make a text editor. Yes, you types keys on the keyboard, and letters are printed sequentially on the screen. Yeah just that. Vim, Emacs, Nano, Pico and 20 others do that pretty well without even a GUI. If you are a GUI-dependent life form, every OS comes with it’s own (or even multiple) text editors — Notepad, TextEdit, Gedit, Wordpad. If you still want some feature overload, there is Notepad++ and for those who really want to use an IDE but pretend they can deal with just a text editor, there was Sublime Text. But those good guys at Github apparently were not so hot with desktop development. Because you see they, for all their lives, had worked on turning git, a version control system built for scale and performance, which very consciously and deliberately doesn’t have it’s own GUI, into a web based social network, where undergrad fuckbois measure their dick sizes in green squares. (Probably like dicks, longer and darker, the better).
So these folks at Github figured, since we only know how to build websites, why not ship an entire motherfucking Chrome and embed our slow as fuck text editor inside it. Cross-platform? Hell yeah, Google made sure of that by compiling Chrome for all operating systems.
Microsoft was totally losing the shit. Desktop user share was dwindling, PC and Laptop sales were giving away to mobile, and guess who couldn’t survive mobile despite buying the one time biggest mobile manufacturer ? Yeah right.
So they figured, the new way to develop apps should be so easy that every guy with a keyboard can do it. How is that possible? Oh make them in Javascript and HTML. Like websites. That will make them cross-platform. It will work on Windows Mobile (which 10 people at Microsoft’s Lumia division use), and Windows 10 (at least when it is not continuously auto-updating itself). Then they figured that developer mindshare is decreasing, and no one is using their premier developer product — Visual Studio, and so they made a lightweight version of Visual Studio called Visual Studio Code. Only, the lightweight version has nothing in common with Visual Studio. It rather had everything common with Github’s code editor Atom. Honestly, pricing VS 2x the annual salary of an Indian IT professional was not exactly the best way to get most people to use it. VS Code being free — well ofcourse. And I don’t want to blame Microsoft. If people want to edit texts in a browser that takes 3 GB of RAM to start up, yeah fuck them. Feed them this Electron crap. All day long.
Anyway, my point being, Microsoft and Github started a landslide of electron apps, and all kinds of apps that had no business wearing a 100 MB heavy Chrome backpack on their shoulders, starting turning into browser-bundled-ram-hogging-poorly-integrated nightmares. Slack is IM. IM should be fast, perrformant, provide native notifications. Spotify. It 90% of the time, plays music in the background. Skype. A video conferencing app — at least that should be able to harness the native codecs and audio layer capabilites of the OS ? Naaaah! Just develop them once for the website, then ship a copy of your website, packaging a full Chrome binary into it, because your website only works on Chrome, that too a particular version.
This was closer to the original WORA promise, but it strayed further and further away from the concept of “applications”. They had less and less to do with using OS integrations and were more and more like websites.
It wonder if people still never figure out that given natural human tendencies, developers will gravitate towards systems that make their life easier, not necessarily their users’ lives. Yes a native music player that runs in the background using only 30 MB RAM and ducks audio when other notification comes, and makes use of HDR audio codecs would be loved by all. Except the team which will have to code it from ground up separately for Windows and Mac (and dare the product manager say — we want to target Linux users too).
I am an user of Apple Music, not because they have the largest catalogue or because I love Apple, but simply because they are the last standing offering, that provides native experience on Mac (and even Windows). I don’t even want to know if Spotify or Google have more music catalogs, unless they can take the time out to make me a native app before dipping their hands into my wallet
Cross-Platform for Mobile Take 1: Compile down to Native
Some of the first shots at code sharing was at the native level. While iOS’s Objective-C stack and Android Java stack had nothing in common (from langauge to IPC models to threading), they did have one thing going for both of them — ability to write some modules in C++, that compiles down to native.
There existed a few solutions here and there that advocated putting “business logic” into native code and sharing it. Business logic after all, is just pure arithmetic and logic. The business logic of an app doesn’t change, whether it is on iOS or Android.
The first big mover in this category (and still a strong contender) is Xamarin. Xamarin makes you still write the UI for each platform separately, because the components like Buttons, Tabs, Views that form the UI is vastly differently architectured in iOS and Android. What didn’t really let Xamarin take off were two things — the dependence on C#, a language that made Xamarin Microsoft’s darling, but also despised in the Java/Javsacript/Python/Ruby loving indie developer community, and secondly, the huge turnaround time Xamarin team takes to make a new iOS and/or new Android version supported within Xamarin. Adding support for new OEM OS versions is not something users can do themselves.
On the other hand, a different kind of apps were cross platform from the beginning, because the view layer itself was the business logic for these. You might have guessed what I am angling at — yes, games.
Unity and Cocos2DX really ran well ahead of the competition, and for now are the crowned champions of the 3D and 2D game development arenas. While the way UI works, background tasks work and app-to-app communication is handled is completely different in iOS and Android, the graphics rendering functionality and capabilites were largely similar, thanks to long time desktop OS legacy of OpenGL and relatively more recent Skia developments.(Although as of today, Apple just last week dropped support of OpenGL from Mac at WWDC, it still remains on iOS). As a result games completely circumvent the architecture the OS lays down for apps, and instead aims straight for the jugular — the graphics rendering engine. Games hardly ever need things like IPC or telemetry or background tasks, and even the rudimentary UI for starting, pausing, showing help is usually developed using the game framework itself.
There are still certain components like leaderboard management, in app purchases etc that require deep OS/Platform integration, but fortunately for game developers, SDKs for most of these features directly target Unity as of the developer platforms. Which means Google Play Games Leaderboard SDK is available for Unity, so people can integrate that with only Unity knowledge and zero Android App development knowledge.
Single Codebase on Mobile Take 2: Let us copy that Electron model and all start making glorified websites
If there are 2 things to learn about software development those are —
- Atwood’s Law — explicitly stated, Javascript is eating software world
- What I just said a while back, developers prioritize their comfort over users’ experience
With NW.js and Electron, developers had tasted blood. If users are giving away performance and space in their RAM, why not. And thus started the onslaught of hybrid apps. These ‘hybrid’ apps are the bane of any mobile developers’ existence.
These are neither hybrid nor are they apps. These are just websites that ship with their very own web browser. Every hybrid app you install is an extra copy of Chrome on your mobile, which could have been prevented if those bloody developers just made a progressive fucking webapp.(PWA).
There are many platforms, including Adobe’s Phonegapp and ionic (a.k.a shoving Angular down a hybrid app and then turning it into a startup). There is nothing different among any of them. They all are extremely, extremely slow. (More apparent on mid range phones, which the majority of Android market does). They require much more RAM than native apps. MUCH MUCH MORE. And worst of all, people who make hybrid apps, get so creative with their UI and UX design, that it neither is familiar to iOS users nor to Android users, and is full of anti-patterns like bottom navigation bar on Android that interferes with the software buttons, or super-crazy back button behaviour, that makes no sense.
Learn Once, Write Everywhere for Mobile Take 3: Native Widgets with JS Runtime
After years of trying way to hard, it was abundantly clear that apart from Morgan Stanley who are way too miserly to spend on a mobile development team and McDonald’s Turkey (no not turkey burger from McDonald’s, I mean McDonald’s in the country Turkey) no one was really making any apps of real world scale using hybrid platforms, because they were just plain unusable.
That’s when Facebook and Telerik (a company famous for making developertools including the famous Kendo UI library) started working on two different (but also similar) projects — React Native and Nativescript.
The story gets really interesting from here, and that’s why that is a separate part. (Part 2 will be published sometime next week)
