I’m here to post a reminder about two key deprecations that are happening soon on the Forge platform. Later this month, both the sandbox runtime and UI Kit 1 will reach the end of their deprecation period. Both deprecations were announced on 28th August 2024 (see CHANGE-789 and CHANGE-1932), with the deprecation taking effect on 28th February 2025.
According to our records, some apps are still actively using these features. So, we are taking a gradual approach to the deprecation of these features. I’ve included some details below.
As a reminder, please make sure you are using the RSS Subscription feature of the Forge changelog to ensure that you stay up-to-date on important announcements for app developers.
What is happening?
On 28 Feb 2025, the Forge sandbox runtime and Forge UI Kit 1 will be deprecated. Apps using these features may have degraded functionality as support for these features is removed.
Apps must migrate from the Sandbox runtime to the new Node.js runtime.
Apps using UI Kit 1 must migrate to the latest version of UI Kit.
When is it happening?
The following changes will be rolled out on the Forge platform to encourage apps to migrate to the supported alternatives:
Date
Sandbox runtime behaviour
UI Kit 1 behaviour
18 Feb 2025
Any invocations of the sandbox runtime will be blocked in development environments. Apps will receive a DEPRECATED_RUNTIME invocation error
A warning message will appear above rendered UI Kit 1 modules indicating that the app is out of date.
28 Feb 2025
Any deployments to the staging and production environment that still utilize the sandbox runtime will be blocked. A Manifest validation error will be generated during the forge deploy operation.
An error message will replace the rendered output of the UI Kit 1 module.
28 Mar 2025
Any invocations of the sandbox runtime will be blocked in all environments.Apps will receive a DEPRECATED_RUNTIME invocation error
What do I need to do?
We have guides available to help with these changes.
If you encounter problems upgrading to the Node.js runtime or the latest version of UI Kit, please contact our developer support team so that we can assist you. You can also contact our support team if you are concerned that your customers will be negatively impacted by these planned deprecation dates.
I am also happy to respond to any questions or concerns directly in this community thread.
@HeyJoe Thanks for the details. Hope you are doing great.
I just wanted to clarify and understand it better.
If we have an app which uses legacy runtime published already on MarketPlace. For the users, who have this app already installed. Would it work normally till 28th March?
If a user installs the app from the marketplace for the first time, which uses legacy runtime after 28th February. Would it get installed and work normally till 28th March?
@HeyJoe thanks for the explanation. As far as I understand, the existing apps in the old runtime will run until 28th March 2025.
I would like further clarification on the UI Kit 1 deprecation. Will the app that uses the Sandbox runtime and UI Kit 1 continue to work until 28th March 2025? The app is internal - not listed in the Atlassian Marketplace.
Apps using UI Kit 1 will stop working on February 28th. When the UI Kit module is rendered, the rendered output will be replaced with an error message.
This is unfortunate, as the Sandbox runtime support extension does not help UI Kit 1 applications. Would it be possible to extend UI Kit 1 support in the same way as the Sandbox runtime? The transition to v2 has been more complex and time-consuming than expected.
My only suggestion as someone who have walked this path (and still walking) and made the same mistake of treating UI1 > 2 migration as a major version upgrade, instead of a full rewrite into a completely new stack - drop UI Kit 2 and go with Custom UI.
CustomUI gets much better results with coding tools (Copilot, ChatGPT) and is (depending on stack of your choice) closer in nature to UI1 than UI2. I spent most time aligning UI components and trying to make it look acceptable, and AI tools were useless as UI Kit 2 components are not known to them.
Also, handling of some components like Forms in UI Kit 2 is utterly confusing (won’t go into details, but that was another area where I spent lots of time - getting my Forms to work and submit values predictably).
@IgorAndriushchenkp Thanks for the tips! I’ve had a similar experience and I agree – I wouldn’t choose UI Kit 2 either because of how complex the app is. A Custom UI that you can manage yourself seems like a better option. The tricky part now is just getting everything done on time. Honestly, I’m not sure if I’ll be able to finish everything in time. It’s been pretty stressful! The app I’m migrating is critical to my client…
The main drawback of custom UI is that it is trapped in an iframe.
When used for a Confluence macro for example, you can run into issues when displaying date pickers or any popups which would want to be rendered outside of your iframe: the result is a truncated popup. It can make your app hard to use or at least not visually appealing.
Using UI Kit will make your component more integrated in the platform. It is yet far to be a perfect solution since the allowed components and props are extremely limited (poor choice of spacings, fonts, no animations, etc…).
I understand the objective from Atlassian to lock designs to force following design guidelines. However, once you are using UI Kit for your component, there is no escape, very little possibilities to work around the limitations.
None of the solutions are currently very good UI wise if you want to deliver solid complex first class software.
You would have to pick the one that fits best your needs, and wait for the platform to evolve.
Please contact our developer support team (https://developer.atlassian.com/support) if you need more time to complete the UI Kit upgrade. We can work with you on this.
The changelog has an RSS feed that you can use to subscribe to changes. Within my team we use a 3rd party RSS service called Blogtrottr to consume the RSS feed and post new entries into our team’s Slack channel.
@HeyJoe will apps stop working but continue to show an “update app” message after March 28th?
Because reminder: Forge still has absolutely no method to push customers to the latest version of an app if any major version change has been made.
And with any forced migration you’re typically always going to be making major version changes given how often Atlassian has changed scope names and requirements.
For the UI Kit deprecation, we’re displaying an error message that the app is outdated and that the administrator should check for updates.
For the runtime deprecation, attempted invocations of the sandbox runtime will immediately fail with a DEPRECATED_RUNTIME error. No built-in affordances for this in the app UI are planned.
I am in the process of trying to build a spreadsheet of all customers of all apps that have installations running on the deprecated runtime where a fix is available by upgrading the app. I can then use this to trigger a bulk notification send to all customers encouraging them to update their app installations. We typically do not get a high success rate for these kinds of communications, but I’m hoping this minimises the blast radius somewhat.
There’s some discussions happening within our team at the moment about how we can improve the root problem here of customers running on old major versions of an app. It’s a three-way pain point for you, us and customers - I’m looking forward to any improvements we can make.
I’m also open to suggestions for improvements to our deprecation process within the Forge team - there’ll be more to come as the platform continues to evolve, so any feedback would be well received.
Cool appreciate the effort, but all of this is still completely absurd.
You guys need to delay this runtime deprecation until you can workout a way to display a UI fallback/warning to customers. Showing errors or nothing at all is unacceptable.
Why not solve these major issues BEFORE deprecating and breaking apps?
For pushing customers to the latest version of an app…
I’ve probably ranted about that before somewhere on CDAC. As a developer I don’t want to have to think about it. Atlassian’s platform should be handling that. If it’s a minor version, automatically update. If it’s a major version, initiate a series of notifications and UI overlays.
The backporting feature is dumb and unnecessary. Devs don’t want to be dealing with that. They just want everyone on the latest version.
For deprecations: the best deprecation is no deprecation…
The Confluence v2 API was an infuriating forced migration. For APIs I have no idea why Atlassian can’t adhere to modern API practices where versions are rolling and timestamped. Stripe’s API is a good example of that.
For UI Kit 1 it’s absurd that Atlassian created yet another component library instead of simply improving and iterating Atlaskit. And rather than building it as a standalone component library you guys intertwined it so heavily with the backend that this deprecation now means those apps break.
Who would ever build a UI component library that could be deprecated-as-in-breaks. At no point was that communicated. At the time, I naively assumed “UI Kit” was Forge’s variant of Atlaskit. You can obviously run very old versions of Atlaskit without any issues.
I assume UI Kit 2 is now more akin to Atlaskit as a standalone frontend package? If so, then there should never be any deprecations. If UI Kit 3 comes out and developers are forced to migrate yet again then we’re all just endlessly digging holes and filling them in.
