AppStarter

Overview

AppStarter is the reusable iPhone application foundation I built after seeing the same setup problems repeat across multiple mobile projects. Flashbackz needed a local-first stack for photo access, persistence, image handling, navigation, and native device features. 1MillionBeers added authentication, profiles, storage, Supabase, and a more complicated native toolchain. The products were different; much of the setup work was not.

Instead of making every new project rediscover a working Expo stack, AppStarter preserves a known-good baseline that can be copied and adapted. It is deliberately iPhone-first and deliberately conservative about dependencies. The goal is not to preload every feature a future app might need. It is to solve the expensive, repetitive foundation once.

One Starter for Two App Types

I initially considered separate starters for local-only and social applications. I rejected that split because most of the useful foundation is shared: navigation, design primitives, persistence, image handling, build configuration, testing, and project conventions.

AppStarter instead uses one superset architecture. A local-first app can ignore Supabase entirely. An app that needs accounts or shared data can reuse authentication, profile, storage, row-level security, and public/private data patterns.

The important constraint is that backend support remains optional. A future app should not become fragile simply because backend credentials are absent.

Designed for Reuse by Coding Agents

AppStarter also reflects the way I increasingly build software. Claude Code handles much of the implementation across my projects while I define product behavior, architecture, constraints, acceptance criteria, testing, and review.

That means a fresh coding-agent session needs more than source code. It needs to understand which architectural decisions are intentional and which infrastructure should be preserved. STARTER.md documents the reusable architecture, while AGENTS.md gives future agents explicit operating constraints — including a simple but important rule: do not re-scaffold the project.

The documentation is therefore part of the system, not an afterthought.

Deterministic Project Creation

A reusable starter is much less useful if each new app still requires manual copying, Git cleanup, and repository-wide search-and-replace.

AppStarter centralizes application identity into a small configuration surface and includes a PowerShell bootstrap workflow that can create a separate project, exclude .git and node_modules, apply the new app identity, preserve the starter, and initialize an independent Git history.

The project also standardizes health checks behind:

npm run validate

The intent is that both a developer and a coding agent inherit one predictable way to verify the baseline rather than reconstructing the validation process from scratch.

Reliability Over Maximum Features

Previous Expo projects showed how quickly useful-looking native dependencies can create peer conflicts, Babel changes, Jest incompatibilities, and native build problems. AppStarter therefore prefers stable Expo and React Native capabilities and avoids adding infrastructure merely because it may be useful someday.

That philosophy also led me to defer Apple Vision support even though another project was already experimenting with it. A reusable starter should inherit technology after it becomes dependable, not while it is still being proven.

Current State

AppStarter is finished and in use, though it is deliberately not published: it is internal tooling for my own projects rather than a distributed starter kit, so there is no repository or download to link to.

The first major implementation pass is complete. AppStarter contains the core Expo/TypeScript architecture, centralized application identity, local-first helpers, optional Supabase foundations, build and testing configuration, agent-oriented documentation, and the project bootstrap workflow.

The current phase is about proving the baseline rather than making it larger. Native iOS behavior — including camera capture, SecureStore/Keychain behavior, haptics, Sign in with Apple, EAS builds, and live Supabase integration — still needs real development-build verification.

The project becomes most valuable when starting the next app feels boring: generate it, validate it, and begin building the actual product.