Publishing a Flet app#
Flet CLI provides the flet build command to package a
Flet app into a standalone executable or installable package for distribution.
Prerequisites#
Platform matrix#
Use the following matrix to choose which OS to run flet build
on for each target platform:
| Run on | Target Platform | |||||
|---|---|---|---|---|---|---|
| apk/aab | ipa | macos | linux | windows | web | |
| macOS | ✅ | ✅ | ✅ | ✅ | ||
| Windows | ✅ | ✅ (WSL) | ✅ | ✅ | ||
| Linux | ✅ | ✅ | ✅ | |||
Flutter SDK#
Flutter is required to build Flet apps for any platform.
If the minimum required version of the Flutter SDK is not already
available in the system PATH, it will be automatically downloaded
and installed (in the $HOME/flutter/{version} directory) during
the first build process.
Tip
The recommended (minimum required) Flutter SDK version depends on the Flet version installed or in use.
It can be viewed by running one of the following commands:
or the below Python code snippet:
Project structure#
The flet build command assumes the following minimal Flet project structure:
-
Serves as the main configuration file for your application. It includes metadata, dependencies, and build settings. At a minimum, the
dependenciessection should specifyfletpackage.Example
Below is an example of a
pyproject.tomlfile:pyproject.toml[project] name = "example" version = "0.1.0" description = "An Example." readme = "README.md" requires-python = ">=3.10" authors = [{ name = "Me", email = "me@example.com" }] dependencies = [ "flet" ] [tool.flet] org = "com.mycompany" product = "My App" company = "My Company" copyright = "Copyright (C) 2025 by My Company" [tool.flet.app] path = "src" -
An optional directory that contains application assets (images, sound, text, and other files required by your app) as well as images used for package icons and splash screens.
- The main entry point of your Flet app. It usually contains the call to
ft.run().
Tip
To quickly set up a project with the correct structure, use the flet create command:
Where <project-name> is the name for your project directory.
Using requirements.txt instead of pyproject.toml
Instead of a pyproject.toml file, you can also use a requirements.txt file to specify dependencies.
In this case, two things to keep in mind:
- if both files are present,
flet buildwill ignorerequirements.txt. - don't use
pip freeze > requirements.txtto generate this file or fill it with dependencies, as it may include packages incompatible with the target platform. Instead, hand-pick and include only the direct dependencies required by your app, includingflet.
How it works#
When you run flet build <target_platform>, the pipeline is:
- Create a Flutter project in
{flet_app_directory}/build/flutterfrom the template. The Flutter app embeds your packaged Python app in its assets and usesfletandserious_pythonto run the app and render the UI. The project is cached and reused across builds for rapid iterations; use--clear-cacheto force a rebuild. - Copy custom icons and splash images from
assetsinto the Flutter project, then generate:- Icons for all platforms via
flutter_launcher_icons. - Splash screens for web, iOS, and Android via
flutter_native_splash.
- Icons for all platforms via
- Package the Python app using
serious_python package:- Install app dependencies from pypi.org and pypi.flet.dev for the selected platform, as configured in App dependencies and Source packages.
- If configured, compile
.pyfiles to.pyc. - Add all project files, except those excluded, to the app asset.
- Run
flutter build <target_platform>to produce the executable or installable package. - Copy build outputs from Step 4 into the output directory.
Configuration options#
Placeholders
Throughout this documentation, the following placeholders are used:
<target_platform>- one of:apk,aab,ipa,web,macos,windows,linux.<PLATFORM>- the config namespace under[tool.flet.<PLATFORM>]; one of:android(forapkandaabtargets),ios(foripatarget),web,macos,windows,linux.<python_app_path>- the path passed toflet build(defaults to the current directory).<flet_app_directory>- the resolved project root for<python_app_path>;pyproject.tomlandrequirements.txtare read from here.<flet_version>- the version of Flet in use. You can check withflet --versionoruv run python -c "import flet; print(flet.__version__)".
Understanding pyproject.toml structure
Flet loads pyproject.toml as a nested dictionary and looks up settings using
dot-separated paths (for example, tool.flet.web.base_url).
The two forms below are equivalent and resolve to the same key-value pair:
-
Form 1 (will be used/preferred throughout this documentation)
-
Form 2
But they are different or should not be confused with the below ("quoted keys" are literals and do not create nesting):
App path#
Defines the root directory of your Python app within <python_app_path>.
Flet looks for the entry point, the assets directory, and
exclude paths relative to this directory.
Resolution order#
Its value is determined in the following order of precedence:
[tool.flet.app].path<python_app_path>
path is resolved relative to <python_app_path>.
Example#
Entry point#
This is the Python module that starts your app and contains the call to
flet.run() or flet.render(). Flet uses the module stem and looks for
<module>.py in your app path.
Resolution order#
Its value is determined in the following order of precedence:
--module-name[tool.flet.app].module"main"(entry filemain.py)
Its value can either be <module> or <module>.py; both resolve to the same Python module.
Example#
Project name#
The project name is the base identifier for bundle IDs and other internal
names. The source value is normalized to a safe identifier: lowercased, punctuation
and spaces removed or collapsed, and hyphens converted to underscores (for example,
My App or my-app becomes my_app).
Resolution order#
Its value is determined in the following order of precedence:
--project[project].name- project/app directory name
Example#
Product name#
The display (user-facing) name shown in window titles, launcher labels, and about dialogs.
It does not control the on-disk executable or bundle name. Use the artifact name for artifact naming.
Resolution order#
Its value is determined in the following order of precedence:
Example#
Artifact name#
The on-disk name for executables and/or app bundles. For example, on Windows it
determines the name of the .exe file, and on macOS it sets the name of the .app bundle.
It does not affect bundle IDs or package identifiers.
It can contain spaces or accents, but keep file system restrictions in mind on your target platforms.
Resolution order#
Its value is determined in the following order of precedence:
--artifact[tool.flet].artifact--project[project].name- project/app directory name
Example#
Organization name#
The organization name in reverse domain name notation, typically in the form
com.mycompany. It is used as the prefix for the bundle ID and
for package identifiers on mobile and desktop targets.
Resolution order#
Its value is determined in the following order of precedence:
--org[tool.flet.<PLATFORM>].org[tool.flet].org"com.flet"
Example#
Bundle ID#
The bundle ID for the application, typically in the form "com.mycompany.my_app".
If not explicitly specified, it is derived from the organization name and the project name used by the build template.
Resolution order#
Its value is determined in the following order of precedence:
--bundle-id[tool.flet.<PLATFORM>].bundle_id[tool.flet].bundle_id
Example#
Company Name#
The company name displayed in about app dialogs and metadata (notably on desktop builds).
Resolution order#
Its value is determined in the following order of precedence:
--company[tool.flet].company- Build template default (see Template Source)
Example#
Copyright#
Copyright text displayed in about app dialogs and metadata.
Resolution order#
Its value is determined in the following order of precedence:
--copyright[tool.flet].copyright- Build template default (see Template Source)
Example#
Versioning#
Build Number#
An integer identifier used internally to distinguish one build from another.
Each new build must have a unique, incrementing number; higher numbers indicate more recent builds.
Resolution order#
Its value is determined in the following order of precedence:
--build-number[tool.flet].build_number- Otherwise, the build number from the generated
pubspec.yaml(see Template Source) will be used.
Example#
Build Version#
A user‑facing version string in x.y.z format.
Increment this for each new release to differentiate it from previous versions.
Resolution order#
Its value is determined in the following order of precedence:
--build-version[project].version[tool.poetry].version- Otherwise, the build version from the generated
pubspec.yaml(see Template Source) will be used.
Example#
Output directory#
The directory where the build output is saved. If the directory already exists, it is deleted and recreated on each build.
For web builds, the app's assets directory is copied into the output directory.
Resolution order#
Its value is determined in the following order of precedence:
--output(or-o)<python_app_path>/build/<target_platform>
Example#
App dependencies#
These are the Python packages that your Flet app depends on to function correctly.
Resolution order#
Its value is determined in the following order of precedence:
[tool.poetry].dependenciesif present; otherwise[project].dependencies(PEP 621).- If
[tool.flet.<PLATFORM>].dependenciesis set (where<PLATFORM>corresponds to<target_platform>), its values are appended to the list above. - If the result of all above is empty and
requirements.txtexists in<python_app_path>, it is used. - If the result of all the above is empty,
flet==<flet_version>is used.
To use a local development version of a dependency during builds, configure
[tool.flet].dev_packages or [tool.flet.<PLATFORM>].dev_packages with a
package name to path mapping.
If your app uses Flet extensions (third-party packages), list them in your Python dependencies so they are packaged with the app. Examples of extensions can be found in Built-in extensions.
Example#
[project]
dependencies = [
"flet",
"requests",
"flet-extension1",
"flet-extension2 @ git+https://github.com/account/flet-extension2.git", # git repo
"flet-extension3 @ file:///path/to/flet-extension3", # local package
]
[tool.flet.<PLATFORM>] # will be used/appended only if <PLATFORM> corresponds to <target_platform>
dependencies = [
"dep1",
"dep2",
]
Source packages#
By default, packaging for mobile and web only installs binary wheels. Use source packages to allow specific dependencies to be installed from source distributions (sdists).
On desktop targets, source installs are already allowed, so this setting is mainly for Android and iOS builds.
Resolution order#
Its value is determined in the following order of precedence:
--source-packages[tool.flet.<PLATFORM>].source_packages[tool.flet].source_packages
Example#
Icons#
You can customize app icons for all platforms (except Linux) using image files placed in
the assets directory of your Flet app.
If a platform-specific icon (as in the table below) is not provided, icon.png
(or any supported format like .bmp, .jpg, or .webp) will be used as fallback.
For the iOS platform, transparency (alpha channel) will be automatically removed, if present.
| Platform | File Name | Recommended Size | Notes |
|---|---|---|---|
| iOS | icon_ios.png |
≥ 1024×1024 px | Transparency (alpha channel) is not supported and will be automatically removed if present. |
| Android | icon_android.png |
≥ 192×192 px | |
| Web | icon_web.png |
≥ 512×512 px | |
| Windows | icon_windows.ico or icon_windows.png |
256×256 px | .png file will be internally converted to a 256×256 px .ico icon. |
| macOS | icon_macos.png |
≥ 1024×1024 px |
Splash screen#
A splash screen is a visual element displayed when an app is launching, typically showing a logo or image while the app loads.
You can customize splash screens for iOS, Android, and Web platforms by
placing image files in the assets directory of your Flet app.
If platform-specific splash images are not provided, Flet will fall back to splash.png.
If that is also missing, it will use icon.png or any supported format such as .bmp, .jpg, or .webp.
Splash images#
| Platform | Dark Fallback Order | Light Fallback Order |
|---|---|---|
| iOS | splash_dark_ios.png → splash_dark.png → splash_ios.png → splash.png → icon.png |
splash_ios.png → splash.png → icon.png |
| Android | splash_dark_android.png → splash_dark.png → splash_android.png → splash.png → icon.png |
splash_android.png → splash.png → icon.png |
| Web | splash_dark_web.png → splash_dark.png → splash_web.png → splash.png → icon.png |
splash_web.png → splash.png → icon.png |
Splash Background Colors#
You can customize splash background colors using the following options:
- Splash Color: Background color for light mode splash screens.
- Splash Dark Color: Background color for dark mode splash screens.
Resolution order#
Their values are respectively determined in the following order of precedence:
--splash-color/--splash-dark-color[tool.flet.<PLATFORM>.splash].color/[tool.flet.<PLATFORM>.splash].dark_color[tool.flet.splash].color/[tool.flet.splash].dark_color- Build template defaults
Example#
Disabling Splash Screens#
Splash screens are enabled by default but can be disabled.
Resolution order#
Its value is determined in the following order of precedence:
- on Android:
--no-android-splash[tool.flet.splash].android- on iOS:
--no-ios-splash[tool.flet.splash].ios- on Web:
--no-web-splash[tool.flet.splash].web
Example#
Boot screen#
The boot screen is shown while the packaged app archive (app.zip) is extracted
to the app data directory (typically on first launch or after the app bundle changes).
It appears after the splash screen and before the
startup screen.
It is not shown by default. Enable it, for example, when then extraction time is noticeable.
Example#
Startup screen#
The startup screen is shown while the Python runtime and your app are starting. On mobile targets this can include preparing packaged dependencies. It appears after the boot screen.
It is not shown by default.
Example#
Hidden app window on startup#
A Flet desktop app (Windows, macOS, or Linux) can start with its window hidden. This lets your app perform initial setup (for example, add content, resize or position the window) before showing it to the user.
See this code example.
Resolution order#
Its value is determined in the following order of precedence:
[tool.flet.<PLATFORM>.app].hide_window_on_start, where<PLATFORM>can bewindows,macosorlinux[tool.flet.app].hide_window_on_start
Example#
Deep linking#
Deep linking allows users to navigate directly to specific content within a mobile app using a URI (Uniform Resource Identifier). Instead of opening the app's homepage, deep links direct users to a specific page, feature, or content within the app, enhancing user experience and engagement.
- Scheme: deep linking URL scheme, e.g.
"https"or"myapp". - Host: deep linking URL host.
See this guide for more information.
Resolution order#
Its value is determined in the following order of precedence:
--deep-linking-schemeand--deep-linking-host(only when both are provided)[tool.flet.<PLATFORM>.deep_linking].scheme/[tool.flet.<PLATFORM>.deep_linking].host, where<PLATFORM>can be android or ios[tool.flet.deep_linking].scheme/[tool.flet.deep_linking].host
Both scheme and host are required; if either is missing, the deep-linking entries are not added.
Example#
Target Architecture#
A target platform can have different CPU architectures, which in turn support different instruction sets.
It is possible to build your app for specific CPU architectures. This is useful for reducing the size of the resulting binary or package, or for targeting specific devices.
For more/complementary information, see the specific platform guides: Android, macOS.
Resolution order#
Its value is determined in the following order of precedence:
--arch[tool.flet.<PLATFORM>].target_arch, where<PLATFORM>can beandroidormacos[tool.flet].target_arch- Platform defaults for the
<target_platform>
Example#
Excluding files and directories#
Files and/or directories can be excluded from the build process. This can be useful for reducing the size of the resulting binary or package.
Resolution order#
Its value is determined in the following order of precedence:
--exclude(can be used multiple times)[tool.flet.<PLATFORM>.app].exclude(type: list of strings)[tool.flet.app].exclude(type: list of strings)
The files and/or directories specified should be provided as relative paths to the app path directory. Paths are matched exactly (no globs), and directories are excluded recursively.
By default, the build directory is always excluded.
Additionally, when the target_platform is web, the assets
directory is always excluded.
Example#
Compilation and cleanup#
Flet can compile your app's .py files and/or installed packages' .py files into
.pyc files during the packaging process (via python -m compileall -b). Cleanup
removes known junk files and any additional globs you specify.
-
Compilation:
compile-app: compile app's.pyfilescompile-packages: compile site/installed packages'.pyfiles
-
Cleanup:
cleanup-app: remove junk files from the app directorycleanup-app-files: additional globs to delete from the app directory (impliescleanup-app)cleanup-package-files: additional globs to delete from site-packages (impliescleanup-packages)cleanup-packages: remove junk files from site-packages (defaults totrue)
[tool.flet.compile].cleanup (deprecated) enables both cleanup-app and
cleanup-packages when set to true.
By default, Flet does not compile your app files during packaging. This allows the build process to complete even if there are syntax errors, which can be useful for debugging or rapid iteration.
Resolution order#
The values of compile-app and cleanup-app are respectively determined in the following order of precedence:
--compile-app/--cleanup-app[tool.flet.<PLATFORM>.compile].app/[tool.flet.<PLATFORM>.cleanup].app[tool.flet.compile].app/[tool.flet.cleanup].app- empty list / empty list
The values of compile-packages and cleanup-packages are respectively determined in the following order of precedence:
--compile-packages/--cleanup-packages[tool.flet.<PLATFORM>.compile].packages/[tool.flet.<PLATFORM>.cleanup].packages[tool.flet.compile].packages/[tool.flet.cleanup].packagesFalse/True
The values of cleanup-app-files and cleanup-package-files are respectively determined in the following order of precedence:
--cleanup-app-files/--cleanup-package-files[tool.flet.<PLATFORM>.cleanup].app_files/[tool.flet.<PLATFORM>.cleanup].package_files[tool.flet.cleanup].app_files/[tool.flet.cleanup].package_filesFalse/False
Example#
Permissions#
flet build allows granular control over permissions, features, and entitlements
embedded into AndroidManifest.xml, Info.plist and .entitlements files.
See platform guides for setting specific iOS, Android and macOS permissions.
Predefined cross-platform permission bundles#
Cross-platform permissions are named and predefined bundles that apply a baseline set of platform-specific entries required for a feature. Each bundle expands into the corresponding platform-specific equivalents. This is especially useful for beginners who may be unfamiliar with the underlying platform APIs or prefer not to interact with them directly.
Only the bundles you list are applied. If you need different wording or extra
entries, set the platform-specific tables directly; those values are merged on top and
can override the bundle defaults. The examples below show the exact pyproject.toml equivalents for each bundle.
Below is a list of current bundles:
-
locationpyproject.tomlequivalent# iOS [tool.flet.ios.info] NSLocationWhenInUseUsageDescription = "This app uses location service when in use." NSLocationAlwaysAndWhenInUseUsageDescription = "This app uses location service." # macOS [tool.flet.macos.info] NSLocationWhenInUseUsageDescription = "This app uses location service when in use." NSLocationAlwaysAndWhenInUseUsageDescription = "This app uses location service." [tool.flet.macos.entitlement] "com.apple.security.personal-information.location" = true # Android [tool.flet.android.permission] "android.permission.ACCESS_FINE_LOCATION" = true "android.permission.ACCESS_COARSE_LOCATION" = true "android.permission.ACCESS_BACKGROUND_LOCATION" = true [tool.flet.android.feature] "android.hardware.location.network" = false "android.hardware.location.gps" = false -
camerapyproject.tomlequivalent# iOS [tool.flet.ios.info] NSCameraUsageDescription = "This app uses the camera to capture photos and videos." # macOS [tool.flet.macos.info] NSCameraUsageDescription = "This app uses the camera to capture photos and videos." [tool.flet.macos.entitlement] "com.apple.security.device.camera" = true # Android [tool.flet.android.permission] "android.permission.CAMERA" = true [tool.flet.android.feature] "android.hardware.camera" = false "android.hardware.camera.any" = false "android.hardware.camera.front" = false "android.hardware.camera.external" = false "android.hardware.camera.autofocus" = false -
microphonepyproject.tomlequivalent# iOS [tool.flet.ios.info] NSMicrophoneUsageDescription = "This app uses microphone to record sounds." # macOS [tool.flet.macos.info] NSMicrophoneUsageDescription = "This app uses microphone to record sounds." [tool.flet.macos.entitlement] "com.apple.security.device.audio-input" = true # Android [tool.flet.android.permission] "android.permission.RECORD_AUDIO" = true "android.permission.WRITE_EXTERNAL_STORAGE" = true "android.permission.READ_EXTERNAL_STORAGE" = true -
photo_librarypyproject.tomlequivalent# iOS [tool.flet.ios.info] NSPhotoLibraryUsageDescription = "This app saves photos and videos to the photo library." # macOS [tool.flet.macos.info] NSPhotoLibraryUsageDescription = "This app saves photos and videos to the photo library." [tool.flet.macos.entitlement] "com.apple.security.personal-information.photos-library" = true # Android [tool.flet.android.permission] "android.permission.READ_MEDIA_VISUAL_USER_SELECTED" = true
Resolution order#
Its value is determined in the following order of precedence:
--permissions[tool.flet].permissions(type: list of strings)[]
Example#
Build template#
flet build creates (and reuses) a Flutter project under <app_root>/build/flutter using a
cookiecutter template from the flet-dev/flet-build-template
repository. The version of the template used is determined by the
template reference option.
The cached project is refreshed when template inputs change or when you pass
--clear-cache.
Template Source#
Defines the location of the cookiecutter build-template to be used.
Supported values include:
- A GitHub repository using the
gh:prefix (e.g.,gh:org/template) - A full Git URL (e.g.,
https://github.com/org/template.git) - A local directory path
Resolution order#
Its value is determined in the following order of precedence:
--template[tool.flet.template].url"gh:flet-dev/flet-build-template"
Example#
Template Reference#
Defines the branch, tag, or commit to check out from the template source.
Resolution order#
Its value is determined in the following order of precedence:
--template-ref[tool.flet.template].ref<flet_version>
Example#
Template Directory#
Defines the relative path to the cookiecutter template. If template source is set, the path is treated as a subdirectory within its root; otherwise, it is relative to the template root.
Resolution order#
Its value is determined in the following order of precedence:
--template-dir[tool.flet.template].dir- root of the template source
Example#
Additional flutter build Arguments#
During the flet build process, flutter build command gets called internally to
package your app for the specified platform. However, not all flutter build
arguments are exposed or usable through the flet build command directly.
For possible flutter build arguments, see Flutter docs
guide, or run flutter build <target_platform> --help.
Important
Passing additional flutter build arguments might cause unexpected behavior.
Use at your own risk, and only if you fully know what you're doing!
Resolution order#
Its value is determined in the following order of precedence:
--flutter-build-args(can be used multiple times)[tool.flet.<PLATFORM>.flutter].build_args[tool.flet.flutter].build_args
Example#
Flutter dependencies#
When you run flet build, Flet generates a Flutter shell project and then
updates its pubspec.yaml using values from pyproject.toml.
Use:
[tool.flet.flutter.pubspec.dependencies]for normal package declarations. (Dart docs)[tool.flet.flutter.pubspec.dependency_overrides]when you must force a version or source, for example, a local path or Git fork. (Dart docs)
Values follow standard Pub dependency syntax, expressed in TOML.
Note
- If the same package appears in both
pyproject.tomland the resultingpubspec.yaml, the value frompyproject.tomlwins. - Important: In most cases, you usually do not need to add/override Flutter dependencies. We recommend doing it only if you fully know what you are doing, as it can lead to unexpected behavior.
Example#
[tool.flet.flutter.pubspec.dependencies] # or [tool.flet.flutter.pubspec.dependency_overrides]
# Version
pkg_1 = "^1.2.3"
# Local path
pkg_2 = { path = "../pkg_2" }
# Git (short form)
pkg_3 = { git = "https://github.com/org/pkg_3.git" }
# Git (expanded form: URL + ref + subdirectory)
pkg_4 = { git = { url = "https://github.com/org/mono_repo.git", ref = "main", path = "packages/pkg_4" } }
# Hosted source
pkg_5 = { hosted = { name = "pkg_5", url = "https://pub.dev" }, version = "^1.0.0" }
# SDK package (dependencies only; typically not used in dependency_overrides)
flutter_test = { sdk = "flutter" }
Verbose logging#
The -v (or --verbose) and -vv flags
enable detailed output from all commands during the flet build process.
Use -v for standard/basic verbose logging, or -vv for even more detailed
output (higher verbosity level). If you need support,
we may ask you to share this verbose log.
Console output#
In packaged apps (flet build output), all output from your Python code such as
print() statements, sys.stdout.write() calls, and messages from the Python
logging module is redirected to a console.log file. The full path to this file is available via
StoragePaths.get_console_log_filename() or the
FLET_APP_CONSOLE environment variable.
Note: FLET_APP_CONSOLE is only set in production builds;
in development runs, output stays in your terminal.
The log file is written in an unbuffered manner, allowing you to read it at any point in your Python program using:
import os
import flet as ft
async def main(page: ft.Page):
log_file = await ft.StoragePaths().get_console_log_filename()
# or
# log_file = os.getenv("FLET_APP_CONSOLE")
with open(log_file, "r") as f:
logs = f.read()
page.add(ft.Text(logs)) # display on UI
ft.run(main)
If your program calls sys.exit(100), the complete log will automatically be shown in a scrollable window.
This is a special "magic" exit code for debugging purposes:
Calling sys.exit() with any other code will terminate the app without displaying the log.
Continuous Integration/Continuous Deployment (CI/CD)#
You can use flet build command in your CI/CD pipelines to automate
the build and release process of your Flet apps.
GitHub Actions#
The below example shows how to use flet build in a GitHub Actions workflow.
It builds the app for all platforms and uploads the resulting artifacts to the workflow run.
You could further customize/tailor it to best fit your specific needs.
name: Build Flet App
on:
push:
pull_request:
workflow_dispatch:
env:
UV_PYTHON: 3.12 # Python version
PYTHONUTF8: 1
# https://docs.flet.dev/publish/
BUILD_NUMBER: 1
BUILD_VERSION: 1.0.0
# https://docs.flet.dev/reference/environment-variables
FLET_CLI_NO_RICH_OUTPUT: 1
jobs:
build:
name: Build ${{ matrix.name }}
runs-on: ${{ matrix.runner }}
strategy:
fail-fast: false
matrix:
include:
# -------- Desktop --------
- name: linux
runner: ubuntu-latest
build_cmd: "flet build linux --yes --verbose --build-number=$BUILD_NUMBER --build-version=$BUILD_VERSION"
artifact_path: build/linux
needs_linux_deps: true
- name: macos
runner: macos-latest
build_cmd: "flet build macos --yes --verbose --build-number=$BUILD_NUMBER --build-version=$BUILD_VERSION"
artifact_path: build/macos
needs_linux_deps: false
- name: windows
runner: windows-latest
build_cmd: "flet build windows --yes --verbose --build-number=$BUILD_NUMBER --build-version=$BUILD_VERSION"
artifact_path: build/windows
needs_linux_deps: false
# -------- Android --------
- name: aab
runner: ubuntu-latest
build_cmd: "flet build aab --yes --verbose --build-number=$BUILD_NUMBER --build-version=$BUILD_VERSION"
artifact_path: build/aab
needs_linux_deps: false
- name: apk
runner: ubuntu-latest
build_cmd: "flet build apk --yes --verbose --build-number=$BUILD_NUMBER --build-version=$BUILD_VERSION"
artifact_path: build/apk
needs_linux_deps: false
# -------- iOS --------
- name: ipa
runner: macos-latest
build_cmd: "flet build ipa --yes --verbose --build-number=$BUILD_NUMBER --build-version=$BUILD_VERSION"
artifact_path: build/ipa
needs_linux_deps: false
# -------- Web --------
- name: web
runner: ubuntu-latest
build_cmd: "flet build web --yes --verbose"
artifact_path: build/web
needs_linux_deps: false
steps:
- name: Checkout repository
uses: actions/checkout@v4
- name: Setup uv
uses: astral-sh/setup-uv@v6
- name: Install Linux dependencies
if: matrix.needs_linux_deps
shell: bash
run: |
sudo apt update --allow-releaseinfo-change
sudo apt-get install -y --no-install-recommends \
clang \
ninja-build \
libgtk-3-dev \
libasound2-dev \
libmpv-dev \
mpv \
libgstreamer1.0-dev \
libgstreamer-plugins-base1.0-dev \
libgstreamer-plugins-bad1.0-dev \
gstreamer1.0-plugins-base \
gstreamer1.0-plugins-good \
gstreamer1.0-plugins-bad \
gstreamer1.0-plugins-ugly \
gstreamer1.0-libav \
gstreamer1.0-tools \
gstreamer1.0-x \
gstreamer1.0-alsa \
gstreamer1.0-gl \
gstreamer1.0-gtk3 \
gstreamer1.0-qt5 \
gstreamer1.0-pulseaudio \
pkg-config \
libsecret-1-0 \
libsecret-1-dev
sudo apt-get clean
- name: Build app
shell: bash
run: |
uv run ${{ matrix.build_cmd }}
- name: Upload Artifact
uses: actions/upload-artifact@v5.0.0
with:
name: ${{ matrix.name }}-build-artifact
path: ${{ matrix.artifact_path }}
if-no-files-found: error
overwrite: false