Did I Just Kill the App Store?

The wait that broke something

I was waiting for Apple to approve an in-app purchase. Not a new feature. Not a redesign. An IAP. The kind of thing that should be routine — configure, submit, done. But it wasn't done. It was sitting in a queue, waiting for a human I'd never meet to review it on a timeline I couldn't control.

And while I was waiting, something clicked. Not a new thought — more like one I'd been suppressing. I asked myself: why am I doing this?

This goes against everything I stand for. I build to innovate. I build to ship fast. I build because the speed between idea and product should be as short as humanly possible. And here I was, sitting idle, waiting for permission to monetize my own app from a company that takes 30% of it for the privilege.

I couldn't innovate. I couldn't ship. I was stuck in someone else's pipeline. And I realized: I needed a different avenue entirely.

The methodology I'd just built

The timing wasn't an accident. The night before, I'd been documenting what I call the AI Full-Stack Methodology — a framework for how I use AI across every phase of building software. Not just code generation. Architecture, infrastructure, database, application, product, and process. Six phases where AI compresses the timeline from weeks to sessions.

I'd just finished writing it down. I was proud of it. And then I looked at my App Store dashboard and realized the framework had a blind spot. I had optimized every phase of building — but I hadn't touched the phase that actually gets the product to users. Distribution was still running on someone else's clock.

So I did what the methodology is built for. I asked the question the framework demands: what's the constraint, and can I engineer around it?

Why do you even need an iOS app anymore?

That was the question. And once I said it out loud, I couldn't unsay it.

The App Store made sense in 2008. Browsers couldn't do what native apps could. You needed access to the camera, GPS, push notifications, the home screen. The App Store was the distribution channel because it was the only distribution channel.

But it's 2026. Browsers support push notifications on iOS. PWAs can go full-screen from the home screen. The Geolocation API works in Safari. My app is fundamentally a UI layer that talks to Supabase — real-time data, authentication, edge functions. None of that requires a native binary. None of it requires Apple's approval. None of it requires their IAP system or their 30% cut.

The answer was obvious: just build it in the browser. Make it run just like the app. Same features, same feel, same data — but delivered through a channel I control completely. And with my methodology, I knew exactly how to do it in a single session.

The product

Some context. I build Weekend Warrior Golf — an app for organizing weekend golf games. Real users, real money tracking, real games being scored on actual golf courses. Stroke play, Wolf, Skins, Best Ball, Match Play, Stableford, Chicago, Scramble — eight formats, each with side games, live leaderboards, team drafts, league standings. It's not a toy project. People use it every Saturday.

The stack was Flutter for iOS and Android, Next.js for the website, and Supabase for everything backend — auth, Postgres, real-time subscriptions, edge functions. The website already had functional pages — game management, scorecard, leagues — but they were built for desktop. On a phone, the sidebar ate the whole screen and half the pages had desktop-only padding.

Applying the methodology

Here's how the AI Full-Stack Methodology turned this from a frustration into a shipped product in one session.

Phase 1 — Architecture. I started by mapping the gap between the Flutter app and the web app. What did mobile users need that the website didn't have? Bottom tab navigation, a home hub, mobile-first game builder, touch-friendly scorecard, PWA support. AI helped me audit every authenticated page and plan the migration in minutes, not hours.

Phase 2 — Infrastructure. The infrastructure was already in place — Supabase handles auth, database, real-time, and edge functions. Vercel handles deployment. No new servers, no new services. The web app hits the exact same backend the Flutter app does. One API, two clients.

Phase 3 — Database. Zero changes. The schema, the RLS policies, the real-time subscriptions — all of it already existed because the Flutter app and the web app share the same Supabase project. This is the payoff of building API-first from day one.

Phase 4 — Application. This was the session. I sat down with Cursor and started building. Ripped out the desktop sidebar on mobile, replaced it with a bottom tab bar matching the Flutter app — Home, Games, Tee Off, Leagues, Profile. Built the Home Hub with the same colored cards per game type. Rebuilt the game builder with club-first search and saved templates. Went through every page — scorecard, players, results, stats, profile — and made them mobile-first. Added PWA support: manifest, iOS meta tags, viewport config, safe area insets. "Add to Home Screen" gives you a full-screen app icon with no browser chrome.

Phase 5 — Product. The product decision was the catalyst. Subscriptions and purchases would happen on the web, on my terms, with no 30% cut and no review queue. Users get the same experience. I get control of my own revenue.

Phase 6 — Process. Push to GitHub. Vercel deploys in 60 seconds. Live. No build archive. No App Store Connect. No waiting. The process is: write, test, push, ship.

The whole thing took one session.

What changed

Left: Vercel deploys in under a minute. Right: Apple's App Store — still waiting.

Before, my deployment pipeline looked like this:

• Write code (hours)
• Test (minutes)
• Build iOS binary (minutes)
• Upload to App Store Connect (minutes)
• Wait for Apple review (days to weeks)
• User gets update (whenever Apple decides)

Now it looks like this:

• Write code (hours)
• Test (minutes)
• Push to GitHub (seconds)
• Vercel deploys (60 seconds)
• User has it (immediately)

Same backend. Same features. Same Supabase queries, same real-time leaderboard, same game logic. The only thing I removed was the gatekeeper.

The 7th phase: Distribution

That night, staring at my methodology document and my App Store dashboard at the same time, I realized the framework was missing something. I had six phases. But I didn't have one for how the product actually reaches users.

So I added a seventh: Distribution.

Distribution is a first-class engineering decision, not something you accept as a given. If your stack is API-first and your client is a view layer, you get to choose where that view layer runs. The browser is a view layer you control completely — no gatekeepers, no revenue share, no review queue, no IAP tax.

The App Store is the last human-approval bottleneck in an AI-accelerated pipeline. I removed it.

How I got here

This didn't come from reading a blog post or watching a conference talk. It came from building. Months of building a real product with real users, using AI across every phase, and documenting what worked.

The methodology came first — born from the daily practice of using AI to architect systems, provision infrastructure, design schemas, write code, and ship features. I wrote it down because I noticed patterns: the same approach kept working across wildly different problems. Plan with AI, execute with AI, validate as a human. Six phases, one loop.

Then the IAP wait happened, and the methodology told me exactly what to do. It wasn't rage. It wasn't impulse. It was the framework doing what frameworks do — showing you the answer when you ask the right question. The question was: what's the bottleneck? The answer was: the App Store. The solution was: remove it.

The question every builder needs to ask

If you're a solo engineer or small team on a modern stack — Supabase, Firebase, any API-first backend — ask yourself one question:

Does your app actually need to be native? Or have you just never questioned the assumption?

The gap between a web app on a phone and a native app has mostly closed. PWAs support push notifications, offline storage, home screen icons, and full-screen mode on iOS. The browser isn't a compromise anymore. It's a choice.

And it's a choice that gives you back full control of your pipeline — from architecture to revenue. No gatekeeper. No revenue share. No review queue. No waiting for permission to ship your own product.

The App Store is the last human-approval bottleneck in an AI-accelerated pipeline.

I removed it. You can too.

This post is part of the AI Full-Stack Methodology series. Read the intro: AI Full-Stack: One Engineer, AI in Every Phase

— CG, March 6, 2026. Written at the end of a long night and a very good morning.