You Bring React. Salesforce Keeps the Runtime.

The sentence everyone repeated after this one shipped was simple: React runs on Salesforce now. That is true, and it is a real milestone. It is also the wrong thing to celebrate on its own, because the interesting question is not which framework you get to write. It is what you handed over to write it there.

The year Salesforce spent decomposing outward

For most of this year the Salesforce story ran in one direction: outward. At TDX, Headless 360 decomposed Customer 360 into REST and MCP endpoints, opened the agent harness to the Anthropic and OpenAI SDKs, and deployed agents to ChatGPT, Gemini, and Claude instead of only Slack. Data 360 reached the bank’s transactional data by federating it in place rather than copying it. The whole posture was unbundling: take the pieces you want, reach them from where you already work, leave the rest.

Multi-Framework runs the other way. It is compose-inward. Instead of pushing Salesforce data and agents out to your surfaces, it pulls your frontend in to run on theirs. And the frontend was, for most shops, the last layer they still owned off the platform. LWC was the price of admission to the Salesforce UI, and plenty of teams paid it by keeping their real applications somewhere else and integrating across the seam.

That seam is what just closed. Worth understanding precisely, because the closing is both the gift and the catch.

What actually shipped

Salesforce Multi-Framework lets you build a native platform application in React, with Angular and Vue named as next, and run it on the platform rather than beside it. Salesforce introduced it on the developer blog in April 2026 and moved React to general availability on the Summer ‘26 platform.

The mechanics are more telling than the headline. A few load-bearing details:

It is a new metadata type. Your built React application deploys as a UI Bundle, a unit the platform recognizes and runs, pushed with the standard sf project deploy start from the Salesforce CLI. The official multiframework-recipes repository shows React, Angular, and micro-frontend samples deploying this way.

It runs alongside LWC, not on top of it. This is not React transpiled into Lightning components. It is a parallel runtime on the same platform, which is why it can be the framework you already know rather than a lookalike.

Users reach it the ordinary way. Access is granted through permission set groups and the app surfaces in the App Launcher, the same governance path as any other Salesforce app.

This is the piece I flagged at TDX as the genuine surprise, when Kush demoed a React app running natively on the platform and said from the stage, “This is not Lightning. This is React.” I wrote then that it “breaks the LWC moat that has defined Salesforce frontend development for years.” Six months later it is GA, and I want to correct my own read. The moat did not break. It moved.

The embed, and the SDK underneath it

The GA piece is deployment. The piece your architecture diagram cares about is the embed.

Data and identity flow through the Multi-Framework SDK, the @salesforce/sdk-data package. Your React code reads and mutates records through GraphQL, invokes Apex, and calls the UI API for user and org context, and it does all of that under the platform’s existing authentication and permission model. There is no bespoke token handling and no parallel auth. The app inherits the trust layer rather than reimplementing it.

Then there is the part that matches what you were describing when you sent me this: embedding an externally hosted app inside the Salesforce UI. The recipes repository includes a micro-frontend sample that, in its own words, “demonstrates how to embed an externally hosted app inside a Lightning page and exchange data and events over the Platform SDK.” The Lightning page becomes a thin host. Your app lives outside, and the Platform SDK is the bridge that carries data and events across the boundary while the platform supplies the shared context and permissions.

One honest caveat up front: the native React deployment is GA, but embedding an externally hosted micro-frontend directly into Lightning pages is on a separate, slower track and is still in closed pilot. Treat the first as something you can build on and the second as something you plan around.

What you gave up to get it

Here is the reframe, and it is the same one I keep landing on when a platform announces that it is opening up. Openness at one layer does not remove lock-in. It moves it up a layer. I wrote that thesis about storage formats and agent protocols; it applies just as cleanly to frontends.

Framework choice is the layer Salesforce just opened, and it is the layer that was already commoditized. React, Angular, Vue, LWC: these are interchangeable in the sense that the market treats them as substitutes, and forcing one on you was a cost without a corresponding moat. Conceding it wins goodwill and a lot of new developers at very little strategic cost.

