Planning Your App with AI
Welcome to Module 3. This is where everything comes together. You have the tools, you have the prompting techniques, you know the anti-patterns to avoid. Now we build a real app — start to finish — using AI.
We are building a Todo app.
I know what you are thinking. “A Todo app? Seriously?” Yes. And here is why: a Todo app is the perfect proving ground for AI-assisted development. It is simple enough that you can build it in one sitting, but complex enough that it touches every layer of a real app — data models, persistence, views, navigation, editing, filtering, animations. If you can build a Todo app effectively with AI, you can build anything.
By the end of this module, you will have a fully functional, polished Todo app built with SwiftUI and SwiftData, and you will have done it in a fraction of the time it would take by hand.
But we are not starting with code. We are starting with a plan.
Why Planning Matters Even More with AI
Here is a counterintuitive truth: AI makes planning MORE important, not less.
Without AI, if you skip planning and just start coding, you waste your own time. With AI, if you skip planning and just start prompting, you waste time AND tokens AND you end up with a tangled mess of generated code that does not fit together. Because each prompt creates code in isolation, and without a plan, those pieces will not compose into a coherent app.
The planning phase is where you make the decisions that shape everything:
- What features go in the MVP?
- What is the data model?
- What is the architecture?
- How does navigation work?
- What are the constraints?
Get these right upfront, and every prompt you write will be grounded. Get them wrong — or skip them — and you will spend more time fixing AI output than you saved generating it.
The Planning Prompt Technique
Here is the workflow I use for every new app:
Step 1: Describe the entire app to the AI. Not a prompt to write code. A prompt to think. You describe what you want, and you ask the AI to create a plan.
Step 2: Review and refine the plan. The AI’s plan will be 80% right. You adjust the 20% that does not match your vision.
Step 3: Execute the plan step by step. Each step becomes its own prompt. The plan is your roadmap.
Let me show you exactly how this works for our Todo app.
Step 1: The Planning Conversation
Open Claude Code in your project directory and send this:
I want to build a Todo app for iOS using SwiftUI and SwiftData.
Before we write any code, I want you to help me plan the entire
app. Do not generate code yet — just think through the design.
Here is what I want:
- Users can create, edit, and delete todos
- Each todo has a title, optional notes, optional due date,
priority level (low, medium, high), and a completed status
- Todos can be organized into categories (Work, Personal, etc.)
- The main screen shows todos grouped into sections: Today,
Upcoming, and Completed
- Users can add new todos via a sheet
- Users can tap a todo to see and edit its details
- Tab-based navigation with a Todo list tab and a Categories tab
Think through:
1. What SwiftData models do we need?
2. What views do we need?
3. What is the navigation structure?
4. What should the file/folder organization look like?
5. What are the edge cases we should handle?
Give me the complete plan.
Notice what this prompt does. It uses chain-of-thought from Module 2 — it explicitly asks the AI to think before coding. It provides clear requirements but leaves room for the AI to fill in architectural details. And it asks for specific deliverables: models, views, navigation, file structure, edge cases.
Claude Code will respond with something comprehensive. It will propose the data models, list every view with its responsibilities, map out the navigation flow, suggest a folder structure, and identify edge cases like empty states and date formatting.
Read that plan carefully. This is where you catch problems early, when they are free to fix.
Step 2: Refine the Plan
The AI’s plan will probably include some things you did not ask for and miss some things you want. That is fine. Refine it:
Good plan. A few adjustments:
1. I do not need a separate Categories management screen for MVP.
Categories should be predefined (Work, Personal, Shopping,
Health, Other) — users cannot create custom ones yet.
2. Add a createdAt timestamp to the Todo model so we can sort
by creation date.
3. The Completed section should only show todos completed in the
last 7 days, not all time.
4. For the navigation: use a TabView with two tabs — Todos and
a simple Settings tab (just a placeholder for now).
5. Skip CloudKit sync for MVP. Everything is local only.
Update the plan with these changes.
This is MVP scoping in action. One of the biggest mistakes developers make — with or without AI — is building too much in the first version. Every feature you add to the plan is a feature you have to build, test, and maintain. For a learning exercise like this, we want the smallest thing that feels complete.
Feature Scoping: MVP vs. Later
Here is how I think about scoping for the Todo app:
MVP (what we build now):
- Create, edit, delete todos
- Title, notes, due date, priority, completion status
- Predefined categories
- Sections: Today, Upcoming, Completed (last 7 days)
- Add todo sheet
- Detail/edit view
- Tab navigation (Todos + Settings placeholder)
- SwiftData persistence
Version 2 (later):
- Custom categories (create, edit, delete, color-code)
- Search and filter
- Sort options (by date, priority, name)
- Notifications for due dates
- Widgets
- CloudKit sync
Version 3 (much later):
- Recurring todos
- Subtasks
- Attachments
- Shared lists
- Siri shortcuts
The point is not that these features are unimportant. The point is that you cannot build them all at once and get quality results. AI is fast, but it is not magic. Each feature needs focused attention.
Step 3: Create the CLAUDE.md
Now that we have a plan, we create the CLAUDE.md that will guide every prompt in this build. This is the most important file in the entire project.
Here is what I use for the Todo app. Send this to Claude Code:
Create a CLAUDE.md file for our Todo app project with these
specifications. Write it as a markdown file — do not generate
any Swift code yet.
And here is the CLAUDE.md we want:
# TodoApp
A native iOS Todo application built with SwiftUI and SwiftData.
Local-first, no cloud sync.
## Tech Stack
- Language: Swift 5.9+
- UI: SwiftUI
- Persistence: SwiftData
- Minimum Target: iOS 17.0
- Architecture: MVVM with @Observable ViewModels
## Architecture
### MVVM Pattern
- Every screen has a View and a ViewModel
- ViewModels are @Observable classes (NOT ObservableObject)
- Views own ViewModels via @State private var viewModel
- Views are declarative — no business logic
- ViewModels handle all business logic and data operations
### File Organization
TodoApp/ Models/ TodoItem.swift Category.swift ViewModels/ TodoListViewModel.swift AddTodoViewModel.swift TodoDetailViewModel.swift Views/ TodoListView.swift AddTodoView.swift TodoDetailView.swift CategoryPickerView.swift ContentView.swift (TabView root) Extensions/ App/ TodoAppApp.swift
## Data Models
### TodoItem
- title: String (required, non-empty)
- notes: String (optional, default empty)
- dueDate: Date? (optional)
- priority: Priority enum (low, medium, high)
- isCompleted: Bool (default false)
- category: Category? (relationship)
- createdAt: Date (auto-set on creation)
### Category
- name: String
- systemIcon: String (SF Symbol name)
- Predefined: Work, Personal, Shopping, Health, Other
### Priority Enum
- low, medium, high
- Each has a display name, color, and SF Symbol
## Coding Standards
- Use #Preview for all views
- Use .task {} for async work, not .onAppear with Task {}
- Prefer smaller, composable views
- Boolean properties: use "is", "has", "should" prefix
- Use os.Logger for debugging, not print()
- Format dates with the user's locale
## UI/UX Rules
- Follow Apple Human Interface Guidelines
- Use system colors (Color.primary, Color.secondary)
- Use SF Symbols for all icons
- Support Dynamic Type — no hardcoded font sizes
- Support Dark Mode — semantic colors only
- Use NavigationStack (not NavigationView)
- Use .sheet for modal presentations
- Minimum tap target: 44x44 points
## Do NOT
- Use UIKit or UIViewRepresentable
- Use third-party libraries
- Hardcode strings that should be localizable
- Force unwrap optionals
- Use AnyView
- Use singletons
- Add CloudKit or networking — this is local only
- Over-engineer: keep it simple and readable
Let me walk through why each section matters.
Project Overview — grounds the AI immediately. It knows this is a local-first Todo app. No cloud sync. No networking. Every time it generates code, it will respect this.
Architecture — prevents the AI from creating god objects, mixing patterns, or putting logic in views. The MVVM rules are explicit.
File Organization — tells the AI exactly where to put each file. Without this, you end up with files scattered randomly across the project.
Data Models — this is unusually detailed for a CLAUDE.md, but for a guided build like this, it is invaluable. The AI knows the exact shape of every model before we create them. When we later ask for views, the AI will reference these model definitions to create correct bindings.
Do NOT — critical. “Do not use third-party libraries” prevents the AI from importing Alamofire for a local-only app. “Do not add CloudKit” prevents scope creep. “Do not force unwrap” prevents crashes.
The Power of Planning First
Here is what we have accomplished before writing a single line of Swift:
- Clear feature scope — we know exactly what is in the MVP and what is not
- Data model design — the models are defined with all their properties and relationships
- View inventory — we know every screen we need to build
- Architecture decisions — MVVM, @Observable, SwiftData — all locked in
- Constraints — no third-party libraries, no networking, no UIKit
- File structure — every file has a home
When we start prompting for code in the next lesson, every prompt will be focused and contextual. We will not waste time explaining the architecture or debating data models. The CLAUDE.md handles all of that automatically.
This is the planning advantage. Fifteen minutes of thinking saves hours of rework.
A Note on Overthinking
There is a balance here. I have seen developers spend two hours planning a Todo app and then feel paralyzed about starting. Do not be that person.
The plan does not need to be perfect. It needs to be good enough to start. You will discover things during implementation that you did not think of during planning — that is normal. The plan is a guide, not a contract.
If you spend more than 20 minutes planning a Todo app, you are overthinking it. Get the data models roughly right, know what views you need, set up your CLAUDE.md, and start building. You can always adjust.
Closing
We have our plan. We have our CLAUDE.md. We know exactly what we are building and how it should be structured.
In the next lesson, we start writing actual code — beginning with the foundation: the data layer. We will create our SwiftData models, set up persistence, and implement the CRUD operations that power everything.
The fun part starts now.
Key Takeaways
- Planning is more important with AI, not less — unplanned prompts produce disconnected code that does not compose into a coherent app
- The planning prompt technique: describe the app, let AI create a plan, refine it, then execute step by step
- MVP scoping is essential — build the smallest thing that feels complete, then iterate in future versions
- CLAUDE.md is your project blueprint — include data models, architecture rules, file structure, and explicit “Do NOT” constraints
- Data model design before code — defining models upfront means every view prompt automatically generates correct bindings
- Do not overthink — 15-20 minutes of planning is the sweet spot. The plan is a guide, not a contract
Homework
Planning exercise (20 minutes):
- Think of a simple app idea — not a Todo app, something different (a habit tracker, a recipe book, a workout log, a reading list)
- Use the planning prompt technique: describe the app to Claude Code and ask for a plan without code
- Refine the plan — scope it to an MVP
- Create a CLAUDE.md for your app idea
- Save it — we will not build it yet, but having this plan ready will be useful for Module 4
Reflection: Compare the plan Claude Code generated with what you would have planned on your own. What did the AI think of that you missed? What did you know that the AI did not?
Mario
Founder & CEOFounder of NativeFirst. Building native Apple apps with SwiftUI and a passion for great user experiences.
Comments
Leave a comment