We Built a React App Inside a Salesforce Platform Years Before Salesforce Let You
A while back, our team built a full React application that lived inside Veeva. Not bolted on through an iframe pointing at some app hosted elsewhere. It ran inside the platform, in front of the same users, next to the same records. At the time, that was an unusual thing to attempt, because the platform underneath Veeva is Salesforce, and Salesforce did not want you running React.
This year Salesforce changed its mind. At its developer conference in April, the company announced that React can now run natively on the platform. For anyone who fought the old way of doing this, the announcement reads a little differently than it does for everyone else. So this is partly a history of how we got here, partly a walkthrough of what is actually shipping, and partly a story about doing something the hard way before the easy way existed.
What "React inside Salesforce" even means
A quick translation for anyone who does not write code for a living.
React is the most widely used toolkit on the planet for building user interfaces, the screens and buttons and live-updating panels you interact with on the web. A huge share of modern web apps are built with it. There is an enormous community around it, a deep library of pre-built pieces, and most front-end developers already know it.
Salesforce is the system of record where a lot of companies keep their customers, their deals, and their data. It is enormously capable on the back end. The catch, for years, was that Salesforce insisted you build your screens its way, using its own tools, and not the tools the rest of the web had standardized on.
So a company would end up in a familiar bind. The data lives in Salesforce. The talent and the speed live in React. And the platform stood between the two, asking you to pick one.
Why this used to be genuinely hard
When we built our React app inside the Veeva environment, there was no supported path. There was a workaround, and the workaround was a fight.
Salesforce lets you upload files as "static resources." Think of it as a locker where you can stash assets the platform did not create. The trick was to package up React itself, drop it into that locker, and then write a small piece of Salesforce-native code whose only job was to load those files, find an empty container on the page, and tell React to take over that container and render everything inside it.
It worked, but you were running two different systems that both wanted to control the screen at the same time, neither aware of the other. On top of that, Salesforce wraps user interface code in a strict security sandbox, so a lot of ordinary React behavior either broke or had to be re-engineered. Every external connection had to be allow-listed by hand. Performance suffered because you were loading a whole second framework on top of the one already running. None of it was blessed by Salesforce, which meant every platform update carried the small risk of quietly breaking the thing you had shipped.
We did it anyway because the result was worth it. The users got an interface that felt modern and fast, and the business kept its data where it belonged. But it was the kind of build where a meaningful slice of the effort went into satisfying the platform rather than serving the user. Anyone who has done this knows the feeling.
How Salesforce arrived here
It helps to see the arc, because the React announcement is the latest step in a long migration, not a sudden reversal.
Salesforce started with Visualforce back in 2008, a page-building approach that was very much of its era. In 2015 it moved to Aura, its first real component framework. In 2019 it introduced Lightning Web Components, usually shortened to LWC, and this was the important turn. With LWC, Salesforce rebuilt its front end on top of genuine web standards, the same underlying browser features that everything else on the modern web relies on. They even released the framework as open source.
LWC was a real improvement, and plenty of teams are productive in it. But it was still a Salesforce-specific skill. You could not take a React component your team already had and run it. You could not reach for the vast library of ready-made React pieces. You hired for LWC, you trained for LWC, and you stayed inside the lines Salesforce drew. That is the wall the new announcement finally takes down.
What is actually being released
The new capability is called Salesforce Multi-Framework. It is a runtime, which is the engine on the platform that knows how to run your code, and it is built to be framework-agnostic. React is the first framework it supports. The plan is for others to follow, with Vue, Angular, and a couple of agent-focused UI standards named on the roadmap.
The part that matters most is the word native. This is not the old locker trick dressed up, and it is not an externally hosted site stitched in through a frame. A React app built this way is deployed as part of a normal Salesforce project and shows up in the Salesforce app launcher like anything else the platform runs. Your React code keeps its own brain, its state management and its component logic, while the platform handles the things that are genuinely hard to get right on your own.
Three of those things are worth calling out, because they are exactly what made the old approach painful:
Your app reaches Salesforce data through standard, governed channels, using a modern query method called GraphQL for reading and changing records, plus the platform's existing code layer for business logic. You are not hand-rolling brittle connections anymore.
Authentication, security, and the platform's governance model come along automatically. The app inherits who the user is and what they are allowed to see, which means the same permission rules that protect your Salesforce data also protect your React screens. For anyone who cares about access control, that is the headline.
It runs alongside LWC rather than replacing it. Existing Lightning Web Components keep working. Salesforce is positioning this as a choice of the right tool for the job, not a forced migration.
There is also an AI angle. Salesforce's natural-language development tool, Agentforce Vibes, was upgraded in the same announcement and can generate these React apps from a plain description. You can ask it for something like a dashboard of open deals by stage, and it produces the React code, the data queries, and the Salesforce wiring to match. The starter project comes with a familiar modern toolchain already configured, the kind of setup a React developer would assemble themselves on day one. And it sits inside Salesforce's broader push, which the company is calling Headless 360, to make every part of the platform reachable by code, by command line, and by AI agents rather than only through the standard browser screens.
The timeline, and the honest caveats
Here is where things actually stand, and where the marketing and the reality diverge a little.
Salesforce announced Multi-Framework at its developer conference, TrailblazerDX, held April 15 and 16 in San Francisco. As of now it is in open beta. That phrasing carries real limits. You can use it in development and testing environments, the disposable orgs and sandboxes developers build in, but only where English is set as the default language. You cannot deploy it to a production org yet, which means it is something to prototype with and plan around, not something to ship to live users this quarter.
A few capabilities are still missing in the beta. The convenient drag-and-drop placement that Salesforce admins are used to does not yet work for React components, and some platform features are not wired up in the beta runtime.
The ability to drop a React component directly into a standard Salesforce Lightning page, as one piece among others, is a step behind the rest. That is in an earlier, more restricted preview, with broader availability targeted for later in the year.
Salesforce has not put a firm date on general availability, the point where this is fully supported and allowed in production. The two things expected to arrive at that milestone are production deployment and the drag-and-drop placement. Until then, the right posture is to experiment seriously and hold off on betting a live system on it.
One genuinely friendly detail: there is no new line item. Salesforce has said Multi-Framework is part of the existing platform and carries no extra per-user fee to build or run React apps on it.
What this looks like from where we sit
We solved this problem once already, the long way, inside a platform built on the same foundation. We packaged a framework the system was not built to host, wrestled it past the sandbox, and kept it alive through platform updates that were never designed with our app in mind. The work held up, and the users were better for it, but a real share of the effort went to the platform instead of the product.
The reason that build mattered was never the cleverness of the workaround. It was the conviction behind it, that the data belonged in the platform and the experience belonged to the user, and that you should not have to sacrifice one for the other. Salesforce has now agreed with that premise and put real engineering behind it. For teams starting today, the wall we climbed is becoming a door. That is a good outcome, even for those of us who learned the terrain by going over the top of it.