[Why Flutter/React Native should not be part of your Business Logic] — The Duty of the Developer As A Professional #3
In my opinion, cross-platform development is a solution for companies to solve “money” and “time” issues only in the short-term, but not a solution for codebase quality.
As Professional Developers, we use libraries on projects only if the need is clearly remarkable. However, when we use a library, it is our responsibility and mission to separate it from critical parts of our code, which is the Business Logic.
If you refer to the S.O.L.I.D principles, especially the D (“Dependency Inversion Principle”) that states that a class or a module should not directly know about the implementation of another class Instead, it should depend on the abstraction in order to invert the flow of control on the source code dependency part. Clearly each class must know only interfaces.
In Clean Architecture, for example, which respects those principles, the goal is to separate the concerns and roles that can be categorized into :
- UI (User Interface)
- Formatter (the format, the legal part, the content)
- Business Logic (the Business rules)
- Data (can be in-memory, network like APIs or Online Database or local persistent store/database)
So, it is clear that we do not want a framework or a SDK to be a part of our critical Business Logic, replacing it by another one is not easy, we can not do that without refactoring all the class or the module.
The impact can be quite painful.
…but what about the UI (User Interface) part?
In a software, we always have code whose rate of changes is very high and other parts whose rate of change is much lower. The UI (User Interface), for example, changes quite often (from one version to another one, or even during the development of a version). The Business Logic, on the contrary, does not change that frequently. In fact the changes on Business rules stay relatively small.
Libraries/frameworks (utilization), as UI, has the same, high rate of change. Changes made here are all about optimization.
For example, for networking calls, we can either implement this layer by ourselves or depend on a well-known library. If tomorrow a new better one shows up, we only need to replace the implementation of our layer without impacting the whole module or project.
In our case, Flutter is a framework for a mobile app (iOS or Android), it is only a dependency, our duty is to use it on layers that change rapidly (UI or Data then).
Flutter is very useful for the UI part, in order to have the same UI written once (and tested once too) for both iOS and Android.
If we use this framework only on the UI part and something happens to Flutter in the future (yes, in our job, changes are very frequent), we would have already secured our Business Logic, we only need to rebuild and renew the UI part to respond to new client’s needs.
We Developers may have the bad habit of overacting on code duplication and code centralization, which may push us to put the Business Logic in the Flutter part as well.
In software, we always depend on something: the language that we use, the environment that we use and the platform that we use.
For iOS Native Mobile Developers, we depend on Apple environment (we have to use Mac Os), we have to build our apps with Apple xcodebuild tools and of course we have to use Objective-C and/or Swift (Apple’s native programming languages). If Apple, in some years, introduces a new native language (like Swift in June 2014), upgrades the iOS version or even upgrades Swift version, the migration time is stressless and can be smooth. For example, Swift is now the official language for iOS development, but code written in Objective-C is still usable, there are still plenty of working projects having both Objective-C and Swift code.
If we have written our Business Logic layer in Objective-C, the risk stays minimal and the migration of our Business Logic to Swift can be made without any problem.
What can happen to our Business logic if we use Dart language?
As we can see, the whole framework layer is written using Dart language.
Dart from Native iOS Apps point of view, is not a Native language but Flutter’s language (in other words, a framework’s language).
Using Dart for centralizing Business Logic code can be dangerous and unlike passing from Objective-C to Swift, passing from Dart to Swift (if tomorrow a new framework more efficient than Flutter comes) can be stressful, time-consuming and hence more costly for the company because we will never respond to that change without breaking all the codebase.
The Business Logic in that case is extremely linked with and depends directly on Flutter, and may be worse: on Flutter’s limitations.
Also, if for example, Flutter API does not allow to implement something that your customer needs, then you are somehow blocked and need to implement your own changes on a separate branch from Flutter repository…if you have not objections to make for example pull requests on the flutter repository you don’t have to force the developers that came after you to make those pull requests too.
Ionic and Cordova are also solutions for multi-platform development, were largely used and praised by a lot of developers. These two were recommended by companies to their clients, in order to save them money and time (…and developers). What happened later? Apple recently refused Ionic and Cordova apps which run on their deprecated UIWebView.
The client/company who were suggested to use multi-platform solutions to save time and money, will loose a lot of money, business and their mobile application’s users for every changes that these multi-platform services can not offer and may have to rebuild a great part or the whole of their mobile apps, using another solution (native code, or yet another multi-platform tool).
Another example for Mac Apps using Electron JS being rejected
Developers are reporting that apps made using Electron (which is a framework that allows companies to ship web apps in a native app wrapper) are now being rejected by the automated Mac App Store review process.
The apps in question are getting flagged because of their usage of private API calls. These API calls are not in the app itself, but part of the underlying Electron framework.
Conclusion
Never let our mobile application Business rules to framework’s and libraries’s limitations.
At the T moment, it can be quick to create our app for iOS and Android, but the changes could be catastrophic through time.
We are not a Professional Developers if we do not follow our proper programming rules.
As far as I am concerned, using cross-platform/multi-platform solutions on the UI part can be a bit more logical than on the Business part.
Where to go from here?
If you have some more minutes to invest on this series, you can see our other posts in here:
Co-writting with Mohammed HIMOUD and Linh NGUYEN.
We hope that you learned something today with this post ! Give us claps if you liked it :)
