Sunshine Coast Award-Winning Digital Agency
Cross-platform mobile development in 2019
No one wants to do the same work twice. The industry has been looking for a way to develop one app for iOS and Android instead of two for a long time. No solution to make it a reality has been successful so far. However, three new frameworks have been announced recently. What is the difference between them and in what way are they better than others?
When a company has apps for iOS and Android, many development tasks in the process turn out to be identical. Therefore, it shouldn’t come as a surprise there’s this idea to somehow form one dev-team using just one code base, instead of two. It will be both easier and cheaper. Long ago framework solutions for cross-platform development — from PhoneGap to Xamarin — began to appear.
But in practice, it is not that simple. Apart from identical tasks are, there are also lots of platform-dependent ones. Code bases of iOS and Android differ significantly: working with UI, accessing hardware components like cameras or sensors, and so on. As a result, trying to create one code base out of two developers often end up with three, in three different languages: a code base used by both platforms, and two specialized ones. Companies were left disappointed.
In recent years, Facebook’s React Native framework has been quite successful and carved out a niche for itself. While it seemed that mobile apps are finally! dying, it didn’t gain a lot of traction. Last year there was a notorious post by Airbnb. After two years of using the React Native framework, the company refused to use it anymore and rolled back to native development.
Nevertheless, new solutions continue to emerge. Which will work, and what makes their creators believe so?
Flutter
The development of this framework began four years ago, and by 2017 the news dropped that Hamilton app was built using Flutter. At that time everything was at an experimental stage, but in December 2018 Flutter rolled out version 1.0, and now the interest in the dev community is at its peak.
Flutter is created by Google, which may seem unexpected. The company aims at making native development of Android apps as convenient as possible. Why does this company also invest in an alternative way of development that allows competing platforms to create applications as well? What’s going on?
The fact is, in part, that it’s not all just about mobile platforms: in the long run, Google wants to allow Flutter apps to run “wherever pixels can be drawn”, including desktop and web platforms. So if — and when — the Fuchsia OS is officially released (still brewing in the depths of Google), Flutter may become the primary development framework for this system.
But that’s all about the OS yet to come. Let’s take a look at what is happening here and now: the development of cross-platform mobile applications using Flutter’s Dart language. The main advantage, apart from reusing the code, is what Google calls “hot reload”. In native development, you have to wait before you see changes you make to code in a running app. With Dart, changes take place almost immediately.
This should simplify and accelerate the development process. However, in the case of React Native, they said just the same, but it didn’t make the framework more popular than the native. So what are the essential differences that can make someone choose Flutter?
Let’s take a look at the approach to UI. React Native uses native interface elements: if you add a button to the project, there will appear a standard iOS button in the iOS version of the app. The same is true for the Android version. Flutter firmly rejects to do so: it does not use standard OS elements. Its graphical elements are not tied to the visual language of any of the platforms.
But if you want a user to be familiar with UI, there’s no problem: Flutter has its own set of ready UI elements that imitate the usual iOS/Android elements.
In addition to the fact that its UI approach, Flutter is created by Google the owners of Android which is another advantage. For example, Google offers to use Flutter with its Android Studio, which Android developers already know very well. At the same time, there is no strict requirement to use only Android Studio, as Flutter is also supported in Visual Studio Code too
Nevertheless, there are still some problematic aspects. One of them stems from Dart as a choice of language. First, this language is not used in either iOS nor in Android. Secondly, it has limited usage overall. React Native was supplemented by the abundance of JavaScript developers in the world. Unfortunately, it is difficult to find an experienced Dart developer. However, those who tried Dart claim that it is easy to master it after Java or other object-oriented languages, so there is no fundamental barrier here.
Another problem is Google’s reputation as a company that often kills its own projects. Therefore, even after the release of Flutter 1.0, many still remained wary: “What happens if we rewrite everything via Flutter, and then Google will give it up?”.
And finally, Flutter does not do wonders: they got rid of UI binding to the platform, while in a number of other tasks, bindings remain. So, you can’t completely detach yourself from any platform, and the development will still require knowledge of both iOS and Android. In some cases, there will still be three code bases in three different languages. In general, Flutter can help, but you shouldn’t expect that everything will be considerably simplified.
Kotlin multiplatform
The Kotlin language has already become a standard in Android development. Apps are migrating from Java to Kotlin en masse. But it’s not confined to Android: the company that created Kotlin, JetBrains, is also working on multiplatform support, and use of Kotlin code on iOS and Android.
JetBrains is, however, significantly different from many other cross-platform supporters in one key aspect: they are initially not aimed at having one universal code base. Unlike others, who try and fail, JetBrains immediately admitted that the radical approach of “one code base for all” works poorly, and doesn’t even try to implement it.
Instead, they suggest reuse of only the truly universal parts of the code. Developers actually write the same initial code for both platforms and only continue to work natively on all the discrepancies. And while Flutter is focused on the full unification of the UI, it’s not the case on the code side of things.
So the Kotlin Multiplatform inherently consists of three components: one universal code base and two separate ones. “Hold on, we were unhappy when two code bases turned out to be three, and now you offer us to do the same. What’s the point, huh?”
That’s where the popularity of Kotlin in Android development plays an important role. While in other cases “three code bases” means “three different languages”, there is no need to bring a new language to your mobile project with Kotlin. It is often already there and the team already has people who know how to write well on it. Anyway, iOS developers will have to deal with a new language, but the similarity between Kotlin and Swift and interoperability with Swift/Objective-C makes life a bit easier for them. Interesting is how all this will affect team roles: the boundaries of platforms are blurred and, yes, there is a “universal” part, but it is not equally close to both sides.
Choosing the “three-base” approach, JetBrains focused on the most seamless interaction of these parts: the idea of combining “universal” and “platform-dependent” code here is supported directly at the language level. When the same function must be implemented differently on different platforms, the “universal” code declares it with a special keyword “expect” (there actually is such a function and you can use it) and with the keyword “actual” for the “platform-dependent” code.
There is still no absolute seamlessness, and a lot of complex issues remain at the junction of these different worlds. Whether or not JetBrains will be able to solve these problems is an open question for now. While Flutter has already reached the key destination of “version 1.0”, the multiplatform capabilities of Kotlin are still “experimental” and are at an earlier stage. And yet there is no example of a big app using Kotlin, but you can look at the code of a smaller one.
“Experimental” usually means that it is too early to roll the technology out into the world of big projects. True, but it also indicates a stage where the technology can still be significantly influenced. Many important decisions are affected by the feedback. So, if you try out Kotlin, encounter a problem and report it to JetBrains — there is a high probability that your feedback will be taken into account.
PWA
Here you can laugh me off, suit yourself. What do the websites have to do with mobile app development? Secondly, how can they be considered a “new approach” in 2019? The concept of PWA (Progressive Web Apps) has been here for a long time, and Steve Jobs offered to use web applications back when he released the first iPhone!
Indeed, my friends, but there is a nuance: web applications in 2007 are not the same in 2019. Over the past year, new solutions have appeared. So you should once again ask yourself if now is the time to consider PWAs as full-fledged, cross-platform applications.
What is the original idea of PWA? It is quite convenient that you avoid all the burden with iOS/Android code bases, but native applications always win, right? In some sense, of course. They can work offline, send notifications, and their beautiful icons beckon users to tap it.
That’s where I, with an attitude of a ring announcer, step up and say: “So, let’s give the websites all the capabilities of the applications!”. Cool, but what’s the reality?
The process of “providing these capabilities” started rather slowly. Although it seems that Google stands for PWAs, there is some sort of a cold war between team Chrome and team Android inside the company. Guys from team Chrome want to give Android users all the features of PWAs as soon as possible, but the Android team has their own priorities such as Instant Apps. And Apple? Oh, Apple simply ignored this phenomenon for years, not supporting the capabilities of PWA on iOS, as if Jobs had never lobbied for anything like this.
A year ago, a major shift occurred: starting from iOS 11.3, Safari added support for key PWA technologies. At the same time, Apple doesn’t speak about it publicly, they didn’t even report these changes in the change log. When users open their PWA website, the iPhone (unlike Android devices) will keep its mouth shut about the fact that this web application can be added to the home screen. It results in strange semi-official support, in which the interested people may miss the benefits of PWA. But, still, the ice is broken, and we can now talk about cross-platforming.
And here’s yet another thing that happened about 4 months ago: Chrome 72 for Android added the support for Trusted Web Activity, and this is a big step towards seeing PWAs in Google Play. Not so easy yet, but the future looks already brighter. Why should a web application be published in the store if the website is already accessible via a link? The answer is that stores remain a good source of users.
And finally, the newsflash: PWA support has appeared in Chrome on macOS, and since it was already in Chrome on Windows and Linux, the desktop segment is now entirely covered. Although it’s not directly connected with mobile development, to someone this news will be an argument in favor of abandoning the native approach. Just think: it’s better to make a website that can be installed anywhere as an application, on any phone and any computer. Sweet?)
Generally speaking, PWA is now more attractive than ever. But there are still a number of inconveniences. On iOS, PWAs can get pictures from your camera, but cannot receive a direct video stream (e.g.: makes life harder for QR-scanners). On Android, if the user has changed the device, the system will willingly restore all the previous native applications (from Google Play store) but not PWAs.
At the end of the day, you can technically say that PWA is truly multiplatform, but a big question still remains. How justified is their use instead of conventional applications? It is likely that support of PWA will continue to improve and then we’ll see.
In Conclusion
So, unfortunately, 2019 will not help you fire half of your mobile developers. None of the solutions above allows you to commence true multiplatform development and simply “do it”. However, those interested in any possible increase in efficiency should pay attention to all three.
When there are so many options, what framework should one choose? The answer is boring, but no less true: each one has its own advantages and risks, so it is better for the team to have a person who is able to make a reliable decision. Will we be able to implement everything we need in PWA? Will the speed of our team’s work be at its maximum with React Native? Will there be problems with native features in Flutter? Do we even have people with knowledge of Kotlin/Swift?
If there is no one best cross-platform approach, which will be the most popular? It’s impossible to say for sure, but debating it can still be fun and I hope you’re in it with me.
Guest Bio:
Founder of GRIN tech — boutique agency doing things online and claiming to do a full cycle: design, development, and marketing. Apart from client projects and everyday hustle GRIN tech’s team is playing around with in house projects like GRIN launcher & GRIN games.
We are social, feel free to communicate on:
About the author
PAUL SMITH - For over 20 years I have worked with businesses, enterprises and brands in Australia, NZ, UK and US to drive digital marketing growth using organic and paid traffic strategies. No fluff or BS, just straight-forward return on investment.
More Blog Posts
