Originally published on LinkedIn – Read the original post
The first two articles in this series were about ideas and feelings. This one is about what happened, the workflow, the failures, the moments where everything went sideways, and the honest verdict on whether any of this was worth it.
It was. But let me tell you what it looked like.
How the workflow evolved
I didn’t start with a sophisticated setup. I started by copying and pasting. Early sessions with ChatGPT involved generating code in a desktop chat window and manually dropping it into Xcode. No integration, no continuity, just a lot of switching between windows and hoping nothing broke.
The toolset evolved from there. AI tools came directly into Xcode, which helped. Eventually I settled into Claude Desktop alongside Claude in Xcode and added GitHub for project tracking. My current setup might look strange to a traditional developer, but it works.
Here’s how it runs: I have two Claude sessions going at the same time. One is the architect. One is the programmer. They serve completely different purposes and keeping them separate is one of the most important things I figured out.
The two-Claude system
The architect session lives in Claude Desktop. This is where strategy happens. We discuss goals, direction, what I want the app to do and equally important, what I don’t want it to do. When I find a bug in testing, I bring it here first. When something isn’t working the way Apple recommends, I ask here. Recently I had issues with notifications not behaving correctly and I asked Claude Desktop: is this the right approach, is this current, is this how Apple wants developers to approach it? That kind of architectural review is invaluable.
Claude Desktop also tracks everything in GitHub and, critically, generates the prompt that goes to the programmer session. It doesn’t just identify the problem. It writes the exact instructions needed to fix it, accounting for the overall project context, the architecture decisions we’ve already made, and the approach we want to take.
The programmer session lives in Claude within Xcode. It receives that prompt and executes it. It touches the code. It makes the changes. It doesn’t need to know the whole project history because the architect has already distilled everything it needs into a precise set of instructions.
When I’ve tested and everything works, I report back to the architect, the GitHub issue gets closed, and we move to the next one.
It sounds complicated written out. In practice it feels like having a project manager and a developer on call at the same time.
What went wrong
Here’s the honest part.
The programmer Claude occasionally goes off script. You describe a problem, you know roughly what the fix should be, and instead of making the targeted change you asked for, Claude starts making broader modifications, touching things that didn’t need touching, solving problems you didn’t have. You must learn to recognize when this is happening and pull it back. Clear, specific prompts help. The more precisely the architect defines the task, the less room the programmer has to improvise in unhelpful directions.
The bigger failure mode was a single incident that tested everything I had.
I had just finished a batch of changes. Ran the app in the simulator, everything looked good. Exited, decided I wanted to check something, reloaded. The app hung on the launch screen. Nothing. Just the launch screen sitting there.
I started troubleshooting with Claude. We added debug lines, console print statements, trying to see what was happening. Nothing showed up in the logs. It was as if the app wasn’t running at all, just displaying a static image of its own launch screen.
So, I rolled back to the previous commit. Same problem. Rolled back again. Still broken. I kept going back through the commit history, undoing hours of work, and nothing changed. Claude suggested approaches, I tried them. Reset the simulator. Restarted Xcode. Nothing worked.
I’ll be honest: I was rattled. This is the part of the experience that’s genuinely hard when you don’t have deep technical expertise. When something breaks in a way you don’t understand and the tools that are supposed to help you can’t find the answer, it’s easy to feel lost. I felt lost.
And then I did what 36 years of problem-solving experience taught me to do. I stopped. I calmed down. I stopped following Claude’s suggestions and started thinking systematically on my own.
Eventually I found it. Xcode had updated, but the simulator environment hadn’t finished downloading the corresponding update. The app wasn’t broken. The simulator was incomplete. There was a download quietly happening in the background with no clear indication that this was the issue. Once it finished, everything worked. I reapplied all the rolled-back code and the app ran perfectly.
Claude didn’t solve that problem. I did. And that matters.
Before a single line of code
If I were starting over today, the first thing I’d tell someone is this: before you ask AI to write anything, have a long conversation about what you’re building.
Not a requirements document. A conversation. Talk through the goals. Talk through what you want and what you don’t want. Ask what the platform is capable of. Get a reality check on your ideas before you’ve invested hours building in the wrong direction. Ask Claude to push back on your assumptions.
This is the step most people skip and the one that pays the biggest dividends. The clearer your vision going in, the more useful every interaction becomes after that.
Here’s what that looks like in practice. Before writing a line of code, work with Claude to produce actual documents: an architecture document, a design document, a list of decisions you’ve made and why. These become living references that both you and Claude can return to throughout the project. They keep the work grounded when things get complicated, and they give Claude the context it needs to make good decisions rather than just technically correct ones.
Then set up a Claude Project for your app and have all your development conversations inside it. Add those architecture and design documents to the project so Claude always has them available. Write project instructions that keep every conversation focused on your goals, your constraints, and your decisions. This sounds like overhead. It isn’t. It’s the scaffolding that keeps the whole thing from drifting.
GitHub plays a similar role. Once you have your plan and your architecture, you need a place to track every task, every decision, every bug, every next step. GitHub issues give you that. But take it a step further: connect Claude to your GitHub directly so it can open issues, update them, and close them out without you having to do it manually. Claude becomes the project manager, not just the programmer. Nothing gets lost, nothing gets forgotten, and you always know exactly where things stand.
The other connection worth making: enable the Filesystem connector in Claude Desktop. This lets your architect Claude read your project files before telling the programmer Claude what changes to make. Instead of working from memory or your description of the code, it can review what’s there. That difference matters. Instructions based on the real current state of your files are more precise, less likely to conflict with something else, and far less likely to send the programmer off in the wrong direction.
The other thing I’d say: expect your workflow to change. Mine looked nothing like my current setup six months ago and I expect it to keep evolving. The tools are moving fast. Stay curious and stay flexible.
The honest verdict
This was an experiment at the beginning. I genuinely didn’t know if someone with my background, deep in IT but decades removed from hands-on development, could build a real, published iOS app using AI as a coding partner.
The answer is yes. Unambiguously yes.
And I’m not done. I have a pipeline of app ideas and the confidence now to build each of them. The experiment became a method. The method became a practice. And that practice is shaping what I plan to do in retirement.
The tools aren’t perfect. The workflow takes time to develop. There will be moments where you feel lost and the AI can’t find the answer either. But if you bring domain expertise, clear vision, and the patience to manage the process like the leader you already are, you can build things you never thought you could build.
I know because I did it. And I’m already doing it again.
This article is Part 3 of a three-part series, Building with Claude. Read Part 1 and Part 2.