Overview
The editor holds your App Store and Google Play listing drafts in Spek. One form per market, with the store's own character limits enforced as you type, and a draft that is yours until you publish it.
Applying an agent proposal writes into this draft. Nothing here reaches the store until you publish. See publishing.
Tabs
For App Store listings, there are five tabs, and the page heading is whichever one is open. Each tab has its own URL, so reloading, sharing the link, or using Back returns you to the same section.
- Metadata is the name, the subtitle and the keywords field.
- Listingis the longer copy: description, what's new, promotional text, copyright and the three URLs.
- Screenshots is the image set per device family. See screenshots.
- Bulk edits one field across many markets at once.
- Version is the build and release state. The build picker only lists binaries whose marketing version matches the version you are editing.
The language picker in the header decides which market you are editing. Every tab except Version is per market.
Saving
The editor saves your draft as you work and reports its state in one line above the form: Unsaved changes while you are typing, Saving… in flight, then Saved. A failure says Save failed and keeps your text.
Saving is not publishing. A saved draft is still only in Spek. There is no discard-changes control: the draft stays until you publish or edit the field again.
Live values
Next to the tab row, a Draft / Liveswitch flips the whole page between your working copy and App Store Connect's own copy. Draft is the editable version you work in. Live shows what is in App Store Connect right now — the synced baseline your draft starts from — read-only, because a change reaches the store only through publishing.
The two views are a diff: a field that differs between Draft and Live is a change you have not published yet, and publishing clears the draft so the two match again. Switching never loses an edit: the draft keeps saving behind the Live view, and you return exactly where you left off. The released store page can lag App Store Connect until Apple processes a change.
Conflicts
If a field changed on the store after you started editing, Spek keeps both values and waits. Ready for review opens a pop-up where you choose which value to keep, then continue.
Reviewing shows both values side by side so you choose which to keep. This is the same problem an agent proposal hits when it goes stale.
Bulk editing
The Bulk tab edits one field across every market at once, which is what you want after a rename or a positioning change. Each cell saves to your Spek draft, the same way Metadata and Listing do. Nothing reaches the store until you publish.
On the App Store, nine fields are available: Name, Subtitle, Description, Keywords, Promotional text, What's new, Marketing URL, Support URL and Privacy policy URL.
Common questions
Where did my agent proposal go after I applied it?
Into the draft, in the field it belongs to. Open the editor for that market and it is there, ready to publish.
Check the same app, market and field in the Editor, and read the save state. You can revise accepted wording there before publishing. Review the complete locale draft so a useful field-level suggestion does not create repetition or an inconsistent product promise elsewhere in the listing.
Why can I not edit anything?
The version may be locked because it is already submitted or live. The editor offers to create a new version when that is the case.
Why can I not pick an older build?
Apple requires a new build for each App Store version. The Version tab only lists builds whose marketing version matches the version you are editing. Upload that build with Xcode or Transporter; Spek cannot upload the binary for you.
How should I check a draft before publishing?
Review the selected app and locale, then read the edited fields together rather than as isolated sentences. Check product accuracy, brand wording, local language, field limits and the destination of any URLs. Confirm that the draft has saved successfully. Use the publishing review to inspect the values that differ from the provider's current record and resolve any reported conflicts or prerequisites. A saved draft is preparation for a store action, so its Saved state should not be reported to colleagues as a completed public release.
When should I use Bulk instead of editing one locale?
Bulk is useful when the same kind of field needs attention across several markets, such as a support URL or a product naming change. Each locale can still need different wording, and a broad edit deserves a review of every affected value. Use the individual locale view when the decision depends heavily on the local listing context. Bulk saves drafts just like the other Editor surfaces; it does not make a multi-market change public without the separate publishing workflow.
Why can the Live view differ from the public store page?
The Live view represents the synchronized provider record used as the draft baseline. App Store Connect can hold an editable or reviewed version before the corresponding public store page changes. Check the version and release state when comparing the two. If the provider record changed outside Spek, allow the relevant read to refresh and inspect any conflict during publishing. Treat the public listing, the provider's editable record and your Spek draft as different stages rather than assuming that all three update at the same moment.
What should I do if a draft save reports a failure?
Read the message next to the save state and keep the text you were working on available while you investigate. Confirm the selected app and locale before retrying or moving to another field. A failed save is different from a provider rejection during publishing: the first concerns your Spek draft, while the second concerns sending a change to the store. If the problem persists, report the affected field, locale, approximate time and visible message without including account credentials or private customer data.