An Overview of SharePoint 2013 App Development Model

SharePoint Apps can be developed using Visual Studio 2012, which includes a fully supported app template. They can also be developed using “NAPA” Office 365 Development Tools, a new set of tools for developing apps in a Web browser only available in hosted installations. SharePoint Apps can leverage any of the industry Web standards such as HTML5 and CSS3, JavaScript and jQuery (or any other frameworks/libraries), JSON, REST, OData, and OAuth. Thus, the options for integrating with external applications are vast.
There are three types of SharePoint Apps: SharePoint-Hosted Apps, Provider-Hosted Apps, and Azure Auto-Hosted Apps.
SharePoint-Hosted Apps are manifested entirely within SharePoint server and generally have no external dependencies. Their custom code is implemented by leveraging Client-Side Object Model (CSOM) or REST API, and is executed within the context of a browser. SharePoint-Hosted Apps can access libraries and lists to store content. Examples of these kinds of apps are PTO request or expense calculator.
Provider-Hosted Apps may have SharePoint components, similar to SharePoint-Hosted Apps, but the main business logic and data storage are manifested in an external infrastructure, such as an external Web server or in the Cloud. These apps are ideal for integration with external systems, such as a help desk support system. It’s important to note that Provider-Hosted Apps can also be developed using any other non-Microsoft tools and technologies, such as Eclipse or LAMP, due to the fact that their business logic and data storage are provisioned by the external infrastructure.
Azure Auto-Hosted Apps are somewhat similar to the Provider-Hosted Apps in that their main business logic and data storage are manifested in an external infrastructure. However, the Azure Auto-Hosted App package additionally contains the Website and database that is deployed and run outside of SharePoint. When this type of app is installed, SharePoint handles automatic provisioning of the Azure SQL Database and Azure-Hosted Website in an existing Azure account setup in the farm.

Development Considerations

SharePoint Solutions have inherent issues that stem from their complexity and that they run directly on the SharePoint server. Farm Solutions are the root cause of most SharePoint outages and errors; they are cumbersome to deploy and not suitable for hosted environments. Sandboxed Solutions have access to limited server-side API, but still require knowledge and experience with the server-side API. In addition, SharePoint Solutions are costly to develop and require performance monitoring to ensure they don’t affect the farm performance.
SharePoint Apps are now the preferred method for developing SharePoint customizations. They have the following advantages over SharePoint Solutions:
  • Stability: Since SharePoint Apps never run on the SharePoint server, this greatly increases the stability and performance of the farm. It makes it easier to upgrade to the next version of SharePoint since testing platform independent Apps is easier and faster than testing Solutions.
  • Capability: SharePoint Apps can communicate with SharePoint via OData and CSOM. Microsoft has greatly improved the capabilities of the CSOM and the REST API to enable developers to create a wide-range of custom solutions without using the server-side API.
  • Security: SharePoint Apps can leverage the newly added support for OAuth 2.0, which provides an easy way to manage their permissions. Developers can specify which permissions the app needs in order to function. The end-user installing the app is then prompted to accept the permission request the app needs to function.
  • Reusability: Apps can be packaged, reused, and sold via a Corporate or Public Marketplace, which makes it easy for end-users to acquire new apps. Also, the same exact app is guaranteed to work in both on-premise and Cloud environments.
  • Deployability: Microsoft has made great investments in simplifying the app installation and upgrade processes; thus, addressing many developer challenges with the solution model.

What Should I Use?

SharePoint Apps are capable enough to replace most of the Farm and Sandboxed Solutions. Specifically, they are suitable for a wide range of customizations, including:
  • Custom Web Parts
  • Event and Feature Receivers
  • Custom Field Types
  • Application Pages
However, there are some SharePoint components which do not have an equivalent in the SharePoint App Model. Some types of customizations are only suitable for Farm Solutions, including:
  • Custom Site Definitions
  • Delegate Controls
  • Custom Themes
  • Custom action groups and custom action hiding
  • User Controls
For more information on how to choose SharePoint Solutions or Apps, check out the article on “Apps for SharePoint compared with SharePoint solutions.”

Deployment Considerations

SharePoint 2013 can be deployed in three different ways: On-Premise Installation, Office 365 & SharePoint Online, and Hosted Installation. Farm Solutions can only be deployed to the On-Premise Installation of SharePoint. Sandboxed Solutions and SharePoint Apps can be deployed to all three different types SharePoint installations.


SharePoint Farm and Sandboxed Solutions are still supported in SharePoint 2013, but Sandbox Solutions are deprecated and should not be used. In some cases, Farm Solutions are either a better way or the only way for specific types of customizations. SharePoint Apps provide a brand new approach to extend SharePoint functionality and are now the recommended way to develop customizations for SharePoint 2013. They address several development and deployment challenges commonly associated with SharePoint Solutions, and allow developers to leverage a wide range of modern Web standards and technologies.