The feature of flutter ,advantages and disadvantages comparing with other programing languages ,the future view
I summarized what I think about the flutter based on my experience developing seven apps with flutter and the flutter developer’s opinions that I fount in the internet.
Cross plat form
It is possible to build on but Android and iOS only web ,Linux ,macOS and Windows.
Building ui with widgets
The declarative UI of the flutter is builded with ui components called widget.
The dart is the static typing languages and the dynamic typing languages. It is language system is similar to JavaScrip.
hot reload/hot restart
I usually use it whenever implement.
IDE(android studio) has a lot of functions.
Classes and widgets is built rapidly using short cut keys.
The iOS build is slower than android.
The build is not fast. It takes a few minutes.
Reduction of development man-hours
It can supports android and iOS with a single source code.
Development efficiency is high
The UI can be expressed with widgets except for illustrations. There are a lot of packages to implement various functions, so you can easily incorporate functions. You can see the code of the public packages, and you can also fork and customize them, which is quite useful.
Easy to unify implementation
There are a lot of packages available, and once you decide on a package, you can minimize the differences in source code between engineers. Even the architecture of the application is determined by the package used. For example, Riverpod and stacked for state management.
I don’t have any statistical data, and I apologize for being subjective, but I think that apps made with flutter crash less than apps made with swift or kotlin.
Design and implementation can be created simultaneously.
You can use flutterFlow, Adobe XD, figma, Sketch, and other design tools to output fluttre source code. In other words, what you design becomes the source code that can be made to behave immediately as an application. However, this source code is not usable as-is and needs to be modified. This is because the UI is implemented, but the business logic does not exist. You need to implement the business logic yourself.
Slow response to Native updates.
If there are special hardware controls or support for new OS features, we will wait for third parties to respond.
Difficulty in embedding third party SDKs
At the moment, there are no third-party SDKs for flutter, and there are often SDKs for Android and iOS, respectively. In this case, the SDK for Android needs to be implemented in kotlin (or JAVA), and the SDK for iOS needs to be implemented in swift (or objective-c). Engineers who only have experience with flutter will have a hard time dealing with it. There is a possibility that the functions that can be implemented will differ depending on the platform, such as functions that work on iOS but not on android. Of course, a lot depends on the competence of the engineer, and with time, most things can be solved. However, this is not a problem if android engineers and iOS engineers handle it respectively, which can happen because flutter engineers handled it. This is an issue that not only the engineers but also the service providers need to be aware of. It will be necessary to discuss whether to differentiate the functions provided by each platform or to give up the functions in the first place.
Native dependent features may not be available
There is a possibility that features that can only be implemented in Native are not available in flutter. So far I haven’t encountered this problem, and if there is such a feature, it will be resolved in the future.
Source code hierarchies tend to be deep
In the process of implementing a UI using widgets, it is easy to have multiple layers of widget nesting. I try to avoid this by dividing widgets into different classes.
Overconfidence in cross-platform
The most important feature is that you can create iOS and android apps with a single code in a cross-platform manner, but don’t overestimate it. It is not enough to have knowledge of flutter to develop. For iOS, knowledge of Xcode and cocoapod is required, and for android, knowledge of build.gradle is required. This is for when you want to build for release, or when you want to use native features. Also, we tend to neglect testing the behavior on android because we somehow think that if it works correctly on iOS, it will not cause any problems on android. The opposite is also true. This is unlikely to happen if separate engineers are in charge of the implementation. Also, the web is pretty much an unknown quantity. Even if the mobile app works correctly, you should assume that it will not work on the web. There are some packages that do not support web, and importing a package for web may not allow you to build on mobile. It tends to create a significant number of ‘if’ statements for the web, resulting in code with poor visibility. My conclusion now is that flutter web is not commercially viable.
As of October 14, 2021, I feel that the cross-platform advantages of flutter and the fact that its quality is comparable to apps made with Swift and kotlin have been widely recognized. Even if it is not adopted, I think it is definitely on the table for consideration at all sites. I think web front-end engineers, iOS engineers, android engineers, and designers will find it easy to enter the market, and the number of engineers who can use flutter will increase in the future. If demand and supply increase, the future of flutter will be very bright. As a flutter engineer myself, I hope flutter will become popular.