46. Mike Hearn
20:50 Share

Hi, thanks for listening. This is the It's So Widget's Flutter podcast. My name is Hela Korn. Each episode, you get a chance to speak with another amazing member of the Flutter community. This episode, we're extremely lucky to speak with Mike. Welcome. Hi.

Thanks for being on. So to start, do you want to share a bit about your background? Yeah, sure. So my background is perhaps a bit unusual because I'm traditionally more of a backend developer than a UI developer, but I've been programming a long time and I've always been doing GUIs at various times. My first was, I think, ball and turbo vision in MS-DOS actually at the start of the 90s and then graduated to Windows 3.1 and have been doing GUIs and other things on and off ever since.

I worked at Google for some years between 2006, 2014, and I've done other projects since leaving. And these days I run Hydraulic, which is a company based in Switzerland. And we make Conveyor, which is a tool for desktop app developers to make it really, really easy to ship your app to the desktop. Amazing. And how did you first hear about Flutter?

I think I first heard about Flutter quite some years ago, and I remember looking at it, and at this time, of course, it still is primarily a mobile toolkit. And I started taking another look at it again at the end of last year because I talked with someone who told me actually that they said, oh, you guys should really check out Flutter, and there's a ton of excitement around it. It's growing really fast. It's got a really nice community. And this guy, he was actually a venture capitalist, but he had development background.

And, um,

He was just really singing the praises of this, not only the technology, but also just the people he came across who were using it. And he said, you guys should do something with that. It's the place to be. So we took a look and I was pleased to see that it was moving beyond just mobile. And I played around with the desktop version primarily because that's my primary interest these days. And it was just

it was just great. You know, it was like really started really fast and it was sort of easy and the code was clean and I, it sort of appealed to me as someone who's been working with, um, GUI toolkits a long time. Um, you know, I've, I've used a whole lot of different toolkits, um,

The footage just seemed really nice. So I said, okay, well, we should support this, especially because what we're interested in partly is when people have built a mobile version of their service, how can they bring their app to the desktop or the big screen, as we call it sometimes? How can people bring their app to the big screen quickly and easily and cheaply and in a pleasant way?

And the standard way of doing that today is you rewrite everything as a web app.

which, it works okay. It's not really ideal from a developer's perspective and it's not really ideal from the end user's perspective either. It's sort of convenient if you're a very casual user. Like if you're going to use this app for five minutes once a week or once a month or maybe you'll use it once and never again, then of course it's convenient. But if it's a more serious type of app and you're using it regularly, then it's nicer to have a desktop version that is more efficient and starts quickly and integrates with your operating system well.

And so I thought, well, you know, as people bring their mobile apps to the big screen, this would be a great way to do it. But the deployment tools, as is often the case with desktop toolkits, were just not very good in my view. Actually, Flutter doesn't really have deployment toolkits, right? The documentation just points you at the native tools that Microsoft and Apple and the Linux community provide.

And so we went ahead and we added support for Flutter Desktop, and it was actually pretty straightforward. And we launched that back in February. And yeah, now we're trying to just let the Flutter community know that it's there and that this is certainly a much more viable and easy option than it once was.

Very cool. That makes a lot of sense. I think really the key value that I see is that it enables you to ship Flutter apps outside the stores. That's something which I work with Invoice Ninja. We struggle with. We actually currently don't. Currently, the apps are only available in the stores themselves through Conveyor. That makes it a possibility. Is that correct?

Yeah, absolutely. I mean, we may well be adding support for the stores in future. And we started outside because on the desktop, people very often want to ship outside the stores. Because, you know, that way, you don't have to deal with the rules and revenue shares and so on.

So Conveyor handles everything that you need if you're outside of the stores. It integrates online update for you, it builds all the packages, and it can do that from your desktop. In some cases, you don't need to, I mean, with Flutter desktop at the moment, you need to compile on each platform, but the actual packaging process itself can just run on one machine, which is pretty convenient.

It'll do icon conversion. It even generates a download page for you that detects users' CPU and operating system. And it does signing and notarization. It does the whole enchilada, basically. So it makes it very easy to release. And because it does support going outside the store, there's also no approval processes or anything like that. You just need a web server.

