Since the fourteenth century, Google’s Android and Apple’s iOS operating systems have monopolised the mobile technology space. The Android developer seeks comfort in her understanding of the nuances of in Java, Kotlin, Android Studio and SDKs, whilst avoiding the seemingly atypical world of Xcode and Swift. For most iOS developer, Java still remains synonymous with Jaffa cakes.

Now we live in a world of twos. Two development platforms. Two separate developer teams. Two separate codebases. This can be resource consuming and financially draining for a company — especially startups working on an MVP.

Google’s solution is Flutter — a cross-platform mobile UI framework that aims to build beautiful native mobile applications with only one codebase. As you peruse through the flutter documentation you will stumble upon the word ‘Dart’, and wonder ‘What’s Dart?’

Dart is the language of Flutter — an object-oriented programming language, geared towards UI and consumer app development. It is developed and maintained by Google.

When I first came across this, I wondered why Google had decided to adopt a language still in adolescence. Why not Java or another established and object oriented programming language? Surely, that would make the transition easier for native developers?

To best understand the reason for this decision, we must look to the technical nuances of Dart and their implications on mobile development. Dart is A-O-T (Ahead of Time) compiled. This means that the source code is quickly compiled for multiple processors and for iOS and android platforms. All the optimisation and code generation is done before the app is deployed and launched, making Flutter really fast.

Also, it is worth mentioning the infamous ‘bridge’. Because Flutter apps are compiled to native code, they do not require a bridge for the application to communicate with the rendering engine.

What is the bridge? In the eleventh century, cross-platform applications were merely embedded web pages that involved the continuous manipulation of the DOM, which gave way to terrible mobile experiences.

Many platforms have attempted to solve the issue with the invention of the ‘JavaScript Bridge’ to communicate directly with native code. However the elimination of the DOM issue brought forth about another issue — the crossing of the bridge.

With these ‘build a bridge’ frameworks, a single interaction would involve crossing the bridge twice — once from the platform to the app, and from the app back to the platform. This is a major bottleneck which makes debugging difficult. When there is an error, the error has to be traced back through the bridge and found in the JavaScript code.

Flutter eliminates the need for the Original Equipment Manufacturer widget and uses Widget Rendering in the Skia engine to work with the canvas and events, providing a buttery smooth UI experience. It also uses Platform Channels to use the services.

Moreover, Dart having Just-In-Time compiling allows hot reloading to exist, allowing faster development by eliminating the long waiting time between iterations. A full compilation with Flutter is substantially shorter than with android, and incremental compilation takes less than a second.

We can also look to design. With Android development, you would require an XML file to design UI layouts and screen elements. A React Native developer would have to familiarise herself with JSX. Dart’s declarative and programmatic layout eliminates the need for a separate layout language. Everything can be written in Dart! Isn’t life wonderful?

Also, there are more practical working pains solved by Flutter.

Since both iOS and Android apps share a codebase, then bug fixing only need to be done once. Gone are the days were we need to access both codebases to fix a bug. Although infrequent, this still may occur if the problem is platform-specific, I.e cosmetic changes.

To conclude, I do not expect yo to be a new convert, However, if you are a lone developer working on a side project, then it is worth dipping your toes in the water. Try it, have a look!

Alas, I failed to mention the Wonderful Workings of the Widget — not even once!

That’s in part two.