Real first-time submission pain points and feature gaps after shipping an app with asc

[brandontan]

We just used asc end-to-end to ship a real iOS app to review, and it got us very close. Thank you — it saved a lot of time.

We also found a few concrete gaps where the flow still had to fall back to App Store Connect web UI. These are the main things that would make the submission path materially smoother.

What worked well

• Build upload and validation
• Metadata and screenshot automation
• Review details updates
• Privacy web tooling exists and was ultimately helpful
• Final asc submit create succeeded once the Apple-side blockers were cleared

Main gaps we hit

1. First-time app availability cannot be initialized from CLI

asc pricing availability set only updates an existing availability record.
For a brand new app, there is no record yet, so the command fails and the user has to open App Store Connect and click through the initial availability setup manually.

What would help:

• asc pricing availability init or similar
• or make asc pricing availability set auto-fallback to the web workflow when no availability exists
• or at minimum, make the error message explicitly say this is a first-time bootstrap limitation and point to the exact ASC page

2. First-time subscription attachment is still too manual / unclear

For a first app submission with first-time subscriptions, the CLI warns that subscriptions are READY_TO_SUBMIT and must be attached from the app version page. That is accurate, but in practice it leaves the user guessing whether the version page state is actually sufficient.

What would help:

• an explicit asc web review attach-subscriptions workflow
• or asc submit preflight that verifies the subscriptions are truly attached to the version page, not just READY_TO_SUBMIT
• or a stronger explanation in the warning about the exact required web action

3. App Privacy publish state should be surfaced earlier and more loudly

We were able to get all the way to asc submit create, and only then got blocked by:

• You must have published answers to your app's data usages.

The asc web privacy tooling existed, but the failure surfaced very late in the process.

What would help:

• make asc submit preflight fail early if App Privacy has not been published
• surface a dedicated blocking check in asc validate
• print the exact remediation command sequence, for example:
  • asc web privacy pull
  • asc web privacy apply
  • asc web privacy publish

4. Review details for Sign in with Apple-only apps are awkward

Our app uses Sign in with Apple for review access, and the API-side review details flow still effectively pushed us toward filling placeholder username/password fields because of demoAccountRequired-style validation behavior.

What would help:

• a first-class review-details mode for SIWA-only apps
• support for a clean “Sign in with Apple only; no demo credentials” reviewer path
• clearer docs around when username/password are truly required vs when notes are sufficient

5. Better “submission readiness” aggregation would help a lot

We ended up checking:

• availability
• subscription attachment
• app privacy published state
• review details completeness
• build compliance
• version state

individually across CLI + web.

What would help:

• one command that answers: “Can I submit this app right now?”
• and if not, prints a blocking checklist grouped by:
  • API-fixable
  • web-session-fixable
  • truly manual Apple-only

Ideal future workflow

For a first-time app submission, it would be amazing if the CLI could support something like:

• asc submit preflight --deep
• asc web bootstrap-first-review --app <id>
• asc submit create --include-first-review-subscriptions

Even if some of those still use web-session internals, having one guided path would be much better than discovering the blockers one by one.

Overall

asc was still very useful, and we did successfully get the app to WAITING_FOR_REVIEW.

These are not theoretical complaints — they came directly from a real first-time App Store submission flow. If helpful, I can also turn this into a more structured issue list with exact commands / stderr from each blocker.

[rudrankriyam]

Thank you so much for this! Fixing these will make the asc cli better for everyone!!

[rudrankriyam]

@brandontan if it is possible can you refer to that thread/conversation with your agent and use asc snitch to create issues? Your agent has more context on what went wrong and how it would want the flow to be so I can fix them better

[brandontan]

ok... will do thanks .. sorry for late response

[andresdefi]

adding to this, it would be nice to have "a direct command for the App Privacy (nutrition labels) section", currently it must be done manually through ASC

[rudrankriyam]

It is there via web command; did you try it or asked your agent?

[brandontan]

