Flightlinev0.7.0

Features

Three layers. Every surface.

A full API CLI at the bottom, state as code on top of it, preflight rules guarding both. This page is the complete map of what Flightline reads, writes, and checks; the docs carry every command and how-to.

Read the docs

The three layers

Each layer is useful alone. Together they close the loop.

Use the CLI without ever touching a state file. Add state as code when you want releases you can diff. Preflight guards both. Pink marks the layer that changes things.

  • L1

    API CLI

    Every App Store Connect surface as a terminal command. Read anything, write most things, pipe all of it as JSON.

    $ flightline reviews summary app.tideterm.ios --output json
  • L2

    State as code

    Declare the release in state.yaml, diff it against live ASC, apply only the delta. The layer that writes.

    $ flightline apply state.yaml --confirm
  • L3

    Preflight

    Eleven rules that catch the clerical rejection causes before Apple does. Offline or live, exit codes for CI.

    $ flightline preflight app.tideterm.ios --version 2.1

Coverage

The full surface map.

Every App Store Connect surface and what Flightline does with it. White checks read and verify. Pink checks change things: CLI writes and everything drivable through state.yaml plus apply.

SurfaceReadWriteAs codePreflight
Authoring writes the config
Versions
Builds
Metadata + localizations
Screenshots11
In-App Purchases11
Age Rating
Export Compliance
Reviewer Demo·
Categories·
Pricing·
TestFlight4
Custom Product Pages11·
Observation reads the data
Apps catalog···
Sales reports···
Finance reports···
Subscription reports···
Subscription configuration2···
Customer reviews2··
Beta feedback···
Diagnostic signatures···
Performance metrics···
Analytics reports···
Privacy nutrition labels3···
  1. 1 Asset bytes (screenshots, IAP review screenshots, CPP screenshots) flow through dedicated upload verbs, not through apply. Apple’s 3-step multipart upload is structurally distinct from JSON PATCH.
  2. 2 Read-only in v1. Replying to reviews and writing subscription configuration are not yet implemented.
  3. 3 Apple’s public API does not expose appPrivacyDetails. Flightline returns a typed diagnostic explaining the gap; manage privacy labels in the portal until Apple ships the endpoint.
  4. 4 TestFlight as code is partial. Beta groups and testers are state as code; public link configuration and beta-review submission are CLI verbs.

Boundaries

What Flightline doesn’t do.

Six functional boundaries. None of them are bugs; all of them are explicit choices, and the tool says so when you hit one.

  • Submit for App Store Review

    Review submission is intentionally manual. Preflight tells you whether the version is submission-ready; you click Submit in the portal when you are sure. TestFlight beta-review submission is a separate, lower-stakes verb that is wired.

  • Reply to customer reviews

    Reading reviews is fully covered. Replying is read-only in v1 and will land when there is a real product reason to wire it.

  • Generate screenshots

    Flightline uploads the screenshots you provide. Bring your own renderer; asset bytes flow through flightline screenshots upload, configuration flows through flightline apply.

  • Replace Fastlane or xcodebuild

    Compilation, signing, and binary upload still belong toxcodebuild, Xcode Cloud, or Fastlane. Point your build at a version with builds attach; Flightline takes it from there.

  • Manage privacy nutrition labels

    Apple’s public API does not expose appPrivacyDetails. Flightline returns a typed diagnostic explaining the gap. When Apple ships the endpoint, this lights up.

  • Resolve reviewer-written rejection text

    Reviewer messages live in the Resolution Center web surface, not the public API. flightline rejection reports every API-visible state field; the actual reviewer text is in the portal.

Install

One binary. Zero ceremony.

go install github.com/ul0gic/flightline@latest

Requires Go 1.26+ and a Mac · MIT · no SaaS, no telemetry, no accounts