The Hell of Multi-Platform Software Development
Tackling fragmentation: how one codebase can dominate every display, keeping costs down
If this title rings distant and gloomy bells for anyone, the effect is intentional. Those familiar with software programming and technology have witnessed various expressions of hell over time. The worst incarnation was the DLL hell, notorious for devastating Windows software until at least 2000. But there’s also the famous, though paradoxically less harmful, Millennium bug. And how can we forget the assembly versioning problem in the .NET Framework (Microsoft… again?), the system driver chaos, the pop-up drift in the early commercial Internet, the challenge of updating car navigation maps, the mental contortions required to use VHS recorders, or the current annoying, expensive, and endless migration of DTV standards?
Technological hell is neither new nor rare, prompting us to wonder why these nightmares occur so frequently. Usually, pandemonium doesn’t arise from the work of an evil being who hates humanity. Rather, it stems from an obscure engineer with poor creative skills, short-sightedness, an inflated self-image, and good standing in company rankings. Unfortunately, this person appears in the wrong place, at the wrong time, in the wrong company, with the wrong team. This combination of elements can produce technology that initially seems brilliant enough to enter the market and perhaps become a standard, only to reveal fatal design flaws later: perhaps it doesn’t scale in size or time, or it neglects fundamental aspects like usability, security, and cost-effectiveness.
More generally, the abyss opens when a technology’s impact on the real world is underestimated.
In this article, I’ll discuss a new hell, the software platforms hell, which is devastating as usual but, for once, doesn’t stem from a design flaw. This technological delirium has an unprecedented origin: the success of computing with its pervasive and explosive diffusion.
How can such absolute success be so harmful?
By computing, I mean using computers in a broad sense, and our world offers dozens of opportunities for computer interaction in daily life. Computer presence is obvious when using a smartphone or PC but less apparent elsewhere. Modern cars provide entertainment systems, driving assistance, navigation, vehicle monitoring, and electronic toll collection. We wear smartwatches, fitness trackers, smart glasses, Bluetooth headsets, and medical devices. At home, we have smart TVs, home automation, security devices, intelligent appliances, and video games, while outside we encounter self-service checkouts, vending machines, and surveillance cameras.
Even this brief list reveals how many hardware platforms are commonly available to us.
Some of these hardware platforms, usually the most advanced, allow adding and running custom software. I’m not talking about low-level firmware customizations but systems designed to be extended with programs. Consider a smartphone and the many services it provides through apps. A smartphone is both a hardware platform and a software platform.
And if one app offers the opportunity to add and run software within itself? Then we have a software platform within another software platform. A prime example is the browser, which is both an application and a system to provide endless other web apps.
What makes computing’s “success” a real disaster for software producers is precisely the fragmentation of environments where programs can be distributed.
A company, in accordance with its business, must discover the ideal publishing platform, study existing competitors, hire professionals who can design and write software for that area (or train internal resources for that), find the right development tools, and establish publishing and promotion channels. Even independent developers must use resources to study the platform’s operation, limitations and strengths, learn appropriate programming languages, libraries, and frameworks, and become familiar with the tools.
Normally, producing and selling something requires budgeting all costs to achieve your goal. But if a single distribution platform isn’t enough and you need to be present on two, three, or ten platforms, costs increase more than proportionally. The project, while essentially the same, must be redesigned, adapted, recoded, maintained, and promoted for each publishing area. It’s as if, for distributing a chair in a new market, you have to start the entire process from the drawing board again. Achieving economies of scale becomes difficult in such a fragmented environment so much so that targeting the niches represented by software platforms raises costs at an unsustainable rate. And when I say “unsustainable,” I’m not exaggerating. The list of companies investing only in apps while neglecting or offering limited web experiences is long and almost embarrassing: Instagram, WhatsApp, TikTok, Revolut, N26, to name a few. Similarly, many web-present companies entered the app world with poor or even pitiful products: LinkedIn, Facebook, Reddit, Amazon, eBay, and more.
What if…
…there existed a simple, economical system to write a project once and distribute it on every platform with virtually no additional costs?
“Write once, run anywhere” wrote Sun Microsystems in the mid-90s when launching Java. They intended Java to run on any platform, even extending beyond desktop environments to the web with Applets. It soon became clear this was more nightmare than dream: Java on the web introduced security, performance, and compatibility problems. Most importantly, desktop code didn’t work on browsers and vice versa, unless you just wanted to display the always useful “Hello World!” message. We were light years away from the “Write once, run anywhere” concept, it was more like “Learn once, write nth-where.”
Later, others tried similar approaches (remember .NET?) but always with poor results, at least for cost containment.
Unifying web and desktop is a difficult game, a game that becomes impossible if we include, in the initial requirements, mobile devices or, worse, the walled gardens (those virtual zoos where people self-exile, becoming totally unreachable unless you enter the cage yourself).
Apparently, the magic key to enter all environments doesn’t exist, and each platform requires its own project, languages, methodologies, experts, and substantial budget allocation.
White flag?
Perhaps the solution is simpler than expected, possibly in plain sight forever but strangely underexploited…
The idea is trivial but interesting: what if we could use the humble web to conquer software platforms?
Theory and practice don’t always align, so to test my hypothesis, I developed a complex enough project covering typical application aspects without the need to access platform-specific resources. This meant no mobile device sensors, no advanced GPU graphics, no high processing capacity, or high-speed network connections. Considering the specifications and limits, it seemed the ideal candidate could be any kind of management software but, wanting to have a bit of fun too, I opted for a simple puzzle game. This spared me from boring inventory calculations or compound interest computations, and above all, I wouldn’t need a database or server-side API complexities that would add nothing useful to this experiment.
Thus, Shades Master, a coloring game written in HTML, CSS, and JavaScript, was born.
What is the recipe for Shades Master?
Apron, knife, cutting board, and pan are there, so let’s move on to the culinary technique.
In its basic form, Shades Master is a web app, so for our recipe we use HTML5, CSS3, seasoned with any JavaScript library or framework for interactivity: Vanilla-JS, jQuery, Vue.js, Angular, React, TypeScript. Amalgamate everything with support technologies like WebPack, SASS, LESS, Bootstrap, Grunt, Gulp, NPM, Bower, Yarn, Slurp… Boing, Mickey Mouse, Peppa Pig… wait, am I getting carried away?
On closer inspection, it’s an odd recipe where ingredient choice doesn’t affect the final result. Metaphorically speaking, being able to use what’s already available in the pantry reduces one of the most significant costs in software project development, which, needless to say, is human resources. The freedom in technological choices allows companies to leverage existing web developers and familiar technologies without additional training or hiring.
Since we’re not designing a simple website but a web app (highly interactive website) that must work across multiple platforms, we need certain precautions not always required in typical web development.
An absolute priority is building responsive pages that ensure usability at any resolution and aspect ratio, from 4K landscape screens to small smartphone displays in portrait mode.
Another consideration is pointer input. Websites collect mouse inputs, but touch-screen devices use finger inputs, with significant differences in the code to manage them.
From these examples, we see that multi-platform development isn’t particularly burdensome but, on the contrary, this kind of care is already in the developers’ background.
Optional ingredients could spice up the recipe and enable deeper interaction with destination platforms (system notifications, authorization requests, native menus, platform-specific analytics), but this approach erodes our efficiency principles and forces platform-specific development. By the way if you need something special from a certain platform, your project is probably suited for that environment and not others.
Get Gianluca’s stories in your inbox
Join Medium for free to get updates from this writer.
Android and iOS
Let’s address the elephant in the room. For almost 20 years, these platforms have dominated personal mobile computing, with the prevailing opinion that applications must be developed in native code. So what does the web have to do with it?
On Android, System WebView allows displaying web content within apps without opening an external browser.
On iOS, WKWebView (evolving from UIWebView) serves the same purpose.
Theory suggests websites can be embedded in apps on both platforms, an approach known as hybrid web apps.
With this particular approach, the expense comes from creating a special “frame” for our hybrid web app to make it appear as a normal native app. In fact it must be publishable on app stores, have an icon and description, be updatable, and not feel like browsing a website. Implementing this frame would increase our costs if special third-party services don’t come to the rescue. For Shades Master, I used median.co, which creates application frames through a simple online wizard.
And so with no effort and no additional cost (thanks to Median’s basic plan), Shades Master for Android is available here:
https://play.google.com/store/apps/details?id=co.median.android.dqrzrk
For iOS, median.co only offers the frame source code, which needs Mac compilation and App Store publication. Both Mac computer and Apple developer subscriptions are expensive, so I left this part theoretical — no apples for me please -. The viable path exists, nonetheless.
With Android and iOS covered, much work is complete, but, as mentioned, software platforms extend beyond hardware platforms or operating systems, so we need to go further to land in the browsers’ world.
Chrome extension
Why develop a Google Chrome extension rather than just a website?
The reason involves distribution. Entering a store is an obstacle but also helps convey your application beyond simple internet searches. A Chrome extension also makes your app enter ChromeOS which, despite its limited market share and ignoring its ability to install Android apps (already covered), represents an interesting niche.
More accurately, we’re creating a Chromium extension rather than a Chrome extension. The extension store is Chrome-branded, but any Chromium-based browser can install extensions from there. Chromium encompasses browsers like Chrome, Edge, Opera, Brave, Vivaldi, Yandex, Samsung Internet, and others.
Microsoft Edge also has its own extension store, compatible with other browsers, making the Chromium extension market even wider.
For those interested, Shades Master in Chromium flavor is available here:
https://chromewebstore.google.com/detail/shades-master/nphkglhhadblccdfjddaoimkfaikopnb
Telegram Mini App
Next step: how nice would it be to enter an exclusive walled garden too?
Let’s target the second-largest messaging system. Second for the number of users, not for application quality.
I’m talking about Telegram and its billion users.
Telegram offers Mini Apps, which are hybrid web apps launched from within the messenger via a bot.
How does a Mini App work? It uses System WebView on Android, WKWebView on iOS, and Chromium on desktop, integrating a website directly within the program.
Needless to say, Shades Master is now available in Telegram as a Mini App through its dedicated bot:
@ShadesMasterBot (https://t.me/ShadesMasterBot)
What about WhatsApp? After all, it’s the first messenger by the number of users and is also the perfect archetype of walled gardens, as its community often has poor technological skills and even less inclination to explore beyond the fence. A potential market of two billion users. Unfortunately, WhatsApp only partially opens to third-party applications and only for messaging related features, preventing anything interesting from distracting WhatsZombieland inhabitants from their viral videos or chain letters. So let’s leave them and wait until WhatsApp opens a door.
Desktop
Are we forgetting half the world?
It may seem strange, but desktop computing isn’t dead and represents a significant portion of global computing.
For desktop users, offering Shades Master through a website might suffice, but that would make our experiment less impressive. The challenge is bringing web technology to as many software platforms as possible, not just demonstrating that browsers are available anywhere.
The solution is Electron, a solid open platform for Windows, macOS, and Linux that hosts offline web apps. It’s so successful that prominent programs like VS Code, Discord, GitHub Desktop, Slack, Atom, Postman, and Tidal use it.
How does Electron work? Quite simply, it uses a customized Chromium version (what? again??) and Node.js to process offline web apps through CLI commands, converting them into setups ready for desktop platforms.
I published the Shades Master Windows setup on itch.io, an indie game marketplace, at this URL:
https://meeplesoft.itch.io/shades-master
So the Virgil who guides us out of Hell is…
My theory of writing an application once and deploying it to almost every software platform proved valid, thanks largely to Chromium’s pervasiveness. We found our Virgil-Chromium, in its various identities, across all explored application areas except mobile devices, which (seem to) use different techniques.
Actually, I should reveal something: Android System WebView is merely a Chromium version adapted for software rather than human use. The only platform where we used something truly different was iOS, which anyway employs a similar concept with WKWebView that is a reduced Safari version.
The general rule from this experience is that as long as Chromium or similar technologies are available on a platform, HTML/JS applications can run without code modification, as online or offline web apps.
This is an extremely valuable conclusion both in terms of reducing development costs and for multiplying publishing outlets, but also in purely strategic terms, in perspective. The software platforms world has already moved in a coherent direction, or at least one of the always available options for software creation is to write your code for a browser.
For long-term technological choices, these signals should be unequivocal.
And So We Went Out to See the Stars Again
The journey was exciting, complex, and varied, sometimes hitting dead ends, but I successfully reduced software platform fragmentation through web omnipresence (omnipotence?).
True, each platform requires learning specific debugging techniques, understanding deployment package generation and publication, and accommodating environmental idiosyncrasies. But what’s truly remarkable and impressive is that the codebase I published across all environments remains exactly and invariably the same…
“Write once, run in the multiverse”
