Imagine, for a moment, that you want to build your dream house from scratch. You don’t know anything about construction, so you buy your plot, hire a specialist contractor and let them get on with it.

A few months later the contractor rings to tell you it’s finished, and sends you the bill. Only instead of getting one bill, you’ve got two: turns out the contractor has built you two exact replicas on the same strip of land.

Ok, we know this is a ludicrous example. The chances of this happening in the real world are effectively zero. Even if it did happen, there’s no chance that you, or anyone else, would pay for two houses.

But for companies that want to build a mobile application, it’s a daily reality. Despite all the recent advances in mobile technology, the vagaries of Android and iOS mean they’re having to pay for the same app twice, and they’ve got no choice in the matter.

It’s a problem which infuriates developers and their clients the world over. But we feel we’ve hit upon a real solution, one which will help us dramatically reduce our build times without compromising quality. And this can only be good news for our clients.

In this post, we’re going to talk about:

• The problems with existing multi-platform technologies.
• Our two-pronged solution to tackle the problem.
• The practical benefits this will offer our clients.

The Challenge

Most companies, naturally, want an app that works on both iOS and Android devices. Android commands the vast majority of the smartphone market, but iOS has the most recognizable brands, so businesses want to cover both bases.

Unfortunately, each of the two main smartphone families has its own distinct programming languages – Objective-C and Swift for iOS, Java and Kotlin for Android – and you can’t mix the two. If you build an app in Objective-C or Swift, Android won’t support it. For us developers, this is a real pain in the backend.

“You used to get two bills
for the same project.”

When we’re writing an app for both platforms (as most customers require), we’ve got to write the code twice. Everything takes double the time it should, and it’s very easy for bugs to appear in one app but not the other, the sort of thing which gives testing crews nightmares.

The engineers behind the world’s programming languages have tried to solve this problem for years, and they’ve devised a number of specialist frameworks — toolboxes which give developers the baseline code to create their applications.

Each of these frameworks claim to work across platforms, meaning developers can write one set of code and re-use it across both platforms. However, as we’re about to show you, each alternative carries obvious drawbacks which pretty much nullify their advantages.

First let’s look at frameworks such as Ionic and Cordova, which take languages such as JavaScript, designed for web apps, and apply them to mobile. These frameworks work across iOS and Android, and they’re fast, but the apps they produce are limited. What’s more, developers can’t use specialized mobile tools until they’re officially endorsed by the framework creators, which is a real drag on innovation. Then there’s the looseness of JavaScript, which is a bit of a ‘Wild West’ technology and is interpreted by different developers in markedly different ways.

In recent years we’ve seen the emergence of React Native, which is supposed to overcome these problems. This framework allows you to use JavaScript, yet build ‘native’ mobile apps. In reality, however, React Native carries all the flaws of Ionic and Cordova. Again, the performance falls short of a native mobile app. And you’ve got to wait for the framework’s blessing before firing up new technologies, and again you’ve got the lawlessness of JavaScript to deal with.Finally there are the specialist mobile frameworks, such as C and C++. These allow you to build cross-platform, for iOS and Android, and they provide greater performance and efficiency. However they’re only really suitable for data processing, so you can’t use them to build the user interface (the front-end stuff that the end user sees). What’s more, they consume a serious amount of time, which translates into higher bills for the client at the end of the project — which kinda defeats the whole point.

Our Solution

Ok, enough yapping about the drawbacks of existing alternatives. What are we doing to tackle the cross-over problem?

Actually, our solution is two-fold. On one hand, we’ve created our own blueprint to make our development process as efficient and consistent as possible. On the other, we’ve invested in a brand-new technology which, we feel, carries more benefit than any of the others.

Harmony

First, let’s talk about the blueprint. Harmony is a set of standardized processes for the way we write our code. Developed by various members of our team in tandem, it tells our engineers which software architecture patterns to use, and addresses specific points, such as which folders to store the code in.

Harmony replicates the speed, and simplicity, of using a framework, giving our developers a base bank of code to use across their projects. In most apps, this code is largely the same, across both iOS and Android. So why not keep reusing it?

There are two specific benefits here. The first is knowledge transfer: the Mobile Jazz team has built up a huge vault of knowledge over our 9 year history, and Harmony allows us to tap into this vault whenever we want. We can take the learnings from one app, and re-use them in another. If we’ve built a killer app in iOS, we can apply the key lessons to Android.

Then, there is the speed. Instead of having to write the same code every time they start a new project, our engineers can now drop in the standard code (adjusted for each individual case), and get to the core of their task more quickly. And, because our code-writing process is standardized, new members of the team can come into a project and hit the ground running, so we can switch engineers without losing efficiency. 

This isn’t a panacea for the whole cross-over problem, however. We still need to write the bulk of the code twice. But it clarifies many of the doubts that developers have, enabling them to work more quickly and effectively. We’ll explain more about Harmony in a future blog post.

Kotlin Native (Also Known as Kotlin Multiplatform)

This is the real crux of our solution. Kotlin Native is so new that many software developers haven’t even begun to use it yet. But we’re already using it in two of our biggest projects, because we feel it’s a game-changer in the way developers handle cross-platform development.

The original version of Kotlin was a cool language — fast, clean and attractive. It was so good, in fact, that Google decided to adopt it as the official development language for Android, replacing Java. But, of course, it didn’t work for iOS. 

So the company behind Kotlin, JetBrains, decided to go one better and release Kotlin Native, a version which will translate Kotlin’s code to native binaries, programs which are only written for one platform. Essentially, this means we can write our code in Kotlin and convert it automatically to run on a program built for iOS.

In fact, we can use Kotlin Native pretty much anywhere. In backend servers, macOS hardware and practically every machine that uses an operating system based on Unix (the classic operating system which has inspired the modern variants used by Apple and others).

Before we get too carried away, we must emphasize that this doesn’t mean we can build two apps with one set of code. We still build the front-end stuff, the UI, natively on each platform, because this allows us to take advantage of the latest platform-specific updates and create an ultra-smooth user experience. What we can do, however, is build the business logic, the data management functions which are core to an app’s overall appearance and performance.

What is business logic, we hear you ask? It’s the technology that springs into action when a user fills out a registration form or enters their payment details, and sends that data back to the server. Practically every app in creation relies on some form of business logic, and it usually takes the bulk of the overall development.

In fact it’s not uncommon for the business logic to account for 70% of the total project. What’s more, it’s got more bugs than a Sumatran Rainforest: glitches pop up randomly throughout the typical business logic codebase, and they often differ completely from one platform to the next.

By unifying the development of the business logic module in addition to use our Harmony resources and libraries, we can not only achieve huge time savings during the development phase, but also reduce the scope for hold-ups during testing, providing even greater efficiency gains for both us and our clients. We truly believe this is the future for fast, smooth development across multiple platforms.

We’re not claiming to have ‘cracked’ the problem of cross-platform app development. We’ve not broken through to the other side yet. But we feel we’ve tunneled our way through most of the heavy rock, and it won’t be too long before we see daylight. And our clients are already reaping the benefits.

Our new programming philosophy is just part of our wider attempt to streamline our business and deliver maximum efficiency for our clients. You can find out more about this ongoing initiative by checking out our blog here.