User Guide

Build the release packet one screen at a time.

The Apple versions keep project facts, release tasks, inventory, screenshots, privacy review, App Store Connect data, GitHub release context, CloudKit sync checks, and release packet notes in one native workspace. The Android companion focuses on opening, reviewing, editing, and exporting schema-versioned release packets.

Release Binder macOS workspace showing the sidebar, releases list, toolbar, and empty release detail area.
macOS workspace: sidebar, release list, toolbar, and detail pane.

Start here

Quick Start

Use this order when setting up a release from scratch. It keeps the binder useful without forcing you to complete every tab before you have the basic shape of the release.

  1. Create or import a project. Use New Project for manual setup, choose the project type that matches the release channel, or Import App Store Connect when an Apple app already exists in App Store Connect.
  2. Add a release. Set the release name, version, build number, tag, branch, and stage fields that matter for that channel. For App Store work, use the version/build planned for TestFlight or review.
  3. Work the tabs. Fill Overview, Checklist, Inventory, App Store, App Store Connect, GitHub, Privacy/Data-use, Dependencies, and Notes as they become known. The visible tabs adapt to the project type.
  4. Check readiness. Use the readiness sheet and release list badges to find missing required items, unverified inventory, and privacy or dependency gaps.
  5. Preview or export. Preview, copy, or export the release packet for review, archive, handoff, or publishing prep after checking that notes do not contain secrets.
Release Binder workspace with project sidebar, release list, and overview tab.
Workspace overview: project, selected release, status badge, progress counts, and Overview tab.

Android companion

Work with a release packet on Android

The Google Play version is a focused, local-only companion for schema-versioned Release Binder JSON packets. It does not reproduce the full Apple project workspace or automatically sync with iCloud.

  1. Open a packet. Choose a schema-versioned Release Binder JSON file with Android's document picker. The app validates the packet before displaying it.
  2. Review release readiness. Check the release summary, readiness findings, checklist rows, inventory facts, and channel-specific packet details.
  3. Update the version when needed. Edit the release version in the focused Android editor and review the updated packet before saving.
  4. Save JSON or Markdown. Save the validated JSON packet for another Release Binder client, or export deterministic Markdown for review, archive, or handoff.

Android files remain on the device unless you explicitly open or save them. The public Android build has no Release Binder account, custom backend, analytics, ads, AI service, or CloudKit transport.

Workspace map

UI Tour

The app uses a native split-view workspace. On wider screens, the project sidebar, release list, and release detail can sit side by side. On iPhone, you move through those same areas one screen at a time.

Project sidebar

Select the project you want to work on. This is also where you start New Project, Import App Store Connect, Setup Wizard, and Sync Status.

Release list

Select a release, scan readiness badges, add a release, duplicate an existing release, or delete a release when it is no longer needed.

Release detail

Open the tabs for the selected release. If no release is selected, the detail pane shows an empty state so you know to choose or create a release first.

Toolbar

Use the toolbar for Field Guide, Release Readiness, Setup Wizard, Sync Status, Project Settings, Add Release, Duplicate Release, and Delete Release.

Release Binder workspace showing project sidebar, release list, toolbar, release header, and tab bar.
Split view: project on the left, releases in the middle, selected-release detail on the right.

Toolbar sheets

Utilities

Toolbar utilities are short-lived sheets or helper windows. Use them when you need setup help, project-wide settings, readiness detail, or current sync context without leaving the release you are working on.

Release Binder Field Guide sheet with concise setup and readiness guidance.
Field Guide: compact in-app reminders for setup, readiness, sync, import, privacy, export, and troubleshooting.

Field Guide

Use it: Open the book icon when you need a quick reminder inside the app.

Done state: You know which tab or sheet to open next.

Release Binder Project Settings sheet showing project type, bundle identifier, repository URL, and platform notes.
Project Settings: project type and identifiers drive templates, tabs, readiness, and export labels.

Project Settings

Use it: Edit the project name, project type, bundle ID or identifier, repository URL, and platform notes.

Done state: New releases seed the right checklist and inventory templates.

Release Binder Release Readiness guide sheet.
Release Readiness: explains what the readiness badge means and what to fix first.

