“Flutter and Fuchsia. In 2019 you will see these two words everywhere, and now is your chance to get ahead of the curve.” - Todd Fabacher, writing for Forbes

Forbes saw it coming back in July of 2018. If you didn’t, then here’s your chance to find out why they did. From lower lead times to increased productivity, the number of platforms you’ll be able to reach to the simplicity of maintenance, Flutter is now leading the way in just about every category.

The most important things to understand are what Flutter is, and is not. Flutter is a UI toolkit, that can also handle the business logic and backend, behind the scenes. However, Flutter is not an operating system. This means it does not have direct access to things like cameras, Bluetooth, GPS and other hardware. If you want to access these things with a Flutter app all you need to do is interface with the OS, but Flutter doesn’t do it directly.

There have been some who complained about the fact that Flutter doesn’t have such capabilities, and my response is always the same.

“Do you also complain about the fact that Android can’t fold your laundry?”

Android isn’t a maid, and Flutter was never designed to be an operating system. That said, Flutter can do far more than enough to change the way you approach app development.

I also have some very interesting news for the nay-sayers who think Google will just abandon Flutter, as it has other great technologies. It’s not going to happen, for reasons I’ll go into after we take a look at a couple of other things first.

One of the greatest advantages of Flutter is that Dart code can be compiled in three different ways. The first is truly native, Ahead Of Time (AOT) compiled machine code. This is not byte code that needs to be interpreted client-side by a Java Virtual Machine (JVM). This is an actual machine code executable that requires no interpretation. The greatest thing about it is you can compile executables not only for Android and iOS, but for Windows, Mac, and Linux, too. This means you can write your code once, and release your finished app to five different platforms.

You will, of course, need to compile once for each individual platform, since each uses a different kind of executable. So unless iOS finds a way to run a Windows exe, I’m afraid that’s just the way it’s going to have to be.

Second, Dart can be Just in Time (JIT) compiled. This is what you use during development, and it’s what we call a “debug build”. The reason we do this differently is that JIT compilation isn’t permanent and inflexible the way AOT is. It’s running whatever code is on your screen. If you change the code in your IDE and tell the compiler to incorporate that change, it does so immediately, in real-time and without the need to run another Gradle build. This is the “Hot Reload” you might hear people talking about.

Third, Dart can be compiled in a way that results in Javascript. This allows Flutter to do something truly amazing. It lets you put the same app you wrote for mobile and desktop into a web browser.

That’s six platforms you can release to while needing only one team to write the code. Think about what that means for your productivity. Think about what it would mean if you only had to worry about maintaining one codebase, instead of six.

Forbes knew this a year and a half ago; they saw it coming like a train barreling down the track. Bottom line, how does this benefit you, your team and your business?

• You only need one team per app. If you currently have more than one team, producing for more than one platform, you can move them all to Flutter and produce more apps without increasing your labor costs.

• Maintenance takes time, and time is money. How many apps are you maintaining now just so you can be on multiple devices?

• Since Flutter does need a little tuning for each platform, that does add a small amount of time to what you would need to maintain one platform… but it’s definitely less labor-intensive than maintaining two or more separate apps.

• Lower lead times comes with using JIT compilation for debug builds, which redefines rapid-prototyping since you can see your changes within seconds instead of minutes. In fact, if you’re only changing the state of the existing app structure then you can see your changes in under one second by using Hot Reload. If you changed the app structure by adding or removing individual components, or even large sections of your app, that takes a little longer… 6-8 seconds under most conditions but I’ve never seen a Hot Restart take more than 11 seconds.

Note: If you change your dependencies, you’ll need to do another build so Gradle can re-run its tasks. Flutter can do a ton to make your life easier, but nothing can get around the need to rebuild Gradle after a dependency change.

In summary: Flutter can make your teams more productive, get the apps out the door faster, make your maintenance both easier and less expensive as well as make the overall development experience more pleasant by allowing your app developers to move at the speed of HTML developers who reload with and + .

But wait, there’s more… Fuchsia.

You might remember in the quote at the beginning of this article that both Flutter and Fuchsia were mentioned. Fuchsia is an open-source operating system currently being spearheaded by Google. It uses a micro-kernel called Zircon, and is designed to be able to run everything from the simplest picture frame up through the most bleeding-edge mobile devices. Why is this important?

For one, Flutter drives the UI for the entire Fuchsia operating system. For another, this means you will be able to use Flutter to write apps for all kinds of IoT devices, from refrigerators to alarm clocks and more.

In fact, I was informed at Google I/O 2019 that Flutter is already driving the UI in the newest addition to the Google Home family, the “Nest Hub Max”.

Think back to the start of this article for a moment. I said that Google won’t be dropping Flutter like they’ve done to many other great technologies, and here’s why. With Fuchsia, this completes a trifecta that Google has wanted for a long time. In fact, it’s kind of a quadfecta… if there even is such a thing.

• Google has long wanted changes to the Linux kernel and they’ve been all but ignored at times by Linus Torvalds. Linus does what he thinks is best for Linux, when he wants, at the pace he wants. But with Zircon, Google now controls their own kernel. It’s a brand-new kernel and that’s something there hasn’t been in a very long time. And they can take it in any direction they want, as fast as they want.

• I would be negligent to not mention the $9 Billion Oracle lawsuit. Without going into detail, Oracle and Google have been suing and appealing back and forth for years over a small detail in Java. Google had originally done a “handshake deal” with Sun Microsystems and, though Sun honored the deal, Oracle did not feel bound by it when they acquired Java. So, they sued Google. The fight has been on ever since, and Google would love nothing more than to divorce Oracle completely… soon they’ll be able to.

• In order to completely divorce themselves from Oracle, Google would need a language they have a lot of control over (Dart), with a UI SDK they have control over (Flutter), running on an operating system they have control over (Fuchsia), and an extra bonus would be to base it all on a kernel they have control over (Zircon).

Google has abandoned great technologies in the past, yes. But none of those technologies helped them solve a $9 Billion problem. Flutter does. I say this jokingly, but I don’t think the lawyers and accountants will let the company cancel Flutter. It’s positioned to be far too important to the company’s bottom line for them to let it go.

I believe Flutter and Fuchsia are the future for application development. Now is the perfect time to get started.