A successful build is only one release artifact. The screenshots, demonstration, store copy and review evidence also have to describe the app that will actually ship.
One shared app, two native build paths
Henge uses Capacitor to bundle its HTML and TypeScript app for iPhone/iPad and Android. The project records an initial TestFlight upload and local Android emulator verification. This is beta and development progress, not a claim of public availability in either store.
The native pipeline uses one version source for Xcode and Gradle. Xcode builds invoke a paired Android build; an Android failure fails the paired build. The numbered release flow reserves a shared build number, creates matching artifacts and records a successful release only after its required checks.
Android release artifacts are unsigned in the documented workflow. Google Play signing and distribution remain distinct steps. An Apple upload likewise does not establish processing completion, tester availability or public App Store approval.
APPLE / RECORDED STORE IDENTITY
Henge - Adaptive Game Timer
Extra Time, but Fairly Tracked
iPhone & iPad beta first. The project’s October 30 store record confirms this title and subtitle.
GOOGLE PLAY / DRAFT SHORT DESCRIPTION
Shared time.
Flexible turns.
Shared timers for board, card and drawing games, with flexible turn queues
Draft from the tracked marketing copy. Android builds and listing preparation do not establish a live Play listing.
Make marketing a checked release input
The marketing tooling prepares a versioned package containing platform-specific copy, recent features, screenshots, demos and review records. Each media asset carries a hash and capture evidence. The package also records a fingerprint of the app source.
The release gate requires the package for major version changes, first releases without a local baseline, and explicitly requested marketing refreshes. It checks before reserving a build number and again before writing the successful release record. That second check catches source or media changes during the build.
A draft package cannot pass merely because files exist. The checker rejects incomplete platform coverage, missing media and stale review fingerprints. It checks recorded integrity; it does not watch a video, establish the truth of a review, or guarantee store acceptance.
Review the store page as a buyer sees it
Try the public Apple and Google Play layout prototypes →
The project builds separate local Apple and Google Play listing simulations, with their own HTML, CSS, copy and media. Web, phone, tablet and search-card views reveal different problems: a screenshot headline may work full size and become unreadable in a result card.
The workflow calls for independent buyer-agent reviews covering tabletop play, standard cards, deck-building/RPGs, family sharing and attention or pacing needs. These are internal critique passes—not customer testimonials or clinical validation. Changes to copy, media or preview layout invalidate the recorded review fingerprint.
The reviews ask whether the use case is recognizable and whether the promise is accurate. Henge can help a group agree on shared turns; it does not automate a board game’s rules or lock another device.
Keep the screen real
For illustrative device-on-table scenes, the workflow retains a background plate, screen mask and calibrated quadrilateral. A compositor inserts a real native screenshot with a perspective transform, then writes hashes for the inputs and output. Image generation must not redraw the app screen.
This makes a scene reusable: a new version needs a new capture and composition, rather than an invented interface or a regenerated setting. Native-only screenshots stay available as evidence, and captions must not cover controls. Apple media and Android media require their respective native captures.
Release evidence has an expiry date
Henge’s launch-polish record explicitly notes that interface changes made earlier store media stale. A successful old review cannot certify a new screen. The same principle applies to physical-device behavior, privacy declarations and distribution status.
The microsite’s screenshots show the running browser app. They help explain Henge, but they are not a replacement for the native media and device checks required by the release workflow.