React Runs Natively on Salesforce Now. I Built Three Apps to See If It Holds Up.

"So Can Our React Developers Build on Salesforce Now?"

Since TrailblazerDX in April, some version of this question has come up in every architecture conversation I have been part of. For years the honest answer was a qualified no: on-platform UI meant Lightning Web Components, and your React team either learned LWC or built off-platform and fought an integration battle over auth, CORS, and data access.

At TDX 2026, Salesforce announced Multi-Framework — a framework-agnostic runtime on the Agentforce 360 Platform that runs React apps as native Salesforce metadata. Not an iframe. Not an Experience Cloud embed. An actual React application, deployed with the same CLI command as your Apex classes, running inside the org with authentication and governance handled by the platform.

Announcements are cheap, so I spent a day testing it properly: three working apps in a scratch org, from sf org create scratch to drag-and-drop write-backs. Here is what I built, what broke, and what I would tell a client.

What Multi-Framework Actually Is

A React app becomes a UI Bundle — a new metadata type that holds your built Vite project plus a config file that registers it with the platform. You scaffold it with sf template generate ui-bundle, develop with hot reload like any React project, and deploy with sf project deploy start. The template ships preconfigured with TypeScript, Tailwind, shadcn/ui, Vitest, and a GraphQL client.

Data access goes through the platform SDK: a createDataSDK() call gives you GraphQL queries and mutations against your org's objects with zero token management — the runtime knows who you are because you are already inside Salesforce. LWC does not go away; the two coexist, and your existing components keep working.

It is in open beta for scratch orgs and sandboxes. Not production, and notably not Developer Edition orgs — my new dev org could only participate as the Dev Hub that creates the scratch orgs.

The Test: Three Apps in a Day

A Recharts pipeline dashboard. The chart library every React developer reaches for, which is genuinely painful inside LWC because of Lightning Web Security wrappers. Here: npm install recharts, one component, a GraphQL query for open Opportunities, done. No static resources, no LWS workarounds, no wrapper components. This alone will convert people.

TriageDesk, a branded case console. The "completely custom UI hosted on Salesforce" claim, tested. A support-queue console with search, filters, and one-click case actions — Start working, Escalate, Close — each firing a GraphQL mutation that updates the Case record instantly. Styled with shadcn/ui and Tailwind in a deliberately un-Lightning ink-on-paper look: black header, rubber-stamp priority badges, monospace ticket typography. Nobody would guess it runs inside Salesforce, and that is the point.

A drag-and-drop case calendar. The stress test. I added a Field Visit Date field to Case, a record-triggered Flow that schedules a visit two days after case creation, and a calendar page built on FullCalendar — the same library you would use on any web project — with Google-Calendar-style month, week, and day views. Dragging a visit block to a new slot fires a mutation that updates the Case record; I verified the write-back with SOQL after every drag. Declarative automation writing data that a React library renders and edits: that is a real platform app, not a demo.

All three live in one SFDX project, deploy together, and open from the App Launcher.

What the Docs Don't Tell You

Four things cost me time that should cost you none:

1. A deployed UI Bundle is invisible. The generator creates the bundle, but nothing puts it in the App Launcher. You need a CustomApplication whose uiBundle tag points at your bundle, plus a permission set granting that application visibility — then assign the permission set. The official sample repo ships these; the generator does not create them and no error tells you they are missing.

2. The announcement names the wrong package. The launch blog references a data SDK import that does not match what the template actually generates. Trust the scaffolded code, not the blog snippets — the generated GraphQL client is the source of truth for how to call the SDK.

3. New fields break the build — by design. The template's build runs GraphQL codegen against a schema snapshot of your org. Add a custom field, reference it in a query, and the build fails until you refresh the schema. Annoying for thirty seconds, then you realize what you have: compile-time validation of every query against your real org shape. LWC has nothing like it.

4. Developer Edition orgs are excluded from the beta. Enable Dev Hub in your dev org and create a scratch org instead — that is the intended path, and scratch orgs had the beta already enabled in my testing.

React or LWC: The Honest Matrix

| Situation | My call |
| --- | --- |
| Record pages, App Builder components, standard UI extensions | LWC — micro-frontend placement for React is not here yet |
| Full-page internal apps with custom branding | Multi-Framework React |
| Heavy visualization (charts, calendars, editors) | Multi-Framework React — the npm ecosystem wins |
| A team of React developers, no Salesforce UI experience | Multi-Framework React — productive on day one |
| Anything shipping to production this quarter | LWC — the beta gate decides for you |

What Hasn't Changed

The beta boundaries are real. No production deployment. No drag-and-drop placement in Lightning App Builder — embedding React components into Lightning pages is a closed pilot, with full support targeted around Spring 2027 per Salesforce's roadmap. Some platform APIs are not available in the beta runtime, orgs must be English-default, and only React is supported today with more frameworks promised. And the governance trade is unchanged: your React app lives under Salesforce's security model, which is the feature, not the bug.

What To Do Right Now

1. Spin up a scratch org and scaffold a UI Bundle. One afternoon from Dev Hub to deployed React app. The experience will tell you more than any analyst summary.

2. Pick one internal tool as a candidate. The sweet spot is an employee-facing app you postponed because LWC made it expensive — a console, a dashboard, a scheduler.

3. Keep customer-facing and record-page work on LWC. The beta gate and the missing App Builder integration make this decision for you until at least next year.

4. Line up your React developers now. If Multi-Framework goes GA in its current shape, the constraint on Salesforce UI work stops being platform knowledge and starts being product thinking. Teams that treat it that way early will move faster than teams that wait for GA to start learning.

Wondering whether your org's next internal app should be React on platform? Let's talk — I will give you a straight answer based on what actually works in the beta.