TechnoEric — Real Salesforce Tutorials That Work

React Just Became a First-Class Citizen on Salesforce. Here's Everything You Need to Know.

For over a decade, Salesforce developers faced a quiet but real trade-off: build with Lightning Web Components and get full platform power, or bring your favorite frontend framework and lose it. That trade-off is now gone — and it happened faster than almost anyone expected.

TL;DR: Salesforce Multi-Framework lets you build native React apps that run directly on the Salesforce platform — with authentication, security, and data access handled for you. It launched in open beta in April 2026 and reached General Availability in July 2026. If you're a React developer who's avoided Salesforce, or a Salesforce developer who's missed the React ecosystem, this is the announcement you've been waiting for.

The Problem This Actually Solves

If you've built on Salesforce before, you know the drill. Lightning Web Components give you base components, Lightning Data Service, and deep platform integration — but you're working inside a walled garden. Want to drop in a popular npm package, a custom hook library, or your team's existing React component system? You'd end up wrapping it awkwardly as a static resource, fighting the framework instead of building with it.

Salesforce Multi-Framework changes that story. It's a framework-agnostic runtime built on Salesforce's platform (referred to as the Headless 360 Platform) that lets React apps run natively — not bolted on, not sandboxed in an iframe, but genuinely native — while still inheriting Salesforce's authentication, field-level security, sharing rules, and governance.

From Beta to GA: A Fast-Moving Timeline

April 2026 — Salesforce Multi-Framework launches in open beta, available only in scratch orgs and sandboxes.
July 2026 — Multi-Framework reaches General Availability, with production-org support, a dedicated app domain, and a handful of breaking changes developers need to know about.

That's a remarkably short beta window — a signal of how much developer demand there was for this capability, and a reminder that if you built anything during the beta, you'll want to check it against the GA changes below before shipping to production.

What Changed at GA (and Why It Matters)

Area	What changed
Production support	Multi-Framework now runs on production, sandbox, Developer Edition, and scratch orgs — no opt-in required.
App domain	Employee-facing apps now run on a dedicated `salesforce.app` domain, giving each app its own browser origin.
Data SDK	Renamed from `@salesforce/sdk-data` to `@salesforce/platform-sdk`, with a cleaner query/mutate API.
Metadata target	The beta's `AppLauncher` target is deprecated in favor of `CustomApplication` for employee apps.

1. Production Orgs Are Finally in Play

This is the headline change. During beta, Multi-Framework was restricted to scratch orgs and sandboxes — great for prototyping, unusable for anything real. At GA, it's enabled by default across production, sandbox, Developer Edition, and scratch orgs running Summer '26 or later. No feature flag, no opt-in request. You can verify it's active for your org under React Development with Salesforce Multi-Framework in Salesforce Setup.

2. Every App Gets Its Own Web Origin

Multi-Framework apps now run on a dedicated salesforce.app domain, following a pattern like:

https://<org>--<namespace>.<instance>.my.salesforce.app/app/c__<bundleName>

Because each app lives on its own origin, the browser's Same-Origin Policy isolates it automatically — one app simply cannot read another app's cookies or storage. That's a meaningful security upgrade, and it comes for free.

3. The Data SDK Grew Up

The client library your React app uses to query and mutate Salesforce data via GraphQL has a new name and a clearer API. Here's the shift, side by side:

Before (beta) — @salesforce/sdk-data:

const result = await sdk.graphql?.<QueryResponse>({ query: MY_QUERY });
const edges = result?.data.uiapi?.query?.Account?.edges;

After (GA) — @salesforce/platform-sdk:

const result = await sdk.graphql?.query<QueryResponse>({ query: MY_QUERY });
const edges = result?.data?.uiapi?.query?.Account?.edges;

Two subtle but important shifts: reads and writes are now separate methods (.query() and .mutate()), and result.data is typed as potentially undefined, so defensive optional chaining is now the expected pattern rather than an afterthought.

Quick Start: Your First React App on Salesforce

Here's the fastest path from zero to a running app, assuming you have the Salesforce CLI and Node.js 18+ installed:

Scaffold the app as a UI Bundle:

sf template generate ui-bundle -n myapp -l "My App" -d "./force-app/main/default/uiBundles" -t reactbasic

Install dependencies and confirm the toolchain:
```
npm install
npm list vite
```
Run it locally and preview at http://localhost:5173:
```
npm run dev
```
Build for production once you're ready to ship:
```
npm run build
```
Expose it to users by pairing a CustomApplication metadata file with a PermissionSet that grants visibility, then deploy:
```
sf project deploy start
sf org assign permset -n "My_React_App_Access"
```

From there, open the App Launcher, search for your app's label, and you're live — a real React app, running natively inside Salesforce.

Migrating a Beta App? Here's Your Checklist

If you built something during the open beta window, don't deploy it to a GA org without making these five changes first:

Update the import from @salesforce/sdk-data to @salesforce/platform-sdk.
Split any .graphql() call into .query() for reads or .mutate() for writes.
Add optional chaining through result?.data — it's no longer guaranteed to be present.
Change <target>AppLauncher</target> to <target>CustomApplication</target> in your bundle's metadata, and add the accompanying CustomApplication and permission set files.
Remove the now-unnecessary UiBundleSettings scratch org configuration.

Why This Is a Bigger Deal Than It Sounds

It's easy to read this as "another SDK update." It isn't. For years, the choice between Salesforce and React was a staffing decision, not just a technical one — teams either trained developers in LWC's proprietary patterns or hired for it, cutting themselves off from the much larger pool of React talent. Multi-Framework quietly removes that constraint. Companies can now build Salesforce-native experiences using the same React skills, component libraries, and tooling their teams already use for every other product surface.

That's not a minor developer-experience tweak. It's the kind of change that reshapes how platform teams get staffed, how quickly internal tools ship, and how much technical debt accumulates from framework-specific workarounds.

What's Coming Next

Salesforce has signaled a few things on the roadmap worth watching:

Microfrontends — embedding externally hosted React components directly inside Lightning pages, alongside LWC.
Angular support — the first framework added beyond React.
Localization — first-class support for multiple languages, locales, and timezones.
Managed packages — packaging and distributing Multi-Framework apps like any other Salesforce product.

The Bottom Line

If you've been avoiding Salesforce development because you didn't want to learn Lightning Web Components from scratch, Multi-Framework is the on-ramp you've been waiting for. And if you're already deep in the Salesforce ecosystem, this is your invitation to bring the wider React world in with you — without giving up the security and governance the platform is built on.

Have you tried building a React app on Salesforce yet? Drop your experience — or your migration horror stories — in the comments below.

Suggested labels: Salesforce, React, Multi-Framework, Web Development, Low-Code, Developer Tools