This is what it does
App Boilerplate
Everything an app needs that is not the app: the legal pages, CI with a secret scan that can actually go red, the store-asset spec, the analytics schema and the launch checklist.
There is no demo on this page, and that is the honest answer rather than a design choice. This kit is a folder of files: Markdown templates, one GitHub Actions workflow and a Python harness that tests that workflow by extracting its scan block and running it against throwaway repositories. None of it runs in a browser, and a browser animation of a shell script would be theatre. What this page gives you instead is the one part with teeth, stated exactly: the decision table the scan step implements, on the real branches and the real exit codes, below.
- What it is: a folder you copy and rename. It needs no service from the studio, no build step and no network connection to work.
- What to try: open the five cases under The decision table and see which branch fires, what it prints, and which single path reports clean.
- What is proven: five passing tests drive the real workflow step — not a copy of it — against throwaway git repositories.
- What it is not: a starter for an app. It is the paperwork and the workflow around one you already have; there is no scaffold, no store art and no dashboard.
The kit is blocked on one decision: the licence in it is a proposal with a placeholder holder, and no price is published. Ask about the licence
The part with teeth
The decision table
Read out of the workflow file itself, not summarised from memory. The pattern the scan matches is sk-…, eyJ…, BEGIN … PRIVATE KEY or service_role. The point of the table is that only one of the five paths is allowed to report clean.
A branch’s first push, or any push with no base commit
The base arrives as all zeroes. The step detects that and diffs against the empty tree, so the first push is scanned in full rather than compared against nothing. It prints: no base commit (new branch) — scanning the full tree at <sha>.
The diff cannot be produced at all
Red. ::error::could not produce a diff for <range> — the secret scan did NOT run, then exit 1. This is the failure the first version shipped: it chained the diff and the search inside one conditional, so an unproducible diff left the condition false and the job printed a clean report for a scan it had never executed.
A credential-shaped string is in the diff
Red. ::error::credential-shaped string found in the diff, the matching lines printed with their line numbers, then exit 1. The scan reads the pushed diff rather than the whole repository, because that is the moment a credential is cheapest to catch — and an ignored secret is still a plaintext secret.
The search tool itself fails
Red. A search that errored is not a clean result, so an exit above 1 is treated exactly like a match: ::error::grep failed (exit <status>) — the secret scan did NOT run, then exit 1.
No match, and the search exited cleanly
Green. no credential-shaped strings in the diff. This is the only path in the step that is allowed to report clean, and it requires the search to have run and succeeded to get there.
Status
Complete as a template folder
- The scan refuses to report a result it did not earn. A first push is scanned, an unproducible diff and a failing search are both hard errors with their own error line, and only a clean exit from the search reports clean.
- Five passing tests run the real workflow step. The harness extracts the
run:block out of the workflow file and drives it against throwaway repositories — a clean range, a planted secret, an unproducible diff, a first push with a secret, and a first push without one. - Four CI jobs, and the summary cannot be skipped. Backend and mobile are separate jobs so a failing type check cannot hide behind a green one, and the summary runs even when a job is skipped and fails on any failure or cancellation, because a skipped suite is not a pass.
- There is nothing to download from here yet. The kit is a folder in the studio’s workspace, not a published artifact, and its licence is still a proposal.
Plainly
What it does not include
- No binary store art. No icons, no screenshots, no preview videos — only the sizes and the rules, because a placeholder that ships as an icon is worse than no icon.
- No dashboard URLs and no pre-built analytics. The schema names the nine events and the folder says which three dashboards to build first.
- No Fastlane
Appfileand no app scaffold. The Fastfile expects an Appfile you create from the Fastlane docs. - No legal advice. The legal pages are bracketed templates, flagged inside the kit as needing review for your jurisdiction.
- No support contract, no updates commitment and no refund terms — there is no service attached to the folder, which is why the price note argues for a one-time figure rather than a subscription. No price is published here.
Under the hood
What it is built on
- What is in it
- Legal page templates, one GitHub Actions workflow, one Fastlane Fastfile, a store-asset specification, an analytics event schema, a launch checklist and the Python harness that tests the scan step. Markdown and one YAML file — no framework, no dependency to install.
- Runs where
- Wherever you copy it. The workflow runs in the app’s own repository; the scan harness runs locally on Python and git.
- Data
- None. The event schema is a document to keep as the single source of truth rather than a service.
- Auth
- None. There is nothing to sign in to; the workflow uses the app repository’s own settings, and secrets belong in Actions secrets rather than in the workflow file.
- Payments
- None. The kit ships no checkout, and its licence file is a proposal with a placeholder holder rather than a settled grant.
- Blocked on
- The licence decision, which the kit’s own pricing note puts first for exactly that reason.
Ask about the licence
How the secret scan is tested, how to adapt the legal templates to your jurisdiction, or how the workflow fits your stack — ask. The licence is the one thing standing between this folder and a download.