Salesforce Multi-Framework: What Building with React Actually Means for Your Next Deployment

For more than a decade, Salesforce held a pretty firm line. Lightning Web Components were built around native web standards, not React. And because of the platform’s security model, running React inside a standard Lightning page was genuinely difficult.

Teams tried anyway. You could embed a React app into a Lightning page through a static resource, and sometimes it worked. But it wasn’t exactly the recommended route. One well-known voice in the Salesforce developer community summed up the general advice by saying he “probably wouldn’t recommend doing that” (Joys of Apex).`

That position changed this year. Salesforce opened the Multi-Framework beta in April 2026, and by July 16, it was generally available for production orgs. React apps can now run natively on Salesforce.

If your team has been relying on a Heroku workaround, or you’ve put a project on hold because the frontend choices felt too restrictive, it’s worth taking another look.

Why React was locked out in the first place

It wasn’t simply Salesforce being stubborn. Lightning Web Security, the sandbox that replaced Lightning Locker, isolates each namespace in its own JavaScript environment (Salesforce docs), which makes React’s broad DOM access and event system difficult to support.

For years, teams wanting React had two main options: run a separate app on Heroku and connect it to Salesforce through jsforce, or use Salesforce’s React-based PWA Kit within Commerce Cloud. There wasn’t a comparable option for the core CRM platform.

Salesforce was already using React internally—Slack, acquired in 2021, uses React across significant parts of its product. The technology wasn’t new to Salesforce; it simply wasn’t a supported option on the core CRM platform.

What Multi-Framework actually gives you

Forget the branding for a moment and the basic idea is fairly straightforward. Multi-Framework provides a runtime—React-only for now—that packages React applications as a new metadata type called a UIBundle. These bundles sit inside your Salesforce DX project alongside your Apex classes and can be deployed through the same CLI workflow your team already uses (Salesforce docs).

There are a few practical details to understand before you start scoping a project.

Two audiences. Internal, employee-facing applications run on a dedicated salesforce.app domain and are accessed through the App Launcher. They’re secured using the same permission sets and profiles used by Lightning apps. Customer-facing applications, meanwhile, go through Experience Cloud.

Data access changed between beta and GA. During the April beta, the package was called @salesforce/sdk-data. By the July GA release, it had been renamed @salesforce/platform-sdk, and the single graphql() method had been split into separate .query() and .mutate() calls. If your team built something during the beta, that code will need to be reviewed before you put it into production.

Authentication is handled for you. A createDataSDK() utility takes care of tokens, so your React application doesn’t have to manage them manually.

The stack is preconfigured. Vite, Vitest, shadcn/ui, and Tailwind are included in the development setup. It’s also designed to work with Agentforce Vibes 2.0, which can scaffold a working application, including GraphQL queries, from a prompt.

No additional license. According to Salesforce’s product page, Multi-Framework is included with your existing platform license.

You need Summer ’26 or later. Production use also requires the org to be running on Hyperforce.

One important caveat: “multi-framework” is still a little aspirational as a name. React is the only framework actually shipping today. Vue, MCP UI, and A2UI are listed as “coming soon,” but Salesforce hasn’t attached a date to those options.

Why this actually matters, and it’s not really about the code

The bigger argument Salesforce is making is about hiring.

LWC-only development means hiring people with Salesforce-specific experience, a narrow and often expensive pool. React, by comparison, was used by 46.9% of professional developers in the 2025 Stack Overflow survey, second only to Node.js and well ahead of Angular (19.8%) and Vue (18.4%).

If you already have React developers, or would rather hire from that pool than compete for LWC specialists, that’s a real difference in cost and speed.

There’s a portability angle too. An existing React app, or a prototype built elsewhere, can now come onto Salesforce without the full rewrite an LWC port would require.

One data point worth flagging, with a caveat: Sigma, a Salesforce implementation partner, published a case study on moving a US-based B2B membership org to React and GraphQL on Multi-Framework, reporting 35 to 45% faster frontend development, 47% shorter onboarding, and over 65% component reuse. That’s Sigma’s own number from its own project, not an independent benchmark. Useful as a directional signal, not a planning figure.

What hasn’t changed is governance. Permission sets, profiles, and SSO still apply the same way they do for Lightning apps. This isn’t a side door. It’s another supported front door.

Key takeaways: Where it makes sense today, and where it doesn’t yet

• It’s early days. Multi-Framework has been GA for about two months as of this writing, not two years. Weigh the limitations below accordingly.
• Two known gaps right now: Lightning App Builder’s drag-and-drop doesn’t support React components yet, and micro-frontend support is still in closed pilot.
• Beta-to-GA changes are a signal, not just a footnote. Anything your team built before July should be tested and reviewed before it goes anywhere near production.
• Start small. The best first project is usually an internal tool, an admin utility, or an Experience Cloud page where the UI needs had already started outgrowing what LWC handles comfortably, not a flagship rebuild.
• What you need to get going: Salesforce CLI, Node.js v18+, and a scratch org or sandbox.
• LWC still wins by default. For most standard Salesforce UI work, it remains the simpler, more established option. Multi-Framework earns its place specifically where LWC’s limitations, or your hiring pipeline, were the actual blocker.

If you’re trying to decide where an upcoming build belongs – LWC, Multi-Framework, or entirely off-platform, it’s worth getting another perspective before committing an entire quarter to the wrong approach. Schedule a discovery call with N28 Technologies and we’ll walk through what actually makes sense for your deployment.