Building custom add-ons into Gmail and Outlook: challenges and lessons learned

To improve the user experience, mailbox giants such as Outlook and Gmail allow the integration of applications that can extend the functionality of the mailbox. Gmail calls them ‘add-ons’ and Outlook calls them ‘add-ins’. Over the past few months, we've had the opportunity to work on both types of applications. The idea behind them is the same, but the development experience they provide is significantly different.

User interface approach

While Microsoft allows the use of a wide range of technologies such as the React.js library, Google forces developers to use the widget-based CardService for interface development and blocks the use of HTML/CSS. CardService has limitations that make the UI feel less interactive. For example, a card can’t be partially updated - you need to develop a separate card for each add-on state.

Mailbox API

Google is very straightforward in this aspect, providing a GmailApp service out of the box that allows it to interact with the mailbox environment. This service is available as a global object. You don't need to worry about additional settings like authentication to use it.

On the other hand, Microsoft provides the Office.js library, but it is very limited in its interaction with Mailbox. You can get basic information about the environment, but you can't change mailbox instances for example.

To be able to delete an email, e.g. you're forced to use the Graph service, a RESTful API that won't work without authentication.

Authentication

Gmail add-ons simplify the authentication process by leveraging the existing Google account login, requiring minimal effort for accessing Gmail services within the add-on. At the same time, Microsoft is stricter in this aspect. As mentioned, to freely manipulate the mailbox, you should use additional Graph service, which won’t work without authentication.

In my opinion, this is the trickiest part of Microsoft add-in development. It forces you to think through various nuances in advance. For instance, SSO doesn’t work on all platforms, that’s why you need to implement a fallback flow. Moreover, authentication won’t work without additional architecture parts such as Azure application and access token validation service. All this increases the development effort and size of the codebase.

Conclusion

Google offers a more strict environment, prioritizing simplicity at the cost of flexibility. Microsoft, in contrast, provides a more flexible environment that allows more creativity and customization, but adds complexity and potential obstacles.

A notable point of comparison is the codebase size. Our Microsoft add-in contains approximately 5 times more lines of code than the Google add-on, despite both implementations offering the same functionality. This is a good example which underscores the difference between both platforms.

Are you looking to broaden the user experience of your digital product into your users’ mailboxes? Don’t hesitate to get in touch via hello@panenco.com, we’ll be happy to help!