OutSystems vs. Flutter

Flutter as alternative for OutSystems Mobile development

In this world of ever-evolving technology, it seems that every year or so, something new comes along that will generate mobile applications for the two major operating systems: IOS and Android. They all promise the holy grail of a single code base compiled to different operating systems. The latest of these is made by Google and is called Flutter. You only have to look at Flutter’s raise in popularity on StackOverflow to know that, for some at least, this is the next big thing.

Of course, OutSystems can already make mobile applications, so why would you even consider using something else? There are some compelling reasons for this. In the interest of keeping abreast with new technologies and to solve the issues of OutSystems mobile, I have played a bit with Flutter and hope to answer that question.

Why Flutter, and not any of the other currently hot platforms, like React Native, Ionic, Xamarin or Cordova? The main reason is that, of all of these, Flutter’s approach brings us closest to native performance. There is no in-between layer once you are on the device – Flutter draws directly to the screen.

Learning Flutter turned out to be a much easier task than anticipated. I did a bootcamp course on Udemy and was up and coding. While I am still very much a starter, I have seen enough to be able to say that, in my opinion, it will be able to do what OutSystems mobile does and more.

My main aim was to try and answer the following two questions:

• Could I develop our latest mobile offering for SAP Plant Maintenance with Flutter? Loosely, this means do I think I can produce a similar application with the same (or better) functionality and performance.
• Would it be sensible to do this? Given the risks that goes with using a new platform, would I advise a client that Flutter is the better option? What about the functionality and services that OutSystems provides for me, that I will lose? Things like version and source control, integrated back-end development, common datastore definitions, to name a few.

So, what are these compelling reasons to switch to Flutter, away from OutSystems?

OutSystems abstractions

• OutSystems has done an excellent job to provide a framework where one can create a mobile app quickly – within that framework. If something goes wrong, then you have no idea of what code is generated and running your app. Debugging becomes a guessing, and time-consuming activity.
• You are bound by their technology choices – in this case Cordova. This means, doing something differently (outside their framework), can be very difficult. If a plugin you want to use, clashes with an existing one, it may very well be that it is fixed, but requires a later version of Cordova or associated libraries than OutSystems currently uses.
• For OutSystems, changing or upgrading technology is not a simple process. They must make sure that they stay backwardly compatible with all their clients existing apps. With a Flutter app, you only have your application to worry about.
• The Mobile Application Build System (MABS) that OutSystems provides works well – mostly. But it all happens on a server far away and the error messages can be cryptic and hard to solve.
• This leads to technology lock in and you lose the ability to be cutting edge. Users could experience your apps as “old” while Flutter apps will have a fresher look and feel. Some functionalities eventually may even to be impossible to implement.
• If you develop in Flutter, then you have full control over the code, as nothing is generated – you have to write it all yourself. Flutter is open source, so, if need be, you can drill into the lowest levels to understand unexpected behaviors.

Development speed

One thing I noticed, is the speed with which I can make small changes and see & test the results. With OutSystems the turnaround time can be anything from a minute or so, to quite a few minutes, especially, if you have to publish the app via MABS. One of my favorite features of Flutter is called hot reload / restart. This allows you to see the effects of your changes almost instantly. This is somewhat mitigated by all the additional (boilerplate) code you now have to write, but once that is done, you do not have to revisit it and the bigger the project, the more valuable this speed benefit becomes.

Debugging is much more productive in Flutter. With OutSystems you debug in the context of an emulator. I had a lot of trouble getting the device-based debugging (with a USB cable) to work reliably in OutSystems, I do not even try that anymore. This means you do not have access to many of the native capabilities of the device like cameras etc. With Flutter you also have an emulator, but it is a lot more powerful and offers more native capabilities. You can also easily debug directly on a physical device.

Cost

Flutter is open source. It has no licensing cost. It also has no vendor lock in. Sure, Google drives most of the development in Flutter and that is why it is already so powerful. If Google decides to walk away from Flutter you can carry on using it. In fact, what typically happens in these situations, is that some of the developers that use and like the technology carries on with the project, because it is open source.

There are good developer tools for Flutter that are also open source and free.

The saving in OutSystems licensing cost for a medium sized mobile application can be 60-90 AO’s.

Consequences

If one decides to go the Flutter route there are some technologies that would have to be re-created and other issues to keep in mind - these are currently solved by OutSystems for you:

• Continuous integration and delivery (CI/CD). The Outsystems MABS server takes care of this and you get a simple QR code to scan and the app is ready for testing (not developer, debug testing) on the actual device. There are currently a few different options for this with Flutter (AppCenter from Microsoft, CodeMagic, Travis, FastLane recommended by the flutter team and Github - to name a few). One would have to do some R&D to see which one works best for a specific project. Currently I am leaning towards GitHub, as it would tightly integrate with source control and it includes a decent issue tracker as well as scrum/Kanban functionality.
• IOS development. While a CI/CD tool could create the IOS apps, it would probably be necessary to have some IOS devices to finally test on. This could be an additional initial investment.
• Source and version control. Flutter code is written in text files and you need a way to organize this amongst distributed team members. Here the best solution is probably GitHub which has a cost of about $100 per annum per user. Using a repository like GitHub, would add significant value because you can have proper versioning and branching which is currently not possible in OutSystems where there is only a “head” version.
• Coding standards and architecture. With OutSystems you are forced to adhere to their architecture and coding standards. This gives a safe and familiar feel and environment to develop an app with. In Flutter everything is hand-coded, and it is very easy for different developers to use slightly different configurations of a widget. This could lead to inconsistencies in the way an app looks, feels and behaves.
• Standardized components. With OutSystems one uses their components. With Flutter you must build your own complex widget chains.
• Data definition / synchronizing. With OutSystems you have a simple and fast methodology to define the data structures for the mobile device and control the synchronization. This sub-system would have to be designed and coded for Flutter and the back end. Using OutSystems for the back end is a very viable option. Flutter can handle REST calls and has good integrations with FireBase and the rest of Google’s back-end infrastructure.
• Flutter is not low code. Coding in Flutter is a lot more technical and requires proper developer skills and knowledge. With OutSystems low-code, there is quite a bit that could be done by citizen developers even though, in the end, you probably still need developers.

Conclusion

On the first question of whether I think it would be possible to set up a Flutter team to build the mobile applications that we did for Plant Maintenance – the answer is yes. There would be a slowdown in initial productivity as we set up the team and work modalities, but I am confident that I would have been able to deliver that application. With the added benefit that even some of the product owner’s wilder ideas for the future can be accommodated with a lot more confidence.

On the second question of whether it is sensible to do this or if it is too risky – that is much more difficult to answer. One of the problems with mobile development, is user expectation. There are so many cool apps out there and many users expect similar functionality your app. In many cases here it will be difficult to deliver it using OutSystems but a lot easier using Flutter. In the end it comes down to appetite for risk/reward. The reduction in cost could go a long way to mitigate the risk.

If your app is aimed at the consumer market and not internal, then you are much more likely to run into the abstraction limitations of OutSystems. In this case it is, in my opinion, Flutter would be the better and lower risk option.

Want to know more on OutSystems or Flutter? Contact us.