Real World Flutter Desktop Experience With Kryanite

While dabbling with a technology is a hobby and can be fun, it really isn’t until I try to build something with it that I can truly have an appreciation for whether it really works or not. I’m now at that point of exploration with Dart and Flutter for cross platform desktop development. I opaquely mentioned this topic in this post. Yesterday I released a beta of my first application written in Flutter Desktop, called Kryanite. I’ve gotten to a comparable stage of work with other cross platform desktop tools over the past couple of years. Obviously none of which were quite totally satisfactory since I kept looking around. That search may be over now. At this point I can say that Flutter Desktop is by far my favorite cross platform development platform to date and I’m planning on doubling down on using it, and more generally Dart, in my development efforts.

Why is the Flutter/Dart stack my favorite so far? The primary reason is that it mostly “just works” for writing and building cross platform applications. I had a comparable ease of use experience with Avalonia on the .NET Core stack. The one deal breaker for me on that front was a limitation of .NET Core which is its inability to make properly self contained executables. Up until the recently released .NET 6, and maybe even in this most recent version, their “self contained executable” was really a self-inflating ZIP file which unloaded a whole runtime and the application. With Dart and Flutter their self-containment is a built in feature of the compilation process so “shipping” executables doesn’t require bringing along a huge runtime or requiring a user to install one. These executables aren’t atrociously large either. A simple Dart command line tool will clock in at about 6 MB, about isn’t that much larger than a Rust tool of similar complexity. While the Kryanite application folders are 20-40 MB unzipped, they compress down to 9-13MB for their shipping forms. That’s quite a bit larger than the applications sizes I was excited about with V but still more than acceptable with modern computers and networks.

Along with the build process just working, so too does the actual development process. I am a Linux first user and developer. I therefore am only interested in working with tools that have first class support for Linux. Again, that’s what drew me to Avalonia with .NET Core and Kotlin Multiplatform previously. I started off using the Android Studio, since that’s the usual route Flutter takes you through as their primary target is mobile developers. Yet I quickly shifted away from that to using IntelliJ proper. The ease of being able to setup and work with the development stack was identical on Linux, Mac, and Windows. Besides the slightly different presentations due to the different UIs the experience was identical everywhere.

The dev stack “just working” is important but it’s even more important that the application I am writing “just working” as well. I was initially concerned about potentially having to write platform specific code for various not-so-edge cases. That was unfortunately something I was encountering with my KMM experimentation. Flutter engineers and third party library developers have definitely made that not necessary. With the exception of a slight shortcoming on getting temp directories on Mac I ultimately didn’t have to write any platform specific code anywhere. Even in that one case it is using platform awareness within one function not requiring working with files scattered everywhere.

Flutter Desktop is itself in beta. It definitely has a little more polishing that they will do and it needs. By far the biggest thing missing from the Flutter dev stack entirely is a graphical editor, but just like with Avalonia I learned to work past that. Their other dev tooling really helps fill in the gap, especially hot reload, tree walkers etc. Beyond that some of it some UX that worked for mobile, their primary platform, not working for desktop and they are adjusting that. Lastly some of this falls down to documentation deficiencies which I was able to work through via typical DDG searching and Stack Overflow. I’ve captured all of that and plan on hopefully writing many blog posts to document what I’ve learned in this blog.

In the meantime though I’m going forward with continuing my Dart/Flutter development. I have some mobile app needs that I’m going to try to use Flutter for as well. The next big step for me is finishing up the Kryanite app and properly publishing it in the various app stores. My first targets will be the Apple, Windows, and Ubuntu snap store. However I’d be interested in trying to get into other Linux app stores like for ElementaryOS. If things continue going well I can see Dart becoming my primary development language and Flutter my primary mobile and desktop application stack. I still have more of an affinity for Kotlin the language than Dart, but the downsides of the platform for what I need to do makes that not a good fit. That’s true at least for desktop/mobile/CLI development.