Nobody wants to do the job twice, and the industry has long been looking for a way to develop one application for iOS and Android instead of two. So far, no attempt to realize this has become triumphant, but three new ones have recently come to the fore. How do they differ, and can they do better?
When a company has applications for iOS and Android, many tasks during their development turn out to be identical. It is not surprising that there is a feeling «we have two development teams doing the same thing, let’s somehow make one of the two code bases, it will be simpler and cheaper.» And for a long time there were various solutions for cross-platform development, from PhoneGap to Xamarin.
However, not all so simple. In addition to identical tasks, there are platform-specific ones, when the approaches on iOS and Android are significantly different: working with UI, accessing hardware components like a camera or sensors, and so on. As a result, the good intentions of “let’s make one of the two code bases” often ended up with three becoming bases (a common one, which is used by both platforms, and two specialized ones). In three different languages. Companies found that the result was the opposite of expectations, and were disappointed.
In recent years, the main contender for success has been the React Native framework from Facebook, and it really managed to occupy a certain niche. But it still didn’t get ubiquitous, and it could not do without disappointments: last year, the Airbnb post made a big noise , which after two years of using React Native abandoned it and returned to separate native development.
Despite this, new solutions continue to appear. What exactly and what makes their creators believe that this time it will work out?
The development of this framework began four years ago, and in 2017 one could hear that they made the application of the musical Hamilton with its help . But then all this was at the experimental stage, and in December Flutter reached version 1.0, and now the interest in the development community is such that even the Russian-language Flutter podcast has appeared — in general, it is time to take a closer look.
Flutter was created by Google, which may sound unexpected. This company strives to make native Android application development as convenient as possible. Why does the same company invest resources in an alternative development method that allows making applications for a competing platform as well? What is going on?
Part of the reason is that this story is not only about mobile platforms: in the future, Google wants to allow Flutter applications to be launched “wherever you can draw pixels,” and work has already begun on desktop and web support. And when (and if) the Fuchsia OS comes out, ripening somewhere somewhere in the bowels of Google, Flutter may become the main development method for it.
But this is all the future, and what is here and now? Ability to write cross-platform mobile applications in the Dart language. The main advantage, in addition to reusing the code, Google calls the Hot Reload function: if, during native development, making changes to the code, you have to wait until you see them in the running application, then they work almost instantly.
This should simplify and speed up development. But they also spoke about acceleration in the case of React Native, and this did not make it more popular than the native development. And what are the differences that can make someone choose Flutter?
For example, in the approach to UI. React Native uses native interface elements: if you add a button to the project, then the standard iOS button will appear in the iOS version of the application, and similarly with the Android version. Flutter resolutely refuses this: it does not call the standard OS elements, but says “the whole screen is my canvas, I want to draw it” (this was made possible thanks to the Skia graphics engine, which has been used in Google Chrome for a long time). And he suggests drawing something like this that is not tied to the visual language of any of the platforms:
But if you want to “make it familiar to the user”, this is not a problem either: Flutter has its own set of ready-made UI elements imitating familiar iOS / Android elements.
In addition to the approach to the UI, Flutter plays into the hands of the fact that it was created by the owners of Android. For example, Google suggests using its Android Studio as the main Flutter development environment, which Android developers already know very well. At the same time, there is no strict requirement “only Android Studio”, Flutter also has support in Visual Studio Code.
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 remained cautious: «What will happen if we rewrite everything on Flutter, and then Google abandons it?»
And finally, Flutter does not perform a miracle: although in the case of the UI they got rid of the binding to the platform, in a number of other tasks this binding remains. So it’s impossible to completely disengage from the platform, while developing it will still require knowledge of both iOS and Android. And in some cases, three code bases in three different languages will still be obtained. In general, Flutter can help, but you should not expect “everything will be simplified by exactly half”.
The Kotlin language has already become the standard in Android development; applications are massively switching from Java to it. But Android is not limited to: JetBrains, the company that created Kotlin, is working on supporting a wide variety of platforms, and on the convenience of reusing Kotlin code between platforms. One of the proposed options for such reuse is just between Android and iOS.
JetBrains has an important difference from many other supporters of cross-platform: they did not initially set the goal «so that there was one completely universal code base.» While someone is striving for this ideal and burns his wings, in this case they immediately recognize that the radical “everything in common” approach works poorly, and they don’t even try to realize it.
Instead, they propose to reuse only the truly general part of the code, where developers on different platforms really write the same thing. And everything that’s different is still natively written. And while Flutter is focused on the full integration of the UI, here, on the contrary, it does not unite in any way.
Roughly speaking, they propose to allocate everything in common to a library on Kotlin, suitable immediately for iOS and Android, and then turn to this library from both sides. So with Kotlin Multiplatform, a mobile project is obviously obtained from three components — a common one and two separate ones. And then an objection begs: “Wait, we were not happy if three of the two code bases turned out to be, and we are immediately offered to do just that. What is the point then? ”
But the popularity of Kotlin in Android development plays an important role here. If in other cases “three code bases” means “in three different languages”, then there is no need to drag a new language into your mobile project: often it already exists there. And the team already has people who can write well on it. Here iOS developers will have to deal with a new language for them, but the simplicity of Kotlin with Swift and interoperability with Swift / Objective-C make their life easier. It is interesting how this will affect the roles in the team: the boundaries of the platforms are blurred and a “common” part appears, but it is not equally close to both sides.
Choosing the “three-part project” approach, JetBrains directed their efforts towards the most seamless interaction of these parts: the idea of combining “common” and “platform-dependent” code is supported directly at the language level. When the same function must be implemented differently on different platforms, it is declared in the «general» code with the special keyword expect («there is such a function in principle, you can call it»), and in the «separate» one with the keyword actual write two specific implementations of this function. In the screenshot above you can see an example of a common code, the platformName () function acts differently depending on which smartphone it is running on.
Of course, absolute seamlessness still cannot be achieved, and there are many complex issues at the junction of different worlds. How successfully JetBrains can solve them is an open question: if Flutter has already stepped over the key mark “version 1.0”, then Kotlin’s multi-platform capabilities are still equipped with the “experimental” icon, everything is at an earlier stage. And so far there is no example of a large application with Kotlin multiplatform (but you can look at the code of a small one ).
The word “experimental” usually means that it’s too early to drag technology into a work project. But it also means a stage when it can be significantly influenced personally: many important decisions are still not cast in granite, and feedback affects them. So, if you try Kotlin multiplatform specifically for your tasks, you will encounter a problem and report it to JetBrains — now it’s more likely that everything will change in a direction convenient for you.
At this point, readers can fly tomatoes. Firstly, if the text is about developing mobile applications, then what does the site have to do with it? Secondly, how can you consider them a “new approach” in 2019, if the concept of PWA (Progressive Web Apps) is far from one year old, and Steve Jobs even suggested using web applications even when launching the first iPhone?
I did offer it, but there is a nuance: web applications in 2007 and in 2019 are not at all the same thing. And literally over the past year, new opportunities have appeared that should once again look at PWA and understand if it’s time to consider them now full-fledged cross-platform applications.
What is the original idea of PWA? “Of course, with sites it’s convenient that you avoid all this weight with duplication of iOS / Android, but native applications win in some ways. For example, they can work offline and send notifications, and their beautiful icon on the home screen and in the App Store attracts users to tap. So let’s give the sites all the features of the applications, and everything will be fine! ”
The process of “giving these opportunities” then really started, but slowly. Although Google advocates the idea of PWA, it looks like a cold war is going on between the Chrome and Android teams inside the company: Chrome wants to give Android users all the PWA features as soon as possible, but the Android team has its own priorities like Instant Apps. And Apple generally ignored this phenomenon for years, not supporting the PWA capabilities on iOS, as if Jobs had never campaigned in favor of anything like that.
But a year ago, a tectonic shift happened quietly: starting with iOS 11.3, Safari introduced support for key PWA technologies. At the same time, Apple is not so public about this that it did not even report about these changes in the list of innovations of iOS 11.3. And when the user opens your PWA website, the iPhone will not pay attention to it: “this web application can be added to the home screen”, as Android does. It turns out weird semi-official support, in which the benefits of PWA can pass by interested people. But the main thing is that the ice has broken, now we can talk about cross-platform.
And here is another event that occurred less than two months ago: Trusted Web Activity support appeared in Chrome 72 for Android, and this is a step in the direction of “publishing PWA on Google Play” (everything is not simple there, but it can become easier in the future). Why should a web application be published in the store at all, if the site is already accessible by reference? Because stores remain a powerful source of audience, users open them when they want to install something.
Finally, the latest news: PWA support appeared in Chrome on macOS, and since it was already in Chrome on Windows and Linux, now the entire desktop segment is covered. Although this does not apply directly to mobile development, for some, this news will be an argument in favor of abandoning the native approach: “I’d better make a site that can be installed anywhere as a program, on any phone and any computer.”
In general, the creation of PWA is now more attractive than ever. But at the same time, a million different inconveniences remain. For example, on iOS, PWA services can receive individual images from the camera, but cannot receive a video stream (this spoils life, for example, to QR scanners). And on Android, if the user changes the phone, the system will gladly restore the native applications installed by him to the previous one — but will not restore the PWA added by him to the home screen.
As a result, PWA can already technically be called “applications that are installed on both Android and iOS”, but practically there remains a big question of how justified their use instead of regular applications is, but it is likely that their support will continue to improve in the future.