That said, you know, some people want to be in the stores for other reasons like distributional because the stores handle billing and tax and things for you. So I think we'll probably add support for upload to the stores in the future. That's great. Yeah. I mean, we want to be in the stores. It just makes things simpler. We also want to use it ideally to leave reviews for the app. I think that helps build visibility. But now,

In our experience, I found on Mac, people are very happy installing from the store. It's on Windows, we would get regular requests. People just don't want to use a Microsoft store, and they want an option to go outside the store. With Android, there's a demand to go outside the store. People like to use FDroid, which is alternatively placed. And on Linux, we use Snap, which Flutter makes very simple. But lately, we've got a lot of requests to support Flatpak. Yes. Yeah, the desktop space is pretty fragmented.

You know, we're looking at adding support for Flatpak. One issue is that, yeah, there's, yet again, you know, the same fragmentation of the Linux space there always has been, right? Ubuntu don't want to support Flatpak. They want everyone to use their Snap store. So Conveyor generates...

like tarballs and debian repositories so again you don't have to deal with that you just publish files and then you know a bunch of users can get self-updating packages without being constrained by snap one of the issues with things like snap or flatpack where it is a enforced mandatory sandboxing which not every app is compatible with um

And then, yeah, on macOS, what I tend to find is actually most of the apps I'm using are outside of the Mac App Store. I don't know if that's just me, but very often people find that...

You know, Apple might reject an update for some reason or whatever. They don't want to be exposed to that business risk. But our goal, our vision really is just to make it super, super easy to ship desktop apps in whatever way you want to do it. And so I think what we're going to look at next is, you know, a Mac store. Actually, the Microsoft store is probably easier to add support for, but we're going to be getting to the Mac store at some point too.

And could this be used alongside GitHub Actions? Yeah, absolutely. So actually, that's one of the things we've focused on recently, especially for open source apps, which we have a really good support for. And it's free to use for open source apps. You can combine GitHub releases and actions and pages together to get continuous deployment for desktop applications. So you can set that up very easily and quickly. We have a

tutorial on how to do it and also a sample repository for how to do that with flutter so you uh you know you get push and github actions will compile your app on each platform and then it runs conveyor and conveyor builds the uh the all the files update metadata and so on pushes it to a new release and um your clients immediately start updating uh to the latest github release um and uh

The download page will also be refreshed and that will automatically be checked into and pushed into your GitHub pages. So it's literally one command and everything is just on Rails from that point on. Or, yeah, you run it somewhere, a push hook, and you just push and everything updates. So if you're built on the GitHub stack, then that's tremendously convenient.

That's huge. I mean, that's one of the big challenges we would have had if I could do manual Windows builds. We could build easily through Flutter, through the command line, but then users are stuck with that version that we released.

and this forces an update. Is that correct? When they relaunch, how does that work? Well, you can do it in two ways, actually. Conveyor supports at least two modes. Well, three, you can also turn updates off or make them be an entire manual. But if you're using auto-updates, the default is a kind of a background update mode, which is a bit like, well, on Windows, it's a background update, so it's like Chrome. So Windows itself will keep your app, if

application up to date. Then it polls like every eight hours or so. It does Delta updates. It can update the app whilst it's running, even if it's not running.

So it's a very Chrome-like experience. On macOS, we use Sparkle, because that way it's a widely used toolkit, and that way you're not locked in as well. And Sparkle can update in the background as well, or it can ask the user, do you want to confirm each time, or do you want to update? And then we also support something that is not a great name, but we're not quite sure what to call it. So we call it aggressive updates, which is almost web-like update mode, where every time the application starts, it

It checks with your repository, which is just static files on a web server somewhere. It checks to see if there's a new version. If there is, it immediately downloads and applies it, and then it starts the app. So in this way, you know that the user is always up to date as long as they restart the app from time to time, and it's pretty fast as well. So that gives you this kind of...

assurance that if you push out a new version, then your users will get updated really fast.

