An Analysis of Google Flutter in the Enterprise
Early this month, Google announced Flutter’s first stable release (a.k.a 1.0). I figured it was time to look into it to try and determine if it’s actually a good development tool for enterprise-grade mobile apps.
First off, Flutter’s pitch is no different than any of the other cross-platform development tools that deliver native iOS and Android apps. Build once, deploy everywhere. Share code, fast development, yadda, yadda. Nowadays, I try to avoid getting caught-up in these statements. Experience has taught me it’s better to continuously advocate for a solid mobile strategy, assemble an excellent team, and be prepared for the change, maturity and evolution these technologies tend to experience.
So, let’s get to it. I’ll compare 3 tool categories with Flutter:
- JS-based tools (e.g. React-Native, NativeScript or Titanium)
- Fully-native development setups (e.g. Swift for iOS and Kotlin for Android).
Here’s my experience so far:
What I Like:
The first round of applause goes to the installation process. It’s easy and straightforward. I can’t say if it’s fast, since it depends on Xcode and Android Studio and therefore requires a lot of data to be downloaded, but the instructions, and its ability to run on simulators, emulators and devices is great!
While Agnostic UIs are not something I’d recommend, some apps do very well with it. These use cases are an excellent pair for Flutter. And if you’re developing for Android you’re going to like the Material UI elements built-in to Flutter, and how easy it is to work with them. iOS: no problem. Cupertino (Flutter’s iOS components) seems fairly decent.
While developing, I found the debugger and the hot reload features to be stable, and I didn’t encounter any major issues. The Navigator mechanism for building navigation in the app is also natural and easy to understand (assuming you have some experience with mobile development). Lastly, the formatting tool is a nice touch for keeping code organized in larger organizations or teams.
The stateful and stateless approach (similar to ReactNative’s) provides a good way to build scalable code that can support robust, enterprise apps.
Flavors, a feature that lets you create custom app icons, app name and dynamic configurations based on a CLI flag is already present in Flutter. And although there’s not much documentation out there, it’s an interesting approach for handling multiple environments or even “themes” in your apps. It relies on Android productFlavors and iOS Schema for each platform—which also makes it really easy to “get it.”
Speaking of documentation, overall the docs website for the framework and language is pretty easy to navigate, making it easy to understand what’s happening under the hood. It’s not exhaustive, but it’s a good place to start prior to trying a Google search.
Things I still haven’t tried—but which, from what I’ve read, seem to deserve mention under the “what I like” category, include:
- Deployment Checklists for Google Play Store and Apple AppStore
- Continuous Integration/Continuous Delivery support.
What I don’t like:
Since Flutter draws pixel-perfect elements on-screen that are not part of the platform’s UI framework, it’s worth mentioning that you will be stuck with an old “look and feel” if any of the OSs decide to update any UI elements. I consider this critical for consumer apps, but not the end of the world for internal, employee-facing apps.
During development, I encountered some weird error messages that—while they weren’t impossible to decipher—did take more time than other platforms to understand. The nature of the problem, and what would it take to fix it, were not immediately apparent. This reminded me of the first iterations of the iOS SDK and Xcode. Not horrible, but be prepared to deal with this predictable element of a nascent platform.
This is a big one for managing application code over the long-term. At Propelics, we have built many apps for clients, and our developers must constantly move from one project to the next. Consistent coding standards and code organization makes these transitions easier. From what I’ve seen, while there’s no official way to organize your code, I did identify folder and file patterns across multiple repositories. Either you’ll have to create your own coding standards (odds say it’ll be wrong the first few times you try) or you grab somebody else’s approach and try to adapt it. Neither of these options seems like a particularly good idea.
Enterprise SDK package availability
We work with several vendors that provide client SDKs (usually native or JS-based) for out-of-the-box functionality (e.g. offline support, session management and even some security features). In a new ecosystem, SAP, Microsoft, Progress, Amazon, etc. won’t have official packages supported. Either you must trust a package from the community (proceed at your own peril) or build your own.
Technology evolves quickly. And while unlikely, for all we know, Google hasn’t migrated all their apps and may stop spending time and resources on this project at any point and leave it to the Open Source community to maintain it. For the record, the Google Ads app is built with Flutter, along with these other apps.
Lack of enterprise support
Big companies like to provide clients a number to call for technical software support. While Google doesn’t offer this service, partnerships with companies like Square suggest an enterprise-level relationship is possible. Depending on how you run your shop, this may be a non-starter, so consider this situation carefully.
Small pool of developers
If your organization is looking to POC new technologies, you should give Fluffer a try and get feedback from your team. Prototypes, or user-experience POCs, are good use cases for investment. The 1.0 of this release really means it’s ready to be tested, but as an emerging technology is not something you want to use as your primary development platform. At least not right away.
If you’re integrating SAP SMP into your app and want to use their SDK—or if you have another key vendor who requires enterprise support, who doesn’t have a Flutter-supported SDK (or a ready pool of developers excited to learn the new language), then Flutter is probably not a good fit for you.
I’ll end this analysis with two things you should do if you’re considering using Flutter in your next project:
- Be sure to spend ample time learning the Dart language.
- Using a cross platform development tool doesn’t give you a free pass to skip learning iOS and Android-native platforms. No matter which technology you prefer—Xamarin, ReactNative, NativeScript, Axway Titanium or Flutter—the more native development knowledge you possess, the better your apps are going to be.
Not sure which mobile framework is right for you? Don’t worry, the Propelics team of business and technical consultants are ready to help you get started. Please don’t hesitate to reach out to us with any questions.