What Happens When a Designer Opens Xcode
How We Build
Jesper Ellesson is a UX Designer at Fantasy. Over a weekend, he built a gym tracker for iOS using Claude Code and Xcode. He'd never opened Xcode before.
The problem
Designers spend their days building things people can look at but never touch. Static prototypes get clicked through in meetings. They cannot answer the question clients actually care about: how does this feel in use? Jesper wanted to close that gap himself, on his own time, with tools that were finally good enough to let a designer ship real software.
What made you actually do this?
“I saw colleagues around me building real things with AI tools, and I wanted to try it for myself. I’ve been hacking together websites since I was a teenager, but I always found the technical side too complicated and too long to learn properly. When I saw how quickly people were going from idea to working software, I realized I could finally start taking my own ideas into reality.
“I’ve always wanted to create an iOS app. And I realized there was nothing stopping me. So I found some time and got to work.
“As to why this particular project: it was a combination of FOMO, curiosity, and personal need. I’ve tried plenty of gym apps that do the same thing, but you always hit a paywall or there are just too many features I don’t need. I wanted something very simple and genuinely useful. When I go to the gym I just need my routine, my weights, and a timer. That’s basically it.”
The first hour in Xcode
“I went to YouTube and typed “Xcode + Claude” and found a great beginner’s video from a YouTuber named Alex Finn. That made the setup fairly easy.
“But I hit a wall when I tried to run the app on my phone for the first time. I was like, how do I see what Claude has made? I want to put it on my phone. How the hell do I put it on my phone? This seemingly obvious thing was not obvious at all. I had to troubleshoot with ChatGPT to figure out how to set my iPhone into Developer Mode and actually install the app on my device.
“That was the hardest part of the whole experience. The environment setup, every bit of it.”
The prompt
“The initial prompt went something like this:
"I want to build a simple iPhone app in Xcode that helps me at the gym. I need it to be able to create routines. I need to be able to add exercises within that routine. I need to be able to search from a library of common exercises to add to a routine. I need to be able to input what weight and how many reps I did for that exercise. I need to be able to see the weight and sets I did previously. I need to be able to reorder the exercises within the routine. I want to be able to start a routine, and when I start a routine I need a rest timer between each set. Once I’m finished with the routine I want a list view of all my previous routines I finished.
“A colleague recommended I use the Planner inside Claude Code. That was mega helpful. I sent it that long paragraph of features and some very light art direction, it asked me a few clarifying questions, I approved the plan, and in a ridiculously short amount of time I had a working app on my iPhone.”
Where it broke down
“Mostly it just worked. But as I tested the app I started to notice small bugs. When I tapped the input field to type the weight for an exercise, there was no way to dismiss the keyboard. I described the problem to Claude in plain language and it sorted it out immediately.
“The surprise was how conversational the debugging felt. I didn’t need to understand the code to explain what was wrong, and Claude understood the context because it had built the thing in the first place.”
The moment it shifted
"The moment I opened the app the second or third time after fixing some bugs, I realized it was going to work. I had discovered that I could just iterate and improve infinitely. At that point I couldn't go to sleep. I was up until 4am going back and forth, adding features and starting to see that I could create more of an experience: an intro splash screen, an animation after the workout was finished.
"That's when it stopped being an experiment."
What I'd do different
“I’d try React Native so it would work on Android as well. And I’d plan more. I’d really think through the features in a much more comprehensive way before building, rather than figuring it out as I went.
“That’s the part that felt most familiar to me, actually. Defining what the app should do, thinking through the user flows, understanding how someone would actually use this thing at the gym. That’s what I do every day as a designer. I just didn’t realize until this project that the same thinking could take me all the way to a working app.”
Jesper spent a weekend building an app he now uses at the gym every week. Claude Code handled the Swift. The hardest part of the whole experience was environment setup: developer mode, device provisioning, getting the build onto his phone.
Once that was sorted, the rest was the work he already does every day: defining features, thinking through flows, deciding what the experience should feel like in someone’s hand. The skill that carried the project was the one Jesper already had.Want to test it for yourself? SimpleGym is now live on the App Store.
How to build your first iOS app with Claude Code, even if you've never coded
Install Xcode from the Mac App Store and install Claude Code. You do not need to know Swift: Claude Code writes it, and Xcode builds and runs it. If you have never opened Xcode, a short beginner video helps; Jesper searched "Xcode + Claude" on YouTube and followed Alex Finn's walkthrough. Create a new SwiftUI project and point Claude Code at that folder.
Before building, write the full feature set as a single paragraph, the way you would brief a designer. Jesper's covered creating routines, adding exercises, searching a library of common exercises, inputting weight and reps, seeing previous weights and sets, reordering exercises, starting a routine with a rest timer between sets, and a list view of finished routines. This paragraph is the design work.
Open Claude Code in plan mode, paste your paragraph plus a little art direction, and have it propose an implementation plan before writing any code. Answer its clarifying questions, approve the plan, and let it build the first working version.
This was the hardest part, and it is setup, not code. On the phone: Settings, Privacy and Security, Developer Mode, toggle on, restart. In Xcode: Settings, Accounts, add your Apple ID (it becomes a free Personal Team); in Signing and Capabilities, turn on Automatically manage signing and pick that team; connect your iPhone, tap Trust, select it, and press Run. A free Apple ID installs to your own device (signing renews every 7 days); the paid $99 per year program is only for publishing to the App Store.
As you test on your phone you will hit small bugs (Jesper's example: tapping the weight field left no way to dismiss the keyboard). Describe each one to Claude Code in plain English; because it built the app, it has the context to fix it fast. You never have to read the code to say what feels wrong.
Once the core works, add the touches that make it feel real (Jesper added a splash screen and a finish animation). When ready, enroll in the Apple Developer Program and submit, the way SimpleGym reached the App Store.
Frequently asked questions
Yes. Jesper Ellesson, a UX designer at Fantasy, had never opened Xcode before and had always found the technical side of building too complicated to learn properly. Over a weekend he shipped a working gym tracker to the App Store using Claude Code, which handled the Swift. He did not need to read or write the code himself. The skill that carried the project was the one he already had as a designer: deciding what the app should do and how it should work.
You set the iPhone into Developer Mode and install the build on the device. For Jesper this was the hardest part of the whole project. Getting what Claude Code had made onto his actual phone was not obvious, and he had to troubleshoot with ChatGPT to get the phone into Developer Mode and the build installed. Once that environment setup was done, the rest was the design work he does every day.
The judgment work is the same craft a designer already practices: defining the features, thinking through the user flows, and deciding how someone would actually use the thing in context. Jesper's takeaway was that this thinking, the part that felt most familiar to him, is what carried the project all the way to a working app. Claude Code produced the code, and the decisions about features and how the experience should feel in someone's hand were his.