ASC ad hoc distribution

Use the experimental asc distribute workflow to turn an existing iOS archive into a private, verified install link for registered devices. Use TestFlight or the App Store release skills instead when the build should go through Apple-hosted distribution.

Confirm the installed contract before acting:

asc distribute --help
asc distribute plan --help
asc distribute apply --help
asc distribute resume --help
asc distribute status --help
asc distribute verify --help

Choose the workflow

• Use plan -> apply -> resume/status -> verify for an end-to-end, hash-authorized run starting from an .xcarchive.
• Use inspect -> prepare -> publish only when the caller already owns the ad hoc IPA and wants to operate the lower-level boundaries separately.

Guardrails

• Treat the distribution spec, devices file, PKCS#12 identity, password file, run state, and exact install-link artifact as private. Keep them out of Git and require owner-only permissions.
• Never put S3 credentials or presigned URLs in the distribution spec, command output, logs, issues, or chat. Use ASC_S3_ACCESS_KEY_ID, ASC_S3_SECRET_ACCESS_KEY, and optional ASC_S3_SESSION_TOKEN, or the standard AWS SDK credential chain.
• plan is read-only and may exit successfully with ready: false. Inspect the typed blockers and effects before continuing.
• apply can register missing devices, create safe App IDs and successor ad hoc profiles, write local artifacts, and publish immutable objects. Run it only after the user authorizes the exact plan hash and effect inventory.
• The orchestrated workflow supports private access to an existing S3-compatible bucket. It does not create buckets, change policies, delete old builds, install the app, or launch it.
• Input drift, an immutable-object conflict, expired signing material, or an expired private link requires a new plan. Do not force the old run forward.

Preconditions