Back to Blog
·4 min read

Vibe Coding an App in 2026: What I Learned Building My First iOS Release

I decided to document my experience building my first app — not because everything went smoothly, but because it didn't. If you're thinking about building your own app, hopefully this saves you a few headaches.


How It Started: Cursor, Claude, and the Search for Autonomy

I started by researching agentic AI coding platforms and landed on Cursor. Honestly, I enjoyed it at first. The workflow felt good. But over time I kept hitting bugs that Cursor struggled to resolve, and I found myself needing something more powerful — something that could run autonomously, iterate on its own, and keep digging until the problem was actually solved. The Cursor workflow was getting too manual for what I needed.

That eventually led me to a Claude Max subscription — around $140 CAD a month — which gave me access to tools like Claude Code and Claude Cowork. Cowork in particular was useful for autonomous testing sessions and for navigating the App Store submission process. I could define a goal, step back, and let it run.

That said, there were bugs that even hours of AI-assisted debugging couldn't fully crack. At a certain point I brought in ChatGPT's Codex to take a second look. Different models think differently, and sometimes a fresh perspective — even a synthetic one — is exactly what you need.


The Real Challenges

The looping algorithm.

The core feature of my app was seamless audio looping — the kind you'd expect from DJ software or a DAW. In practice, this meant the audio had to loop without any clicks, gaps, or timing artifacts at the loop point. It sounds straightforward. It wasn't. This one feature alone required many hours of troubleshooting to get right.

Feature creep.

I got ambitious and decided to add a low-pass filter so users could dial in the texture of the sound — roll off the highs, keep things smooth. The UI was there. The slider worked visually. But the actual filter functionality refused to behave consistently across builds. It became a rabbit hole, and eventually I made the call to ship without it. That was the right decision.

No Mac, no speed.

I started developing for iOS without a Mac, which meant every build had to go through Expo EAS — a cloud build process that's functional but slow. Testing something as nuanced as audio looping through a remote build pipeline is painful. I eventually invested in a MacBook Neo specifically to speed this up, and it made a genuine difference. Quick local builds straight to my iPhone meant I could test and iterate in a fraction of the time. If you're building an iOS app, just get a Mac. It's not optional if you're doing anything hardware-adjacent.


Where Things Stand

The app is submitted and awaiting Apple's review. There's a minor flag on one of the promotional images — nothing major, and we expect to have it sorted shortly. We're close.


Lessons for Anyone Starting Out

Start simple. If this is your first app, pick an idea with a small surface area. Get familiar with the submission process, the toolchain, and the feedback loop before you take on something technically ambitious.

Learn Git early. I ran into a situation where a key feature was working, then broke during later development, and we spent hours trying to restore functionality that had already been solved. If I'd been more disciplined about committing working states to GitHub, that recovery would have taken minutes. Learn what a commit is, use it constantly, and treat GitHub as your safety net.

Vibe coding is real — but it's not magic. Building an app in 2026 with AI assistance is genuinely more accessible than it's ever been. But it's not a one-click process, and it probably shouldn't be. Apps take time to develop properly. Features need to be tuned. Bugs need to be hunted down. Use multiple AI tools, stay patient, and don't confuse "accessible" with "easy."

If you put in the work, you can ship. We're almost there.


Have questions about the process? Drop me a line via the contact page — happy to help.