iOS App Development: Converting vs Fresh Build

You know what they say: “Past every hard mountain you climb is a joyful ride down.” No, I’m lying—nobody says that. But maybe they should.

After three days hitting roadblocks trying to convert my web app TaskCocoon to mobile, I sat down with Claude Code (my AI partner in crime) and asked the real question: what’s the better way to build TaskCocoon for iOS?

I found videos showing fresh builds work differently. Loveable, Replit, Claude Code—vibe code an app from scratch and it handles design, onboarding, UI automatically. Seemed simpler than converting.

But here’s what I discovered: the nuance between building fresh and converting an existing web app is a deep chasm.

So I broke down both paths: the real pros, the real cons, and what I’m actually doing moving forward.

My original thinking was straightforward. I have TaskCocoon running on web. It’s functional. I built it with Claude Code in about a week. The backend is solid on Supabase. The logic works.

So the plan was: take that web app, adapt it for iOS, submit to the App Store. Reuse as much as possible.

Sounds logical, right?

Day 1 was optimistic. I set up Expo, started mapping web components to React Native equivalents. The architecture seemed transferable. Same API calls, same authentication flow, same data model.

By day 2, things got messy. Web components don’t translate 1:1 to mobile. A responsive flex layout that works on desktop needs rethinking for a 6-inch screen. Components built for mouse interaction don’t feel right for touch. Navigation patterns designed for browsers don’t match iOS conventions.

Day 3 I was stuck in decision hell. For every feature, a question: do I adapt the web component or rebuild it for mobile? Do I share this logic or create a mobile version? Every decision felt like a compromise. The code was getting bloated with conditionals. The mental load was crushing.

By end of day 3, I had built something that technically worked. But it felt wrong. It wasn’t a great web app shrunk down. It wasn’t a great iOS app either. It was Frankenstein code trying to be both.

That’s when I stopped and asked Claude: what if I just built it fresh?

The idea seemed counterintuitive. Throw away three days of work and start over?

But the more I thought about it, the more it made sense.

Fresh build means: keep the backend exactly as-is. Supabase, authentication, API endpoints—untouched. But rebuild the entire UI from scratch, designed specifically for iOS.

The backend doesn’t care if you’re calling it from a web browser or an iPhone. An API call is an API call. Authentication is authentication. Data is data.

What changes is the experience layer. How users interact. How information is presented. The patterns and conventions they expect on iOS.

So instead of adapting web code for mobile, I’m writing mobile-first code that happens to connect to my existing backend.

The architecture is cleaner. The code is purpose-built. The mental model is simpler: “What does a great task manager feel like on iOS?” instead of “How do I make my web app work on a phone?”

I researched both paths. Talked to Claude about the trade-offs. Here’s what actually matters.

Pros:

Cons:

Pros:

Cons:

When I lined them up, the fresh build won on almost every measure except one: the psychological hurdle of “throwing away” three days.

But three days of wrong architecture is worth throwing away. Better to start fresh than spend two weeks fighting the wrong decision.

Expo (framework), Gluestack UI (components), Claude Code (vibe coding), Lottie (animations), Supabase (unchanged backend), Nano Banana (custom graphics).

All free except Apple Developer ($99 one-time). Backend stays the same. Everything else is built fresh for iOS.

Won’t Gluestack look generic? Not if you’re intentional.

Gluestack is LEGO bricks—high quality pieces. You’re the builder. I’m briefing Claude with direction: “Butterfly metaphor. Green and purple. Premium but playful.” Claude styles the components accordingly. My logo, my colors, my animations. That’s where personality comes from.

The difference between generic and intentional isn’t the component library. It’s your vision and the refinement you do afterward.

I’m starting fresh. Expo project initialized this week. Gluestack installed. Supabase connected.

Next step: brief Claude Code with the full vision. Splash screen with animated butterfly. Three onboarding screens explaining the task transformation concept. Login screen. Main task list. Task detail screen. Add task form. All connected with React Navigation.

Claude will generate the foundation in one session. I’ll test in Expo Go on my phone.

Then iteration: Does the onboarding feel rushed? Add breathing room. Are the button colors right? Claude adjusts. Is the animation too subtle? Make it more satisfying.

By end of week one, I should have a functioning iOS app that feels intentional, not generic. Not polished yet, but directional.

By week two, ready to submit to TestFlight for testing.

By week three, hopefully live on the App Store.

That’s the fresh build timeline. Versus the conversion timeline: three more weeks of fighting the wrong architecture, ending with something that feels compromised.

The hard mountain wasn’t technical. It was architectural.

Technical problems have solutions. But architectural problems require stepping back and asking: is this the right foundation?

Three days in, I realized the answer was no. The conversion path was the wrong mountain to climb.

So I’m switching paths. Starting fresh. Building an iOS app that respects the platform, connects to my proven backend, and actually feels good to use.

Not because it’s faster on day one. But because it’s faster on day ten. And day thirty. And when I want to add features six months from now.

The joyful ride down the mountain isn’t just about shipping. It’s about building something you’re actually proud of.

I’m committing to the fresh build. Starting this week.

The design angle matters too—I’m not just vibe coding randomly. I’m briefing Claude with a clear vision: TaskCocoon’s butterfly metamorphosis metaphor becomes the design system. Every screen, every animation, every color choice serves that theme. Splash screen, onboarding, the main app itself—all intentional, not generic. But that deserves its own post. Next week I’ll break down exactly how I’m planning the UI/UX and the prompts I’m using to make sure it looks and feels unique.

If you’re sitting where I was three days ago—staring at a web app wondering if you can just make it mobile—I hope this helps you see the chasm sooner than I did.

Sometimes the faster path isn’t the obvious one.