That's great. And how is the UI handled? Does it require custom Flutter code or does the package handle showing to the user that the download's happening? Yeah, so that's all handled for you automatically. It depends on the OS. So on Windows, we have a bit of custom UI that displays a progress bar and your app logo while the app is installing or whilst it's updating.

And on Windows, actually what happens is we generate a small, it's about 500 kilobytes, it's really small, little installer app, and then that actually drives the download. And the reason we do that is because we're actually delegating the download and install process to Windows, and the latest versions of Windows, well, I say latest, Windows 10 onwards, so everyone has it these days, basically, will actually only download the bits of the files that you need. So if you have a Flutter app installed already, then...

then that download, the second app you install, will not actually download the Flutter runtimes and so on again. It will actually reuse that data that you've already got on your disk. It just copies it into the new install directory. So this can make installs of apps, even if they have large runtimes, it can make it really, really fast because you're only downloading the code which is unique to your program. So this is a really great feature.

And on Mac OS, we use Sparkle. So it's native Mac UI to render the progress bar and, you know, just a few buttons and things. So it's native UI on each platform. And that means you don't have to actually adjust your application at all. There's no need to alter your code or anything like that. It's all done for you. That's awesome. Very cool. Can you go into a bit of detail about how certificates are handled?

Yeah, right. Yes, good question. Because code signing is always a huge pain when distributing to the desktop, which has been. Well, actually, not just desktop, right? You have to sign as well for mobile. So it's something that lots of developers are well familiar with. So actually, Conveyor does all the signing and notarization itself, which is why it's able to build and assign all the packages for every OS from any OS. So you can actually do all the packaging and so on and release from the Linux CI machine or your laptop.

Um, for frameworks that don't require any native compilation, um, you know, it means you can do everything. You can release an entire desktop app to everyone from, from your laptop. Now, Flutter currently does require a little bit of native compilation. It's not really fundamental, right? Because, uh, the Dart VM is a cross-platform VM. So maybe in future versions that will no longer be necessary, but, uh, it's pretty nice to be able to do that. And it can do this because it implements all the sign-in code itself. Um, so you just provide it with, uh, your, um,

your certificates that you've acquired from Apple or Windows CA. Or if you don't have them, that's fine, and it will actually generate and do self-signing. So it will generate certificates for you and self-sign. So you'll get security warnings, but the application is still able to auto-update and it's still being signed properly, which the OS wants in many cases. But otherwise, yeah, you provide it with your certificates and it will even generate CSRs for you. So if you don't have certificates, it will walk you through that process of getting them.

all derived from a single root key that you can write down with pen and paper. And then you press go, and it will proceed to sign everything and upload to Apple for notarization, and everything is on Rails from that point on. Just press enter, and it's all done for you. That's great. That sounds great. It's been a lot of time just managing certificates and backing them up. Yeah, we've done a lot of work on the usability of code signing, and there's more that we could do. You know, there's always...

All ways to improve the usability of this. But we do, for example, a lot of usability sanity checks because basically every time someone gets stuck or hits a problem or they file a support ticket, we dig in and we update the products to try and ensure that won't happen again. So at this point, there's lots of little code paths checking. Are you using the wrong type of certificate? Are you using the wrong type of web server, which can matter in some cases? Handling all times at Apple's notarization service flake house and all these things. So yeah, we put a lot of work into that.

Can you talk a bit about the business model, the pricing? Yep. So it's, as I mentioned already, it's free for open source apps. It's not itself open source. It's a product. It's not a service. It's not a SaaS platform. We could do one of those if people want it. But it's a development tool. So we ship it as a command line app that you run locally. And that allows you to iterate very quickly.

You just configure it with a local config file, tweak it, and it's actually an incremental parallel build system. So you can make a tweak and see the effects on the packaging very, very quickly.

And then for commercial apps, you pay and it's a subscription pricing and you get support with that, which our customers tend to really like, and that's 45 bucks a month. And you get three apps for that. And we define an app as a update URL, basically. So different platforms, that's all considered to be one app. So if you have Mac, Windows, Linux, whatever, that's one app. But if you want to have

