starred/App-Store-Connect-CLI

Fork 0

mirror of https://github.com/rudrankriyam/App-Store-Connect-CLI.git synced 2026-04-25 23:55:51 +03:00

[GH-ISSUE #561] Apps: add asc apps create (new app record) - feasibility + UX #152

New issue

Closed

opened 2026-02-26 21:33:48 +03:00 by kerem · 1 comment

kerem commented

2026-02-26 21:33:48 +03:00

Owner

Originally created by @rudrankriyam on GitHub (Feb 16, 2026).
Original GitHub issue: https://github.com/rudrankriyam/App-Store-Connect-CLI/issues/561

Summary

Users want to create a brand-new App Store Connect app record from the CLI.

Add a first-class entrypoint:

asc apps create --name "My App" --bundle-id "com.example.app" --sku "MYAPP001" --primary-locale "en-US"

This issue tracks:

feasibility using officially supported APIs
the best UX if creation is not supported

Why this matters

App creation is a high-friction, high-frequency onboarding step:

new apps (client work, side projects, new bundles)
multi-target apps (iOS + macOS)
CI bootstrap flows where everything after creation is automated

asc already covers post-create automation very well (asc app-setup, signing, metadata sync, TestFlight, submissions). The missing piece is the initial app record.

Current state (verified)

The public OpenAPI snapshot does not include POST /v1/apps.
- docs/openapi/paths.txt includes GET /v1/apps and PATCH /v1/apps/{id}, but no create endpoint.
asc apps has no create subcommand (list/get/update/etc only).
Prior work explicitly focused on post-create automation using supported public APIs.

Constraints

Public API limitation

If Apple does not expose app creation via the App Store Connect public API, asc cannot implement true app creation while remaining public-API-only.

Authentication model

asc is API-key/JWT driven. App Store Connect’s website uses cookie + CSRF protected calls.
If app creation requires web-only endpoints (commonly observed under /iris/ or /ra/ on appstoreconnect.apple.com), that implies:

different auth material (session cookie instead of JWT)
higher breakage risk
different security posture (session data is extremely sensitive)

Proposed UX (two-phase)

Phase 1: “Honest” create command with guided output

If creation is not possible via the public API, still add:

asc apps create --name ... --bundle-id ... --sku ... --primary-locale ...

Behavior:

exit with usage-style guidance (non-zero)
print a clear explanation: app creation isn’t supported via public API
emit a machine-readable JSON payload describing the intended app record
optionally print an --open URL that takes the user to the correct App Store Connect UI page

This preserves a consistent automation surface: pipelines/agents can generate the desired spec and then proceed with asc app-setup ... once the app exists.

Phase 2: Feasibility spike (explicit decision)

Re-verify Apple docs (public) that app creation is unsupported.
Confirm there is no alternative official endpoint in the current OpenAPI snapshot.
Decide whether asc will ever support web-session-based operations.

If (and only if) the project decides to support an explicitly gated, experimental web-session mode, design it with very strict guardrails:

opt-in flag (e.g., --experimental-web-session)
session provided via env var only (never printed; never stored by default)
explicit disclaimers in help text + docs

Detailed implementation plan (Phase 1)

Add apps create subcommand stub:
- validate required flags (--name, --bundle-id, --sku, --primary-locale)
- print actionable guidance to stderr
- output JSON “create spec” to stdout
- include next-step commands:
  - asc apps list --bundle-id ... (find the new app id)
  - asc app-setup ... (post-create setup)
Add cmdtests asserting:
- exit code is usage-style (2)
- message is explicit and non-ambiguous
- JSON spec is deterministic

Acceptance criteria

asc apps create --help exists and documents the limitation clearly.
Running asc apps create ... produces deterministic output suitable for automation.
Command does not attempt undocumented network calls unless a future explicit opt-in design is accepted.
Tests cover exit behavior + output contract.

Originally created by @rudrankriyam on GitHub (Feb 16, 2026). Original GitHub issue: https://github.com/rudrankriyam/App-Store-Connect-CLI/issues/561 ## Summary Users want to create a brand-new App Store Connect app record from the CLI. Add a first-class entrypoint: ```bash asc apps create --name "My App" --bundle-id "com.example.app" --sku "MYAPP001" --primary-locale "en-US" ``` This issue tracks: 1) feasibility using officially supported APIs 2) the best UX if creation is not supported ## Why this matters App creation is a high-friction, high-frequency onboarding step: - new apps (client work, side projects, new bundles) - multi-target apps (iOS + macOS) - CI bootstrap flows where everything after creation is automated `asc` already covers *post-create* automation very well (`asc app-setup`, signing, metadata sync, TestFlight, submissions). The missing piece is the initial app record. ## Current state (verified) - The public OpenAPI snapshot does not include `POST /v1/apps`. - `docs/openapi/paths.txt` includes `GET /v1/apps` and `PATCH /v1/apps/{id}`, but no create endpoint. - `asc apps` has no `create` subcommand (list/get/update/etc only). - Prior work explicitly focused on **post-create automation** using supported public APIs. ## Constraints ### Public API limitation If Apple does not expose app creation via the App Store Connect public API, `asc` cannot implement true app creation while remaining public-API-only. ### Authentication model `asc` is API-key/JWT driven. App Store Connect’s website uses cookie + CSRF protected calls. If app creation requires web-only endpoints (commonly observed under `/iris/` or `/ra/` on appstoreconnect.apple.com), that implies: - different auth material (session cookie instead of JWT) - higher breakage risk - different security posture (session data is extremely sensitive) ## Proposed UX (two-phase) ### Phase 1: “Honest” create command with guided output If creation is not possible via the public API, still add: ```bash asc apps create --name ... --bundle-id ... --sku ... --primary-locale ... ``` Behavior: - exit with usage-style guidance (non-zero) - print a clear explanation: app creation isn’t supported via public API - emit a machine-readable JSON payload describing the intended app record - optionally print an `--open` URL that takes the user to the correct App Store Connect UI page This preserves a consistent automation surface: pipelines/agents can generate the desired spec and then proceed with `asc app-setup ...` once the app exists. ### Phase 2: Feasibility spike (explicit decision) - [ ] Re-verify Apple docs (public) that app creation is unsupported. - [ ] Confirm there is no alternative official endpoint in the current OpenAPI snapshot. - [ ] Decide whether `asc` will *ever* support web-session-based operations. If (and only if) the project decides to support an **explicitly gated, experimental** web-session mode, design it with very strict guardrails: - opt-in flag (e.g., `--experimental-web-session`) - session provided via env var only (never printed; never stored by default) - explicit disclaimers in help text + docs ## Detailed implementation plan (Phase 1) - [ ] Add `apps create` subcommand stub: - [ ] validate required flags (`--name`, `--bundle-id`, `--sku`, `--primary-locale`) - [ ] print actionable guidance to stderr - [ ] output JSON “create spec” to stdout - [ ] include next-step commands: - `asc apps list --bundle-id ...` (find the new app id) - `asc app-setup ...` (post-create setup) - [ ] Add cmdtests asserting: - [ ] exit code is usage-style (2) - [ ] message is explicit and non-ambiguous - [ ] JSON spec is deterministic ## Acceptance criteria - [ ] `asc apps create --help` exists and documents the limitation clearly. - [ ] Running `asc apps create ...` produces deterministic output suitable for automation. - [ ] Command does not attempt undocumented network calls unless a future explicit opt-in design is accepted. - [ ] Tests cover exit behavior + output contract.

kerem

2026-02-26 21:33:48 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-02-26 21:33:49 +03:00

Author

Owner

@rudrankriyam commented on GitHub (Feb 16, 2026):

Closing this as addressed by the asc-app-create-ui skill in the skills repo: https://github.com/rudrankriyam/app-store-connect-cli-skills/pull/3

The public API does not support app creation (POST /v1/apps does not exist). Instead, the skill drives the App Store Connect web UI via browser automation (Cursor browser MCP or equivalent). The only manual step is signing in.

Tested end-to-end twice — both apps verified via asc apps get.

@rudrankriyam commented on GitHub (Feb 16, 2026): Closing this as addressed by the `asc-app-create-ui` skill in the skills repo: https://github.com/rudrankriyam/app-store-connect-cli-skills/pull/3 The public API does not support app creation (`POST /v1/apps` does not exist). Instead, the skill drives the App Store Connect web UI via browser automation (Cursor browser MCP or equivalent). The only manual step is signing in. Tested end-to-end twice — both apps verified via `asc apps get`.