Flutter: Will Google’s framework revolutionize cross-platform development?

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.

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.