different versions of your app or different editions or whatever that update separately than those we consider to be different apps which is why we include three for the price of that subscription because that way you can have a beta channel for example and it's all included in the price got it sounds great and for the future are there other features you're planning to add well you know we're sort of driven by what um users ask for and at the moment you know the past six months or so we've spent a lot of time um just uh as customers have been turning up and and

needing features or hitting problems or whatever. We've just been fixing those. I think where we're looking at going next is for one, we're working on an IntelliJ plugin. So it's much easier to get set up because Conveyor is all about usability, really. That's like the primary pitch. It's all like taking the pain away from shipping outside of the browser.

Yet looking at things like the stores, maybe things like Flatpak, we'll see. What we tend to see is a lot of interest in that because people are asking about it as a new thing. But often developers, their primary focus is they just want Linux to work. They don't want to invest a lot of time in it. And so we're going to look and see how much effort it is to support sandboxing and things there in particular. And also, in the longer run,

I would say the vision of what we're trying to do is we want to make distributing software outside the browser competitive with software being distributed through the browser. And so we've been exploring ideas like apps that uninstall themselves automatically if you don't use them for a couple of months, for example. So one of the reasons why people like web apps or they find them convenient is they're sort of self-cleaning.

You don't really have to manage them in any way. They go into the cache and after a while they get automatically deleted by the browser.

There's no reason you can't do that on a desktop as well. You can have self-cleaning apps. One thing we also thought about a little bit is signing on behalf of other people. So for projects where, you know, if you don't have certificates today, but we can quickly verify that you're not distributing malware, we'll sign for you. And one way we might be able to validate that is if you're willing to run inside a sandbox. If, you know, if you're willing to go that route and so on, then we might, because we could...

In that case, you would upload your files to us, we would build the packages for you, and then because we're controlling the packaging, we control the entry point. And so at that point, the application could be changed so that it enforces a sandbox before it runs your code. And in this way, we're very interested in just constantly driving down the complexity, constantly improving that usability to the point where

It's just as easy, if not easier, to do this for both developers and end users than to actually build a web app. Awesome. As a developer, we appreciate simplicity, right? Keep it simple. Yeah, that's what it's... I think as developers, we often find it very easy to spend inordinate amounts of time on setting things up, configuring stuff, and so on, and getting the paper cuts along the way, but

And what we find is our customers often turn up, they tend to turn up kind of shell-shocked a little bit from the difficulty and complexity of doing it by hand. And they just say, okay, I thought it would be easy. I thought I could just do it myself. And now I just want someone to take away the complexity, take away that pain. Is there anything else you'd like to add or promote? Well, I mean, let me think.

One thing I would say where this can really make a lot of sense, actually, is for apps that you're distributing inside organizations. We don't tend to think about desktop apps much in this context anymore. But for example, if you want to make a UI for some internal database or dashboard or something, well, again, historically, it would be too much effort to do this as a desktop application. But now the distribution side is getting so easy.

In particular, for distributing inside companies, you don't even necessarily need to get it signed because self-signing is good enough. In that case, you can have employees install their own root authority even if you want to do that.

You can just start banging out apps that just update immediately when they get started, and you can benefit from that great Flutter development experience with the nice language and hot reload and the nice toolkit and so on, even for cases where you previously would have just knocked together something with HTML.

And, you know, the end result is going to work better for your end users too than something like Flutter Web, where it's often quite sort of slow to load and a bit clunky and so on. And so I think this is one of those cases where I'm really trying to get the message through to developers here that you can start to think about using this nice tech in places you previously would have written it off as being too much effort. And, you know, it's for reasons like that, I think. Framework said Flutter Desktop had a really bright future.

Yeah, I'm looking forward to it. Nice. I agree entirely. I think Flutter Desktop is great. We're really happy with it. The development experience is like nothing else. I mean, it's nothing even close to the market, in my opinion. It sounds like a great product. I wish you best of luck. I hope a lot of developers hear the podcast and are willing to try it out. We're going to try it out. It's a great fit for us. Mike, thank you so much for being on the podcast. Thank you very much, Phil. It's been great. Thanks for listening. Until next time. Music