The App Store page is a full, live preview of the App Store Connect listing for Busymate DevTools, laid out the way App Store Connect — and the App Store itself — present it. Open it at Settings → App Store to see, at a glance, what's live on the App Store, what's in preparation or rejected, every listing field for each, the screenshots, and exactly what changed between the two. Every value is fetched live from Apple, so the page is the team's single read-only window onto the release without anyone signing into App Store Connect.
What it's for
App Store Connect is admin-only and noisy. This page distills the part the team actually needs — which version is live, which is in review, the full "What's New" and description, the keywords and screenshots, and whether the latest submission was approved or rejected — into a familiar, read-only listing preview that any teammate with testflight:view can open. Nothing here writes to App Store Connect; it's a faithful mirror of Apple's current data.
The two tabs
The page splits the version timeline into two tabs, mirroring how App Store Connect groups versions:
- Current / Approved — the version that is live on the App Store (state Ready for Sale), or the most recently approved one.
- In Preparation / Rejected — the version you're working toward: Prepare for Submission, Waiting for Review, In Review, Pending Developer Release, or Rejected.
Switching tabs swaps which version card is shown; both are always loaded, so the switch is instant.
App Information
Above the tabs sits one App Information card holding the metadata that's shared across every version — the App Store Connect "App Information" page, surfaced once:
- The app name and subtitle, with the age rating as a badge (the App Store rating, plus the Brazil ClassInd classification as a secondary line when present).
- The bundle ID, SKU, and primary language.
- The primary and secondary App Store categories.
- The privacy policy and privacy choices URLs (linked), and the content-rights declaration.
What a version card shows
Each tab renders one version card, styled like the App Store product page / App Store Connect version detail, top to bottom:
- The app icon, the app name (see Per-version app names below), the version string (e.g.
Version 1.4.0), and a color-coded state badge — green for Ready for Sale, amber for In Review / Waiting for Review / in preparation, red for Rejected — so the state reads at a glance. - A destructive rejection alert when the version was rejected (see Rejections).
- The screenshots gallery, grouped by device size (see Screenshots).
- The full description — the App Store product-page description, rendered in full and never truncated or collapsed.
- What's New in This Version — the release notes.
- The per-version listing metadata: keywords (as chips), promotional text, and the marketing and support URLs.
- The Build & Version grid: build number, uploaded date, processing state, minimum iOS version, the export-compliance (encryption) declaration, the submitted date, the release type (manual / automatic on approval / scheduled), and the release date.
- The App Review Information Apple has on file: the contact line, whether a demo account is required, and any review notes.
Per-version app names and the pending rename
Each version card prints the app name verbatim from App Store Connect for that lane — the live listing name on the Current / Approved card, and the editable in-preparation name on the In Preparation / Rejected card. These are not prose the dashboard authors; they are Apple's live data, mirrored as-is. (When App Store Connect returns no per-version name — a rare metadata hiccup — the card falls back to the static product name, "Busymate DevTools".)
This is exactly how a pending app rename surfaces before it goes live. While the App Store rename from "Busymate Helper" to "Busymate DevTools" is in flight, the live card shows the name that's still live on the store — currently Busymate Helper — while the in-preparation card shows the Busymate DevTools name attached to the next submission. The page is the team's window onto watching that rename land: when the new version reaches Ready for Sale, the Current / Approved card's name flips to the new one. In Compare mode, a differing name is flagged with a small inline changed tag, so a pending rename is unmistakable.
Screenshots
The screenshots gallery loads by default — the page is a full listing preview, so the App Store product-page imagery is always there on open, no toggle required. (Earlier builds hid screenshots behind an opt-in switch; that's gone.) Each version's screenshots are pulled live from Apple's signed asset URLs and grouped by display type — a labelled, horizontally-scrolling strip per device class (e.g. iPhone 6.7", iPad Pro (12.9")), with the shot count beside each group header. A version with no uploaded screenshots shows a quiet empty state instead.
Compare mode
The Compare toggle switches both versions into a side-by-side split view — the Current / Approved version on the left, the In Preparation / Rejected version on the right — so you can read both at once and spot exactly what changed before submitting.
The cue for a changed field is deliberately flat and quiet: a differing field renders identically to an unchanged one, except a small inline changed label sits next to its label. There's no border, padding, or background tint around or behind a changed field — the only indicator is the inline tag. Compare flags differences in the app name (a pending rename), version string, state, build number and dates, minimum iOS, release type and date, description, keywords, promotional text, and the marketing/support URLs. (Keywords are compared order-insensitively, so a pure re-order isn't flagged.)
The one field that gets a true line diff is What's New in This Version: the release notes are diffed line-by-line, with removed lines tinted on the left column and added lines tinted on the right — the fastest way to confirm the release notes you wrote actually shipped.
Reload
Reload triggers a fresh live fetch from App Store Connect, so the cards always reflect Apple's current state — useful right after you submit, or while a review is in flight. The page loads once when you open it and never polls; Reload is the only way to re-fetch. The header shows when the data was last fetched.
Rejections and the Resolution Center
When a submission is Rejected, the card shows the red Rejected badge and a destructive alert — but not the reviewer's message.
Apple's API limitation. The App Store Connect API exposes the rejection state but not the reviewer's literal text. There is no field for the reviewer's note, so no tool — this page included — can display it. To read what App Review actually said, open Resolution Center in App Store Connect.
So the page tells you that a version was rejected and which one; the why lives only in Resolution Center.
Access
The page is gated at testflight:view — the same capability that governs the rest of the TestFlight admin surface — and that gate is enforced both in the UI and server-side in the Edge Function. It's read-only: it never writes to App Store Connect, so testflight:view (without edit) is enough to open it. A role without that capability won't see App Store in the nav. See Roles & permissions.
Over MCP and BusyBro
The exact same App Store Connect snapshot is available programmatically through the get_app_store_status MCP tool (also at testflight:view), so you — or BusyBro — can ask "is the latest build approved yet?" from any MCP client and get the live state back without opening the dashboard.
How it works
Both the page and the MCP tool read through the testflight-admin Edge Function's read-only app_store_status action, so they always agree. That action mints an ES256-signed JWT from Apple's private .p8 key (kept only in Edge Function secrets — never on the dashboard or the VPS) and calls the App Store Connect API: it fetches the app's appStoreVersions, partitions them into the live and in-preparation cards, pulls the per-version localizations (description, keywords, promotional text, URLs) and build detail, fetches the shared app-level metadata and the per-version names, and — unless the caller opts out — the screenshots for the two selected versions. The metadata and screenshot fetches are fail-soft: a hiccup degrades that part of the payload but never drops the version cards.