Microsoft CEO Satya Nadella has called Office 365 “the most strategic development surface area” for the company. With add-ins, Azure and the latest versions of the productivity tools inside the suite, Microsoft is sharpening its focus on what has come to be known as “the future of worker productivity.”

Office 365 was first launched by Microsoft in 2011. It consisted of the hosted solutions for SharePoint, Exchange and Lync. At the time, the service was offering the 2010 versions of these products, which had some limitations in terms of the extensibility options for developers. SharePoint 2010 was limited to support just sandboxed solutions, which offered developers only limited options when deploying custom code. This left many developers with limited options for deploying customizations to Office 365, specifically SharePoint.

Sandboxed solutions allowed developers to include custom server-side code that would run in Office 365, but it was restricted to working with a subset of what was possible with the server-side API; specifically, it was limited to the current site collection. In addition, Office 365 development for the most part really only meant SharePoint Online development, as there were not many development and customization options available with Exchange Online and Lync Online.

With the release of SharePoint 2013 and the entire “Office 15” wave of products, the development story was greatly improved. As Microsoft gradually upgraded all customers on Office 365 to the latest versions of these products, customers started to see many more customization options. At the time these new options were mostly still limited to just SharePoint Online, but two significant additions or changes to the platform had great impact.

The first big change that SharePoint 2013 introduced was a new development and extensibility model called the SharePoint App Model, since renamed to the SharePoint Add-in Model. It has one significant difference from the old way of doing SharePoint customizations with SharePoint solutions. Unlike with SharePoint solutions, where the custom server-side code authored by developers was run within the SharePoint process (either as a fully trusted solution or within the sandboxed user code service), SharePoint Add-ins are run external to the SharePoint process. These SharePoint Add-ins can run within the browser as a client-side solution, or remotely on some other server or service external to SharePoint.

To support this new development model, Microsoft made significant investments in SharePoint’s API service, specifically around the client-side object model (CSOM), JavaScript object model (JSOM), and tremendous improvements to the SharePoint REST API that was previously limited to just reading and writing to SharePoint lists. In addition, Microsoft added support for apps to have their own first-class identity so developers could assign applications permissions that were either independent or used in combination of the user’s permissions.

The second big change that SharePoint 2013 introduced was the Office Store. The Office Store contains apps created using this new SharePoint Add-in Model. Customers can search and find Add-ins and install them into their SharePoint environment. This includes either SharePoint 2013 on-premises installations or SharePoint Online within Office 365. Developers can create custom Add-ins and publish them to the store.

Like other online stores, such as the Apple App Store and similar stores for OS X, Android, Windows and Windows Phone, once the Add-in goes through a certification process, the developer can collect a percentage of the revenue from the sale facilitated by Microsoft. The significant impact of the Office Store for Office 365 customers is that it makes the installation, upgrade and uninstallation process for acquiring SharePoint Add-ins much easier than the same process with the SharePoint solutions.

In addition to the Office Store, all customers have a private store called the App Catalog. Each customer in Office 365 has a single App Catalog that is shared across all site collections in their tenant. In an on-premises SharePoint 2013 deployment, each Web application can have its own App Catalog, or one can be shared across multiple Web applications. This allows customers to create Add-ins and share them to just their organization and not publically to the Office Store. It also allows them to bypass any special requirements or limitations the store puts on Add-ins for various reasons.

Understanding the SharePoint Add-in Model
Let us look at this new development model for SharePoint a bit more. The two most significant impacts this new development model has for SharePoint developers over the previous SharePoint solution model are the fact that they no longer write code that runs within the SharePoint server-side process, and that all SharePoint Add-ins that they build will work both in SharePoint 2013 on-premises and SharePoint Online deployments. This is very different from the solution extensibility model in the sense that farm solutions are not permitted in SharePoint Online. Only sandbox solutions are permitted in SharePoint Online, and they are limited in what they can achieve when compared to farm solutions.

Developers can create one of two types of SharePoint Add-ins. Each type differentiates where the Add-in resides when it is deployed. The first type is a SharePoint Hosted Add-in. These types of extensions have all the assets related to the Add-in deployed to SharePoint in a special site called an AppWeb. The AppWeb is an isolated location within a SharePoint site that keeps the Add-in from interacting with the hosting SharePoint site without being granted explicit permissions to do so, giving customers the confidence what they are installing is safe.

