fastforge packages and publishes a Flutter app, and is being rewritten in Rust

A rewrite in progress, and the README says so

The most important paragraph in this repository is the warning at the top. The core of Fastforge is being rewritten in Rust, to deliver better performance, a smaller install footprint and zero runtime dependencies on the Dart SDK. The native CLI lives in apps/cli with its core libraries in crates/, and it is developed in parallel with the existing Dart packages. What that means in practice is spelled out. The current Dart-based CLI, activated with dart pub global activate fastforge, continues to work and receives bug fixes. The Rust CLI is released as a native binary with no Dart or Flutter SDK required to run it. APIs and configuration formats are designed to remain compatible, and any breaking changes will be clearly announced. The project is also renamed, formerly Flutter Distributor, and it is now published on pub as fastforge, with a Discord, a melos badge and an all-contributors list. The audience is Flutter teams that want one tool for building, packaging and publishing, and the maintainers are candid that the tool you install today may be replaced by a different binary with the same name.

One configuration across a wide set of package formats

The feature list is one-click build across a long format matrix, and the format list is the concrete part. Android produces AAB and APK. iOS produces IPA. OpenHarmony produces HAP and APP, which is the unusual entry that tells you this is not a purely Western tool. Linux produces AppImage, DEB, RPM, Pacman and ZIP. macOS produces DMG, PKG and ZIP. Windows produces EXE, MSIX and ZIP. Web produces a ZIP. And for any platform there are custom packaging commands, plus the direct format, which is the unpacked build output, available on Linux, Windows and Web. The mobile formats are what most people need, but the desktop ones are what a team shipping a Flutter app to users on more than one platform actually needs, and the fact that DMG, PKG, EXE and MSIX are first-class rather than afterthoughts is the differentiator. The documentation is per format under docs/en/packagers, with separate pages for android, ios, ohos, linux, macos, windows and web, and a packaging page for the custom format.

Publishers cover stores, CI targets and object storage

The publisher side is broader than the packaging side, and it is the half of the tool that saves the most scripting. The supported destinations are the App Store, the AppGallery, Firebase, Firebase Hosting, FIR, GitHub Releases, Gitea and Forgejo Releases, PGYER, the Play Store, Vercel, APT and Pacman repositories, the AUR, and object storage with S3 and MinIO, Qiniu, Alibaba Cloud OSS and Tencent Cloud COS. There is also a custom publisher that runs a shell command, which is how you would target a store the tool does not know about. The design is that a release has a name and a list of jobs, and each job has a package step and a publish step, so one configuration can build an APK and an IPA and push each to a different place. This is what makes it a CI/CD citizen rather than a local utility, and the repository integrates with GitHub Actions, GitLab CI and similar, with the documentation under docs/en/publishers.

The old quick start is already marked deprecated

The quick start in the README is explicitly a legacy path. It uses the deprecated distribute_options.yaml and the release command, which the note says still work in both CLIs, while new projects should follow the getting started guide and the local workflows documentation. The legacy configuration has a variables section for your API keys, an output directory, and a list of releases, each with a name and a list of jobs, and each job has a name, a package section with a platform, a target and build_args, and a publish_to:

variables:
  PGYER_API_KEY: "your api key"
output: dist/
releases:
  - name: dev
    jobs:
      - name: release-dev-android
        package:
          platform: android
          target: apk
          build_args:
            target-platform: android-arm,android-arm64
            dart-define:
              APP_ENV: dev
        publish_to: pgyer

The build_args are the parameters supported by the flutter build command, passed through unchanged, and the note says to modify them for your project. Once the configuration is in place, the release is one command:

fastforge release --name dev

The newer shape separates the two halves into standalone commands, which is easier to script and easier to retry, since packaging and publishing no longer have to happen in the same process:

fastforge package --platform=android --targets=aab,apk
fastforge publish --path dist/your-app-1.0.0+1-android.apk --targets pgyer

