Releases / Developers

6 Salesforce Spring ‘25 Updates for Developers

By Peter Chittum

The festive holiday season may be over, but the gifts keep on coming. That’s right – we’ve rolled into the Spring ‘25 Salesforce release notes season: developer feature edition.

I’ve been poring over the release notes to pull out the best features that will make your developer experience a delight. So, sit down with a warm cup of coffee or tea and a fresh pre-release scratch org, and check out what’s in store.

1. Local Dev for Lightning Experience Desktop and Mobile

Hot reloading – sometimes called hot module replacement – refers to seeing an update to your (typically frontend) source code reflected in your app immediately, without a refresh, the moment your source is updated to your file system. It is a well-established feature of web development. Of course, it’s easy to do when you have access to the runtime file systems, as you normally would when building a web application in any other frontend framework.

But LWC – specifically, LWC running on and hosted by the Salesforce Platform – is different. Your source on the local file system is completely decoupled from the runtime, which runs on Salesforce’s servers. Until now.

Lightning Dev Server allows you to serve the JS code from your local source files and have them injected into the DOM of Salesforce. Using a web socket connection, as files are updated in your project, the new code will be automatically injected into the DOM, giving you instant access to changes.

Animation showing several changes to source code and the automatic updates to the browser UI.

For now, you’ll need to manually install the Lightning Dev Server plugin and check the sourceApiVersion in sfdx-project.json to make sure you’re running on API version 62.0 or later.

Screenshot of the terminal running sf plugins install @salesforce/plugin-lightning-dev with a successfully completed installation of the extension.

There is a quick configuration to set up the Lightning Dev Server to run on the org you wish to use (this can also be configured in a scratch org definition file). Running the local development server is done through the Salesforce CLI. You have to identify the environment to run in (desktop or mobile) and the app you want to launch. Once invoked, it will open your org in a new browser tab, just as if you’d run sf org open.

Starting the Lightning Dev Server.

There are also limitations on which LWC changes can be hot reloaded. For instance, changes to anything that is @api decorated will not be hot reloaded. As of the writing of this piece, I haven’t been able to successfully debug my code in the browser dev tools when running Lightning Dev Server, but that could be me. I expect this will be most useful in the fine-tuning stages of LWC development, especially around look-and-feel. And importantly, this feature is available only in Beta for Experience Cloud sites.

Read the full release notes and documentation to get the most out of this feature, and keep an eye out for updates.

2. SLDS 2 Is Coming

Sticking with frontend matters for a moment, Salesforce has announced its next UI theme: Cosmos. Along with this, there is a next iteration of the Salesforce Lightning Design System (SLDS) and accompanying tools called SLDS 2. Cosmos is currently in Beta, with availability limited to some org editions and types.

As developers, there’s an important point in the release notes: with SLDS 2 being applied to base LWC components, internal component DOM structures will change! This shouldn’t be a problem for most orgs. However, if you’ve accessed protected component structures with your LWC code, it could break once SLDS 2 goes live.

To assist with this, the SLDS Validator is now up to date with the current rule set to find problem areas in your frontend code, including SLDS 2 rules. You do need to activate the SLDS 2 ruleset through VS Code’s command palette with the SLDS: Enable SLDS2 validation command. It might also be a good time to revisit any usage of the @sldsValidatorIgnore annotations to see if you can bring any of those into compliance!

3. Apex Gets Zippy

File compression has always been a challenge for Salesforce Developers. While there are quite a few workarounds, as well as external apps and services available to fill the gap, a native solution has remained elusive.

In Spring ‘25, Apex developers finally get a generally available, on-platform, native API to compress and extract files!

This set of Apex classes lives in the Compression namespace and looks straightforward to use, including a set of APIs to compress, extract, and control the level of compression. Here’s an excerpt from the example in the release notes, showing how you would retrieve a document from Salesforce and compress it using the Compression.ZipWriter class.

Compression.ZipWriter writer = new Compression.ZipWriter();

List<id> contentDocumentIds = new List<id>();

// Add IDs of documents to be compressed to contentDocumentIds 

for ( ContentVersion cv : [SELECT PathOnClient, Versiondata
                           FROM ContentVersion
                           WHERE ContentDocumentId IN :contentDocumentIds]) 
{
      writer.addEntry(cv.PathOnClient, cv.versiondata);
}

blob zipAttachment = writer.getArchive();

As with any feature like this, I always wonder what underlying library they’ve decided to use, in case there are challenges in using the API. Only time will tell. And if someone from the Salesforce product reads this, we’d love to know!

4. Evaluate Dynamic Formulas in Apex

