Flutter to the Future: The Inevitability of Cross-Platform Frameworks
So, you want to build a tech start-up. You have your product idea, your seed capital, and your founding team. Now you just have to hire three engineering teams and build three versions of your product. Surprised?
Let us count them down. A website, obviously, that’s one. An iOS app that works on iPhones, that’s two. And an Android app that works on all the other smartphones, that’s three. Each one requires knowledge of different technology stacks and programming languages, so you need three engineering teams, or at the very least three engineering ninjas, each with total mastery over each of those respective areas.
Your seemingly straightforward path to minimally viable product has just gotten three times thornier, with impacts to resources, costs, and timelines. And that’s before a single line of code has been written.
It Used to Be Easy
Mark Zuckerberg sitting in his Harvard dorm room did not have to worry about hacking together three separate versions of Facebook. Larry Page and Sergey Brin, grabbing coffee in Palo Alto, did not have to worry about ranking anything other than websites. And Jeff Bezos working out of his garage did not have to pay for three separate Amazon online bookstores.
The rise of smartphones and mobile app stores has brought a new reality to the internet. Companies across every industry have recognized that customers demand an omnichannel gateway. We all want to move from laptop to tablet to smartphone and back again with no degradation in user experience.
What has been a win for consumers has also created a barrier to entry for start-ups. It used to be that a single engineer could build a new port of call for the entire world because the entire world came visiting on the same type of boat — the browser. No longer. Now some come by browser, some by mobile browser, and many on smartphones, expecting a native app experience.
One Size Fits (Not) All
In the span of a decade, mobile strategy has gone from afterthought to prerequisite. So much so that a growing number of successful start-ups have bypassed the traditional web application altogether and built strictly for the smartphone. This can work if your app idea lends itself to the medium, as it often does in the worlds of gaming, social networking, and digital entertainment. However, customers for a vast majority of businesses still expect equal play on both web and mobile.
That means the typical modern-day start-up must often raise capital to pay not only for the designers and full-stack and devops engineers, but also for iOS and Android developers. Beyond compensation, there is also the question of management. Designing and engineering three stand-alone applications just to provide a single offering to the market means three times the product and project management lift along with coordination among all three efforts.
The brick and mortars equivalent of this conundrum is the form that must be filled out in triplicate. Remember those? Carbon copies — the real sort, not the email kind — solved that inefficiency some two hundred years ago. So, where is the carbon copy solution for web, iOS and Android?
Cross Platform We Go
The first iPhone was released in 2007 and the first Android phone followed in 2008. In a testament to the pace of innovation, the first cross platform frameworks for both iOS and Android were released as early as 2009. The best known of these was eventually (and aptly) titled “PhoneGap”. The commercial version of PhoneGap was acquired by Adobe while an open-source version was made available via the Apache foundation under the title “Cordova”.
By the mid-2010s, several additional frameworks emerged, including Xamarin, NativeScript, Kivy, and Ionic, with the latter built atop the aforementioned Apache Cordova framework. The challenge with these frameworks was that they offered less granular control than writing native code and remained a couple steps behind the latest SDK improvements from Apple and Google, respectively. However, for those organizations that were able to leverage these frameworks, they offered a 2x savings in development cost and time.
Before long, the world’s technology giants recognized that there was a lot of money to be made in providing the means to do something twice as fast, not to mention centralizing their own cross-platform development. In quick succession, Microsoft acquired Xamarin, Facebook developed React Native, and Google developed Flutter.
State of Play
Modern cross-platform frameworks have come a long way since the first version of PhoneGap. Today, Flutter and React Native sit atop a quintuplet of high-powered and widely used cross-platform mobile frameworks that also include Xamarin, Ionic, and Cordova.
For new development, Flutter is the heavy favorite in this five-faced selection. The reason is simple — it supports a single codebase across all platforms. The other frameworks also support a single codebase but with exceptions, particularly for UI rendering.
In addition to offering the first purely unified codebase, Flutter has been designed to expedite development tasks and to compile directly into machine code. Bypassing intermediate code, which is relied on by other frameworks, enables Flutter to deliver native level performance even for complex graphics and computations.
Flutter to the Future
Whether you are a founder determining a development direction, an IT executive selecting a technology stack, or an engineer choosing your next area to upskill, chances are that the right answer is Flutter. It is robust yet bleeding edge. Cross-platform development is the future and Flutter is the clear winner in this space.
Each of the other frameworks is based on older approaches and is held back by legacy building blocks in their foundations. Designed atop the lessons learned from the shortfalls of earlier frameworks, Flutter is the first to present what founders and engineers alike thirst for — a truly cross-platform foundation that is the closest modern equivalent to the Write Once Run Anywhere (WORA) slogan first popularized with Java in the 1990s.
There are challenges, of course. Flutter is still new and expertise is limited. However, winning in technology is about making bold bets on near-term evolution. Two or three years ago, Flutter made sense on paper, but the ecosystem was still limited. On the eve of 2021, the framework is ready to jump off the page and into your infrastructure.
Regardless of whether you make the bet on Flutter, there is no question that cross-platform frameworks are slowly but surely supplanting native approaches. If your source code only runs on one platform then you are limiting your reach and disappointing a lot of customers. And if you are writing three versions of your source code then you are overstretching your resources and overtaxing your investors.
It is important to remember that evolution from native to cross-platform has happened before. Early assembly languages that were tuned to native hardware architectures were inevitably replaced by higher level languages like C and Java that worked across computer types and operating systems.
Technologies change but patterns remain the same. There is a reason car controls, restaurant menus, and computer keyboards all fit the same mold even though they come in different packages. We are wired for comfort and efficiency, and that means learn once or build once, and then re-use as often as possible.