Vibe Coding a Cross-Platform App: Building a Daily Word Game with AI in 24 Hours

I've been a professional iOS developer for about 10 years. I've shipped apps at companies, contributed to open source, and built plenty of side projects the traditional way.

At work, I use Claude with guardrails - code review, tests, careful commits. But for indie projects, where code quality matters less and the goal is simply validating an idea and shipping something I'd actually use, I wanted to try the opposite: a fully hands-off approach where AI drives the entire process while I observe how my workflow and instincts change.

The question wasn't whether vibe coding could handle a hard problem. It was simpler: how fast can I go from idea to the App Store when I stop writing code entirely and just give in to the vibe.

The project: a daily word puzzle game called UnJumbl, built for both iOS and Web. My girlfriend and I play the NYT games every day, so I knew I'd actually use this. The core mechanic is simple (unscramble letters, find words) - the project itself isn't particularly complex. There are a few genuinely interesting technical problems — consistent hashing algorithms between iOS and Web so both platforms deterministically select the same puzzle each day, local persistence and caching strategies, advanced animations — but nothing that should stump a seasoned developer or, in theory, AI.

I did almost no upfront planning. I started with a single sentence describing the idea, bounced it between Claude and ChatGPT to generate a rough requirements doc, and then handed it back to Claude to implement without even reading through it myself.

I gave zero design guidance — no fonts, no color schemes, no mockups of what the gameplay view should look like. All of that emerged from the dialogue between ChatGPT and Claude as they handed the evolving requirements back and forth. I wanted to see how far it could get on its own with minimal hand-holding.

24 hours later, the Web version was deployed and the iOS app was in review.

What I Built

UnJumbl gives you 6 scrambled letters each day and you find all the valid 3-to-6-letter English words hiding in them. Same puzzle for everyone, every day. There's streak tracking, a GitHub-style contribution heatmap, a share card, and a reward system where you get 3 free reveals per puzzle with more available via rewarded ads.

Both platforms were built within the same 24-hour window. The Web version went live immediately, while the iOS app landed on the App Store a few days later after clearing review.

The Tech Stack

iOS: SwiftUI, MVVM, Google AdMob, Firebase Analytics, Lottie

Web: Next.js 16, TypeScript, Tailwind CSS, Google AdSense, GA4, Lottie

Both platforms share the same word dictionary and use identical puzzle generation logic. There's a server for hosting the website, but there's no database, no API, and no backend logic. All the game logic runs on the user's device.

How the Vibe Coding Workflow Played Out

The workflow was almost entirely hands-off. I used a Ralph loop — an automated feedback cycle where Claude writes code, builds, encounters errors, and fixes them on its own without me intervening. I passed in the Markdown requirements doc and set the iteration count to 3. What came out the other side was a perfectly playable game. Shippable even.

From there, I had a few minor iterations to lock down font sizes and animation timings, but these were trivial corrections. The core gameplay, the UI, the state management — all of it landed in that first automated pass.

What went fast:

• Setting up the project structure and boilerplate: ad integration, analytics, privacy prompts. The kind of work that is well documented but tedious to wire up manually.
• Porting the game logic from the iOS app to the website. When it came time to build the Web version, I could basically say, “Here’s how this works on iOS. Do the same thing for the Web matching it 1:1.” Claude produced a working version in its first iteration.
• All the behind-the-scenes Web details: metadata that makes links look good when shared on social media, a sitemap so Google can discover the pages, privacy manifests, and other peripheral pieces you normally have to remember to add.

What didn’t go fast:

• Anything involving timing and race conditions. The auto-submit feature (valid words submit themselves after a short delay) had edge cases that Claude kept cycling on. Tapping letters quickly could trigger a submit before you were done spelling. It kept generating solutions that looked right but had subtle sequencing bugs, and it took several rounds of prompting before Claude converged on a fix.
• Ad integration was painful. Rewarded ads specifically. The flow of "load ad, show ad, wait for completion, grant reward, handle failure, hide ad banner if no ads availabe" touches a lot of state and has to work with the Google SDK's lifecycle, which is... not always intuitive. Claude burned through several iterations on this before it stabilized.
• Anything that required taste. How long should the auto-clear delay be? How should the tiles animate? What does "done" look like for the results screen? Should the result screen feel celebratory or minimal? These are judgment calls. The AI can implement any answer to these questions, but it can't tell you which answer is the right one.

Features That Emerged During the Process

Several technical decisions and features appeared that I never explicitly prompted for. I only noticed them after the implementation was already finished.

My original prompt was just a single sentence describing the idea. As Claude and ChatGPT iterated on the requirements, additional capabilities made their way into the build without me ever specifying them directly.

Deterministic push notification previews. Because the puzzle is fully deterministic, the iOS app can pre-generate tomorrow’s puzzle and include the scrambled letters directly in a scheduled local push notification. Users get a teaser like “Today’s letters: R A M B L E” before even opening the app.

Drag-to-select with line drawing. Both platforms ended up with a draggable letter selection system where a line is drawn between selected tiles in real time, with a dashed preview line from the last tile to the current finger or cursor position. The original idea only mentioned selecting letters, but the implementation expanded that into drag-to-select with visual feedback.

Onboarding spotlight cutouts. The first-launch tutorial highlights specific UI elements by punching transparent holes in a dimmed overlay. The final implementation included a full spotlight system with animated cutouts. Each platform used a different rendering approach, but the visual result is the same.

