On December 4th, Google launched Flutter 1.0, showing how we will build beautiful user experiences in the future.

I was lucky enough to attend Flutter Live in person. If you missed the event, you can catch up on the amazing announcements here:

Today I share my thoughts on why Flutter is already a superior technology for front-end development, and will be even more so in the future.

Just to be clear: The opinions in this article are entirely my own and not endorsed by Google.

More in detail, we’re going to look at:

The last 10 years of iPhone history and the Apple ecosystem

What makes Flutter more productive

A direct Flutter-iOS comparison by example

This is going to be a long article, so here is the short version:

TL;DR

Mobile app developers spend a LOT of their time building UIs.

The development process is much slower on iOS than it is on Flutter.

In particular, the iOS tooling (Xcode) and APIs are sub-optimal for building modern apps.

Flutter is far more productive.

Flutter makes it easier to do things that are really hard on native SDKs.

Flutter will enable full cross-platform development across iOS, Android, desktop, web and beyond with one codebase.

Developers and entire product teams will ship better products, faster.

This will greatly benefit small independent shops, startups and digital agencies.

Apple could build better tools and APIs, but these would remain confined to their ecosystem.

build better tools and APIs, but these remain confined to their ecosystem. Remember: Apple is a hardware company, and has no incentive in building and promoting a cross-platform framework.

Exactly how we got to this point is a fascinating story.

Having been an iOS developer since 2012, I’m familiar with the ins and outs of building products for Apple platforms.

And having experienced first-hand how Flutter is radically different, I want to share my perspective.

Starting from the beginning.

The iPhone

Image Credit: Mark Mathosian

This device changed everything. It really did.

And Apple did a superb job at creating the right experience on this new Internet device.

With the iPhone, every app was just an icon on your home screen. Multitasking wasn’t supported until iOS 4.0.

To make up for that, a child could quickly learn the basic interaction patterns.

The device was sexy, and easy to use. And Apple’s marketing machine helped making the iPhone a resounding success.

Naturally, developers jumped at the opportunity, and started building apps with the available iOS tools and APIs.

UIKit was the framework used for building UIs on iOS, and it was originally designed for the first iPhone.

But then, new screen sizes came, and then the iPad.

Image Credit: Muhammad Cordiaz

And suddenly, new considerations had to be made about how to position content on screen.

And these had to baked into UIKit in the form of new APIs. With springs & struts first, and then auto-layout.

And iOS developers went along with these changes as they were introduced.

It wasn’t the smoothest ride ever.

Alongside working with UIKit and its legacy, iOS developers had to contend with a 34 year old language called Objective-C (so old, in fact, that it didn’t have a logo!). This would use manual reference counting to manage memory, until the introduction of ARC in 2011.

But many of us had a love affair with iOS development.

I remember building and launching my first iOS app. It made it possible to combine touch interaction, camera input, 3D graphics, and UI overlays.

Back then, I was in wonder, and I knew my heart would be on iOS for a long time.

Swift

Fast forward to 2014, Swift was launched.

Many of us jumped with joy and embraced this shiny new language.

Initially it would crash Xcode. A lot:

But it got better.

And Swift was a very significant departure from the closed-source nature that was typical of Apple.

Chris Lattner (the mastermind behind Swift and LLVM), had been working on Swift since 2011, and managed to have it blessed as the future programming language in the Apple ecosystem.

Swift had a huge audience from the start, since it was fully compatible with Objective-C and the existing iOS APIs.

But Swift was meant to grow and expand beyond iOS and the Apple ecosystem.

Using Chris Lattner’s own words:

My goal for Swift has always been and still is total world domination. It’s a modest goal. — Chris Lattner

It was open-sourced in 2016. And it started getting interest on the server-side, but didn’t quite take off in that space.

You see, Swift had been let down. By Apple’s strategy with Xcode.

Developers outside the Apple ecosystem had enjoyed more productive IDEs for years.

And for any given language, they could often choose between multiple IDEs.

But if you wanted to use Swift, you had to use Xcode.

Until October 2018, when Apple announced Language Server Protocol (LSP) support for Swift. This opened up the language for integration with other IDEs, such as Visual Studio Code.