Launched this week
MCP apps are the new website: they're real, interactive apps that run right inside AI assistants like ChatGPT and Claude. The tooling to build them didn't exist, so we built it. Meet Skybridge, the React framework that handles the infrastructure and the dev loop so you can focus on your features: MCP server, view rendering, client compatibility, testing tunnel, and more. Code once, ship everywhere. Already +500K downloads and dozens of apps in the stores!
Skybridge
👋 Hey Product Hunt!
The internet is going headless. More and more, people don't open a website or an app, they just ask an assistant. That's making MCP Apps the new UI: real, interactive apps that run right inside Claude, ChatGPT and the rest. We think it's one of the biggest shifts in how software gets built and used right now.
While building these apps at Alpic, we kept hitting the same wall: every host (Claude, ChatGPT, Cursor…) has its own quirks, and writing the plumbing to support all of them is painful. So we built Skybridge. It is an open-source framework to build MCP apps, from idea to the official app stores. Code once, ship everywhere.
It abstracts away the implementation differences, so your app runs the same in Claude, ChatGPT, VS Code and any MCP-compatible client. It bundles a full local emulator, Hot Module Reload and an instant tunnel to connect your local app to Claude and ChatGPT. Agents are first-class users too: Skybridge gives your coding agent everything it needs to build an MCP app end-to-end.
Want proof the hard parts work? Have a look at our showcase page. You'll find many of the apps the community and us made with Skybridge and published to the stores. Skybridge already powers dozens of apps live in the stores.
What's happening in the MCP world right now is wild, and we can't wait to see what you build with it 💫
@julienvallini this is actually a pretty big shift if MCP apps keep going in this direction 🚀
the “build once, run across Claude, ChatGPT, VS Code, etc.” problem is real — every platform feels slightly different in practice, and the glue code becomes the real product pain
one thing I’m curious about: when you abstract all these runtimes into one framework, what tends to break first in the real world? is it tool compatibility, auth flows, streaming behavior, or just subtle UX differences between clients?
also love the idea of agents being first class users — that feels like where things are naturally heading
excited to see what people build with this!
Skybridge
@julienvallini @md_khayruzzaman Gladly the runtimes are not THAT different, what usually breaks is that some runtimes will not support some of the diplay modes (like fullscren or picture in picture), or for instance state management will be implemented differently. This is where good abstractions come into play
Good to know it's mostly handled. On those polyfills though: when a host has no real equivalent for something like PiP, does the polyfill emulate it with a fallback view, or just no-op that capability? And can my app tell at runtime which path it actually got, so I can adjust the UI instead of assuming the native mode is there?
The testing tunnel plus the client-compatibility layer is what catches my eye — the MCP-app dev loop across ChatGPT vs Claude clients seems like where most breakage would hide. With 'code once, ship everywhere,' how much per-client branching actually leaks into app code versus being abstracted by the framework? And for view rendering, does state stay scoped to the MCP server session, or is there shared client-side state I have to reason about across hosts?
Skybridge
@hi_i_am_mimo the tunnel indeed helps a lot on development! We put a lot of thought into it, as none of the existing solutions allowed for such traffic in a single tunnel!
As for the client specific code, all ship in each client, just the code running path changes :)
What do you plan on building with Skybridge?
For me it'd be a local-first dev utility shipped as an MCP app — reads a project folder and answers in-client — so the per-conversation state scoping fits fine, and good to know cross-host state lives server-side. On the polyfills: when a host lacks a display mode like PiP or fullscreen, do they degrade gracefully on their own, or do I need to feature-detect before rendering so I don't push a broken view to that client?
Skybridge
@hi_i_am_mimo Your MCP app doesn't have to do any per-client branching. Skybridge takes care of everything. As for state, it's confined to a single conversation. If you need state across conversations or hosts, you'd handle that server-side.
Skybridge
@hi_i_am_mimo there's almost no per-client branching, we added pollyfills to the most important features to make things seamless
The "code once, ship everywhere" angle is the part that resonates — I build a lot of my own tooling on top of MCP and the host quirks between Claude and ChatGPT are exactly the kind of friction that quietly eats a weekend. The compliance-scanning piece caught my eye too; that's not where most early frameworks put their attention. Curious how you handle host capability divergence — when one host supports a UI primitive the other doesn't, do you degrade gracefully or gate the feature? Congrats on #1.
Skybridge
@peterdigitalis Yes we do provide polyfills when we can, for instance Claude doesn't have a viewState primitive, so we implemented one that mimicks the one in ChatGPT with local storage implementation.
@nikolay_rodionov Smart — a localStorage-backed viewState is the kind of pragmatic shim that makes "code once" actually hold up across hosts. Only thing I'd keep an eye on is that it stays client-local (no cross-device sync), which is totally fine for ephemeral UI state. Following the project — this is solving a real problem.
Skybridge
Thanks for your message @peterdigitalis , glad Skybridge proposal to be the React native of AI Apps resonate with issues you've been dealing with.
One example feature where host implementation diverge but where Skybridge is able to shim partially the feature is view state, which gets persisted on ChatGPT in order to be able to reconstruct any state in the rendered view that might have evolved the component during the conversation, in order to reconstruct it as it was last time the conversation was visited. Such host provided persistence mechanism is lacking from the Claude implementation. We had to rely on some tricks using navigator local storage to offer some kind of similar functionality.
Of course not all feature can be shimmed with such tricks. ChatGPT in-house payment flow can't be replicated as is in Claude. In such case, we only provide the API on host specific hooks included in Skybridge, and degrade gracefully when an non-compatible host is rendering the app.
Which host divergence gave you the most headaches and you wish you had Skybridge for at the time?
@fredisterik Honestly the persistence one you just described — keeping tool state coherent across a revisited conversation, then falling back to the same localStorage trick and watching it get brittle. Close second, not being able to trust that output renders the same across hosts, so I'd defensively flatten the UI. Abstracting both is exactly why this resonates. Will take a proper look — thanks for the detail.
Skybridge
@peterdigitalis happy to tell you more about other places where we shim in Skybridge if you need!
This resonates — I'm building voice/WhatsApp AI agents on top of Vapi + Twilio + Anthropic, and the "each host has its own quirks" pain is real even with just 3 providers, let alone every MCP client. The nastiest bugs aren't the obvious API mismatches, they're silent ones: I just spent hours chasing a bug where a local .env file baked into a Docker image was silently overriding production secrets at runtime — same code, different environment, completely different behavior, no error thrown. Curious how Skybridge handles that class of problem: env/config drift between the local emulator and the actual Claude/ChatGPT/VS Code runtimes. Is that abstracted away too, or still something devs have to test for per-host?
Skybridge
@david_marko thank you for the question! The main advantage of Skybridge is that is abstracts the host-specific APIs, and adds polyfills for the ones that are not supported in certain runtime. As the MCP App is usually hosted remotely, there are no issues with the env variables from the user PoV
Skybridge
@david_marko can't wait to see apps in the voice space and what it would look like. What's the UI of audio? I feel like this could go in a Alexa-like direction but it didn't catch as much as expected so not sure similar experiences will resurface anytime soon. What do you think?
Mention ✪ Insights Center
Just tried and it's amazing ! Will be using it across our companies at Hexa !
Skybridge
@mvaxelaire Thank you so much Matthieu :)
Skybridge
Thanks @mvaxelaire , shipping MCP app as the interface is the way to go for businesses built in 2026, happy to hear companies at Hexa building on that space ❤️
Skybridge
👋 Hey Product Hunt! I'm Fred, co-founder and CTO of Alpic, and core maintainer of Skybridge!
When ChatGPT Apps launched in October 2025, the OpenAI Apps SDK was just a page of documentation. No runtime, no tooling, nothing. So we built the missing SDK ourselves. That was Skybridge, day one.
But the deeper frustration was the feedback loop. Hot Module Reload, instant iteration, host context mocking (like locale, theme, or screen size), things web developers have taken for granted for a decade, mostly natively supported in modern browsers, simply didn't exist for AI Apps. Every change meant a full restart, a metadata refresh, and manually reconnecting to your conversational agent. The stack was brittle at best. When your feedback loop takes ages, you stop experimenting. You stop building.
So the DevTools became a core pillar of Skybridge: a local-only environment where you can iterate freely on your app before ever connecting it to Claude or ChatGPT. Tight loop, no friction.
Fully open-source. Because foundational tooling for this new layer of the web should be built in the open.
Since then, we've seen the number of apps built with Skybridge skyrocket! We've made the DevTools both human- and agent-friendly, enabling development loops we couldn't have even dreamed of 6 months ago. Can't wait to see what experiences people will bring to life with Skybridge.
If you want to give it a go yourself, check out our getting started guide!
Easop 2.0
@fredisterik Product looks really well made for developers! I can't wait to test it 💪
Skybridge
Thanks @thierreasop , feel free to share your thoughts after trying it out! Always on the lookout for ideas on how to help make Skybridge a better tool to build app with!
Huge👏 congrats @julienvallini on the release, the headless web framing is spot on. love it's a open source, qq. do we have to deploy to alpic cloud to get the store auditing features or can we run the full beacon compliance scan locally via the cli?
Skybridge
Hey @priya_kushwaha1, thanks for the support! :)
Your MCP server doesn't need to be hosted on Alpic to run the compliance check. Any public MCP server can be audited, wherever it's hosted.
If you want to give it a try : https://beacon.alpic.ai/
Thanks, Perfect appreciate the answer👏