We can now create desktop apps with Flutter. This article covers the key points of my interest and demonstrates how to build them.
Register to the App Store Connect
You need to register your app to the App Store Connect to release it in the AppStore. The process for AppStore Connect remains the same, even when using Flutter.
Configuration of the Xcode Project
Set up your Xcode project. You will find a folder called
macos in the project’s code set folder. Open
Runner.xcworkspace in this folder. A project file is also in the same folder but open the workspace file.
Open the workspace file,
Runner.xcodeproj is registered and contains two targets. First, open the target Runner settings.
On the General tab, configure the following.
- App Category
You set the above on this tab, but there is one more thing to focus on: the Deployment Target. The default is
10.11; Flutter supports macOS 10.11 or later.
As it’s an older OS now, the minimum requirement for the apps I develop for work is macOS 10.13. For macOS 10.11, it was around the time macOS introduced GateKeeper2.
Newly developed applications typically require a newer OS. Therefore, I believe we can increment the Deployment Target to reflect this.
The bundle identifier and product name are configured in the
AppInfo.xcconfig file, so don’t edit the project file directly. If you edit the project file, Xcode doesn’t update the
Signing & Capabilities Tab
The configurations in the Signing & Capabilities tab are the following.
- Automatically manage signing
- Signing Certificate
The default setting is to use Sandbox to support the App Store. Since it is Sandbox-compatible, you can create applications for distribution through the App Store.
Two sandbox settings exist, one for Debug and another for Release. You should enable the necessary features for your application.
When distributing outside the App Store or when it is necessary to implement processing that Sandboxing cannot perform, remove the Sandbox setting and change it to enable Hardened Runtime.
App name and other settings
Adjust the following parameters in the
AppInfo.xcconfig file. Usually, you edit the Xcode project file directly, but
Runner.xcodeproj is edited in
|The product name|
|The bundle identifier of the application package.|
|The copyright information.|
In the same folder, there are two configuration files. The
Debug.xcconfig file sets build options for the debug build, and
Release.xcconfig sets build options for the release build. There is also
Warnings.xcconfig for configuring warnings.
xcconfig files override the settings in the Xcode project file, so it seems better to edit these files for Flutter than to edit the project file directly.
You can set the version number in the
pubspec.yml file. This value also does not edit in the project file; changing the version in
pubspec.yml and building the app will automatically update the version number in the Xcode project file.
version value contains two numbers separated by a
+, as shown below.
The front of the
+ is set to
CFBundleShortVersionString (Version), and the back of the
+ is set to
CFBundleVersion (Build). If you open the target
Runner settings after the build, you will see that the project file has been updated.
Build a macOS desktop app
To build a macOS desktop app, run the following in the Terminal.
% flutter build macos
Upon completion of the build, an application package is created in the directory mentioned below.
It is a typical desktop application that can be launched by double-clicking in the Finder.
Runtime file size
Many cross-platform libraries have been created in the past. One of the concerns when using frameworks, including Flutter, is file size. I looked into this.
Open the application package and check inside the
Frameworks folder. You will find two frameworks in addition to the Swift runtime. These frameworks would be the Flutter runtime. Each has the following capacity.
The total is 33.6 MB. Hmmm… that’s not small. For comparison, let’s look at Swift’s runtime capacity.
The total is 11.26 MB, calculated in Finder way with 1 MB = 1000 KB; if you make a desktop app with Flutter, it also contains the Swift runtime, so the total runtime is 44.86 MB.
Considering these numbers purely, it is a large size. However, consider development efficiency, the current storage situation, and Internet communication speed. In that case, it is an acceptable size. On the other hand, if the developed application is simply a side application and only necessitates a web browser’s capabilities. In that case, it is a size that I think about.
Supporting Apple Silicon
The developed application is a universal binary natively compatible with Apple Silicon. The architecture of the binary file for the Flutter-built app is depicted below.
% cd mac_menubar_demo.app/Contents/MacOS % file mac_menubar_demo mac_menubar_demo: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64 - Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64 - Mach-O 64-bit executable arm64] mac_menubar_demo (for architecture x86_64): Mach-O 64-bit executable x86_64 mac_menubar_demo (for architecture arm64): Mach-O 64-bit executable arm64
It is a universal binary with
x86_64 executable code. I also looked at runtime frameworks, and they are the same.
Apple Silicon native support without any problems.