Can you actually publish a vibe-coded game?
Most vibe-coded games never leave the browser tab they were built in. Here's what it actually takes to go from AI prototype to published product.
The short answer is: technically yes. But almost nobody does.
Vibe coding has produced an explosion of game prototypes. People are generating playable demos in minutes — platformers, puzzle games, little arcade experiments. The tools are genuinely impressive. You describe what you want, and something appears on screen.
But here's the uncomfortable truth: virtually none of these games will ever be published. Not on the App Store. Not on Google Play. Not anywhere that real players discover and download games.
They live and die in browser tabs.
The prototype trap
Most vibe-coded games exist as web demos. They run in the browser, they're fun to share on Twitter, and they prove that AI can generate playable experiences surprisingly fast.
But a browser demo is not a product. It's not even close to a product.
The distance between "a thing that runs in a browser tab" and "a thing a stranger can find, download, and play on their phone" is enormous. And it's a distance that vibe coding tools are not designed to help you cross.
Think about the last game you downloaded from an app store. It had an icon. It had screenshots. It had a description, a privacy policy, an age rating. It loaded quickly, ran at a stable frame rate, didn't drain your battery in twenty minutes, and handled interruptions like phone calls without crashing.
None of that is vibe-codeable. All of it is required.
What publishing actually requires
Let's get specific. Here's what stands between a vibe-coded game and a real app store listing.
Developer accounts and certificates
You need an Apple Developer account ($99/year) and a Google Play Developer account ($25 one-time). You need code signing certificates. You need provisioning profiles. You need to configure bundle identifiers that are globally unique. If any of this is set up wrong, your build won't even upload — let alone pass review.
Native builds
Your browser game needs to become a native app. That means compiling for iOS and Android, handling different screen sizes, supporting different input methods, managing memory within the constraints of mobile hardware. A game that runs fine in Chrome on your laptop might chug on a mid-range phone.
Store metadata
Every app store listing requires: a title, subtitle, description, keywords, category selection, screenshots in multiple resolutions (different for each device size), an app icon in various dimensions, and a feature graphic. Google Play wants a short description and a long description. Apple wants promotional text, a support URL, and a marketing URL.
This is not optional. Missing any of it means your submission gets rejected.
Privacy policy and compliance
Both stores require a privacy policy URL — even if your game collects zero data. If your game shows ads, tracks analytics, or uses any third-party SDKs, you need to accurately declare all data collection practices. Apple's App Tracking Transparency requirements add another layer. COPPA compliance matters if kids might play your game.
Get this wrong and you face rejection. Get it wrong badly and you face removal.
Age ratings and content declarations
You need to fill out content rating questionnaires for each store. Violence, language, mature themes, user-generated content, in-app purchases — all must be accurately classified. This determines whether your game is rated 4+, 12+, or 17+. Wrong ratings mean rejection or, worse, post-launch removal.
App review
Apple's review team will actually play your game. They'll test edge cases. They'll check that your app does what it claims. They'll verify that your screenshots match the actual experience. Review can take anywhere from 24 hours to several days, and rejection means fixing the issue and resubmitting — starting the clock over.
Google's review is faster but still catches issues. Both stores will reject apps that crash, drain battery excessively, or provide a subpar user experience.
The quality bar nobody talks about
Here's what really kills vibe-coded games at the publishing stage: the quality bar is higher than people think.
App stores are not GitHub. Users expect a polished, complete experience. That means:
Performance. 60fps on a three-year-old phone. Fast load times. No memory leaks. No frame drops during gameplay. Battery usage that doesn't make users regret downloading your game.
Stability. Handle backgrounding and foregrounding without losing state. Handle notifications without crashing. Handle low memory warnings gracefully. Handle screen rotation, accessibility settings, and dynamic font sizes.
Polish. Proper onboarding. Clear UI. Responsive touch controls calibrated for fingers, not mouse cursors. Haptic feedback on iOS. Proper safe area handling for notched screens. Loading indicators that aren't just frozen frames.
Completeness. A main menu. A pause function. Settings. Sound controls. A way to restart. A way to exit. None of these exist in a vibe-coded prototype, and all of them are expected by real users.
A vibe-coded game that technically "works" will feel broken the moment a real user interacts with it on a real device. The controls will feel off because they were designed for keyboard input. The UI will be misaligned because it was built for a fixed browser window. The game will stutter because nobody optimized the rendering pipeline for mobile GPUs.
So... is it actually possible?
Yes. But not with vibe coding alone.
The honest answer is that publishing a game requires a pipeline — a system that handles all the unglamorous work between "I have a prototype" and "a stranger can download this on their phone."
That pipeline needs to:
- Compile native builds for iOS and Android
- Optimize performance for mobile hardware
- Generate store-compliant metadata and assets
- Handle code signing and provisioning
- Package the app with correct permissions and entitlements
- Manage the submission and review process
- Deal with rejections and resubmissions
Each of these steps has its own complexity, its own failure modes, and its own expertise requirements. A solo creator who vibe-coded a game in an afternoon could easily spend weeks trying to navigate the publishing process — and still fail.
This is why the vast majority of vibe-coded games stay as prototypes. The creation is the fun part. The publishing is a slog that requires entirely different skills.
The missing piece
The problem isn't that vibe coding doesn't work. It does — for prototyping. The problem is that the pipeline between prototype and product doesn't exist in most tools.
You can generate a game in minutes. But you can't publish a game in minutes. Not unless someone has already built the infrastructure to handle native compilation, store compliance, asset generation, performance optimization, and the entire submission workflow.
That's what we built at Exekite. Not just a tool that generates games — a platform that takes them all the way to the app store. The publishing pipeline is built in, not bolted on. Because a game that nobody can download is just a demo — and demos don't count.