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.
Xcodeの設定
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.
General Tab
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 AppInfo.xcconfig file.
Signing & Capabilities Tab
The configurations in the Signing & Capabilities tab are the following.
- Automatically manage signing
- Team
- 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 macos/Runnder/Configs/AppInfo.xcconfig file.
| Configuration | Description |
|---|---|
PRODUCT_NAME | The product name |
PRODUCT_BUNDLE_IDENTIFIER | The bundle identifier of the application package. |
PRODUCT_COPYRIGHT | 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.
The 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.
Version Number
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.
The version value contains two numbers separated by a +, as shown below.
version: 1.0.1+2
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 macosUpon completion of the build, an application package is created in the directory mentioned below.
build/macos/Build/Products/Release
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.
| Framework | File Size |
|---|---|
App.framework | 6.9MB |
FlutterMacOS.framework | 26.7MB |
The total is 33.6 MB. Hmmm… that’s not small. For comparison, let’s look at Swift’s runtime capacity.
| Library | File Size |
|---|---|
libswiftAppKit.dylib | 222KB |
libswiftCore.dylib | 6.5MB |
libswiftCoreAudio.dylib | 75KB |
libswiftCoreData.dylib | 99KB |
libswiftCoreFoundaion.dylib | 42KB |
libswiftCoreGraphics.dylib | 190KB |
libswiftCoreImage.dylib | 50KB |
libswiftCoreMedia.dylib | 87KB |
libswiftDarwin.dylib | 99KB |
libswiftDispatch.dylib | 328KB |
libswiftFoundation.dylib | 3.2MB |
libswiftIOKit.dylib | 45KB |
libswiftMetal.dylib | 85KB |
libswiftObjectiveC.dylib | 62KB |
libswiftos.dylib | 72KB |
libswiftQuartzCore.dylib | 58KB |
libswiftXPC.dylib | 46KB |
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 arm64It is a universal binary with arm64 and x86_64 executable code. I also looked at runtime frameworks, and they are the same.
Apple Silicon native support without any problems.
