Overview
Publishing sends your draft to the App Store or Google Play. It is always yours to start. The steps below describe App Store Connect: use Ready for reviewin the Editor or the Agent inbox header, or give Agent chat an explicit publish command when your role and the app's provider prerequisites allow it. Nothing starts it on its own.
Ready for review sits in the editor header and to the right of All countries on the Agent inbox. The pop-up resolves store conflicts, a missing version, or a missing build before the final send. If there is nothing to send it says so rather than making a call.
Preflight
Before anything is sent, Spek checks the draft against what the store will accept: field limits, required values, and whether the version is in a state that allows an edit at all.
A fixable gap (a store conflict, a missing version, or a missing build) stays in the pop-up so you can finish it there. An unfixable failure stops the send and says what to fix. Nothing has been sent at that point.
Chat performs the same current-store, draft-revision and conflict checks on the server. Naming one locale sends that locale; naming several binds the exact set into one publish operation; leaving locale scope out means every pending locale for the selected app.
What publishing sends
Only the fields that differ from the store, for the markets you selected. For App Store Connect, publishing from the Editor writes those drafts onto the editable version in App Store Connect and stops — you submit the version for review in App Store Connect yourself, where Apple lists anything still missing. Agent chat can also hand the eligible current version to App Review in the same run. Spek does not publish the app binary itself.
If some markets succeed and others do not, it reports Publish finished with errors and names the ones that failed, rather than rolling everything back.
Submitting for review
An iOS listing publish opens with Ready for review. The pop-up lists every field about to change with its value before and after, then Publish to App Store Connectstages the approved changes on the editable version. Nothing goes to Apple's review from the pop-up — you submit the version in App Store Connect when you are ready, and Apple shows there anything the submission still needs. The keyword field is shown word by word — the words leaving in red, the words joining in green — so a two-word change is not buried in a long comma list. If Apple keeps other items in the same draft review submission, those staged events, product pages or tests go to review with the version when you submit it.
Common questions
Can the agent publish for me?
Agent chat can publish after your explicit interactive command when your role and the app's provider prerequisites allow it. The agent never publishes store content on its own. See what the agent will never do.
Name the exact app and locale scope when giving an interactive instruction, and inspect the reported provider result afterward. A research request or discussion of a possible release is not the same instruction. Store version, permission and other prerequisites still govern what can be sent.
Publishing failed for one market only.
That market's value was rejected by the store, usually a length or a required-field problem. The others went through; fix that one and publish again.
The store response was uncertain. Should I retry?
In Agent chat, use Reconcile. In Editor, opening publish again checks the same durable operation against the store before any new write. Spek replays an already-finished result or keeps an unresolved mismatch quarantined; it does not blindly send the same mutation again. Retry appears only when repeating the request is known to be safe.
Can I undo a publish?
Not from Spek. Edit the values back and publish again, the same way you would in the store console.
What is the difference between a draft, a provider update and a public release?
A draft is the working content saved in Spek. A successful publishing action sends the approved changes to the relevant provider record. The store's review and release process determines when that content becomes public. In the App Store Editor flow, writing the editable version does not itself submit that version to App Review. An explicitly authorized supported chat publish can include submission. Read the exact action and result so your team reports the correct stage instead of describing every successful save as a live release.
How should I prepare a publish across several locales?
Review each locale's final draft and identify the exact set you intend to send. Check shared links, local wording and any version or build requirements before the final action. A successful result for one market should not be used as proof that every market succeeded; read the per-market outcome if errors are reported. Keep a clear record of the scope and time so colleagues can compare the provider's current values with the intended change and investigate any rejected locale without redoing successful work unnecessarily.
What should I check when the public listing has not changed yet?
Start with the recorded publishing outcome and the relevant App Store Connect version or submission state. A provider can hold updated metadata before it appears on the public store page. Confirm that you are viewing the same app, storefront and locale, and distinguish a delayed public refresh from an actual failed write. If the operation is uncertain, use the available reconciliation path before attempting another publish. Repeating the action is not a reliable way to accelerate a store's review or release process.
How can I correct wording after it has been published?
Prepare the corrected value in the Editor, review the current provider state and use the normal publishing workflow again when the store permits the edit. A historical value in Changelog is useful reference material, but opening it does not roll the listing back. Some fields or version states may require additional store steps. Check the full scope of the correction, especially if several locales used the same wording, and verify the new result rather than assuming that an earlier successful publish guarantees the next one.