Capstone — the spec: scope a real, shippable app
Unit 31 · Capstone. This is the whole ladder in one project: your app, your choice, shipped to TestFlight or the App Store. AI stage: Professional throughout. This spec lesson is where you scope it honestly — the single most important decision you will make.
Every project so far handed you a spec. The capstone does not. You choose the app, and the first way capstones fail is scope: a learner picks "a social network with video and real-time chat and payments," builds none of it well, and ships nothing. A shippable app that does one thing correctly beats an ambitious app that does not run. Your job in this lesson is to scope something you can actually finish and submit.
Choose from a guided template (or bring your own)
If you have an idea, use it. If you do not, pick one of these — each is a known-good capstone shape that exercises the full stack without sprawling:
- A focused tracker (habits, workouts, reading, expenses): SwiftData persistence, charts, a clean list/detail. Tier 0–1. Ships in a weekend if scoped tight.
- A single-purpose API client (transit times, air quality, a sports team):
URLSessionCodable,@Observablestate, offline caching. Tier 0 (public API).
- A small social or sharing app (a book club, a recipe box with a friend): auth, a feed, media upload. Tier 2 (Supabase) or Tier 3 (AWS) — reuse Snapgram or Loops's domain layer.
- A utility with a system integration (a timer with Live Activities, a player with background audio): reuse the Trackcast patterns. Tier 0–1.
The best capstone is the smallest app you would actually be proud to show in an interview. "It does one thing, it does it correctly, it is on TestFlight, and I can walk you through every architectural decision" is a stronger portfolio piece than a half-working clone of a famous app.
Pick a backend tier honestly
The tiers are not a difficulty leaderboard. Pick the lowest tier that your app genuinely needs:
| Tier | Means | Choose it when |
|---|---|---|
| 0 | No persistence or a public API only | The app is stateless or reads a public API |
| 1 | Local persistence (SwiftData) | Data is per-device and private |
| 2 | Supabase (managed backend) | You need accounts and shared/synced data, fast |
| 3 | AWS (Cognito, API Gateway, Lambda, S3) | You want to demonstrate cloud infra depth |
A well-built Tier 1 app scores higher than a broken Tier 3 one. Choose the tier that serves the app, and be able to say why you did not go higher. "I chose Tier 1 because the data is private to the device and a server would add operational risk for no user benefit" is a senior answer.
Write the spec
Produce, before you write code, a one-page spec in the shape you have seen eight times:
- What it is — one sentence a stranger understands.
- The screens — a table of screens, their inputs, and their outputs.
- Concepts it exercises — the Swift/SwiftUI/backend features you will demonstrate.
- In scope — the finishable list.
- Out of scope — the tempting features you are deliberately not building, named explicitly.
- Definition of done — the concrete "a person can do X and Y and it is correct" statement.
The out-of-scope list is the one that saves you. Writing "no real-time sync, no social graph, no Android" down makes the cuts real instead of guilt you carry while overbuilding.
The bar
Because this is the capstone, "done" means more than "runs on my simulator":
- Builds clean, no warnings you cannot justify.
- Swift 6 strict concurrency on, no
@uncheckedwithout a written reason. @Observablestate, SwiftData or a clean repository boundary for persistence.- Swift Testing coverage on the logic that matters.
- Light and dark correct, VoiceOver on interactive controls, tokens only (no raw hex).
- On TestFlight or the App Store, installable on a real device.
- A written AI-workflow reflection (a graded artifact — see Milestone AI writeup).
Knowledge check
Q: Why is scope the first way a capstone fails, and what is the antidote? Because an over-scoped app ships nothing — breadth with no depth and no submission. The antidote is an explicit out-of-scope list written before coding, turning the temptation to overbuild into decisions you already made.
Q: Is choosing a lower backend tier a weaker capstone? No. The tier should fit the app's real needs, and a well-built lower-tier app beats a broken higher-tier one. What is graded is the correctness of the architecture and your ability to justify the tier, not the tier number itself.