It used to be that formulas ran where they ran – formula fields, validation rules, flows, and the now-deprecated workflow rules were all made very powerful with formulas. As of Spring ‘25, you can now evaluate a formula in Apex code.

This brings some cool potential performance gains and opens up the possibility of custom formula editors, such as for AppExchange providers. However, opinions on this are divided. It doesn’t seem that there is a way to get some of the important features of custom formulas, such as protected API names of fields used in functions.

If you have a use case for evaluating dynamic formulas in Apex, we’d love to hear what you’re thinking of implementing.

5. ApexGuru Generally Available

Recently, Salesforce has been investing in better tooling to support developers. One such feature is ApexGuru, which is being made generally available this release. This tool provides code analysis that uses machine learning to identify potentially problematic code.

ApexGuru goes beyond rule-based code analysis by being aware of the runtime context of how code is executed. So, if a statement is known to be producing high heap usage, long execution times, or other risky runtime performance problems, ApexGuru would factor that into what it flags. This should mean that it would find problematic code that might not be discovered by a deterministic set of rules.

Potential problems are flagged as different levels of severity, and in each instance, the specific line of problem code is noted, along with a suggested alternative with better performance characteristics.

6. Say Goodbye…

A number of feature and product retirements are in the works and should be on your radar for 2025.

API Versions 21.0 Through 30.0

As of Spring ‘25, the Salesforce API will be on version 63.0. The beauty of versioned APIs is that existing integrations can remain stable at a given version until thoroughly tested and updated to the new version.

At least, ideally, that’s what happens. However, we all know that sometimes an integration that’s working isn’t maintained and is left to float along on its original API version.

API version 21.0 marked the Spring ‘11 release over thirteen years ago. That dates back to just about the time Salesforce acquired Heroku. I’d say it’s time we thank them and bid them farewell. The retirement of API version 21.0 through 30.0 was postponed from its original 2023 date and is now scheduled for the Summer ‘25 release in four months’ time. So, if this work isn’t on your backlog yet, it’s time to start looking into it.

Instance-Based Domain Names

Remember na1.salesforce.com? You’d be forgiven if you don’t. But when I first signed into salesforce.com, that was the instance I logged into. These days, orgs have their own boutique MyDomain names too, which are more secure and resilient. These domains look like my-org-name.my.salesforce.com. MyDomain has been required for several years now, and because of this, Salesforce is decommissioning instance-based URLs in mid-2025.

If you have old integration code knocking about that has hard-coded references to one of these old-style instance-based domain names, it’s time to fix it! Pay attention to old integrations and references to static resources on public sites.

And remember, if you have any hard-coded references in Apex code, the best practice is to use Url.getOrgDomainUrl().

Salesforce Functions

Five years ago, we were all excited by the possibility of elastic compute easily called from Salesforce. Alas, but for the customers who got Functions into production, they are soon to be no more. And even if you have some in production, the clock is ticking.

Salesforce stopped selling Functions in 2023, and there are no more renewals as of last January. If you have an essential feature still running on Salesforce Functions, it’s time to look for alternatives, such as directly on Heroku, AWS Lambda, or other serverless services from other cloud providers.

Moving an implementation from Salesforce Functions to another host is, of course, not trivial. But the Heroku team has tried to provide ample documentation on integrating a Heroku app with Salesforce. There is also a dedicated repo with code examples in Java and TypeScript for migrating Salesforce Functions to Heroku apps.

Ironically, the original internal name for Salesforce Functions was – wait for it – Evergreen.

Honorable Mentions

There are always more features than we have time to talk about. But here are a few others that are worth looking into:

  • More straightforward ConnectApi rate limits
  • Improved type checking and CSS class selectors in LWC version 63.0.
  • This known issue related to reparenting Master-Detail records in Apex has been fixed.
  • There is a Beta platform event called BulkApi2JobEvent to get notifications for Bulk API V2 query jobs. 
  • Updates for the CLI, VS Code extensions, Code Builder, and Agentforce for Developers all run off-cycle releases. So, make sure to keep tabs on those updates throughout the year. 
  • You can now pre-book your scale tests during peak load periods. 
  • There have been updates to the AppExchange guides you can look into. 
  • There are a bunch of new CDC-enabled SObjects.
  • And finally, event relays are now packageable

Summary: Looking to the Spring

As usual, Salesforce has brought out a great set of features for developers this release. If you’re new to Salesforce, Trailhead offers a trail with modules on how releases work. The Spring ‘25 modules aren’t available just yet, but there’s still good information about the overall process.

What features are you looking forward to using? We’d love to hear, so let us know in the comments below!

Read More

The Author

Peter Chittum

Peter is a self-taught software developer. He worked at Salesforce for 12 years and is now a freelancer working in developer relations and client advisory.

Leave a Reply