flitz plugins

To run bundles inside your own app you embed the Flitz loader plugins in its Android and iOS builds. The plugins live in private repositories gated by the same organization license as the SDK. Three commands cover the CLI's side of that, each doing one thing:

flitz plugins configure                  # which version, and which repositories
flitz plugins credentials --write        # store the repository token locally
flitz plugins skill                      # the build-file changes to apply

All three need a credential and an active license. None of them edits your project's build files — that half is documented under Loader plugins, per platform.

How the version is resolved

The loader plugins are versioned independently of the SDK. Each published plugin version declares the lowest SDK tag it supports, and the CLI picks the newest plugin version whose floor is at or below your project's pinned tag. When the current directory has no flitz.yaml, the target is whatever tag latest resolves to.

Resolution is recommend-only. The CLI never reads your Gradle, Podfile, or SwiftPM files, so it cannot report installed-versus-recommended drift; it tells you what the project should use for its pinned SDK. flitz status shows the same resolution as its plugin_version row.

When no published plugin version supports the pinned tag, the command fails with a configuration error (exit 1) naming the target tag and the lowest published floor, and hints at flitz sdk use <floor-tag> or newer.

configure

flitz plugins configure

Loader plugin version: <version>
Resolved for SDK tag:  <tag>

Repositories:
  Maven      https://…
  SwiftPM    https://…
  CocoaPods  https://…

  → run `flitz plugins skill` for the build-file changes to apply

It never prints the repository token.

--version-only

For a build script, --version-only prints the bare resolved version on stdout and nothing else:

PLUGIN_VERSION="$(flitz plugins configure --version-only)"

--json

flitz plugins configure --json

{
  "version": "<version>",
  "target_sdk_tag": "<tag>",
  "repositories": { "maven": "https://…", "swift": "https://…", "cocoapods": "https://…" }
}

The token is not in the document. On failure no JSON is emitted; check the exit status first.

credentials

flitz plugins credentials

With no flag, prints what would be stored and where and writes nothing — the command has no side effect until you ask for one:

Flitz loader-plugin credentials — nothing was written. Re-run with
`--write` to store them, or `--print-token` to output just the token.

Gradle reads the entitlement token from /home/you/.gradle/gradle.properties:

  flitzMavenToken=…

CocoaPods and SwiftPM read it from /home/you/.netrc:

  machine …
    login token
    password …

The token goes into your developer-local stores only. Never write it into a committed file — the repository URLs belong in your build files, the token does not. flitz status reports whether the stores hold one (plugin_credentials).

skill

flitz plugins skill

Prints a complete prompt, on stdout, describing exactly which repository and dependency lines to add to your Android and iOS build files — with the resolved plugin version and the SDK tag already substituted, so there are no placeholders to fill in. Hand it to a coding agent, or read it yourself. The repository token is never part of it.

The prompt is the command's result, so flitz plugins skill > prompt.txt captures it cleanly. It covers: the Android Gradle plugin and per-flavor activation, the iOS CocoaPods or SwiftPM dependency, the AppDelegate and SceneDelegate changes, the Info.plist entries for the flitz:// scheme and camera permission, and the dual-mode gating that keeps your normal builds loader-free.

Related

• Loader plugins overview — what the loader does and what the host must provide.
• Android and iOS — the build-file integration the prompt describes.
• Compatibility — why the host and every bundle must be built against the same SDK tag.