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.