Release Readiness

Use it: Open the question-mark icon when the release list says Needs Work.

Done state: You can trace each blocker back to a tab and resolve it there.

Release Binder Sync Status sheet showing local model counts and CloudKit readiness notes.
Sync Status: checks local counts and reminds you what CloudKit needs for cross-device sync.

Sync Status

Use it: Check local record counts, CloudKit container notes, and schema reminders before device smoke tests.

Done state: You have confirmed sync expectations before testing on another device.

Project setup

Projects

A project is the thing you ship: an App Store app, Mac utility, command-line tool, package, web product, GitHub release, or generic software release. Project settings provide the facts that every release under that project inherits.

Fields to review

Field How to use it
Name The product or repository name shown in the sidebar and Markdown packet.
Kind Choose the closest release channel. This controls templates, readiness checks, and visible release fields.
Bundle ID For Apple apps, use the bundle identifier tied to the App Store Connect app and iCloud container.
Repository URL Add the source repository or project home so reviewers can find code and release history.
Platform notes Capture non-secret setup details that apply to all releases, such as supported platforms or release channel constraints.
Release Binder Project Settings sheet.
Project Settings: project-level fields control templates, release tabs, readiness checks, and export labels.

Release channels

Project Types

Project type is the fastest way to keep Release Binder from becoming an App Store-only checklist. Choose the closest channel for how the work actually ships; it drives templates, visible fields, readiness checks, labels, links, and export sections.

Type Use it for
Apple App App Store Connect, TestFlight, App Review, screenshots, privacy labels, CloudKit schema checks, bundle IDs, entitlements, and platform build numbers.
GitHub Repository Repository releases with tags, previous-tag comparisons, target branches, milestones, Actions checks, artifacts, changelog, and draft release body copy.
Library or Package Swift packages, reusable modules, registry releases, compatibility matrices, API changes, dependency/license review, docs, and upgrade guides.
CLI Tool Command-line tools with version tags, install docs, package-manager metadata, binary artifacts, checksums, supported platforms, and compatibility notes.
Web Product Web apps, SaaS releases, docs sites, deployments, migrations, feature flags, monitoring, rollback, backup checks, customer notices, and post-release verification.
Mac Utility Mac apps or utilities that may ship through the App Store, direct download, notarized builds, GitHub artifacts, or signed installer packages.
Other Any release that still needs a structured packet but does not fit the named channels. Use it for generic version, source, artifact, notes, risk, and rollback tracking.

What changes by type

Project Type Workflows

Every project type still gets Overview, Checklist, Screenshots, Inventory, Privacy, Dependencies, and Notes. The difference is the language, seeded checklist/inventory rows, readiness blockers, and the release-channel tab fields.

Apple App

Use when: The release goes through App Store Connect, TestFlight, App Review, or Apple-platform review prep.

Project setup: Use Bundle ID / identifier, Repository URL when one exists, and platform notes for supported Apple platforms, iCloud container, distribution constraints, or review-sensitive behavior.

Release tabs: App Store, App Store Connect, Screenshots, Privacy, SDKs, Inventory, Checklist, Notes, and GitHub when repository release notes or source links matter.

Readiness focuses on: Version/build, App Store metadata, App Store Connect linkage, screenshots, privacy/data-use rows, SDK review, CloudKit schema, entitlements, review notes, and test-account instructions.

GitHub Repository

Use when: The release is a GitHub tag, GitHub Release, source artifact, or repository milestone.

Project setup: Add the repository URL. Release Binder recognizes common GitHub web and SSH remotes and builds Repository, Releases, Actions, Milestones, Compare Tags, and Open Draft Release links without storing a GitHub token.

Release tab: The GitHub tab shows Previous tag, Tag, Target branch, Milestone, Release title, Changelog / release notes, Breaking changes, Migration notes, Assets and artifacts, CI status, Docs updated, Announcement copy, Rollback notes, and Post-release verification.

Actions: Open Repository, Releases, Actions, Milestones, Compare Tags, Open Draft Release, and Copy Release Body.

Library or Package

Use when: You are shipping a Swift package, reusable module, package-registry release, internal library, or versioned dependency.

