Overview of apps for SharePoint

apps for SharePoint

Learn what apps for SharePoint are, why you should build them, and the concepts that are fundamental to building them in SharePoint 2013. This topic describes the basic concepts about how to build apps in SharePoint 2013.

Last modified: February 27, 2015

Applies to: apps for SharePoint | Office 365 | SharePoint Foundation 2013 | SharePoint Server 2013

Apps for SharePoint are easy-to-use, lightweight web applications that integrate popular web standards and technologies to extend the capabilities of a SharePoint website. This topic helps you understand the basic concepts about how to build apps in SharePoint 2013.

There are two basic types of apps for SharePoint as shown in the following diagram. An app can also have some components in SharePoint while others are in the "cloud." Learn more about the various types of apps and hosting options in Choosing patterns for developing and hosting your app for SharePoint.

Apps for SharePoint hosting options

Why build apps for SharePoint?

There are many great reasons to build an app for SharePoint:

A familiar programming model, plus popular technologies and languages

For provider-hosted apps, the web is the platform. If you can build a web application, you can build an app for SharePoint.

Here are some highlights:

  • For provider-hosted apps, use any language - like HTML, JavaScript, PHP, or .NET - and your favorite web development tools - like Visual Studio 2012.

    For SharePoint-hosted apps, you can use the new Napa Office 365 Development Tools.

  • Distribute the app’s logic, data, and user interface (UI) in separate components to fit your needs.

    For example, a provider-hosted app can have presentation logic in HTML and JavaScript that runs on the client, business logic in .NET that runs in Microsoft Azure, and data that is stored in SQL Azure. Or, an app in PHP could have data in MySQL.

    A SharePoint-hosted app can have presentation logic in ASP.NET and SharePoint controls and logic in JavaScript.

  • Connect to most internal or public web services with provider-hosted apps.

  • Use the new OAuth 2.0 support in SharePoint in provider-hosted apps. (SharePoint-hosted apps do not requre an authorization system.)

  • Use the expanded capabilities of REST and client APIs (JavaScript and .NET) to access the rich data and services in SharePoint such as search, workflow, social networking, taxonomy, user profiles, and Business Connectivity Services (BCS).

A familiar web experience, yet more flexible

Apps for SharePoint have the same user experience as SharePoint websites but are more flexible – they fit seamlessly 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 app parts to surface an iframe element that contains the app

  • As UI custom actions, extending ribbons and menus by adding the app to list items, documents, and more

The following diagram shows the types of user experiences available. For more information about apps for SharePoint, see UX design for apps in SharePoint 2013.

Apps for SharePoint user experience options

Integration with apps for Office

Apps for SharePoint can integrate with apps for Office, which are based on the new web-based extensibility model in Office 2013. Apps for SharePoint can also be part of an Office 2013 document template. For more information about apps for Office, see Overview of apps for Office.

Reach users through the Office Store and the App Catalog

Use the Office Store to sell your app for SharePoint to users and IT professionals for personal or corporate use. The Office Store handles the end-to-end process from discovery to purchase to updates.

Apps for a company are deployed to the organization's internal App Catalog that is hosted on SharePoint, which provides the same complete back-end support. For more information about the Office Store and the App_Catalog, see Publish apps for SharePoint.

Building an app for SharePoint

To build your app for SharePoint, you must do the following:

Configuring an app

An app for SharePoint is configured with SharePoint using an app manifest—an XML file that declares the app’s basic properties, where it runs, and what to do when it starts.

An app manifest file can do many things, such as use different authentication schemes (also known as app principals) and declare the permissions the app needs. It can also include tokens that are replaced at build/run time, so you can reference your app and pass context (for example, the SharePoint language and where the app is installed).

The following simple app manifest tells SharePoint to register the app and invoke a remote page when the app starts.

<?xml version="1.0" encoding="utf-8" ?>
<App xmlns="http://schemas.microsoft.com/sharepoint/2012/app/manifest (http://schemas.microsoft.com/sharepoint/2012/app/manifest)"
ProductID="{5eccee90-1e41-4ecc-af8c-485facb5c188}"
Version="1.0.0.0"
SharePointMinVersion="15.0.0.0"
Name="LocalTheater"
>
  <Properties>
    <Title>Local Theater</Title>
       <StartPage>https://~remoteAppUrl/Default.aspx/?{StandardTokens}</StartPage>
  </Properties>
  <AppPrincipal>
    <RemoteWebApplication ClientId="*" />
  </AppPrincipal>
</App>

Deciding where the app’s code runs (hosting options)

You decide where the app’s code runs by choosing the hosting option —in SharePoint, in the cloud, or a mix of SharePoint and cloud.

  • SharePoint-hosted apps: When the app is hosted in SharePoint itself, the code is only in HTML and JavaScript and is hosted by SharePoint.

  • Provider-hosted apps: You or your app purchaser’s IT department must host a provider-hosted app on a dedicated server or third-party hosting service. Depending on your choice, these apps run either on your server or in the cloud. A provider-hosted app can also include SharePoint components that run in SharePoint, so it can be mixed in its hosting.

Communicating with SharePoint using SharePoint APIs

Apps show their power when they 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 much more. SharePoint APIs include the following:

To start working with SharePoint APIs, see How to: Complete basic operations using SharePoint 2013 REST endpoints, How to: Complete basic operations using JavaScript library code in SharePoint 2013, and Basic operations with the SharePoint .NET client object model.

Before your code can call SharePoint APIs from a provider-hosted app, you must authenticate to SharePoint and get user consent or authorization. (This is not required for SharePoint-hosted apps.) For more information, see Data access options for apps in SharePoint 2013 and App permissions in SharePoint 2013.

Packaging and distributing an app

Apps for SharePoint are distributed as an app package, and the components it contains depend on where your app is hosted. A provider-hosted app package might contain only the app manifest if the app is hosted on a dedicated server or third-party hosting service. A SharePoint-hosted app package might contain some SharePoint-related components and the app manifest. In addition, app packages can include components such as apps for Office. For more information, see How to: Publish an app for SharePoint by using Visual Studio.

If you use Napa Office 365 Development Tools or Visual Studio 2012 to build apps and deploy directly from them, the tools let you publish your app into a file that has an .app extension. You can then distribute the app in one of two ways:

  • Apps that are meant to run within a particular organization can be deployed using the App Catalog.

  • Apps for the Office Store can be submitted via the Microsoft Seller Dashboard. Always remember to add licensing checks to the app. For more information, see How to: Submit apps for SharePoint to the Office Store.

Next steps: Build your own app

Show:
© 2015 Microsoft