The layers that did not open are the ones that matter. Where your code executes is the platform runtime. How it reads data is the platform’s GraphQL and Apex and UI API. Who the user is and what they can see is the platform’s identity and permission model. What gets logged, encrypted, and audited is the platform’s governance. Your React skills are now portable onto Salesforce. Your React application, once it reads records through the SDK and runs under the trust layer, is not portable off it. The switching cost did not disappear when the framework requirement did. It relocated to the runtime and the data plane, which is exactly where durable switching costs like to live.

The experience case, made honestly

None of that makes this a bad deal, and it is worth steelmanning the other side, because the developer-experience win is real and large.

A team that already builds in React can now ship inside the tool its users live in all day, without standing up a separate app, a separate host, and a separate integration layer to keep them in sync. One authentication model instead of two. One permission model instead of a home-grown mapping between your roles and Salesforce’s. Records over GraphQL instead of a REST client you wrote and now maintain. The trust layer, the encryption, the audit trail, all inherited rather than rebuilt. For most teams that is weeks of undifferentiated integration work that simply evaporates, and it evaporates in favor of code that does something a user cares about. That is a genuine good, and dismissing it as lock-in bait would be its own kind of dishonesty.

The control case, for a regulated shop

Now the other pole, because for a regulated institution the same facts read differently and both readings are true at once.

When your application runs under one identity model, one permission model, one egress and audit posture, that is a control, not a constraint. A bank spends enormous effort making sure the customer authorized the action, the data did not leave where it was allowed to be, and someone can reconstruct what happened. Inheriting a single governance plane that already does those things is a real answer to a real problem, and it is often a better answer than the parallel governance console you would otherwise run.

The catch is that the control and the dependency are the same object. The plane that governs your frontend is the plane you now cannot leave cheaply. Where the code runs moved onto the platform. Who governs it moved onto the platform. The audit of record, the identity of record, the place an examiner would look, all moved with it. You can say yes to embedding precisely because the governance is unified, and saying yes deepens the dependency that unified governance creates. The resolution is not to pick a side. It is to price both: the control plane is what lets a regulated shop say yes, and the plane stayed Salesforce’s.

The architect’s call: embed or stay headless

The useful decision this forces is the same boundary question I keep drawing. Draw it before you buy deeper, not after.

Embed in Lightning when the application is Salesforce-centric to begin with, when it lives on Salesforce data, when the users already spend their day in the CRM, and when inheriting the trust layer is a feature rather than a cage. In that case the integration work you save is pure margin and the governance you inherit is governance you wanted.

Stay headless, the way Headless 360 lets you, when the application has to span systems Salesforce does not own, when it needs its own runtime or its own data-residency story, or when keeping it off the platform is itself the control you are buying. Multi-Framework and Headless 360 are the same platform offering you both directions at once, inward and outward, and that is not a contradiction. It is a menu. The mistake is ordering from it by developer convenience alone and discovering the runtime bill later.

What I am still figuring out

I am not scoring this, because the parts that decide it are not GA yet.

The externally hosted micro-frontend embed is pilot, and pilot is not production. I want to see the data-residency and egress story for an externally hosted app talking back over the Platform SDK, and I want to see what disaster recovery looks like when your frontend is a UI Bundle on the platform and your service of record is somewhere else. Angular and Vue are named but not proven at React’s level, and framework parity is easy to announce and hard to sustain. And the migration path from an LWC estate you already run, to React alongside it, is the kind of detail that looks trivial in a demo and turns into a two-year program in a real org. None of those are reasons to wait. They are the questions to ask the account team before the runtime bill compounds.

The pattern, one more time

Open the framework, keep the plane. It is the same move Salesforce made when it opened the agent harness and kept the trust layer, the same move the data platforms made when they opened the storage format and kept the semantic layer. The layer a vendor hands you for free is worth taking. The layer they quietly keep is the one to read the contract on. Your React is portable now. Watch where your runtime lives.

Sources

Salesforce Developers: Introducing Salesforce Multi-Framework (April 2026) · Multi-Framework Is Now GA (July 2026) · trailheadapps/multiframework-recipes (UI Bundle deploy, micro-frontend and Platform SDK samples)

---

If you want the outward half of this story, read Salesforce Headless 360: The Day One Read, where the same platform decomposes itself into endpoints and pushes out to ChatGPT, Gemini, and Claude. This post is the inward half. Together they are the two directions of one strategy, and what an architect actually takes home from it.

Find me on X or LinkedIn. I write about what happens when AI infrastructure meets regulated reality.