Project setup: Use Package ID plus Repository or package URL. Platform notes should capture supported platforms, compatibility policy, registry target, or package-manager expectations.

Release tab: The Package tab uses Package version, Package build, Release branch, Registry target, Changelog / compatibility notes, Package artifacts and registry notes, CI / package test status, Docs, examples, and upgrade guide, and Rollback / yanked-version notes.

Readiness focuses on: Compatibility notes, public API changes, package metadata, dependency/license review, registry target, docs, upgrade guide, and post-release verification.

CLI Tool

Use when: The release is a command-line tool, developer utility, binary package, Homebrew-style artifact, or installable script/tooling release.

Project setup: Use Command or package ID plus Repository or package URL. Platform notes should capture supported shells, OS targets, runtime requirements, and install channels.

Release tab: The CLI tab uses CLI version, Build / artifact, Release branch, Distribution target, Changelog / install notes, Binaries, packages, and checksums, CI / lint / test status, README, command help, and install docs, and Rollback / previous-version notes.

Readiness focuses on: Install and upgrade instructions, binary artifacts, checksums, supported platforms, runtime dependencies, package-manager metadata, and command help.

Web Product

Use when: The release is a web app, SaaS deployment, docs site, marketing site, backend deployment, or customer-facing rollout.

Project setup: Use Domain / service ID plus Repository or deployment URL. Platform notes should capture hosting target, environment names, migration constraints, or release-window notes.

Release tab: The Web tab uses Version / rollout, Deployment ref, Deployment branch, Deployment target, Changelog / customer-facing notes, Deployment, migrations, and artifacts, CI / deployment status, Docs, status, and customer comms, and Rollback / redeploy notes.

Readiness focuses on: Staging smoke checks, migrations, feature flags, monitoring, backups, rollback, customer-facing notes, support/status updates, and post-release verification.

Mac Utility

Use when: The release is a Mac utility that may ship through the Mac App Store, direct download, GitHub assets, signed installer, notarized zip, or mixed distribution.

Project setup: Use Bundle ID / identifier and Repository URL. Platform notes should capture sandboxing, automation permissions, signing/notarization requirements, helper tools, or direct-download channel details.

Release tabs: Mac Utility gets App Store and App Store Connect tabs because Mac utilities may still ship through Apple, plus the GitHub release channel for direct-download or repository artifact work.

Readiness focuses on: Build number, signing, notarization, downloads, screenshots, privacy disclosures, SDKs, App Store metadata when applicable, and rollback / previous-build notes.

Other

Use when: The release needs a binder but does not fit the named project types yet.

Project setup: Use Identifier, Repository URL, and platform notes to explain the release channel in plain language.

Release tab: The Release tab uses Version, Build / ref, Target branch / ref, Milestone / target, Release ref / tag, Changelog / release notes, Assets, artifacts, and distribution, Build / release status, Docs and announcement target, and Rollback notes.

Readiness focuses on: Source/version clarity, artifacts, docs, risk notes, rollback plan, and post-release verification.

Release detail

Tab Options By Project Type

The tab bar changes in two ways: some tabs appear only for App Store-style releases, and the release-channel tab changes its title and field labels based on project type.

Project type Release tab options
Apple App Overview, Checklist, App Store, Screenshots, App Store Connect, GitHub, Inventory, Privacy, SDKs, Notes. GitHub is available for repository-linked release notes and copied draft release bodies.
GitHub Repository Overview, Checklist, GitHub, Screenshots, Inventory, Privacy, Dependencies, Notes. The GitHub tab contains repository links, previous tag, tag, target branch, milestone, changelog, artifacts, CI, docs, rollback, and post-release verification.
Library or Package Overview, Checklist, Package, Screenshots, Inventory, Privacy, Dependencies, Notes. The Package tab changes labels to package version, release branch, registry target, compatibility notes, package artifacts, package test status, and upgrade-guide docs.
CLI Tool Overview, Checklist, CLI, Screenshots, Inventory, Privacy, Dependencies, Notes. The CLI tab changes labels to command/package identity, CLI version, build/artifact, distribution target, install notes, binaries/checksums, lint/test status, and command help.
Web Product Overview, Checklist, Web, Screenshots, Inventory, Privacy, Dependencies, Notes. The Web tab changes labels to version/rollout, deployment ref, deployment branch, deployment target, migrations/artifacts, deployment status, customer comms, and redeploy rollback notes.
Mac Utility Overview, Checklist, App Store, Screenshots, App Store Connect, GitHub, Inventory, Privacy, SDKs, Notes. Use App Store fields for Mac App Store distribution and GitHub fields for direct-download artifacts, notarization/download notes, and repository releases.
Other Overview, Checklist, Release, Screenshots, Inventory, Privacy, Dependencies, Notes. The Release tab uses generic labels for release ref/tag, target ref, assets/artifacts/distribution, build/release status, docs, announcement target, rollback, and verification.