New configuration lives in .fastforge, and workflows are local

The replacement for the old file is a directory. New configuration goes in .fastforge for the project, or in the home directory for machine-level settings, and new automation goes into local workflows, documented at docs/en/workflows.md. The deprecated distribute_options.yaml and the release command keep working for compatibility but get no new features, which is a clear signal about where the project is going and a clear instruction about where to put new work. The workflow model matters more than it sounds. A local workflow file is checked into the repository, which means the release steps live next to the code they release and are reviewed like code, rather than in a CI provider's web interface where they drift. The repository structure supports this. There is a packages/ directory for the Dart packages, apps/ for the applications including the native CLI and the studio web and API apps, crates/ for the Rust libraries, docs/ for the documentation in English and Simplified Chinese, examples/ with hello_world, multiple_flavors and custom_binary_name, and skills/, scripts/ and fixtures/ directories.

The Rust workspace is where the size argument is made

The Cargo workspace shows the shape of the native implementation, with crates/core, app_analyzer, app_builder, app_packager, app_publisher, dmg_maker and remote, plus a stores directory with app_store_connect, app_gallery_connect and google_play_console, and the studio crates and apps. The release profile in Cargo.toml carries a comment that is worth reading, because it explains a decision a user would otherwise feel in a download size. The CLI is shipped as a prebuilt binary through install.sh and install.ps1, so the release size is user-visible. Without the profile the binary was 30 MB, of which 7.4 MB was the symbol table, with rustc's v0 mangling making names long, plus un-deduplicated monomorphized generics, and lto with codegen-units = 1 remove most of the latter. The measured result on aarch64-apple-darwin was 30.0 MB down to 16.8 MB. Two further knobs are deliberately left off, panic = abort at 14.0 MB because it turns a panicking tokio task into a whole-process abort, and opt-level = "z" at 8.7 MB combined with abort because it trades runtime speed for size. The install and uninstall scripts sit at the repository root alongside the Cargo.lock and the melos.yaml, so the Dart and Rust halves are developed together.

Flutter only, and a deprecation window to plan around

The scope is narrow, and there is no way around it. Fastforge builds Flutter applications, so a native mobile or desktop project has no use for it, and the tool still depends on the Flutter SDK to do the actual building, since the fastforge package step passes build arguments through to the flutter build command. Removing the Dart dependency applies to running Fastforge, not to producing an app from Flutter. The second limitation is the migration itself. Two CLIs with the same name, one of which only receives bug fixes, and two configuration formats, one of which is deprecated and frozen, is the shape of a project mid transition, and the README's promise that breaking changes will be clearly announced is a promise rather than a schedule. The third is the release channel. The published tags are development builds, v0.7.0-dev.6 on 2026-10-12, v0.7.0-dev.4 on 2026-10-04 and v0.7.0-dev.2 on 2026-10-02, and the last push was on 2026-10-14, so the pace is fast and the versioning is pre-1.0. The licence is MIT with a LICENSE file in the root, which keeps the adoption decision simple, and the documentation and the project itself are published in English and Simplified Chinese.

Editorial conclusion

fastforge is worth adopting if you ship Flutter apps to more than one destination and are tired of maintaining a separate build and upload script per store, since the package and publish steps are described in one vocabulary and the format matrix is broad enough to cover desktop and web as well as mobile. It is the wrong tool if your app is not Flutter, and it is a cautious choice for a team that needs a stable interface today, because the current documentation in the README itself is deprecated and the project is in the middle of a language migration with breaking changes announced rather than scheduled. Before adopting it, decide which CLI you will use, since the Dart one only receives bug fixes, and read the native CLI documentation separately, because the two are documented in different places and the new configuration directory is not the same format as the old one.

Frequently asked questions

Official sources

1. fastforgedev/fastforge on GitHub
2. License: MIT
3. Project website
4. README
5. Releases