Skybridge

Name: Skybridge
Rating: 5.0 (5 reviews)

The full-stack open source React framework for MCP Apps

5.0•5 reviews•

1K followers

The full-stack open source React framework for MCP Apps

5.0•5 reviews•

1K followers

Visit website

Testing and QA software

•

Vibe Coding Tools

•

AI Code Editors

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!

Free

Launch tags:Open Source•Developer Tools•Artificial Intelligence

Launch Team / Built With

Wispr Flow: Dictation That Works EverywhereStop typing. Start speaking. 4x faster.

Promoted

Skybridge

Maker

📌

👋 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 💫

Report

26d ago

@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!

Report

7d ago

Skybridge

Maker

@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

Report

7d ago

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?

Report

6d ago

Skybridge

Maker

@hi_i_am_mimo Good question. We don't fake native modes. `setDisplayMode("fullscreen")` asks the host and returns the mode it actually applied, which can differ from the request and updates if the host switches on its own. You read that back via `useDisplayMode()` and branch your UI on it.

The one capability we genuinely emulate is the modal: on hosts without a native one, Skybridge renders a local fallback view so it works everywhere.

Report

5d ago

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?

Report

7d ago

Skybridge

Maker

@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?

Report

7d ago

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?

Report

6d ago

Skybridge

Maker

@hi_i_am_mimo No feature-detect needed before rendering. Default mode is `inline`, which every host supports, so you render for that and never push a broken view. Requesting `pip`/`fullscreen` just returns the mode the host actually applied. If it can't honor it you stay inline, and `useDisplayMode()` reflects that. So you branch on the real mode after the host responds rather than predicting it up front.

Report

5d ago

Skybridge

Maker

@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.

Report

7d ago

Skybridge

Maker

@hi_i_am_mimo there's almost no per-client branching, we added pollyfills to the most important features to make things seamless

Report

6d ago

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.

Report

7d ago

Skybridge

Maker

@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.

Report

7d ago

@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.

Report

7d ago

Skybridge

Maker

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?

Report

7d ago

@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.

Report

7d ago

Skybridge

Maker

@peterdigitalis happy to tell you more about other places where we shim in Skybridge if you need!

Report

6d ago

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?

Report

7d ago

Skybridge

Maker

@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

Report

7d ago

Skybridge

Maker

@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?

Report

6d ago

Mention ✪ Insights Center

Just tried and it's amazing ! Will be using it across our companies at Hexa !

Report

7d ago

Skybridge

Maker

@mvaxelaire Thank you so much Matthieu :)

Report

7d ago

Skybridge

Maker

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 ❤️

Report

7d ago

The React Native comparison cuts both ways for me, since RN's bridge always lagged whatever Apple or Google shipped next. Same shape here. When one host ships a brand-new primitive with no equivalent on the other, do you expose it and break 'code once', or sit on it until both catch up? We hit that exact fork wrapping several agent runtimes behind one tool interface, and the honest answer ended up being a capabilities map the caller can query, not a true single surface. Curious which way Skybridge leans when hosts diverge upward, not just sideways.

Report

11h ago

Skybridge

Maker

Hi @dipankar_sarkar, the React Native comparison is the right one. Capabilities that both hosts share live on the shared surface, and that's where "code once" actually holds. It's enabled by the MCP protocol, which normalizes most of the interactions between the views and the MCP server. Like you, we ended up with code once for the common path, feature-detect for the host specifics.

Report

8h ago

Skybridge

Maker

👋 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!

Report

7d ago

Easop 2.0

@fredisterik Product looks really well made for developers! I can't wait to test it 💪

Report

7d ago

Skybridge

Maker

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!

Report

7d ago

1 2 3

•••

5.0

Based on 5 reviews

Review Skybridge?

Reviews

All Reviews

Most Informative

👋 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.

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.

If you want to give it a go yourself, check out our getting started guide!

Skybridge

The full-stack open source React framework for MCP Apps

The full-stack open source React framework for MCP Apps

What's great

What needs improvement

vs Alternatives

What's great

What needs improvement

vs Alternatives

What's great

What's great

What needs improvement

vs Alternatives

What's great

What needs improvement

vs Alternatives

What's great