Release selection

Release List

Each release row is a compact status report. Use it to decide what needs attention before opening the full detail view.

Release title

The version, beta name, deployment name, or milestone you are preparing.

Version, build, and stage

Shows where the release is in the workflow, such as Planning, TestFlight, App Review, Ready, Shipped, or Archived.

Readiness badge

Highlights whether the release still needs work. Open the release or readiness sheet to see the blockers.

Progress counts

Summarizes verified inventory, privacy/data-use rows, SDK/dependency count, and checklist completion.

Release Binder release list with readiness badge and progress counts.
Release rows: scan readiness, open counts, and checklist progress before drilling into tabs.

Release detail

Release Tabs

Tabs keep the release packet organized by job. You do not need to complete them in order, but a ready release should have each required area filled or intentionally marked not applicable.

Release Binder release detail area on macOS.
Visual reference for Overview: the detail pane is where selected-release tabs appear.

Overview

Purpose: Track the release summary, readiness status, important counts, and high-level facts.

Use it: Confirm name, version, build, stage, date targets, and current release health.

Done state: Someone can understand what is shipping and whether the release is blocked.

Release Binder Checklist tab with grouped release tasks.
Checklist tab: grouped task rows, completion toggles, and guidance buttons.

Checklist

Purpose: Track concrete release tasks such as screenshots, metadata, privacy review, QA, archive, and submission steps.

Use it: Mark items complete as work is verified. Add missing template items after changing project kind.

Done state: Required tasks are complete or intentionally marked not applicable.

Release Binder Inventory tab with release facts and verification toggles.
Inventory tab: required release facts, values, owners, notes, and verified state.

Inventory

Purpose: Record release facts that must be verified, such as source ref, build environment, App Store record, CloudKit status, and rollback plan.

Use it: Fill the value, verify it, and leave non-secret notes when the value needs context.

Done state: Required inventory rows are filled and verified.

Release Binder App Store Connect tab with manual linkage and local Keychain credential fields.
App Store Connect tab: non-secret linkage, local Keychain credential fields, fetch, preview, and apply controls.

App Store Connect

Purpose: Link a release to App Store Connect, fetch facts, apply safe values into the binder, and push selected listing metadata back after preview.

Use it: Add app ID or bundle ID, Team ID, issuer label, and local Keychain credentials when fetching or pushing metadata.

Done state: Fetched facts match the app, safe values have been previewed before applying, and selected listing fields are current in App Store Connect.

Release Binder App Store metadata tab with listing fields and review prep notes.
App Store tab: listing copy, release notes, URLs, legal fields, and review prep notes.

App Store

Purpose: Draft App Store metadata or release-channel copy such as changelog, review notes, URLs, and announcement text.

Use it: Keep public-facing copy and reviewer context here. Keep passwords, tokens, and private keys out.

Done state: App Store metadata is current, reviewed, and safe to export.

Release Binder release detail area with channel-specific release fields.
GitHub tab: repository links, release fields, compare context, and release-body actions.

GitHub

Purpose: Prepare repository releases with tag, previous tag, target branch, milestone, changelog, artifacts, CI status, docs, rollback, and verification notes.

Use it: Add the repository URL and release fields, open Repository/Releases/Actions/Milestones/Compare links, then copy the GitHub release body when it is ready for a draft release.

Done state: The release has enough tag, comparison, CI, artifact, changelog, and verification context to publish or hand off.

Release Binder Screenshots tab with stored image assets, preview, labels, and notes.
Screenshots tab: stored image assets, local imports, App Store Connect imports, preview, labels, and notes.

Screenshots

Purpose: Store the screenshots that belong to this release instead of tracking them only in Finder or App Store Connect.

Use it: Import local images, apply fetched App Store Connect screenshots, label platform/display/locale, and click an image to preview it larger.

Done state: Required screenshots are present, named, reviewed, and synced with the release record.

Release Binder Privacy tab with data-use rows and tracking toggles.
Privacy tab: data type, purpose, linked-to-user state, tracking state, and notes.

Privacy/Data-use

Purpose: Capture data types, privacy labels, tracking behavior, analytics, cookies, and policy URLs.

Use it: Update rows whenever app behavior, SDKs, or service providers change.

Done state: Privacy notes reflect the shipped behavior and are ready for review.

Release Binder SDKs tab with dependency names, versions, privacy review toggles, and notes.
SDKs tab: dependency names, versions, data-use summary, privacy review toggle, and notes.

Dependencies

Purpose: Track SDKs, packages, services, runtime components, versions, privacy manifests, and data-use notes.

Use it: Review changes before submission or deployment, especially when dependency behavior affects privacy.

Done state: Dependencies are current and any privacy or review impact is documented.

Release Binder Notes tab with screenshot, review, test-account, and submission notes.
Notes tab: screenshot notes, review notes, test-account process, and submission notes.

Notes

Purpose: Keep reviewer instructions, QA context, rollout notes, rollback notes, and post-release verification.

Use it: Write the process, not the secret. Refer to secure credential locations without pasting credential values.

Done state: The notes help someone review or ship the release without exposing sensitive data.

Release gate

Readiness

Readiness is a working signal, not a magic approval. It looks across release basics, checklist progress, required inventory, privacy/data-use rows, dependencies, reviewer notes, and channel-specific fields.

Purpose

Find the missing pieces that would slow down TestFlight, App Review, package publication, GitHub release, or deployment.

Key steps

Open Release Readiness, review blockers and warnings, fix the source tab, then re-check the badge.

Done state

Blocking items are resolved, required inventory is verified, and the exported packet has enough context for final review.

Common blocker

Inventory has values but was never marked verified, so readiness still treats the row as unfinished.

Release Binder Release Readiness guide sheet.
Readiness guide: use the sheet to understand what each blocker means before fixing the source tab.

Walkthrough

App Store Connect Import

Import creates a Release Binder project from App Store Connect facts. It is useful when the app already exists in App Store Connect and you want the binder to start with the correct app record, bundle ID, SKU, platform versions, latest builds, privacy policy URL, listing context, and screenshots already uploaded to the app version.

Security rule

Use App Store Connect credential material only in the local import form or Keychain-backed credential form. Never paste private keys, JWTs, authorization headers, passwords, API keys, or tokens into binder notes, exported Markdown, docs, support tickets, screenshots, tests, or source files.

What you need before importing

  • The App Store Connect app record, numeric app ID, or bundle ID.
  • The Apple Developer Team ID for the team that owns the app.
  • An App Store Connect API Key ID.
  • The App Store Connect API Issuer ID.
  • The downloaded private key file ending in .p8.
  • A role that can fetch app, version, and build facts for the app.
  • For push, a role that includes Edit App Store details.
Release Binder Import App Store Connect sheet with app lookup and temporary local credential fields.
Import sheet: app lookup fields, temporary local credentials, Keychain save toggle, Fetch Preview, and Project Preview.

Where to find the App Store Connect details

Detail Where to find it
App ID Open App Store Connect, choose Apps, select the app, then check the app information page. The numeric Apple ID/App ID is also commonly visible in the page URL.
Bundle ID Open the same app information area in App Store Connect. Use the bundle identifier tied to the app record and Developer portal identifier.
SKU The SKU is part of the App Store Connect app record. Release Binder can fetch it after the record preview succeeds.
Team ID Use Apple Developer account membership details or Certificates, Identifiers & Profiles. It must be the same team that owns the bundle ID, CloudKit container, and app record.
Issuer ID In App Store Connect, go to Users and Access, then Integrations. The Issuer ID appears with App Store Connect API access.
Key ID and .p8 In Users and Access, open Integrations, choose Team Keys, generate an API key, copy the Key ID, and download the private key once. Store the private key securely outside the project repository.

