Apps for SharePoint overview
Published: July 16, 2012
Learn what apps for SharePoint are, why you should build them, and the concepts that are fundamental to building them in SharePoint 2013.
Applies to: apps for SharePoint | Office 365 | SharePoint Foundation 2013 | SharePoint Server 2013
SharePoint 2013 introduces a Cloud App Model that enables you to create apps. Apps for SharePoint are self-contained pieces of functionality that extend the capabilities of a SharePoint website. Apps integrate the best of the web and SharePoint; they are targeted, lightweight, and easy-to-use, and do a great job at solving a user need. Users discover and download apps from the Office Store or from their organization's private App Catalog and install them on their SharePoint sites.
For example, let’s say you have a SharePoint site to collaborate with a team, and you want to create a survey to gather more data. In SharePoint 2013, you get a “survey app” from the Office Store or from the App Catalog and install it on your site. Another example would be a mortgage broker who sets up a website with apps from the Office Store. These apps might include a “bank rates app” that helps find the best mortgage rates, a “mortgage calculator app” that helps calculate mortgage payments, and a “property value estimator app” that provides an approximate value of a property. The website might also include apps from the mortgage company’s App Catalog that help the mortgage broker view and update client details and initiate a mortgage loan for a client.
The Cloud App Model in SharePoint 2013 enables you to build apps for SharePoint by using familiar tools and a rich set of features. Let's look at the key pieces of the Cloud App Model and briefly examine why you should create apps for SharePoint.
Familiar programming model and access to SharePoint data and services
Apps are essentially web applications. If you know how to build a web application, then you know how to build an app for SharePoint. You can use any language, such as HTML, JavaScript, PHP, or .NET, and you can use your favorite web development tools, including Microsoft Visual Studio 2012, and a new web-based tool, "Napa" Office 365 Development Tools, to build app for SharePoint. The Cloud App Model supports a tiered architecture in which the app's business logic, data, and user interface (UI) can be distributed into separate components. You can take advantage of the development tools that are designed specifically for the development of that tier instead of using general purpose tools. For example, you can have an app whose presentation logic is in HTML and JavaScript and runs on the client, whose business logic is in Microsoft .NET and runs in Windows Azure, and whose data is stored in SQL Azure. Or you can have an app that is written in PHP and has its data stored in MySQL.
You can connect your app with just about any internal or public web services, take advantage of the new OAuth 2.0 support in SharePoint, and use the Representational State Transfer (REST) and client APIs (JavaScript and .NET) to integrate and connect your app with SharePoint. SharePoint 2013 provides a wide variety of features—such as Search, workflow, social networking, taxonomy, user profiles, and Business Connectivity Services (BCS)—that your apps can take advantage of.
Figure 1 shows the programming model for building apps for SharePoint.
Multiple options for hosting
The Cloud App Model offers multiple hosting options for your app. You can choose your own web stack, have Microsoft provision Windows Azure and SQL Azure, or have it hosted on SharePoint, as shown in Figure 2. For more information about the various types of apps and hosting options, see Hosting options for apps for SharePoint.
Important
|
|---|
|
You can also mix and match and host some components in SharePoint and some others in the “cloud.” |
Familiar user experience for end users
Apps for SharePoint fit seamlessly into the SharePoint website where they are installed and therefore bring data and functionality to the users’ familiar work environment and provide them with a familiar user experience. An app for SharePoint provides a fully immersive experience and optionally can extend some of the existing UI, such as in menus, or by providing embeddable parts for other pages. App parts surface an iframe element that contains content from your app. Ribbon or context menu extensions make your app available on list items, documents, or anywhere else a ribbon is shown. Figure 3 illustrates three types of user experiences available in apps for SharePoint.
For more information about the UI for apps for SharePoint, see Accessing the app from the UI.
Integration with apps for Office
Apps for Office, which are based on the new web-based extensibility model in Office 2013, can integrate with apps for SharePoint. You can also use apps for SharePoint as a part of an Office 2013 document template. For more information about apps for Office, see Overview of apps for Office.
Office Store and App Catalog
Microsoft will host and regulate a Office Store, where developers around the world will be able to publish and sell their custom apps for SharePoint. End users and IT professionals will be able to acquire these apps for personal or corporate use. The Office Store will handle the end-to-end acquisition experience from discovery to purchase, and updates.
Company-developed and IT-acquired apps can also be deployed to an organization's internal App Catalog hosted on SharePoint (which can be either on-premises or in SharePoint Online. For more information about the Office Store and the App Catalog, see Tenancies and deployment scopes for apps for SharePoint.
In its most basic form, an app for SharePoint is a web application that is registered with SharePoint using an app manifest. An app manifest is an XML file that declares the basic properties of the app along with where the app will run and what to do when the app is started. The following code is a very simple app manifest that basically 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://localhost:44303/Default.aspx/?{StandardTokens}</StartPage>
</Properties>
<AppPrincipal>
<RemoteWebApplication ClientId="ca81d876-8525-44a8-8a60-e02ee79a4a6e" />
</AppPrincipal>
</App>
You can do a lot more with the app manifest, such as use different authentication schemes (also known as app principals, declare what permissions the app needs to run, and other tasks. Also, do you notice strings like “{StandardTokens}” in the app manifest shown above? These are tokens that are replaced at build/run time. These tokens allow you to reference your app and also pass context (for example, the SharePoint language, where the app is installed, and so on). To learn more about what you can do with the app manifest and tokens, see App for SharePoint manifest file.
The code for an app runs in different places, depending on where your app is hosted.
-
SharePoint-hosted apps: When the app is hosted in SharePoint itself, the code is HTML and JavaScript and is hosted by SharePoint.
Note
When you deploy a SharePoint-hosted app, SharePoint creates a new website called the app web. You can think of it as a dynamically created safe space for your app. Besides allowing you to store pages, lists, and libraries, the app web is also an isolated endpoint that your app can securely call client side by using JavaScript.
-
Provider-hosted and autohosted apps - In the cloud: For autohosted apps, SharePoint automatically deploys your app into Windows Azure Web Sites and SQL Azure, and these apps run in the cloud. For provider-hosted apps, you or your IT department hosts the app on a dedicated server or third-party hosting service. These apps run on your server or in the cloud, depending on how you choose to host your app.
-
Apps that have a mix of components in SharePoint and in the cloud: SharePoint components run in SharePoint, and components hosted in the cloud run in the cloud.
|
Important
|
|---|
|
Within apps, SharePoint 2013 decouples server-side code from the server, enabling you to run server-side code from outside SharePoint, in the cloud. You can host server-side code in autohosted and provider-hosted apps. |
The real power of apps is in using SharePoint to do interesting things, such as reading documents, adding posts, doing searches, connecting people, and so on. SharePoint 2013 provides a wide variety of features, including Search, workflow, social networking, taxonomy, user profiles, BCS, and more. You can connect to and integrate with these features from within an app using SharePoint APIs.
SharePoint APIs for integrating with SharePoint features in an app include the following:
To get started using SharePoint APIs, take a look at the following:
-
How to: Complete basic operations using SharePoint 2013 REST endpoints
-
How to: Complete basic operations using JavaScript library code in SharePoint 2013
-
Basic operations with the SharePoint .NET client object model
Authentication options in apps for SharePoint
Before you can call SharePoint APIs from your app, you need to authenticate to SharePoint. Which authentication mechanism you use is tightly coupled with where the code of your app is running.
-
Inside SharePoint: If the code of your app runs on SharePoint-hosted pages, the decision is easy: you have to use HTML and JavaScript, and authentication is already taken care for you.
Note
Remember that no server-side code can be hosted on SharePoint.
-
In the cloud: If the code is running outside of SharePoint, you have two choices:
-
Use client-side code along with the cross-domain library.
-
User server-side code along with OAuth.
-
-
REST APIs
For more information about data access for apps in SharePoint 2013, see Data access options for apps in SharePoint 2013.
Authorization and user consent to actions
Regardless of how you authenticate your app with SharePoint, you need to have user consent to perform actions. You declare the required permissions in the app manifest, and the user is asked to grant or deny those permissions to the app during installation. For more information, see App permissions in SharePoint 2013.
Apps for SharePoint are distributed as an app package. Depending on where the app is hosted, the package may contain different components. For provider-hosted apps, where you or your IT department hosts the app on a dedicated server or third-party hosting service, the package might just contain the app manifest. Autohosted app packages may include items to be deployed on the Windows Azure cloud. SharePoint-hosted apps might contain some SharePoint-related components, in addition to the app manifest. App packages can include additional components, such as apps for Office. For more information about app packages, see How to: Package apps for SharePoint for publishing 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 seller hub. Always remember to add licensing checks to the app.
Now that you have a general understanding of what apps are, as next steps, you can learn more about building apps for SharePoint and build a simple app of your own.
Read the following articles:
-
How to: Set up an on-premises development environment for apps for SharePoint
-
How to: Create and customize an app with Access 2013 Preview
Try some code samples:
