Through extensive user research, we’ve identified what Microsoft 365 users value most for boosting productivity. They want uninterrupted workflows, an all-in-one workspace, and minimal context switching. With this insight, we evolved Microsoft 365 into a unified platform across Microsoft Teams, Outlook, Microsoft 365 app (formerly Office.com), and more. For you as a developer, this means broader user reach without needing to rewrite code for each host. For IT admins, it’s about centralized app management. That’s why with manifest version v1.13+, apps will now automatically appear across multiple Microsoft 365 hosts, making development smoother and more impactful.

Here’s an example of how this new app experience would work: Picture two users, Kat and Daniela, working on a project in a collaborative design app called Relecloud. They kick things off during a Teams meeting, using Relecloud’s configurable tab app capability. After the meeting, they keep the conversation going asynchronously via email in Outlook. Whenever they need to make changes to the project, they can simply open Relecloud’s static tab directly within Outlook. Finally, when Kat feels the project is ready, she leaves a comment in Relecloud, and the app’s bot automatically notifies Daniela in Teams.

This new app experience requires a shift in how developers think. Instead of building for individual hosts, developers now create for the unified Microsoft 365 platform—using modular app elements like static tabs, message extensions, configurable tab and bots. These elements adapt across hosts, delivering a seamless, consistent experience for users.

To streamline building apps for Microsoft 365, we are improving developer documents, tooling and automated testing to facilitate the mindset shift from specific products to platform. At the core of this evolution is the new ability to specify runtime requirements in your app manifest—a key feature that optimizes functionality across hosts.

Feature overview

So how does it work? The ability to specify runtime requirements in your manifest enables you to build apps that only show the relevant components supported by the host. Here’s a sneak peek of how this feature can enhance your app’s versatility:

• Functionality Support: Maintain the unified app package for Microsoft 365 platform and only show the app capabilities whose functionalities are fully supported by Microsoft 365 suites including Teams, Outlook, Microsoft 365 app and Copilot. For instance, a static tab that relies on HTML-based dialogs will only be available on hosts that support this functionality.
• Element Dependencies: Ensure dependencies between different parts of your app are respected, in order to deliver the full user scenario. For example, imagine you’re building an app with a static tab that depends on a message extension. Being able to specify these requirements in manifest allows you to ensure that the static tab will only appear if the message extension is supported on the host.

“This new ability to specify runtime requirements in app manifest will allow us to seamlessly expand our app from Teams to Outlook, Microsoft 365 app and beyond, without sacrificing any functionality or user experience.” – Microsoft 365 Copilot for Sales, early preview user.

With this new ability, you’re not just future-proofing your app—you’re ensuring it’s optimized for each and every user interaction, no matter which host they’re in. This type of intelligent control improves user experience and reduces unnecessary debugging or host-specific issues.

Dive into the feature highlights

Now, let’s explore some of the key components of this new feature, designed to provide greater flexibility and ease of development:

1. hostMustSupportFunctionalities Property

This property enables developers to specify the capabilities their app elements rely on. For example, if a static tab requires a specific TeamsJS capability to function, you can ensure that the tab won’t appear on a host where that capability isn’t available.

1. elementRelationshipSet Property

Sometimes, your app’s elements depend on each other to create a cohesive experience. The elementRelationshipSet property allows you to define dependencies between these elements, ensuring that they either all appear together or not at all—avoiding fragmented user experiences.

• • oneWayDependencies: Ideal when one element relies on another. For instance, a static tab that serves as a settings page for a message extension will only show up when both are supported on the host.

• • mutualDependencies: When multiple elements depend on one another, this new property ensures that if one element isn’t supported, none of them will appear.

Start building today

The best part? You can start leveraging this new ability today! The ability to specify runtime requirements is now available in the devPreview manifest schema for public preview. By adding those properties to your app, you’re setting yourself up for success, ensuring a seamless experience for your users, no matter where they engage with your app. It brings you the future of productivity apps—where flexibility meets functionality, and your app thrives on the unified Microsoft 365 platform. Ready to dive in?

• Step-by-Step Implementation: Integrate this feature into your app using our detailed dev documentation. Start by adding the hostMustSupportFunctionalities and elementRelationshipSet properties to your manifest.
• Interested in sharing your feedback? We’re eager to hear from you! Your feedback is invaluable to us as we continue to fine-tune and enhance this feature. Fill out this form to leave your contact information and we’ll reach out to collect feedback on how this new feature is working for you.

Take the leap and start developing apps that are smarter, more adaptable, and ready for the cross-host future of Microsoft 365. The platform is evolving, and with it, so are the possibilities for your apps. Let’s build together!