Create the App Store Connect API key

  1. Open App Store Connect. Go to Users and Access, then Integrations. If API access is not enabled, the Account Holder may need to request access first.
  2. Use Team Keys. Generate a team API key for the Apple Developer team that owns the app. Give it a recognizable name such as Release Binder.
  3. Choose the lowest useful role. Start with the least role that can fetch app, version, and build facts. Use a role with Edit App Store details only on devices where you intend to push listing copy from Release Binder. Admin works, but it is broader than Release Binder needs for metadata writes.
  4. Copy the non-secret IDs. Copy the Key ID and Issuer ID into Release Binder when importing or configuring the release tab.
  5. Download the private key once. Save the .p8 file somewhere secure outside the repository. Do not paste the private key into notes, docs, Markdown exports, support tickets, screenshots, or tests.

Import steps inside Release Binder

  1. Open Import App Store Connect. Use the sidebar or setup action. This opens the import sheet before a project is created.
  2. Fill App Lookup. Enter either the App Store Connect app ID or bundle ID. Add the Apple Developer Team ID and an issuer/team label that helps you recognize the account later.
  3. Fill Temporary Local Credentials. Enter the Key ID and Issuer ID. Import the .p8 file or paste its contents into the local-only credential field for this fetch.
  4. Choose whether to save credentials locally. Leave Keychain save enabled only on devices that should refresh App Store Connect facts later. Keychain storage is local to that device.
  5. Fetch Preview. Confirm the app name, App ID, SKU, bundle ID, platform versions, latest builds, listing locale, privacy policy URL, screenshot count, and screenshot import details.
  6. Create Project. Create the project only after the preview matches the expected app and team. Imported screenshots appear on the release Screenshots tab when App Store Connect exposes image delivery URLs for the app version.

Release tab

App Store Connect Tab

After a project exists, use the release-level App Store Connect tab to refresh facts, apply safe values into the binder, and push selected App Store metadata back to each current platform version localization. Applying updates binder fields only. Push writes only the previewed listing fields; it does not upload assets, assign testers, change groups, create app records, or submit for review.

Manual Linkage

Stores non-secret identifiers such as app ID, bundle ID, SKU, Apple Developer Team ID, and issuer/team label.

Local Keychain Credentials

Lets this device fetch App Store Connect facts and push selected metadata. Use Save Credentials only when the device should keep refreshing or writing through App Store Connect.

Fetched Facts

Shows selected app, primary bundle ID, platform versions, latest builds, listing locale, privacy policy URL, screenshot import details, and last fetch time.

Preview Apply

Review every proposed binder change before applying. Safe apply fills blank metadata fields and updates App Store Connect-derived inventory rows.

Preview Push

Review binder values against current App Store Connect values before writing promotional text, description, keywords, release notes, support URL, or marketing URL.

Release Binder App Store Connect tab showing manual linkage and local Keychain credential fields.
Release-level ASC tab: select a release first, then fetch, preview apply, or preview push selected metadata.

Push permissions

Fetch can use a Developer-style key. Push requires an App Store Connect role that includes Edit App Store details, which Apple describes as metadata on App Information, Version Information, and privacy policy URL fields. If the key can fetch but push returns HTTP 403, create a narrower metadata-writing key instead of defaulting to Admin unless your team policy allows it.

Release tab

Screenshots Tab

The Screenshots tab stores image assets for the selected release. Use it for App Store screenshots, review evidence, product-page work, or any visual that should travel with the release packet.

Import Images

Add one or more local image files. Release Binder stores the image data, title, file name, dimensions, source, and sort order with the release.

App Store Connect Screenshots

When fetched App Store Connect facts include screenshot delivery URLs, Preview Apply can import those images into the same tab. Applying does not upload, delete, reorder, or submit anything in App Store Connect.

Labels and Notes

Use title, display type, platform, locale, and per-image notes to explain which device size, storefront, or review purpose each image serves.

Preview and Sync