In these types of Add-ins, any custom business logic is implemented using client-side scripts and executed within the client’s browser. This model is well suited to the single-page app style of development that has been made popular using frameworks like Angular and Ember, or libraries such as KnockoutJS.

The other type of SharePoint Add-in developers can create is a Cloud Hosted (or Provider Hosted) Add-in. In this option, the majority (or all) of the Add-in is deployed external to SharePoint. This external deployment option is left entirely up to the developer. Microsoft would clearly like to see them deployed to Azure Web Apps, but they can also be websites on IIS or competing platforms and technologies such as Amazon Web Services, Google’s cloud, Heroku, Apache servers… It really does not matter.

The reason why it does not matter is because the Add-in is simply registered with the SharePoint site upon installation using a simple XML file, known as the AppManifest.xml. This file defines the unique ID, name, start page and permissions the app needs to be granted in order to function. The applications then communicate with SharePoint over HTTP[S] requests using either the CSOM, JSOM or raw REST APIs. This is true for both the SharePoint Hosted and Cloud Hosted Add-ins.

SharePoint Add-ins can be surfaced in the hosting SharePoint site in a few ways. One option is to take over the entire browser interface in an immersive experience. Developers are free to make their custom applications either look unique, or have them inherit the same user interface colors and controls as the hosting application using controls provided by Microsoft. Another option is to host the application in an app part, also known as a client Web Part. To the end users, these feel very similar to traditional Web Parts in SharePoint as they carve out little boxes on the site and load the custom application within an IFrame.

Developing for Office clients as well
So far we have only looked at the extensibility options for SharePoint in Office 365, but another significant opportunity for developers is developing for the Office 2013 client suite. Previously, developers could write Add-ins using Visual Studio Tools for Office (VSTO). This option was limiting, though, because the customizations would only work in the Windows versions of the Office clients such as Outlook, Word, Excel and PowerPoint. In recent years, Microsoft has released versions of the Office clients online as well as for OS X, iOS and Android, and these platforms do not support the VSTO-based extensions.

To address this limitation, in Office 2013 Microsoft introduced a new extensibility option: the Office Add-in model. Similar to SharePoint Add-ins, the extensions run as Web applications hosted externally to the Office clients. Developers leverage a JavaScript-based API for their application provided by Microsoft. Users can acquire Add-ins from the Office Store or their company’s App Catalog. Developers declare an Office Add-in with a single XML manifest file that tells the Office client application what kind of application it is, what permissions it requires, and what features it supports, as well as the URL for the start page of the application. Each Add-in can have a separate URL depending on the hosting application experience, such as a desktop, tablet or mobile experience.

At the time of this writing, Office Add-ins are not supported in every deployment of the Office clients. There is full support in the Windows clients and various support for Add-ins in the OS X and iOS clients, but Microsoft is continuing to add support for Add-ins in all the modern versions of the Office clients throughout the remainder of 2015 (and going forward) as the goal is full support in all Office clients.

So what kind of things can developers build using this model? With Outlook, developers have access to an area in the e-mail read/compose pane between the header and body of the e-mail. Developers have access to the contents within the e-mail (provided the user who installs the Office Add-in grants the permissions it requests). For Word and Excel, users can add their Add-ins in the task panes within those applications. Similar to Outlook, developers can access content within the hosting application like in an Excel workbook or Word document, as well as write to selected areas.

These are significant productivity improvements for Office customers because it allows them to work with their data right where they are spending a considerable amount of their time: in Office. Some of the popular Add-ins within the Office Store today are ones that detect shipping tracking codes within an e-mail and show the tracking details right inline without ever leaving the e-mail.

Office 365-enabled Web applications
In addition to SharePoint Add-ins and Office Add-ins, developers have a third option they can take advantage of. I like to refer to these as Office 365-enabled Web Applications. These are regular Web applications authored in any Web technology and on any platform, such as ASP.NET MVC, Node.js, Ruby, Java or PHP. Developers can then leverage data within their company’s Office 365 investments within the application.

