PARITYEnter control room

App Store Connect, Google Play, and the repository between them.

Your release config has two sources of truth.

StoreParity tells you when they disagree, shows the evidence, and puts every fix behind your approval.

Checks
21 deterministic comparisons
Access
Outbound-only private runner
Changes
Single-use approvals
Representative findingAPPLE.PRIVACY-LABEL
Tracking declaration driftThe binary and the store listing disagree.
Needs attention
Repository
NSPrivacyTrackingfalse
App Store Connect
Trackingtrue
Evidence

No tracking symbols or advertising identifier access found. The live privacy label still declares tracking.

Fix prepared Review the exact console change before it can run.

Unknown is never reported as healthy.

Every result carries both compared values.

Every automated action leaves evidence.

One finding, all the way through

From a mismatch to a verified fix.

The evidence and the decision stay together. You never have to reconstruct why an automation changed something.

  1. 01

    Observe

    Read the repository, the live store console, and the runner that connects them.

  2. 02

    Name the drift

    Show both values, where they came from, and why the difference matters.

  3. 03

    Approve one action

    Bind the exact fix to a single-use approval. No open-ended access and no surprise writes.

  4. 04

    Verify the result

    Run the same deterministic check again and keep the evidence in the audit trail.

Coverage

The configuration around a release, not just the binary.

StoreParity checks the quiet settings that build pipelines cannot see and teams usually discover after a rejection or a missed launch.

Store declarations

  • App privacy label
  • Play Data safety
  • Age rating
  • Listing copy
  • Cross-store privacy parity

Release readiness

  • Build numbers
  • Version codes
  • Signing assets
  • Release status
  • Xcode Cloud wiring

Automation health

  • Scheduled routines
  • Runner registry
  • Project coverage
  • Dead-code baselines
  • Credential access

And more Listing punctuation, CI signing fallbacks, automation cadence, and the checks your own release process adds next.

Private by architecture

Your operational credentials stay where you put them.

The control plane coordinates work. Your runner reads repositories and store consoles, then returns only the result and its evidence.

StoreParity control plane

Identity, projects, findings, immutable approvals, jobs, and audit history.

  • Coordinates
  • Never holds store keys
  • Never sends arbitrary shell commands

Your private runner

Repository access, store credentials, and your AI-provider access remain on your Mac or Linux host.

  • Observes
  • Executes allowlisted jobs
  • Reports evidence
No inbound port. No credential upload. No standing approval.
From the blog

Notes from the release desk.

Store best practices, how-tos and what changed in App Store Connect and Google Play.

All posts
Release configuration deserves a diff.

See what changed before the stores make it your problem.

Enter control room