OverView of SharePoint Apps

There are two basic kinds of apps for SharePoint — SharePoint-hosted and provider-hosted. To make the best decision about the right kind to develop for your scenario, start by learning what both types of apps for SharePoint have in common.

Note
A device app, such as mobile app, isn't really an "app for SharePoint" even when it accesses SharePoint. The same is true of a web application that is launched from outside of SharePoint. If you want to develop any of these kinds of apps, see Access SharePoint from mobile and native device apps.

• All apps for SharePoint are self-contained pieces of functionality that you write to extend the capabilities of SharePoint websites to solve a well-defined business problems.
  
• Apps don't have custom code that runs on the SharePoint servers. Instead, all custom logic moves "up" to the cloud, or "down" to client computers, or "over" to an on-premise server that is outside the SharePoint farm or SharePoint Online subscription. Keeping custom code off SharePoint servers provides reassurance to SharePoint administrators that the app can't harm their servers or reduce the performance of their SharePoint Online websites.
  
• Business logic in an app for SharePoint can access SharePoint data through one of the several client APIs included in SharePoint. Which API you use for your app depends on certain other design decisions you make.
  
• Almost all major types of SharePoint components can be part of an app for SharePoint, including pages, lists, workflows, custom content types, list templates, Web Parts, and more.
  
• The SharePoint websites where apps for SharePoint are installed, and from which users launch them, are called host webs. The SharePoint components, however, are generally in a special child web of the host web called the app web.
  
• Apps for SharePoint can fit into a SharePoint website in several ways:
  

  	As an immersive full-page experience that can have the look and feel of a SharePoint page.
  	As part of a webpage, using a special kind of control, called an app part, to surface an iframe element that contains the app.
  	As UI commands that extend ribbons and menus by adding the app to list items, documents, and more.

• All apps for SharePoint that users install get a tile on the Site Contents page of the SharePoint website. Clicking the tile runs the app.
  
• An app for SharePoint is configured using an app manifest—an XML file that declares the app’s basic properties, where it runs, and what SharePoint should do when the app starts. Among other things, the manifest can specify what languages the app supports, what SharePoint services and functionality it depends on, and the permissions to the host web that the app needs. (Apps for SharePoint have full control of their own app web.)
  
• You distribute apps for SharePoint in app packages that always include at least the app manifest. (If there are no SharePoint components, the app manifest may be the only thing in the app package. ) If the app has SharePoint components in an app web, these are included in the package as a set of XML files. Remote components that are hosted outside of SharePoint, such as a remote web application or database, are not included in the package and are deployed separately from the app package. (However, the app manifest does specify the URLs of the remote components.)
  
• App packages can also include apps for Office. When the app for SharePoint is installed, the app for Office is added to an apps for Office catalog in SharePoint. Users can install it from the catalog into the Office applications like Word or Excel.
  

Tip
Take a look at a few apps for SharePoint in the Office Store to get a sense of what you can develop. Or open a SharePoint 2013 website and install some of the free apps for SharePoint. Just navigate to Site Contents | Add an App | SharePoint Store.

A couple of points for veteran SharePoint developers

We've deprecated sandboxed solutions that contain custom server-side code. We still support "No code" sandboxed solutions and sandboxed solutions that contain only JavaScript.
Apps for SharePoint don't use the server-side SharePoint object model. The client-side object models are greatly expanded in SharePoint 2013. Although some APIs in the SharePoint server object model aren't available in the client object models, these are almost entirely administrative and security-related classes. Custom SharePoint logic that addresses these areas is more appropriate for a Windows PowerShell script or classic SharePoint farm solution. To learn how to choose among apps for SharePoint, classic SharePoint farm solutions, and sandboxed solutions, see Apps for SharePoint compared with SharePoint solutions.

Two ways to distribute or sell an app package

You can distribute an app package in two ways:

• To an organization's app catalog, which is a dedicated SharePoint site collection in the SharePoint Online subscription or on-premise farm. This method is used when the app is custom-made for a particular organization.
  
• To the Office Store. The store handles the marketing process for you, from discovery to purchase to updates. Microsoft has a Seller Dashboard to help you sell apps through the Office Store.
  

After you deploy the app in either way, it is available for installation on the add an app page of SharePoint websites. If the app needs permissions to the host web or its parent subscription, SharePoint prompts the user who installs the app to grant those permissions.
When you need to update an app to fix a bug or to add functionality, make the changes and raise the app's version number in the app manifest. Then redeploy the app package to the store or app catalog. Within 24 hours, users get a notice in the SharePoint UI that an update is available. They can install the update with a single click.

Two types of apps for SharePoint: SharePoint-hosted and provider-hosted

SharePoint-hosted apps for SharePoint

SharePoint-hosted apps consist almost entirely of SharePoint components in an app web. They are sometimes said to have their center in SharePoint.
Like all apps for SharePoint, a user can run a SharePoint-hosted app from a tile on the Site Contents page of the SharePoint websites to which it's installed. Optionally, it can also have two other kinds of UI components in the host web; app parts and custom actions (that is, custom ribbon buttons or menu items). Everything else in a SharePoint-hosted app is deployed to the app web. These components are defined declaratively using XML files, and they can include, among others:

Custom pages	Workflows	Modules (sets of files)
List templates	List and library instances	Custom list forms and views
Custom content types	Web templates	Built-in columns (not custom columns)
Built-in Web Parts (not custom Web Parts)	JavaScript files	Custom buttons and menu items for the app web

