# Asc Ad Hoc Distribution

Prepare, publish, resume, and verify private iOS release-testing installs with asc...

- Repository: https://github.com/rorkai/app-store-connect-cli-skills (1119 stars)
- Category: Testing
- License: MIT
- Last updated: 2026-10-26
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add rorkai/app-store-connect-cli-skills --skill asc-ad-hoc-distribution -g -a claude-code -y`
Codex: `npx skills add rorkai/app-store-connect-cli-skills --skill asc-ad-hoc-distribution -g -a codex -y`
Cursor: `npx skills add rorkai/app-store-connect-cli-skills --skill asc-ad-hoc-distribution -g -a cursor -y`
Gemini CLI: `npx skills add rorkai/app-store-connect-cli-skills --skill asc-ad-hoc-distribution -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add rorkai/app-store-connect-cli-skills`

## Description

Prepare, publish, resume, and verify private iOS release-testing installs with asc distribute. Use when distributing an IPA to registered devices outside TestFlight, reconciling ad hoc profiles, publishing through caller-owned S3-compatible storage, or diagnosing a resumable private distribution run.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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:

```bash
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

The rest: https://github.com/rorkai/app-store-connect-cli-skills/blob/HEAD/skills/asc-ad-hoc-distribution/SKILL.md