What you can do in an app for SharePoint
Published: July 16, 2012
Learn about the wide variety of functionality that you can make available to your customers in apps for SharePoint.
Applies to: apps for SharePoint | Office 365 | SharePoint Foundation 2013 | SharePoint Server 2013
The following sections describe some of the major kinds of functionality that can be part of an app for SharePoint. You can include almost any end-user focused (as distinct from administrator-focused) SharePoint component in an app for SharePoint, and you can seamlessly add external components into the SharePoint experience of the user. (For more information about the difference between end-user and administrator functionality, see Apps for SharePoint compared with SharePoint solutions.)
Almost every major type of SharePoint component can be part of an app for SharePoint, including custom content types, list templates, list instances, pages, workflows, event handlers, and many more. You can also have built-in Web Parts, including a Silverlight Web Part that hosts a Silverlight application and an app part that wraps an IFrame. For a complete discussion of the SharePoint components that can and cannot be in an app for SharePoint, see Host webs, app webs, and SharePoint components in SharePoint 2013.
An app for SharePoint is a great way to surface a remote web application in SharePoint—and the remote web application can be on any platform. It can be an ASP.NET application or a web application built on a non-Microsoft platform stack, such as the LAMP (Linux, Apache, MySQL, PHP) stack. Any web application that the host supports can be surfaced in an app for SharePoint.
You can also include remote storage and remote databases. The storage can be blobs, caches, message queues, and content delivery networks (CDN), among others. The databases can relational and nonrelational, and you can use a non-Microsoft database as well as SQL Server. 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. The remote web applications and databases can be located and managed in your own servers or they can be located in Windows Azure, SQL Azure, or a non-Microsoft cloud account.
Note also that the model for apps for SharePoint supports external event handlers.
Your business-logic code can run on remote servers and on client machines. In fact, the only place it cannot run is on the SharePoint servers themselves, and you do not really need it to run there. Moreover, keeping custom code off SharePoint servers provides reassurance to SharePoint administrators that the app cannot harm their servers, which makes your app for SharePoint easier to sell.
Business logic in an app for SharePoint can access SharePoint data through one of the several client APIs included in SharePoint 2013 and shown in the following list. (For more information about these APIs, see Choose the right API set in SharePoint 2013.)
A remote web server is a client relative to the SharePoint data, so code on the server uses one of these client APIs.
.NET Framework client object model. This is available in a redistributable package from SharePoint Client Components. If you prefer LINQ syntax, you can use it with this library.
Silverlight client object model. This is also available in the same redistributable package and you can also use LINQ syntax with it.
REST endpoints. SharePoint 2013 provides REST/OData endpoints that can be accessed from any web client, including non-Microsoft clients and servers. If you prefer to use LINQ syntax, you can do so with this same web service from any .NET Framework platform.
Mobile client object model. This is available for use on Windows Phone. devices. The assemblies are available in %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\15\TEMPLATE\LAYOUTS\ClientBin and must be included in the .xap file of the mobile app. These mobile apps can take advantage of the support in SharePoint 2013 for the Microsoft Push Notification service and a new geolocation field type.
For many information workers, SharePoint has become the digital headquarters of their work life, and they like to use it as a portal to their applications when possible. And if the application shares a compatible appearance with SharePoint, so much the better! The model for apps for SharePoint provides easy methods for surfacing applications in SharePoint, including applications that do not use SharePoint list data or have any other intrinsic connection to SharePoint. You can surface the application in three ways:
All apps for SharePoint can be started in a full-page experience from a link on the Site Contents page.
Optionally, an app can include one or more app parts which are Web Parts that users can add to SharePoint pages. This makes it possible to expose the app as a kind of widget on multiple pages.
Optionally, an app can add an item on the SharePoint ribbon or context menu that can be used to interact with a list item or document directly.
The model also provides ways for you to make the appearance and behavior of the application consistent with SharePoint. For more information, see Accessing the app from the UI and How to: Use the client chrome control in apps for SharePoint.
Apps for Office integrate web services and remote data directly into Office desktop clients and Office Web Apps. You can also integrate SharePoint data into Office with an app for Office. Moreover, the app for Office package can be included in the package of an app for SharePoint. When the app for SharePoint is installed, the app for Office is added to a corporate apps for Office catalog in SharePoint. This enables you to develop an app for SharePoint and an app for Office that are highly complementary in their functionality and user experience. You want your complementary app for Office to be available for download on all SharePoint websites where the app for SharePoint is installed. Adding the app for Office to the app for SharePoint package ensures that it is.
With previous versions of SharePoint, farm administrators sometimes refused to install any custom SharePoint extensions because of the danger of errant code. In SharePoint 2013, that problem is essentially eliminated because the client object models have been greatly expanded. This means that you as a developer do not have to use the server object model anymore. All your custom business logic moves "up" to the cloud or "down" to a client machine, and it uses one of the client APIs discussed in an earlier section. Because the app does not (actually cannot) contain custom code that executes on the SharePoint servers, administrators are assured of its safety.
Some APIs in the SharePoint server object model are not 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 extension or classic SharePoint farm solution. For more information about choosing among apps for SharePoint, classic SharePoint farm solutions, and sandboxed solutions, see Apps for SharePoint compared with SharePoint solutions.