All business logic in a SharePoint-hosted app uses JavaScript either directly on a custom page or in a JavaScript file that is referenced from a custom page. A JavaScript version of the SharePoint object model (JSOM) is available to make it simple for the app to perform create, read, update, and delete (CRUD) operations on SharePoint data.
Custom pages in a SharePoint-hosted app are generally ASP.NET pages (ASPX) and they can declaratively reference ASP.NET and in-the-box SharePoint controls, but there can be no code behind. However, you can customize the SharePoint controls using a client-side rendering option and custom JavaScript.
The JavaScript in SharePoint-hosted apps can access data and resources that are outside of the app web by using either of two techniques for safely working around the browser's same origin policy: a special JavaScript cross-domain library or a specific JavaScript WebProxy class. Using these techniques a SharePoint-hosted app can work with data on the host web, its parent subscription, or anywhere on the Internet.

Provider-hosted apps for SharePoint

Any SharePoint component that can be in a SharePoint-hosted app can also be in a provider-hosted app. But provider-hosted apps are distinguished from SharePoint-hosted apps because they include at least one remote component; such as a web application, service, or database that is hosted externally from the SharePoint farm or SharePoint Online subscription. This could be a server in the same corporate network as a SharePoint farm or a cloud service. The external components can be hosted on any web hosting stack, including the Linux, Apache, MySQL, PHP (LAMP) stack.

Note

The "provider" is whoever owns the server or cloud account. It can be the same company or organization that owns the SharePoint farm or SharePoint Online tenancy where the app is to be installed. But the developer of the app can also be the provider. Typically, when an app is created for an organization, the organization provides the hosting. However, when an app is created for multiple organizations, it's more likely that the developer hosts the remote components. Developer-hosting is mandatory if the app for SharePoint is being marketed through the Office Store, because the developer doesn't have any contact information for the app purchasers. In this scenario, the various instances of the app know the URI of the remote component because it is specified in the app manifest.

You have complete flexibility for the hosting framework that you use for the remote components. You don't have to use a Microsoft stack. Any web hosting framework can be used, including LAMP (Linux, Apache server, MySQL, PHP), Nodejs, Java, Python, and others; and it is fine to use non-Microsoft development tools. In addition, the remote components can be hosted in non-Microsoft cloud services.
You can give remote pages in the app the look and feel of SharePoint pages by using a special chrome control.
Remote data can be blobs, caches, message queues, content delivery networks (CDN), and databases, among others. And databases can be any type including relational and object-oriented. The remote data can be accessed in a variety of ways. For example, you can use Business Connectivity Services (BCS) to surface the data in a SharePoint list. Another option is to expose data in a grid on a page of a remote web application.
Apps for SharePoint use SharePoint APIs to connect and integrate with SharePoint features—search, workflow, social networking, taxonomy, user profiles, BCS, and more. This lets them read documents, do searches, connect people, and perform CRUD operations. There is more than one set of the APIs:

• When the remote components are implemented with .NET, the managed code SharePoint Client-Side Object Model (CSOM) library is available.
  
• For remote components that are not based on .NET, there is a set of REST/OData APIs that can be used to access SharePoint data. These can also be used from a .NET client if you prefer working with an OData interface.
  
• The JSOM library, described earlier, cannot be used on a remote page, but provider-hosted apps can have custom SharePoint pages in an app web and JavaScript on these pages can use the JSOM library.
  

Provider-hosted apps that access SharePoint are security principals just as users and groups are. The app principal has to be authenticated and authorized, just as the user does. The app needs permissions to perform operations on SharePoint data in the host web. In most scenarios, the effective permissions of a user working with SharePoint through an app for SharePoint are the intersection of the user's and the app's permissions, although there are some scenarios in which a user can do things with an app that she wouldn't otherwise have permission to do.
Provider-hosted apps can connect to any internal or public web service; and, unlike SharePoint-hosted apps, they can handle SharePoint list and list item events, such as adding an item to a document library.

Choose your SharePoint development path

Ready to get started?

• If you are an experienced SharePoint developer, we recommend that you start with SharePoint-hosted apps. They're the most similar to the kinds of SharePoint extensions that you have made in the past.
  Get started creating SharePoint-hosted apps for SharePoint
  
• If you are an experienced ASP.NET web application developer, we recommend that you start with provider-hosted apps. They're built around web applications.
  Get started creating provider-hosted apps for SharePoint
  
• If you want to develop a provider-hosted app on a non-Microsoft stack, here's how to get started:
  
  • Install tools that are appropriate for your stack, if you don't already have them.
    
  • Get a developer account on Office 365 for testing and debugging purposes. For details, go to Set up a development environment for apps for SharePoint on Office 365, or if you already have an Office 365 subscription, you just need to create a Develper Site on it..
    
  • Your app will use SharePoint's REST/OData APIs to perform CRUD operations on SharePoint data:
    
    • Find our explanatory documentation in the article Get to know the SharePoint 2013 REST service and other articles that this one links to.
      
    • Find reference documentation at REST API reference for SharePoint 2013.
      
  • If you are not using Visual Studio, you have to create the app manifest file and the app package. For information, see Explore the app manifest structure and the package of an app for SharePoint. There are a lot of time-saving advantages to using Visual Studio and Microsoft Office Developer Tools for Visual Studio to make your manifest and package. We recommend that you consider them, even if you use another tool to create the remote web application itself. The Community edition of Visual Studio is free.
    
  • There are sample provider-hosted apps for some non-Microsoft languages and platforms in the OfficeDev section of GitHub; for example, PHP-App-for-SharePoint.