Share card rendering. The results screen generates a shareable image on both platforms. The implementation includes the full pipeline: rendering the results view to an image and passing it to the native share sheet.

What It Cost

Basically nothing. The domain unjumbl.app was $13 and that was the only new expense. I already have a VPS where I host all of my other websites, including this blog, so hosting the Web version didn't add anything to my existing fixed yearly fee. The iOS app runs entirely on the user's device, so there's no server cost there either.

The Apple Developer Program is $99/year, but I already had that for other projects. No database, no cloud functions, no ongoing costs beyond what I was already paying.

Things I'd Do Differently

The project wasn't hard. These aren't lessons about the technical challenges — they're about learning how to delegate to AI more effectively.

Start with the Web version. I built iOS first because it's what I know. Bad call. For a daily puzzle game, the Web is the distribution channel. Wordle didn't take off because of an app. It took off because people could share a link directly to the puzzle. Beyond distribution, the tooling gap matters — AI-assisted development on the Web is significantly more mature. MCP tools like XcodeBuildMCP exist for iOS, but the Web ecosystem has had tighter feedback loops for longer. Claude can spin up a dev server, inspect the DOM, and iterate in ways that aren't as seamless with a simulator. If I'd built the Web version first and let AI iterate to a working product with full visibility, then done a one-shot port to iOS, I think the total time would have been even shorter.

Curate your word list manually from the start. Claude's initial attempt at generating a word dictionary was rough. It included obscure three-letter words that no normal person would know — the kind of words that make players feel like the game is broken. When I gave it that feedback, it pivoted to finding existing open-source word lists on GitHub and repurposing them, which was smarter. But even after many rounds of prompting to distill the list down to only common, recognizable words, it still wasn't great. I eventually had to do a manual pass myself, and even now I'm occasionally finding words that probably shouldn't be in there. For a game where the word list is the product, this isn't something you can fully delegate.

Build one platform as the reference, then port. Write comprehensive tests for the first platform, then use those tests as the acceptance criteria when porting to the second one. This would have caught cross-platform bugs way earlier.

What I Actually Learned

Here's the thing I keep coming back to: I never once opened Xcode to look at code during this project. Not once. Everything was done through Claude, Xcode CLI tools, and the terminal. I didn't read a single line of Swift or TypeScript. For someone who has spent 10 years as a professional developer — someone who would normally be deep in the debugger, stepping through breakpoints, reading stack traces — that felt genuinely surreal. And it worked.

The biggest takeaway is that for a project like this, the coding was almost an afterthought. What actually took the most time was assembling the App Store screenshots, writing the descriptions, choosing the right keywords, designing the icon. The meta-work around shipping took longer than the development itself. That's a strange thing to type, but it's true.

My relationship with commits changed too. In professional development, I commit frequently and in small, well-scoped chunks. On this project, my commits were large and infrequent. The iteration speed was so fast, and I knew Claude's snapshot system would let me roll back easily, so incremental progress tracking just stopped being front of mind. That felt atypical for me, but it also felt... fine?

One thing that worked surprisingly well was the only bit of preemptive setup I gave Claude before the experiment started.

I pointed it at my personal projects directory and asked it to study my existing apps. Look at how I handle things like app review prompts, contact-the-developer flows, privacy policy links, error dialogs, and the other small details that polished apps usually include.

These are the kinds of peripheral features you rarely think to mention in a prompt, but they’re part of what makes an app feel complete.

I then asked Claude to write a CLAUDE.md file documenting those patterns so it could reuse them when building my projects.

That was the only upfront guidance. The actual project prompt for UnJumbl was still just a single sentence. Claude and ChatGPT went back and forth a few times to expand it into a rough requirements doc, which I never read, and then Claude entered the Ralph loop and implemented everything.

Because of that CLAUDE.md file, UnJumbl still shipped with all those additional touches without me ever explicitly asking for them. Even better, that file now lives alongside my other projects, so future apps can inherit the same conventions without any extra prompting.

By the Numbers

Wrapping Up

Let me be honest: this is a simple app. Of course vibe coding could handle it. A daily word game with no backend, no auth, no real-time multiplayer — this is squarely in the sweet spot of what AI-assisted development handles well today. The animations, the ad integration, the analytics wiring, the App Store metadata — all of this would have taken me several hours to assemble by hand. Claude did it in one sitting. For a side project where I just wanted something that worked, that's a genuine shift in what's possible.

But I don't want to overstate it. Not every project will go like this. I recently built SimTag, which involved significantly more nuance — and in that project, the cracks in vibe coding were much more visible. I'm finding this to be true of my professional work at Luma AI as well - more on all this in the next post.

What I'll say is this: as a professional developer who spends all day writing careful, reviewed, well-tested code, there was something strangely freeing about being able to ignore all of that for a weekend project.

I didn’t read a single line of code. I didn’t open a debugger. I didn’t step through the plan.

I wrote one sentence describing the app I wanted — and it appeared.

Less than 24 hours later it was live, people were playing it, and the whole thing worked well enough to ship.

That’s not how you build production software. But for indie projects, experiments, and small ideas that might otherwise never exist, it might be exactly how you start.

Try the game if you want:

unjumbl.app (Web)
unjumbl.app (iOS)