Flutterでデスクトップアプリが作れるようになった点について、気になるポイントをいくつか確認しました。この記事ではビルド方法についてです。
App Store Connectへの登録
AppStoreで配布する場合は、App Store Connectでアプリの登録などを行います。App Store Connectでの作業はFlutterを使わない場合と同じです。
Xcodeの設定
Xcodeのプロジェクトを設定します。プロジェクトのコード一式のフォルダー内にmacosというフォルダーがあると思います。このフォルダー内のRunner.xcworkspaceを開きます。同じフォルダーにプロジェクトファイルもありますが、ワークスペースファイルの方を開きます。

ワークスペースファイルを開くと、Runner.xcodeprojが登録されていて、2つのターゲットが入っています。ターゲットRunnerの設定を開きます。
Generalタブ
Generalタブで以下を設定します。
- App Category
「App Category」で設定するのは上記ですが、もう1つ、注目点があります。Deployment Targetです。デフォルトでは10.11になっています。FlutterはmacOS 10.11以降対応となっています。
今となっては古いOSで、私が業務で開発しているアプリの最低環境はすでにmacOS 10.14まで上がっています。macOS 10.11だとGateKeeper2が導入されたあたりですね。Notalizeが必要になったのもこの辺だったと思います。
新規に開発するアプリの動作環境はそれらよりも新しいOSだと思います。それに合わせて、Deployment Targetを引き上げても問題ないでしょう。

Bundle Identifierやプロダクト名は、別ファイルのAppInfo.xcconfigファイルで設定するので、直接、プロジェクトファイルは編集しません。編集してしまうと、AppInfo.xcconfigファイルが反映されなくなります。
Signing & Capabilities タブ
Signing & Capabilitiesタブで設定するのは、次の項目です。
- Automatically manage signing
- Team
- Signing Certificate
デフォルトの設定状態で、App Storeに対応できるようにSandboxを使うようになっています。Sandbox対応されているので、App Storeで配布するアプリを作ることもできますね。
Sandboxの設定がDebug用とRelease用で分かれています。アプリにとって必要な機能をオンにする必要があります。
App Store以外で配布する場合や、Sandbox化では実行できない処理を実装する必要があるときには、Sandboxの設定を削除して、Hardened Runtimeを使用する設定に変更します。
アプリ名などの設定
以下の項目はAppInfo.xcconfigファイルで変更します。通常はXcodeのプロジェクトファイルを直接編集しますが、Runner.xcodeprojは、macos/Runnder/Configs/AppInfo.xcconfigファイルで編集します。
PRODUCT_NAME製品名PRODUCT_BUNDLE_IDENTIFIERバンドル識別子PRODUCT_COPYRIGHT著作権情報
同じフォルダー内に、デバッグ用とリリース用のビルドオプションを設定するための、Debug.xcconfigとRelease.xcconfigがあります。ワーニングの設定用にWarnings.xcconfigもあります。
xcconfigファイルはXcodeのプロジェクトファイルの設定を上書きするファイルです。Flutterの場合はプロジェクトファイルを直接編集するよりも、これらのファイルを編集した方が良さそうです。
バージョン番号
バージョン番号はpubspec.ymlファイルで設定します。バージョン番号もプロジェクトファイルでは編集しません。pubspec.ymlのversionを変更して、アプリをビルドすると、自動的にXcodeのプロジェクトファイル内のバージョン番号も変更されます。
versionの値は次のように、+で区切って2つの番号を設定します。
version: 1.0.1+2
+の前はCFBundleShortVersionString (Version)に設定され、+の後ろ側はCFBundleVersion (Build)に設定されます。ビルド後にターゲットRunnerの設定を開くと、プロジェクトファイルが更新されたことを確認できます。

Macデスクトップアプリをビルドする
Macのデスクトップアプリをビルドするには、ターミナルから次を実行します。
% flutter build macosビルドが完了すると、次のディレクトリにアプリケーションパッケージが作成されます。
build/macos/Build/Products/Release
Finderでダブルクリックして起動する普通のデスクトップアプリです。
ランタイムのファイルサイズ
クロスプラットフォームなライブラリは過去から多々作られてきました。多くは、MacとWindowsを共通で作れるというものでした。Flutterも含めてフレームワークを使うときに、気になるのはファイルサイズです。調べてみました。
アプリケーションパッケージを開き、Frameworksフォルダー内を確認すると、Swiftのランタイムの他、2つのフレームワークが見つかります。この2つのフレームワークがFlutterのランタイムでしょう。それぞれ、容量は次の通りです。
App.framework6.9MBFlutterMacOS.framework26.7MB
合計で33.6MB。確かに、これは少々大きいと感じるかもしれません。比較のため、Swiftのランタイムの容量を見てみましょう。
libswiftAppKit.dylib222KBlibswiftCore.dylib6.5MBlibswiftCoreAudio.dylib75KBlibswiftCoreData.dylib99KBlibswiftCoreFoundaion.dylib42KBlibswiftCoreGraphics.dylib190KBlibswiftCoreImage.dylib50KBlibswiftCoreMedia.dylib87KBlibswiftDarwin.dylib99KBlibswiftDispatch.dylib328KBlibswiftFoundation.dylib3.2MBlibswiftIOKit.dylib45KBlibswiftMetal.dylib85KBlibswiftObjectiveC.dylib62KBlibswiftos.dylib72KBlibswiftQuartzCore.dylib58KBlibswiftXPC.dylib46KB
合計で11.26MB。Finderの流儀に合わせて1MB=1000KBで計算しました。Flutterでデスクトップアプリを作る場合には、Swiftランタイムも組み込まれるので、ランタイムが合計で44.86MBとなります。
この数字を純粋に考えると、やや大きい。しかしながら、開発効率や現在のストレージ事情、インターネットの通信速度を含めて考えると、許容できるサイズかなと思います。単純な側アプリで、Webブラウザで提供可能な機能しか持っていない場合は、この限りではありません。
Apple Silicon対応
ビルドされるアプリはユニバーサルバイナリになっており、Apple Siliconにネイティブ対応しています。Flutterでビルドしたアプリのバイナリファイルのアーキテクチャを確認すると次のようになりました。
% 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 arm64arm64とx86_64の実行コードがたしかに入っているユニバーサルバイナリになっています。ランタイムのフレームワークも見てみましたが同様に入っていました。
問題なくApple Siliconネイティブ対応しています。











