37
GitHub Actions workflows across CI, release, store ops, analytics, and repo automation.
What is excellent here
He treats app shipping as a system, not a button press. Release publishing, store readiness, screenshots, App Review prep, Play Console validation, and device tests all have explicit code paths.
What I would copy first
The Makefile, native CI jobs, release preflight script, Python verification scripts, Playwright store-console checks, and the reusable weekly runner are the highest-leverage patterns.
What I would treat carefully
There is visible config drift. Some docs still mention Expo, React Native, or workflow names that do not exist anymore. We should copy living code, not older prose.
Execution roadmap
What I can wire now vs what still needs you
This is the split that matters for handoff. By the time you give me the GitHub repo link, the codebase should already contain the automation shell, workflows, checks, and docs. The remaining work should be mostly credentials, policy, and platform access.
Ready Now
Things I can complete without your intervention
- Root CI, security, release-artifact, remote-health, and docs-site workflow scaffolding.
- A monorepo-style Makefile and root verification scripts around the native apps.
- Repo docs, local Playwright contract checks, PR templates, and future handoff checklists.
- Fail-fast guards so missing secrets or policy choices are explicit and documented.
Blocked On You
Things that require your accounts or decisions
- GitHub secrets, store credentials, signing assets, and any repo settings that require your account access.
- GitHub secrets, App Store Connect credentials, Android signing files, and Play service account JSON.
- Repository settings like branch protection, environment reviewers, and optional Pages activation.
Later
High-leverage additions after the base is stable
- Authenticated store-console verification with Playwright storage state.
- Maestro mobile flows and device automation once the app surfaces stop shifting.
- Growth loops, ASO rotation, attribution feedback, and project-ops bots.
The repo should start behaving like a disciplined mobile delivery repo on first push, even before store credentials exist.
I can prepare the slots, guards, and workflows, but I cannot generate the real credentials or platform approvals.
You should end up with a precise TODO list instead of a vague “some setup is still left” answer.
Tool atlas
The stack by layer
This grouping is the most useful way to understand the repo. It separates delivery plumbing from product growth experiments, so you know what must exist on day one versus what can wait.
1. CI and orchestration
GitHub Actions is the control plane. The repo uses standard hosted runners, reusable workflows, artifact uploads, concurrency controls, environment gating, and branch protection to keep delivery predictable.
GitHub Actions
Reusable workflow calls
Artifacts
Branch protection
GitHub Projects v2
2. Native build and release
Release automation is native-first: Gradle for Android, Xcodebuild and Fastlane for iOS, plus custom Python wrappers for store verification and Play publish logic. This is the real backbone of the repo.
Gradle
Xcodebuild
Fastlane
match
App Store Connect API
Google Play Developer API
3. Test automation
The testing model is layered: native unit tests, iOS simulator tests, Android emulator/device tests, Maestro mobile flows, ADB shell checks, Playwright store-console tests, and an optional agent-browser execution path.
XCTest
Android unit tests
Maestro
ADB
Playwright
agent-browser
PhoneClaw
4. Quality and security
The repo uses both local and CI protection. Trunk handles linting and hygiene. CI adds gitleaks, CodeQL, Snyk, OWASP Dependency-Check, MobSF, npm audit, and custom release-readiness checks.
Trunk
gitleaks
CodeQL
Snyk
OWASP Dependency-Check
MobSF
Checkov
5. Store ops and metadata
This is unusually strong. The repo has dedicated scripts and workflows for metadata sync, screenshot reset, review readiness, review submission, version resolution, release verification, and console access checks on both Apple and Google sides.
Fastlane metadata
ASC scripts
Play metadata sync
Store-console browser checks
Release verification
6. Analytics, ASO, and growth ops
The repo goes beyond build-and-ship. PostHog, Apple Ads, wiki sync, ASO rotation, attribution feedback, North Star metrics, and growth content pipelines are all automated as scheduled workflows.
PostHog
Apple Ads APIs
GitHub Pages
Wiki sync
North Star guardrails
7. AI and repo operations
AI is used for more than code generation. Claude reviews pull requests, Seer contributes safety-focused review signals, docs mention CodeRabbit, and project metrics are pushed into issues and board state automatically.
Claude Code Action
Seer by Sentry
CodeRabbit docs
GitHub Script automation
Critical analysis
Current truth vs legacy drift
This is the main thing to understand before copying anything. The repo has strong live automation, but it also carries some older files that no longer match the current native architecture.
Do not copy the repo literally
- native-release.yml looks current. It uses Fastlane, Gradle, Xcodebuild-friendly paths, App Store Connect keys, Play keys, release verification, and store metadata steps that match the native folders.
- release.yml looks stale. It still references Expo/EAS, package.json, and app.json at the repo root, but those files are not present in the current upstream tree.
- .github/INFRASTRUCTURE.md and .github/project.yml are stale in places. They still mention React Native, Expo, and even a different app description. That means prose cannot be trusted as much as executable code.
- .github/AUTOMATION.md is stale too. It references pr-automation.yml and issues-automation.yml, which are not present in the workflow directory anymore.
| Pattern | Decision | Reason |
|---|---|---|
| Makefile as one human entrypoint | Copy | It centralizes everyday commands and makes the stack teachable. |
| Native CI in ci.yml | Copy | It verifies Android, iOS, Playwright local checks, Python scripts, and security in one lane. |
| Python release/store scripts | Copy | They turn fragile console work into auditable code. |
| Weekly growth and ASO automations | Adapt later | Useful once acquisition and analytics matter, but too heavy for day-one setup. |
| PhoneClaw visual checks | Adapt later | Interesting for physical-device validation, but not essential until the core lanes are stable. |
| Expo/EAS release workflow | Skip | It does not match the current native-only layout of the upstream repo. |
Release design
The release conveyor belts
These are the flows worth stealing. Notice how both platforms use the same shape: preflight, credentials, build, upload, verify, then metadata/review work.
iOS release path
1
Preflight gate
Run scripts/preflight-release.sh --platform ios --layer 1 to validate metadata, screenshots, privacy URLs, and versioning before expensive work starts.
2
Provision signing and ASC access
Ruby + Fastlane + match set up certificates and profiles, while Python checks App Store Connect credentials separately.
3
Build and upload to TestFlight
fastlane beta increments the build, builds the archive, and uploads to TestFlight.
4
Verify processing
scripts/verify_release.py --platform ios checks that the uploaded build is actually visible and usable.
5
Sync metadata and submit review
Fastlane metadata lanes and ASC helper scripts drive screenshots, listing text, version resolution, and review submission.
Best practice worth copying: he does not trust a successful upload by itself. He verifies the remote store state after upload.
Android release path
1
Preflight gate
The same shell preflight script validates Play listing files, changelogs, icons, screenshots, and version codes before release.
2
Provision store credentials and keystore
Google Play API access is checked first, then the Android keystore is decoded and inspected on the runner.
3
Build the AAB
./gradlew bundleRelease creates the release artifact using env-provided signing settings.
4
Publish with fallback logic
scripts/play_publish.py can retry and fall back from production to a safer track if preconditions fail.
5
Verify landing state
scripts/verify_release.py --platform android confirms the build is visible on the expected Play track.
Best practice worth copying: release logic is not buried entirely inside Fastlane. Important store rules live in testable Python.
Verification model
How the repo tests itself
The strongest idea here is not any single test tool. It is the coverage ladder. Fast, deterministic checks run early. Slower or more fragile device and console checks run in dedicated lanes.
| Layer | Main tools | Example entrypoint | Why it exists |
|---|---|---|---|
| Local day-to-day verification | Make, Gradle, Xcodebuild | make verify | One human command that runs platform checks without memorizing platform-specific syntax. |
| iOS test lane | Xcodebuild, simulator resolution script | ./scripts/ios_verify.sh | Runs unit tests on a valid simulator automatically, which removes a common source of local friction. |
| Android unit and instrumentation | Gradle, Android test APIs | ./gradlew testDebugUnitTest assembleDebug | Covers Kotlin logic quickly and leaves instrumented tests available when hardware/emulators are ready. |
| Mobile UI smoke and regressions | Maestro, Android emulator runner | maestro test .maestro/smoke-test.yaml | Exercises real user flows, app lifecycle, notifications, and regression paths on mobile UI. |
| Shell-driven device behavior | ADB, dumpsys, uiautomator | bash scripts/device-tests/run-all.sh | Validates things normal UI tests often miss: lock screen state, media buttons, notifications, audio focus, cross-app return. |
| Visual physical-device experiments | PhoneClaw scripts | bash scripts/device-tests/phoneclaw/setup-device.sh | Experimental layer for device-side visual confirmation. Interesting, but optional at first. |
| Store readiness checks | Playwright, agent-browser | npm run verify:strict | Checks screenshot inventory and metadata readiness before store submission work begins. |
| Read-only console verification | Playwright, saved auth state, agent-browser | npm run test:console | Confirms App Store Connect and Play Console show the expected app/version state without mutating store data. |
| Automation script protection | Pytest, coverage | python -m pytest scripts/tests/ -q --cov=scripts | Protects the store, release, growth, and reporting scripts that would otherwise be the most fragile part of the system. |
Protection layers
Quality and security stack
He uses multiple concentric rings instead of one giant gate. That is the right model for a repo that mixes Swift, Kotlin, shell, YAML, Node, and Python.
Trunk as local hygiene hub
.trunk/trunk.yaml enables a broad lint mix including yamllint, trufflehog, taplo, oxipng, shfmt, shellcheck, markdownlint, osv-scanner, ktlint, dotenv-linter, checkov, actionlint, eslint, and prettier.
Custom pre-commit hook
scripts/pre-commit adds secret scanning and targeted checks before changes even leave a developer machine. This is a strong pattern because it pushes failures earlier than CI.
Security workflow in CI
security.yml runs npm audit, Snyk, OWASP Dependency-Check, CodeQL, gitleaks, and MobSF, then publishes results as artifacts. That gives both source-code and mobile-specific coverage.
Secret fingerprints are customized
.gitleaks.toml adds project-specific rules for Sentry auth tokens, Sentry DSNs, Expo tokens, and Firebase keys. That means the secret scan is tuned to the actual ecosystem being used.
Release verification is remote-state aware
verify_release.py checks what the store actually sees after upload, rather than assuming a successful API call means the release is truly ready.
Crash health is part of CI
There is even a Crashlytics stability check wired into CI using BigQuery export access. That is more advanced than typical mobile repos and shows production operations are part of the definition of done.
Automation beyond shipping
Repo ops, growth loops, and AI assistance
These layers are impressive, but they are not all equally urgent. The trick is to borrow them in the right order.
Reusable weekly runner
weekly-shared.yml is a very good pattern. It standardizes Python setup, optional package install, command execution, commits, wiki publishing, issue creation, and artifact upload into one reusable workflow.
Project metrics pushed into GitHub
main.yml computes issue, PR, activity, throughput, and Projects v2 swimlane metrics, then writes them into a status issue. This is repo operations as code.
Growth automation is code, not spreadsheets
The scripts folder includes ASO keyword rotation, attribution feedback, paid acquisition seeding, North Star guardrails, review velocity tracking, and content generation. Few app repos go this far.
AI review is wired into PR flow
claude-review.yml runs advisory PR review, optional auto-approval when review passes, and on-demand help through @claude. Seer is also configured as a review bot with required status checks.
Store visibility is browser-tested
The Playwright package is a major differentiator. It treats store consoles like production interfaces and verifies them with authenticated, read-only browser state.
Documentation publishing is automated
Wiki sync and GitHub Pages publishing mean documentation and growth content are part of the same automation graph, not separate manual chores.
Our setup path
What we can set up before you give me your repo
Without your actual GitHub repo, the main thing I can do now is build the operating model and the copy order so we do not waste time later. This is the sequence I recommend.
Stage 1: Define now
- Choose the branch model: likely develop and main, or a simpler trunk model if you want less overhead.
- Define environments and release tracks: TestFlight internal, App Store review, Play internal, Play production.
- Define the secret matrix: App Store Connect, Play API, signing, analytics, crash reporting, CI-only auth state.
- Define the canonical commands we want to expose later through make.
Stage 2: Copy first when repo arrives
- Root Makefile with verify, platform-specific verify, Maestro, Playwright, and store-check targets.
- Minimal ci.yml that proves Android build/tests, iOS build/tests, Python automation tests, and security scans.
- scripts/preflight-release.sh and scripts/verify_release.py style gates.
- tests/playwright for local readiness plus read-only store-console verification.
Stage 3: Add later if they earn their keep
- Weekly growth loops and ASO rotations.
- PhoneClaw or other physical-device visual validation.
- Project-board metrics issues and review-velocity bots.
- Automated content and GitHub Pages publishing.
| Bootstrap item | Why we should do it | Recommended shape |
|---|---|---|
| Repository folder contract | Prevents workflow sprawl and makes future automation composable. | .github/workflows/, scripts/, tests/playwright/, .maestro/, docs/ |
| Human command contract | Removes tool memorization and makes onboarding faster. | make verify, make verify-ios, make verify-android, make maestro-ios, make maestro-android, make store-checks |
| Secret inventory spreadsheet or markdown | Most mobile release automation dies from invisible credential debt. | Track secret name, owner, source system, rotation policy, and workflow consumers. |
| Release readiness checklist as code | Store failures should happen before archive/upload time. | Borrow the upstream preflight script shape and tune it to your assets, URLs, and changelog rules. |
| Store console auth-state plan | Needed for browser-based verification later. | Decide who records Playwright auth state, where it is refreshed, and which CI secrets store the JSON blobs. |
Primary sources
The files that matter most
If you want to audit the upstream repo yourself, start here. These are the files I would treat as the best source of truth.