This is part one of a two part series about Flutter. If you’re looking for the developer tutorial and a first app to try, feel free to skip ahead to Part Two.
After working with Flutter on multiple projects, we are solidly convinced that it is the best cross-platform mobile app development framework. We picked up Flutter pretty soon after Google first started talking about it in 2016 and have loved it ever since. If it’s new on your radar, don’t feel bad. Google tends to label things as alpha and beta for a really long time. (Gmail was in “beta” for three years.) Flutter got a windfall of attention in spring 2018 when Google moved it officially to beta.
Flutter is an open-source native cross-platform mobile app development platform using the Dart programming language that Google has been developing for some time. It started out as an experiment to see what they could do if they started from scratch and has become a fast-to-develop, high-performing, and beautiful platform that Google even uses for a lot of their own apps (check out some apps written with Flutter here).
One of the most common questions that gets asked when we bring up Flutter is “Why Flutter and not Xamarin or React Native?” It’s a reasonable question, as both Xamarin and React Native are more widely known than Flutter, and Google’s liberal use of “alpha” and “beta” sometimes scares people off. Read on for the reasoning behind our recommendations.
Xamarin vs Flutter
Broadly speaking, if you are committed to .NET and don’t mind deprecations resulting from Apple or Google breaking your apps for months at a time, you should use Xamarin. Otherwise, we would not suggest Xamarin.
What Xamarin doesn’t tell you
One thing that a lot of people don’t realize about Xamarin is that unless you want to use their Xamarin.Forms library, you are going to have to create all of the Android and iOS interfaces separately. That’s a LOT of duplicate work. Which may lead you to wonder about Xamarin.Forms. Last time we used it, it was an almost unusable mess that created even more work for us. The kicker was with all that work, we got a product that wasn’t even close to our strict standards. We spent nearly as much time building cross-platform as we would have spent building natively, and ended up with apps of massively degraded quality.
Flutter, on the other hand, created an interface engine which allows you to write your interface once and run anywhere, but still makes it “feel native” on both platforms. It also allows you to customize based on the platform the app is on, and if you really need one view that is 100 percent platform specific, it is built on top of the normal native platforms and integrates easily.
Xamarin’s coupling problem
The other big reason we stopped using or offering Xamarin apps (besides the fact that it wasn’t saving any time or cost) was because at the time it was a black-box proprietary solution. This means that when we found bugs in their code, be it an existing bug or one introduced by Apple or Google changing something in their platforms, we had no way to fix it. The app was just broken publicly on the app stores until Xamarin could release a fix and we could rebuild/resubmit it.
Obviously, that is a huge deal for any app owner, and it only had to happen once for us to deem Xamarin not production ready and go back to writing for the two platforms separately again. In late 2016, Microsoft open-sourced the platform onto github and they have done their best to improve and move the platform forward. However, since it is still tightly coupled to both platforms, any changes made by Apple or Google can still cripple it on that platform. Flutter is also open-source with a wonderful community that is always happy to help, but, since Google wrote the interface engine from scratch, it seems highly unlikely any OS changes Google (or Apple) would make would ever break a Flutter app without breaking everything else on the stores.
React Native vs Flutter
Comparing Flutter to React Native (RN) is a little more complicated, and they both share some positive qualities.
Great structure
If you are familiar with React for Web development or using the component pattern of programming you will have no problem picking up either platform. RN and Flutter have you create your entire interface in pure code. Both interfaces are constructed by putting self-contained widgets together. This method makes it much easier to make an interface that is super responsive to any device screen, because instead of moving pixels around in a layout editor, you are defining the rules that the engine will use to lay the components out on the screen. One big difference between these two is that RN maps these components directly to native UI components (so UIKit views in iOS and Android widgets there). In Flutter you are directly using material components which their engine has implemented to Materia guidelines. They have also recreated iOS’s older-themed components if you would prefer that.
One downside to RN’s approach is that if Apple or Google break/change a component it will break/change the component for RN as well, but Flutter, since it has its own complete rendering system, would be completely unaffected. Luckily RN is also open-source, so at least you could submit a fix yourself. Keep in mind some RN components are iOS or Android specific, meaning that if you are going to have your code work the same on both platforms, you will have to duplicate those parts of the code. Flutter will handle all platform-specific visual changes or behaviors automatically without you having to add any additional code.
Highly extensible
Both React Native and Flutter allow for integration of external code. RN calls these APIs and Extensions, while Flutter calls them all plugins and packages. Both are highly extensible in this way. Take special note of the Firebase and Google Cloud Services plugins for Flutter, because they are amazing. They make creating a real-time application dramatically easier than in the past.
Very different under the hood
Flutter uses a language called Dart that is very similar to Javascript, while React Native uses Javascript. This starts to get into the biggest difference between the two. To have native applications in a language not supported by Apple or Google you have two options:
- Interrupt the code at run-time
- Compile it down to a native arm64 binary and load that
The engineers over at Facebook have done an amazing job of taking the Webkit Javascript run-time and creating what they call “the Bridge” to interrupt the Javascript they have installed (or are streaming from a server). This makes it so that they have one of the fastest interrupters on any platform that does a fantastic job at what it does. So, credit where credit is due!
Flutter, however, will use a Dart interrupter as its development run-time, which gives it a super fast development turn around with its hot-reload system (save, and about as soon as you can switch to the simulator/emulator your change is already there on the screen). When you are ready to compile for production, all of your code and Flutter’s code is compiled down to a native arm64 binary and that is run on the device. That, along with Flutter’s blazing fast engine, which is more akin to a highly optimized and specialized 2D game engine, means that our Flutter mobile apps have actually not only been more performant than their RN counterpart, but even their “native” platform counterparts.
The downside of Flutter
So while we love Flutter, its community, and its tooling, there are a couple of “gotchas” that we have to address in order to stay honest. Most of the issues we’ve had in the past have been resolved over the past 18 months, all prior to the platform reaching beta.
The following remain:
- Support for integrating native widgets isn’t quite there yet, but they are working on it, specifically focusing on mapview and webview. This seems to be a important goal for them before releasing 1.0 officially, and they have made great strides.
- Realm, our favorite on device database solution, doesn’t have Flutter support yet.
Why do we use Flutter?
Because it’s fast. It’s fast to develop, it’s fast to tweak, play, and prototype with, and it’s fast on the device. In less time than it used to take us to write one app for one platform, we can now write apps for both platforms that look and feel even better than if we had written them independently.
Ready to dive deeper into the technical side of Flutter? Head on to Part Two.
Even though we love Flutter more than any other cross-platform option, we still approach every project with an open mind. If you are interested in finding out if Flutter is right for your app, let’s chat.