Written by Rody Davis Jr
So you built your first Flutter application and released it on the AppStore for iOS devices and Google Play for Android devices. Then you wanted to reach a larger audience and targeted web, so you released it with static hosting. But you still want more. If you want the performance of mobile but the responsiveness of web, desktop is the answer.
Read the article on getting started with Flutter desktop.
Current options
With desktop, you have a couple of options for releasing — but all of them come with certain tradeoffs. Here, we will discuss why you may want to choose one over the other.
Electron
You may have heard of Electron before since most of the third party applications currently available on MacOS and Windows are released with it. Electron is a chromium-powered browser with Node.js to glue the web browser to the filesystem. You get the benefit of developing for the web but with the flexibility of desktop. It uses a lot of JS to do this so you lose out on AOT (Ahead of time compilation), which means that there is no tree shaking, optimization or general performance.
The reason Flutter works so well on mobile is because of the AOT from release builds. You can release a Flutter application with Electron by adding a manifest file to the root and a few extra boilerplate scripts. You package up your Flutter Web application just like when deploying to static hosting. If you want to use the FLUTTER_WEB_USE_SKIA flag, you can get better performance out of the web version.
Standalone
Regardless of whether you build your Flutter desktop app with Electron, desktop embedding or a custom embedder, you will need a way to release the application to the world. If you create a release build with Codemagic, Github Actions or manually, you upload the build to Amazon S3 or similar CDN and offer the link to customers. This approach is nice because you don’t have to wait for a review process or deal with very specific rules for each platform. You can then take that link and put it on your Flutter web application or PWA manifest to offer a native experience whenever it seems right for the user.
A major downside with this approach is how you handle updates. You will need to use a library or custom-built solution for downloading and installing the update in the background or notifying users of a new update. The more steps you give to the user, the less likely they will complete all of them. You trade off flexibility with usability at the cost of the user.
There are some nice tools, such as Sparkle for MacOS and Windows that powers a lot of the apps you use every day. Anytime you see a popup saying an update is ready to install, there is a good chance it is using the library. The library runs off a hosted RSS feed that you parse to get the release notes, versions, and links to install. The app will attempt to install them automatically for you in the background and will reload the next time you launch.
Official stores
Now the choice that you may be putting off is releasing to the official stores. There can be legitimate reasons for going outside the app stores as you may not be following all the guidelines, have a custom deployment and release backend, enterprise application only for internal or limited use or you just want a link on your website to download the application. Many apps even offer the app in stores but also have a version online that could be the beta channel or special builds. I find this to be a good approach because the Mac AppStore for example still does not have TestFlight for MacOS applications like it does for iOS.
Deploying to the stores can be challenging but I believe it is worth it in the end, as you gain security and auto updates. They will also handle payments and refunds. In a future article I will go over releasing a Flutter application to the Mac AppStore just as I have with the new Widget Studio on iPadOS and MacOS. By the way, Widget Studio is also available as a PWA. I suggest that on MacOS you should only include the permissions you are actively using and if you want to share a purchase of a Mac and iPad app, you need to have the same bundle ID. You do not do this with Catalyst but rather the current desktop embedding.
Conclusion
It is an exciting time to bring mobile applications to desktop in a native way that hasn’t been possible before. Flutter is awesome for letting you target MacOS, Windows and Linux and now it is up to you to decide how you want to distribute. Codemagic supports Linux and MacOS and it could not be easier than 2 check boxes. Let me know if you have any questions and I look forward to seeing your Flutter Desktop applications!
Rody Davis Jr is a professional full stack developer in both enterprise and personal applications. He creates apps for App Store, Google Play, Web and Desktop using the latest frameworks. Rody loves Flutter, Web and all things creative and writes Flutter articles on Medium. He hopes to reach as many people possible with his applications and show what is possible with the latest tech.