Click a screenshot to inspect it larger. Stored screenshots sync through the user's private CloudKit account after the Production schema includes the screenshot asset fields.

Release Binder Screenshots tab with stored image assets and release notes context.
Screenshots stay attached to the release alongside notes and imported App Store Connect context.

Sync readiness

CloudKit Sync

Release Binder uses SwiftData with private CloudKit. Signed TestFlight and App Store builds use the Production CloudKit schema, so Production must be promoted after model, project type, GitHub release-channel, screenshot, or App Store Connect field changes.

Purpose

Keep projects and releases available across Mac, iPhone, and iPad for the same iCloud account.

Key steps

Confirm the signing team, bundle ID, iCloud container, and App Store Connect app match. Exercise the current model in a signed build, then promote CloudKit schema changes to Production.

Done state

A small project and release created on one device appears on the other devices, and edits sync both directions.

Common blocker

Development schema contains new fields, but Production does not. For each review candidate, verify Production includes project kind/repository fields, App Store Connect linkage fields, screenshot asset fields, and the release-channel previous tag field before relying on App Store or TestFlight sync.

Release Binder Sync Status sheet with local record counts and CloudKit readiness notes.
Sync Status sheet: use signed builds, matching iCloud account, and promoted Production schema for real sync testing.

Review packet

Preview and Export

Preview and export actions create a release packet from the current binder content. Use them for final review, archive, handoff, release notes prep, or an external publishing workflow.

  • Release summary and readiness state.
  • Open checklist and inventory work.
  • App Store or release-channel fields.
  • Checklist, inventory, privacy/data-use, dependency, and note sections.
  • Non-secret App Store Connect linkage and fetched status facts when present.
  • GitHub release body copy, including tag, previous-tag comparison context, changelog, artifacts, docs, rollback, and post-release verification when present.

Use Preview Packet before sharing, Copy Packet for a quick handoff, Export Markdown for an archive file, or Copy GitHub Release Body when you are pasting into a draft GitHub release. Before sharing an export, review the source binder fields. If sensitive content appears, remove it from the binder, regenerate the export, and rotate the exposed credential if needed.

Release Binder Notes tab with release notes that export into the Markdown packet.
Export uses the selected release. Notes, checklist, inventory, privacy, SDKs, and fetched non-secret facts flow into the packet.

Safety

Privacy And Secrets

Release Binder is not a password manager and is not a place to store private keys. Keep the binder useful by recording process and release context, not credential values.

Record

  • Support and privacy policy URLs.
  • Data types and app behavior.
  • SDK, package, and service summaries.
  • Reviewer instructions and access process.
  • Where credentials are managed, without the credential values.

Do not record

  • Passwords or test-account passwords.
  • API keys, private keys, or tokens.
  • App Store Connect private key contents.
  • JWTs, authorization headers, or raw credentials.
  • Screenshots that reveal secret values.

Fix the common blockers

Troubleshooting

Import says App Store Connect API access is unavailable.

In App Store Connect, open Users and Access, then Integrations. The Account Holder may need to request API access before Team Keys can be created.

The import cannot find the app.

Check that the app ID or bundle ID is correct and that the API key belongs to the same Apple Developer team as the app record.

The key works in one account but not this app.

Confirm the Issuer ID, Key ID, Team ID, and role. Use the lowest role that can read the required app, version, and build facts; increase only if App Store Connect denies read access.

Push returns HTTP 403.

The key can authenticate, but its role cannot edit the requested App Store metadata. Use a key with Edit App Store details for push. Admin works, but a narrower metadata-writing role is preferred when available.

Projects created from App Store Connect do not sync to iPhone.

Check Production CloudKit schema first. After SwiftData, screenshot, GitHub release-channel, or App Store Connect field changes, Production must include the current fields before TestFlight or App Store builds can upload and sync those records.

Readiness says inventory is not verified.

Open Inventory and verify required rows after confirming their values. Empty or unverified required rows are treated as blocking work.

The wrong tabs appear for a release.

Check Project Settings and confirm the project kind. Existing releases keep existing rows until you use Add Missing Template Items.

Markdown export contains something sensitive.

Remove that content from the binder source field, regenerate the export, and rotate any exposed credential if needed.