In the last two years Android development is moving in the direction that we could compare to Flutter. Obviously, we are talking about Jetpack Compose — a new set of tools for building UI components.
Why this topic?
Jetpack Compose, as the name suggests, changes approach from inheritance to composition which is a serious change, as it completely inverts the way of arranging UI elements. In other words, if you want to create a text field with a spacing around using Flutter, you should place a Text widget and wrap it with a Padding component.
On the other hand, in Android you have to adjust the Text’s padding modifier. This example may show you that, although both technologies share common concepts, they differ even in the simplest usages.
And that’s what encouraged us to talk a bit more about the pros and cons of both technologies.
Views
Better widgets cohesion in Flutter seems to be an advantage over Android’s Compose in many different places. What’s more, the green platform still refers to the XML when it comes to data pickers or Activity’s theme, which may be confusing for composition adopters.
The native platform is always advertised as more performant and stable. Without additional effort, Android supports device’s highest screen refresh rate, whereas Flutter for many years pointed to stable 60Hz and more is not always so easy to achieve.
When we mention sweet features like hooks and foldable support, it becomes obvious that writing views in Flutter is a pure pleasure. If you’re interested in the topic, check the article below.
Language
When we consider Kotlin as a default language for Android applications, Flutter and its Dart sound like an unfunny joke.
Despite JetBrains language’s potential to be really really short and thus not very readable, there are no more arguments in favor of Dart.
Lack of reflection, base syntax structures and much boilerplate for simple classes — these are the main pain points for the developer community.
Of course, Dart has even easier async code creation and mixins which may be great, but still don’t allow to put Dart over Kotlin, especially from the dev’s point of view.
Native services
This is the topic which should not be considered to be better on any platform. Usually, if any functionality is easy in Android, it will also be quite easy in Flutter.
However, the Flutter community already provided many packages with coverage of native options like location or notifications. This kind of package really speeds up development, as long as it is maintained by the contributors.
Native approach gives you a taste of the old Java classes and simple interfaces over C++ code. Developer experience in that case is very often considered as painful. On the other hand, as long as we have access to the C layer, almost everything is possible.
When a product greatly depends on a device’s features, probably you will have to write native code, and then Flutter can make things only harder not easier.
Responsiveness
Before foldable devices, Android already had challenges with responsive design. Screen rotation and tablets forced developers to think in two orientations.
And what is surprising is that there is no complex tool in order to manage layout resizes. Well adopted Fragments and less liked separate xml files are some improvement, but custom widget measuring and drawing is still a really tough process.
Here, Flutter seems to be a really good partner. Thanks to DisplayFeatureType and other MediaQuery information we can adjust the dimensions of the whole screen or direct component.
The thing that in Android Fragment also has its own lifecycle and cannot communicate with parents and childs so easily makes our job just harder.