Following up with a more concrete repro around subscriptions ... state=MISSING_METADATA, because I now have a case where the remaining missing field is not obvious from asc validate subscriptions.

Context

• App: 6760935380 (app.brandontan.anu)
• Subscription group: 21989617 (Anu Pro)
• Monthly subscription: 6760935267 (app.brandontan.anu.ios.premium.monthly)
• Annual subscription: 6760935638 (app.brandontan.anu.ios.premium.annual.v2)
• asc version: 0.45.2

What I fixed already in ASC

1. Added subscription group localization:
   • asc subscriptions groups localizations create --group-id 21989617 --locale en-US --name 'Anu Pro'
2. Confirmed both subscription localizations exist:
   • asc subscriptions localizations list --subscription-id 6760935267 --output json
   • asc subscriptions localizations list --subscription-id 6760935638 --output json
3. Confirmed price records exist:
   • monthly summary shows $14.99
   • annual summary shows $129.99
4. Confirmed availability exists in USA for both subscriptions:
   • asc subscriptions pricing availability available-territories --availability-id 6760935267 --output json
   • asc subscriptions pricing availability available-territories --availability-id 6760935638 --output json
5. Uploaded App Review screenshots for both subscriptions.

Current result

• asc validate subscriptions --app 6760935380 --output markdown
  still returns only 4 warnings:
• 2x subscriptions.images.recommended (promotional image missing, which seems non-blocking)
• 2x subscriptions.review_readiness.needs_attention because both subscriptions are still MISSING_METADATA

What is hard to diagnose
The validator no longer points to a concrete missing field after the group localization was fixed. At this point:

• group localization exists
• subscription localizations exist
• prices exist
• availability exists
• review screenshots exist
• but asc subscriptions get --id ... still shows state: MISSING_METADATA

Practical impact
On device, StoreKit still returns no products for these real product IDs, so the app cannot show live subscription pricing. We updated the app to stop showing fake fallback prices and instead show Price unavailable, but the remaining Apple-side cause is still opaque.

Separate but possibly related signal

• asc status --app 6760935380 --output json shows app health red with No builds found for this app.
• I do not know whether that is a separate blocker, or related to why the subscriptions never leave MISSING_METADATA.

Request / feature gap
It would be really useful if asc validate subscriptions (or a new diagnostics command) could surface the exact unresolved relationships/fields behind MISSING_METADATA once the obvious checks pass.

For example, something like:

• review screenshot attached? yes/no
• group localization attached? yes/no
• subscription localization attached? yes/no
• price record attached? yes/no
• territory availability attached? yes/no
• build/version linkage required? yes/no/unknown
• introductory offer / trial config missing? yes/no
• review submission state missing? yes/no

Right now the CLI gets me very close, but once the easy metadata is fixed I still have to guess what Apple thinks is incomplete.

[rudrankriyam]

On it!

[brandontan]

thanks!

[rudrankriyam]

This has been addressed in 0.45.3 released yesterday! Thank you so much for your efforts! Really appreciate it

[brandontan]

Following up with a focused sandbox-tester repro.

I upgraded to asc 0.45.4 and checked the latest sandbox command surface plus the embedded schema.

Current CLI surface:

• asc sandbox list
• asc sandbox view
• asc sandbox update
• asc sandbox clear-history

Current schema evidence:

• GET /v2/sandboxTesters
• PATCH /v2/sandboxTesters/{id}
• POST /v2/sandboxTestersClearPurchaseHistoryRequest
• no POST /v2/sandboxTesters

So today this looks blocked by the official App Store Connect API surface, not only by a missing CLI subcommand.

I filed a focused issue for this here: #1212
#1212

Request-wise, I think the best next step would be one of:

1. document this limitation explicitly in asc sandbox --help / docs, with the exact fallback to App Store Connect web UI
2. add an experimental unofficial web-session workflow for sandbox tester creation if you want to support it outside the official API path

Practical reason this matters: for StoreKit testing you often need multiple clean sandbox testers, e.g. one monthly-first tester and one annual-first tester, and right now that still requires leaving the CLI.