We are now able to create desktop apps with Flutter and check the points of my interest. This article is about how to build.
Register to the App Store Connect
You need to register your app to the App Store Connect to release in the AppStore. The operation for the AppStore Connect is same as without the 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. There is also a project file in the same folder, but open the workspace file.
Open the workspace file, Runner.xcodeproj is registered and contains two targets. Open the target Runner settings.
General Tab
On the General tab, configure the following.
- App Category
The above is what you set on this tab, but there is one more thing to focus on: the Deployment Target. The default is 10.11; The Flutter supports macOS 10.11 or later.
It is an older OS now. The minimum environment for the apps I develop for work is macOS 10.13. For macOS 10.11, it was around the time GateKeeper2 was introduced.
I believe the system requirement for newly developed applications is a newer OS. I wonder if we can raise the Deployment Target accordingly.
The bundle identifier and the product name is configured in the AppInfo.xcconfig file, so don’t edit in the project file directly. If you edit in the project file, the AppInfo.xcconfig file will not be reflected.
Signing & Capabilities Tab
The configurations in the Signing & Capabilities tab are following.
- Automatically manage signing
- Team
- Signing Certificate
The default setting is to use Sandbox to support the App Store, and since it is Sandbox-compatible, you can create applications for distribution through the App Store.
The sandbox settings are separated for Debug and Release. You need to turn on the features that are necessary for your application.
When distributing outside of the App Store or when it is necessary to implement processing that cannot be performed by Sandboxing, remove the Sandbox setting and change the setting to use Hardened Runtime.
App name and other settings
The following items are configured in the AppInfo.xcconfig file. Normally, the Xcode project file is edited 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 Debug.xcconfig and Release.xcconfig for setting build options for debug and release. 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 the Flutter than to edit the project file directly.
Version Number
The version number is set 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 change the version number in the Xcode project file.
The value of version is two numbers separated by + , as follows.
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 macosAfter the build is completed, an application package is created in the following directory.
build/macos/Build/Products/Release
It is a normal 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.
If you open the application package and check inside the Frameworks folder, you will find two frameworks in addition to the Swift runtime. This would be the Flutter runtime. Each has the following capacities.
| 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, the Swift runtime is also included, so the total runtime is 44.86 MB.
Considering these numbers purely, it is somewhat large. However, if you include development efficiency, the current storage situation, and Internet communication speed, I think it is an acceptable size. If the application to be created by it is simply a side application and only has enough functions with a web browser, it is a size that I would think about a little.
Supporting Apple Silicon
The built application is a universal binary that is natively compatible with Apple Silicon, and the architecture of the binary file of the app built with Flutter is shown 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 indeed a universal binary with arm64 and x86_64 executable code. I also looked at the runtime framework and it was included as well.
Apple Silicon native support without any problems.
