Flutter is slowly starting to gain a foothold in the world of cross-platform mobile applications. But what is Flutter? What are its advantages and limitations? And above all, is it a wise choice for your project?
Flutter
Flutter is a development framework developed by Google for building web, mobile , and desktop applications with the promise of a single source code for all platforms.
The latter is very young: the beta version was made available in May 2017, and the first official version was released at the end of 2018. Flutter is therefore less than a year old in stable version , which makes it a framework dedicated to undergoing important vectors of progression and optimization.
The language used by Flutter, Dart, is, him with quite young. Its first version was released in 2011, just 3 years before the release of the first version of Swift, one of two native programming languages for iOS. This very relative novelty means that many current concepts are missing (such as a real management of certain aspects of functional programming, with an operation different from what a developer accustomed to other languages expects). However, other current concepts are beautiful and very present, in particular the management of asynchronous calls which are natively supported by Dart.
However, Dart does add a layer of abstraction with the native code that removes some functionality that is considered “acquired” by default. We think in particular of the observation of the state of a scrollable view, which can allow the creation of effects like this one:
It is easier than natively to code the standard components of your project design and reuse them throughout your project. If the stage of establishing the design and its patterns has been correctly turned towards this way of thinking, the development time of the screens of the entire application will be greatly reduced compared to their native equivalent which does not allow or at least not so simply to handle this case.
However, you have to be very careful to keep readability in your source code as you use these pieces of component so that the project can easily be maintained.
This logic of design components also applies to logical components of the application if they are to be used in several different places (for example a field verifying the validity of an email address which can be used during registration and registration. the connection).
However, although this problem arises from the point of view of logical components, it is quite different for visual components.
UX / UI
Flutter has 3 predefined application skeletons:
- A skeleton is governed by the rules of Material Design. Full documentation on what Material Design is can be found here. This skeleton makes it possible to directly include several essential mechanisms, such as floating action buttons, sandwich menus, and finally the entire navigation mechanism of the application.
- A skeleton is governed by iOS design rules. We find among others the gesture of backtracking by sliding from the left edge of the screen.
- A skeleton allowing to create an application that obeys neither the rules of Material Design, nor those of iOS.
All solutions are possible depending on the rendering expected by the design of the application: should it comply with the design rules of each OS? Should it apply Material Design rules on Android and iOS? Should it offer a unique interface that obeys only its own rules? In any case, the choice in terms of design is much easier to set up with Flutter.
We’ll talk about application maintenance with Flutter in a few moments, but one of the intrinsic advantages of this cross-platform language is that a design change can be done in one fell swoop on Android and iOS, or on just one of the two. if you want a result with more granularity.
Many details inherent in the behavior of application elements depend on the operating system running the application. For example, the scrolling animation is, by default, different between iOS and Android, but Flutter gives us the ability to control the latter on each of the OS.
There is nothing trivial about using a fully customized skeleton. It makes it possible to create extraordinary user interfaces, which could not be done natively, or else very difficult and therefore requiring much more resources and budget than with Flutter. This skeleton allows you to have control over all interactions between the user and the application, allowing to offer an extraordinary user experience that will make your application stand out from the crowd.
These skeletons and their associated design components allow you to build an interface very quickly. Likewise, the animations are much easier to set up without an external library with Flutter than in native Android or iOS code.
Flutter offers several solutions to animate the content on the screen. One of the most popular animations lately is called Hero and can be found especially on the App Store:
This type of animation is much more complex to set up natively than with Flutter, which makes it a framework of choice for “complex” animations.
Flutter also makes the management of certain sources of ergonomic problems much simpler; in particular with a simplified management of the famous “safe area” , this dead zone in the notch and the lower part of the telephones. Managing the space occupied by the keyboard on the screen is also much simpler with Flutter which manages it automatically if the skeleton is properly mastered, eliminating important sources of recurring user experience problems ( like the keyboard which hides a validation button for example).
Already implemented in new versions of Android, and implemented by iOS 13, managing dark mode is much easier with Flutter, but also and above all instant!
Finally, managing the interface between phone and tablet is much easier with Flutter. Since everything is an independent element in Flutter, we just have to arrange the tablet view to display two elements side by side, and in just a few moments we get a so-called master / detail view like the settings in iOS:
Use
In theory, a cross-platform language would like the development time to be divided by 2. But the reality is much more nuanced.
Indeed, it is important to take into account from the beginning of the project the possibility of developing a “bridge” allowing to call a system library.
But what is a bridge?
It is simply an implementation for the Dart application of an Android and / or iOS library, with code specifically written for these platforms.
The most recurrent case with Flutter is communication with “hardware” libraries: camera, payment terminal, microphone … Libraries exist for iOS and Android, but nothing official in Flutter. Several cases can arise:
- Either a third-party developer has already made a bridge for this use case, in which case it may be wise to use it after having analyzed the relevance of its code as well as its update frequency
- Either nothing has yet been done, in this case you will have to make the bridge yourself.
Although relying on third-party libraries does not generally pose a problem natively because of the large community always ready to update them, the data is quite different for those available in Dart.
Indeed, many of these libraries are currently in per-versions and are in no way excluded from bugs that are intolerable in a production environment. It is therefore wiser to develop this bridge internally, in order to be able to have direct control over the code of the latter in the event of a problem.
Despite this constraint, Flutter offers an undeniable advantage: application maintenance is much easier to manage.
With a single code for several platforms, maintenance time is more easily divided by 2, but above all easier to set up. This is in particular due to the fact that the new functionalities will be de facto coded at the same time for each platform, the same for the resolutions of bugs or the changes of design. The low maintenance cost makes it an unstoppable argument if the budget allocated to this part of the application’s life is limited.
Another big advantage is the rock-solid backwards compatibility. Although the question is more sensitive on Android than on iOS, Flutter puts everyone in agreement, pushing the compatibility to 99.4% of the Android fleet (in May 2019) and 99% of the iOS fleet (in July 2019 – iPhone and iPad combined).
A small downside to this data, some functionality needs may increase the minimum version required. For example, to store data securely in the phone (to store a password for example), it is necessary to have a phone running Android 4.3 or higher (i.e. 96.7% of the Android fleet instead of 99 , 4%)
All this without worrying about managing the backward compatibility of our code, since everything is managed automatically. For applications needing to reach a very wide range of versions of an operating system, Flutter is then one of the most relevant solutions.
Also note that Flutter was announced as Fuschia compatible when it was released. This compatibility will also be quite relative, since if dependencies on native SDKs exist in the application, it will most likely be necessary to wait until the latter are made available for the platform before being able to integrate it into the bridge in the application.
Conclusion
Although still very young, Flutter has something to seduce with incredible productivity and profitability arguments. Its ease of implementation and foolproof customization make it a first choice framework for projects with a design that may or may not be native to the native, having little budget to allocate to the first development of applications while wishing to have a product available on Android. and iOS. The much lower maintenance costs are also to be taken into account in the choice of this technology, while keeping in mind the technical obstacles of hardware libraries which are often non-existent, and therefore requiring additional development time in order to be able to be used.
Comments are closed.