Think of all the times you have been tasked to create a Web application that needed to include contacts, e-mail, calendar items or files from your user’s enterprise data. When your company is in Office 365, all this data is accessible to you as a developer using the multiple API options at your disposal.

The many API options with Office 365
As previously mentioned, Microsoft greatly expanded on the CSOM, JSOM and REST APIs for SharePoint in SharePoint 2013. While they have been improving these since release, they have also introduced a significant number of APIs for Office 365.

In late 2014, Microsoft shipped a new set of Office 365 APIs based on the OData 4.0 protocol specification that exposed not only SharePoint Online data, but also data within Exchange Online such as contacts, calendars and e-mail (not to mention files stored in users’ OneDrive for Business deployments). These APIs share a common versioning, permission and authentication model.

Each of these endpoints was treated as a separate endpoint, which meant separate authentication and lookup requests, but Microsoft has improved upon this with the announcement in April of the new Unified API. This single endpoint will be the entry point for all Microsoft APIs. At the time of this writing, the Unified API is available as a Preview API and has coverage for all Office 365 endpoints such as contacts, calendars, messages and files. It includes support for new endpoints that Microsoft has recently introduced, as well including the groups API.

Microsoft also announced both plans and preview APIs for things such as the Office 365 Video Portal, Skype for Business, the Office Graph that powers tool such as Delve, as well as many others.

Each of these different Office 365 APIs, including the Unified API, have native SDKs as well as raw REST APIs. The Office 365 team is moving fast and releasing things as they are available, so which APIs and SDKs are available for each endpoint vary. (But they all include a REST API.) The native SDKs wrap the REST APIs in a fluent API that some developers prefer. In a show of their openness in the Office 365 platform, you will find native SDKs for .NET, iOS and Android, as well as cross-platform SDKs for Cordova and Xamarin.

Azure AD
There is one very important aspect that I have not addressed so far: app identity and authentication. Office 365 uses Azure Active Directory (AD) as the storage mechanism for all users and applications deployed to Office 365. It relies on Azure AD to handle all authentication and app permissions. All the Office 365 APIs require that developers create applications in Azure AD and give those applications access to the different endpoints, granting granular permissions to each application. These applications can have both delegated permissions, where both the application and user must have the necessary permissions; or application permissions, where the application can impersonate a user or authenticate without user involvement.

Azure AD implements the popular OAuth 2.0 Web standard authentication protocol. This protocol supports multiple options for authentication, referred to as OAuth flows. These include the Authorization Code Flow where users authenticate with Azure AD and provide a token to the application or SharePoint Add-in that is used to obtain an access token (the key used in all Office 365 APIs).

Another option is the Client Credentials Flow, which allows developers to create applications that have app-only permissions that can authenticate without user involvement or elevate the permissions of the current user.

Finally, Azure AD also supports Implicit Flow, which facilitates pure client-side applications such as the popular single-page app model of development.

At the time of this writing, there is a little confusion about where SharePoint Add-ins reside: Do they live in SharePoint or Azure AD? When SharePoint 2013 was introduced in Office 365, Add-ins and their permissions were stored using Azure’s Access Control Service, but that has since been deprecated in favor of Azure AD. Microsoft is working to converge all SharePoint Add-ins to Azure AD and into a single Add-in registration portal. Stay tuned for more information on this throughout 2015.

Conclusion
Microsoft has made significant strides with Office 365 development opportunities for SharePoint, Exchange, the Office clients, as well as custom Web applications that leverage Office 365 data. Developers have many options available to them in creating custom applications. This is just the tip of the iceberg too as Microsoft and the Office 365 team are constantly improving upon their investment and introducing options for developers.

One of the hardest things is staying on top of everything. The best place to get the latest information is at dev.office.com. Here you’ll find documentation, articles, news and tons of free training opportunities from the Microsoft Virtual Academy and code samples found in its quickly growing organization on GitHub.

In addition, the Office 365 Developer team announced in April a new venture: the Office 365 Developer Program. Developers can sign up for free to get a monthly newsletter on the latest changes and improvements, as well as to get access to special deals, meetings and webinars from third parties.