It’s official: Teams Apps are becoming Microsoft 365 Apps

Ever since Build 2021, when Microsoft Teams message extensions and personal tabs started showing up in Outlook and on Office.com, I’ve been saying that it was the start of a journey. The app ecosystem that was created for Microsoft Teams has been a success and the technology behind it is solid. The app manifest, the different areas of development, the way those are built into the client experience, the support across multiple devices and platforms: the Teams Developer Ecosystem was just too good to keep to just Teams.

The two questions left were: how soon would this functionality reach other Microsoft 365 clients, and when would the name get changed?

We got the answer to at least one of those this week.

Less Teams App Manifest, more Microsoft 365 App Manifest

From a possibly-AI-generated marketing blog post this week, and from a less-marketing-but-more-useful technical document from the week before, we now know that Microsoft intends to refer to the development experience that creates Teams apps as “the unified app package for M365[sic] platform” – a name that I think will probably change, but no longer includes the Teams product name.

We also know that Microsoft will start referring to the Teams App Manifest as simply the “app manifest”:

Invest now, for future reward

All this re-naming is pointless though, unless there’s some actual change. We’re at the very start of that now. Microsoft is seemingly ready to make the next move and build on top of just exposing extensions and tabs in Outlook. We’ve already seen messaging extensions used to kickstart the Copilot plugin library and as a bridge for developers looking to build Copilot support into their applications.

Aside: Copilot, Messaging Extensions & Plugins

Looking back on it now, I actually think that Messaging Extensions being used as pseudo plugins by Copilot were the perfect “right time, right place” example of technology being ready to be re-purposed. By solving an immediate need for Copilot (how can we support plugins without loads of dev effort), they also brought in hoards of developers and their existing applications, all keen to showcase their offering within the Copilot UI. I think that this really elevated Messaging Extensions (and the Teams Developer Platform in general) within Microsoft, out of obscurity and into the board room, giving leaders some new ideas how what else they could do with it. I think that journey has (in some respect) led to the decisions discussed in this blog post.

The next version of the Teams app manifest will allow developers to both specify what client capabilities their apps need, and also any dependencies between components of their solution. This abstraction will (in the future) allow Microsoft to expose apps in many more places, as long as the core capabilities are catered for. Knowing the dependencies also means that Microsoft won’t try and show a tab from an app that also requires a message extension to be useful, if the surface they’re exposing the tab on doesn’t support them.

Today, developers can specify that their app requires one or more of:

• HTML-based dialogs
• HTML-based dialogs for Bot Framework
• Adaptive Card dialogs
• Adaptive Card dialogs for Bot Framework

That’s a pretty mediocre list, but I imagine that it’s going to get a lot more detailed over time.

When defining relationships between components, developers can record whether they are one-way or mutual dependencies.

Developers using the devPreview app manifest (after v1.19) can add this in today – look for the elementRelationshipSet and requirementSet tags.

If you’re not using the devPreview version of the app manifest you’ll need to wait for this to come to the latest version of the app manifest – most likely v1.20.

Nothing Changes Yet, Though

Despite the hype of the blog post we saw this week, nothing actually changes for the moment. Support for specifying runtime requirements in app manifests (and indeed, supporting the app manifest for having apps at all) is still very limited, and essentially reflects the position established in 2021:

However, we can at least now see the direction of travel, and that’s helpful for planning. Developers can now set aside time to work out what the required components of their applications are, and what the dependencies between them are.

Also, for what it’s worth, I like the approach that Microsoft is taking here: working in abstract terms rather than asking developers to specify support for named applications. It allows more flexibility in the future as things change on Microsoft’s side, without requiring rework for developers.

This whole subject might well come up at Ignite this year (I’ve no idea, I’m just speculating) – but if it does, just remember that this is about putting foundations in place for the future rather than anything actually changing soon.