Building a finance app with SwiftUI and zero iOS experience

Six months ago, I couldn't tell you the difference between a View and a ViewModifier in SwiftUI. I'd never opened Xcode. My entire coding experience was JavaScript, Python, and enough SQL to be dangerous.

Today, PeerWealthy is a working iOS app. It lets couples and shared households compare their financial positions—spending patterns, savings rates, investment allocations—side by side. It's built in SwiftUI with The Composable Architecture, backed by Supabase, and designed by someone whose design tool of choice is a napkin.

Here's how a PM built an iOS app without learning iOS development in the traditional sense.

Why This App

My wife and I manage our finances separately but make big decisions together. Every few months, we'd sit down with spreadsheets and try to figure out where we stood relative to each other. Are we saving at the same rate? Who's spending more on discretionary stuff? Are our investment strategies aligned?

The spreadsheet approach was tedious and the data was always stale. I wanted something that pulled in real data and showed us a live comparison. Nothing like this existed.

I tried building it as a web app first. It worked, but the experience was wrong. Finance is personal. People check it on their phones, quickly, privately. A native iOS app was the right form factor.

Problem: I don't know Swift.

The Decision to Build Anyway

I'd already been using Claude Code daily for building products and automations. I knew it could write SwiftUI. The question was whether it could write a complete app—not a demo, not a tutorial project, but something with authentication, data persistence, complex state management, and real-world edge cases.

I decided to find out. Worst case, I'd learn something. Best case, I'd have an app.

The approach was simple: I'd be the product manager. Claude Code would be the engineer. I'd make every product decision—what to build, why, for whom, how it should feel. Claude Code would handle the implementation.

Choosing the Architecture

This is where things got interesting. I didn't know enough about iOS to choose an architecture, so I researched first. Read about MVVM, MVC, VIPER, TCA. Asked people I trust. Looked at what modern SwiftUI apps use.

I landed on The Composable Architecture (TCA) by Point-Free. Here's why:

Predictable state management. TCA uses a unidirectional data flow pattern. State goes in, actions come out. Every state change is explicit and traceable. For someone who doesn't intuitively understand iOS patterns, this predictability was essential.

Testability. TCA makes testing straightforward because all logic lives in reducers—pure functions that take state and actions and produce new state. I could write tests that verified behavior without understanding UIKit lifecycle methods.

Great documentation. Point-Free has extensive tutorials and documentation. When Claude Code generated something I didn't understand, I could look it up.

Claude Code knows it. This was the practical reason. TCA is well-represented in Claude's training data. It generates idiomatic TCA code consistently.

The tradeoff: TCA has a steep learning curve and adds boilerplate. For a solo developer, the overhead felt heavy at first. But the structure it imposed saved me from the chaos that would have ensued without it.

The Stack

Here's what PeerWealthy runs on:

• SwiftUI — Apple's declarative UI framework. It's the obvious choice for new iOS projects.
• TCA — State management and architecture. All business logic lives in reducers.
• Supabase — Backend-as-a-service for auth, database, and real-time subscriptions. I chose it over Firebase because the PostgreSQL foundation gives me more flexibility, and the SDK is clean.
• Swift Charts — Apple's charting framework for visualizing financial comparisons.

I deliberately kept the stack minimal. Every additional dependency is a surface area for bugs I can't debug.

The Build Process

Phase 1: Authentication and Data Model (Week 1-2)

I started with the foundation. User authentication through Supabase, the core data model for financial profiles, and basic CRUD operations.

My prompts were product-oriented: "Create an authentication flow with email/password and Apple Sign In. After login, check if the user has an existing financial profile. If yes, go to the dashboard. If no, go to onboarding."

Claude Code generated the TCA features, the SwiftUI views, the Supabase client configuration. I reviewed each file, ran the app in the simulator, and iterated.

The first version took three days to get authentication working end-to-end. Two of those days were spent on Supabase configuration issues that had nothing to do with Swift.

Phase 2: Financial Profile Entry (Week 3-4)

This was the core of the app. Users enter their financial data across categories: income, fixed expenses, variable spending, savings, investments, and debt.

I designed the data model on paper first. Categories, subcategories, amounts, frequencies. Then I described each screen to Claude Code: "Create a form for entering monthly expenses. Categories are rent, utilities, groceries, transportation, subscriptions, and other. Each category has an amount field and an optional notes field. Show a running total at the bottom."

The SwiftUI forms came together quickly. TCA handled the state management cleanly. But I hit my first real wall: data validation.

Financial data has constraints that aren't obvious. Monthly vs. annual amounts need normalization. Percentages should sum correctly. Currency formatting varies by locale. Claude Code got the basic validation right but missed edge cases. I spent a week finding and fixing data integrity issues.

Lesson learned: describe your constraints explicitly. "The savings rate is calculated as total savings divided by net income, displayed as a percentage, capped at 100%" is better than "show the savings rate."

Phase 3: The Comparison Engine (Week 5-7)

This is what makes PeerWealthy different. Two users in a household can compare their financial positions side by side.

I designed the comparison views on paper: bar charts showing spending by category for both partners, line charts showing savings rate over time, a summary card highlighting the biggest differences.

Implementing this meant:

• Real-time data sync between two users via Supabase subscriptions
• Calculating deltas across every category
• Building comparison visualizations with Swift Charts
• Handling asymmetric data (one partner has investment data, the other doesn't)

Claude Code handled the SwiftUI layouts and TCA state management well. The Supabase real-time subscription integration was trickier. The Swift SDK's real-time features were less documented than the JavaScript version, and Claude Code sometimes generated patterns from the JS SDK that didn't translate.

I ended up reading the Supabase Swift SDK source code on GitHub—not to write code, but to verify what Claude Code generated. A PM reading framework source code. Strange times.

Phase 4: Polish and Edge Cases (Week 8-10)

This phase was the hardest and the one where AI assistance helped the least.

Animations and transitions. SwiftUI animations are declarative, which sounds simple until you want a specific timing curve on a chart that's loading asynchronously. I spent days tweaking .animation() modifiers and withAnimation blocks. Claude Code would generate something that technically animated, but it didn't feel right. The last 20% of polish required manual iteration in Xcode's preview.

Keyboard handling. Financial forms have lots of number inputs. The keyboard behavior—showing the right keyboard type, dismissing on tap, scrolling to keep the active field visible—required more manual fiddling than I expected.

Empty states. What does the comparison view look like before your partner has entered data? What about before you've entered data? Every screen needed an empty state, a loading state, and an error state. Claude Code generated these reliably when I asked, but I had to remember to ask.

Dark mode. I didn't think about dark mode until week 8. Retrofitting it was painful. Start with dark mode from day one.

What AI Got Right

Boilerplate generation. TCA requires significant boilerplate—feature structs, actions, reducers, views. Claude Code generates this flawlessly. What would take an experienced developer 20 minutes takes 30 seconds.

SwiftUI layouts. Describing a layout in words and getting working SwiftUI code is genuinely magical. "A card with a title, a horizontal bar chart, and a label showing the percentage difference" → working code on the first try, most of the time.

Supabase integration. CRUD operations, authentication flows, basic queries—Claude Code handles these cleanly because the patterns are well-established.

Code organization. When I said "this file is getting too large, refactor it into separate features," Claude Code made sensible decisions about how to split things up. It understood TCA's conventions for feature composition.

What AI Got Wrong

Platform-specific knowledge. iOS development has tons of tribal knowledge. When to use @StateObject vs @ObservedObject. How to handle the keyboard on older devices. Why your SwiftUI preview crashes silently. Claude Code sometimes generates code that's technically correct but doesn't account for platform quirks.

Third-party SDK specifics. When a library has sparse documentation or recent API changes, Claude Code hallucinates. The Supabase Swift SDK caught me here multiple times. I'd get code that looked right, compiled fine, but failed at runtime because a method signature had changed.

Performance intuition. Claude Code doesn't flag performance issues proactively. It'll happily generate a view that recalculates an expensive comparison on every frame if you don't tell it to cache the result. I learned to ask: "Is there anything in this code that would cause performance issues?"

Design judgment. It can implement any design you describe. But it can't tell you whether a design is good. That's still a human job—and arguably the most important one.

What I Learned About Building as a PM

Product Sense Is the Bottleneck

With AI handling implementation, the quality of the product depends entirely on your product decisions. What to build. What to leave out. How it should feel. When to ship.

I made plenty of bad decisions. I built a budgeting feature that I later removed because it didn't fit the core value proposition. I over-engineered the comparison engine before validating that people actually wanted granular category-level comparisons (they mostly wanted the summary).

These aren't coding mistakes. They're product mistakes. And no AI tool prevents them.

You Need to Read Code, Not Just Generate It

I can't write Swift from scratch. But I can read it now. I understand TCA patterns, SwiftUI view lifecycle, Supabase client configuration. This reading fluency is essential for reviewing what Claude Code generates.

Without it, you're shipping code you don't understand. That's fine for a prototype. It's terrifying for an app that handles financial data.

Constraints Force Better Products

Having zero iOS experience was actually a constraint that improved the product. I didn't know how to build complex features, so I built simple ones. I didn't know enough architecture patterns to over-engineer, so I kept things straightforward.

The result is a focused app that does one thing well. A more experienced developer might have built something more technically impressive and less useful.

Side Projects Need Deadlines

I gave myself 10 weeks. Without that constraint, PeerWealthy would still be a collection of half-finished features. The deadline forced me to cut scope ruthlessly. The budgeting feature? Cut. The social sharing feature? Cut. Multi-currency support? Later.

Ship the core experience. Add features based on real user feedback.

The Numbers

For the curious:

• Timeline: 10 weeks, evenings and weekends
• Lines of code: ~12,000 (generated by Claude Code, reviewed and edited by me)
• Screens: 14 main screens
• TCA features: 8 composable features
• Supabase tables: 6
• Times I wanted to quit: 3 (authentication, keyboard handling, App Store submission)
• Total cost: $20/month for Supabase, $20/month for Claude Pro, $99/year for Apple Developer Program

Would I Do It Again?

Absolutely. Not because the process was smooth—it wasn't. But because the alternative was not building it at all.

Before Claude Code, a PM who wanted to build a native iOS app had two options: learn iOS development for 6-12 months, or find a co-founder who's an iOS developer. Both are significant commitments for validating a product idea.

Now there's a third option: describe what you want to build, review what gets generated, and iterate until it works. It's not as fast as people claim on Twitter. It requires more technical understanding than zero. But it's dramatically more accessible than the traditional path.

The early AI adopter lessons apply here too. The technology isn't magic. It's a tool that amplifies your existing skills. If you have good product sense, AI helps you build good products faster. If you don't, it helps you build bad products faster.

I had the product sense. I didn't have the engineering skills. Claude Code filled the gap.

PeerWealthy is live and I use it with my wife weekly. It's not perfect. The charts could be prettier. The onboarding could be smoother. But it exists, it works, and it solves a real problem.

That's more than most side projects can say.