What is a SharePoint App?

A SharePoint app is a web application that is registered with your SharePoint document management solution environment, granting it a specified set of permissions.
There are two types of SharePoint apps:

SharePoint Hosted
Provider Hosted

Both types of apps can expose functionality in the host web by making client web parts available and by adding custom actions to the ribbon and the context menu of lists and libraries.
For a full breakdown of SharePoint application development, check out this write up on the Office Dev Center.

SharePoint Hosted Apps

SharePoint Hosted apps live in a special site created by SharePoint, called an “app web”. This site is actually in a different domain from the site where the app was added, called the “host web”, for security and performance reasons. Only certain types of software artifacts can live in this site, such as HTML/ASPX, JavaScript, CSS, image files, and XML files that provision various SharePoint content upon app installation, such as lists, libraries, and content types. Any access to SharePoint must happen using the JavaScript Object Model or REST API.

Provider Hosted Apps

Provider Hosted Apps can contain any of the SharePoint components that a SharePoint Hosted App can, as well as any number of remote components. A Provider Hosted App should be used in cases where the app needs to interact with external data sources, an external web application, or when the app needs to execute server-side code. A Provider Hosted App is the weapon of choice when greater access is needed to the host SharePoint tenant, since the app can be given elevated permissions independent of the user interacting with the app. A hybrid app can be built that relies on SharePoint for services such as document management but handles business login in a remote web application.

When to Use SharePoint Apps

To understand which approach to take when developing SharePoint apps, we need to understand the alternatives and what advantaged and disadvantages are involved with each.

SharePoint apps/add-ins were introduced in order to increase the security and stability of the farm on which they were running. As opposed to farm solutions, app code is run as a separate process and on a separate domain from the rest of the farm, meaning poor code cannot lead to the entire environment crashing, and apps cannot make changes to the farm without explicit consent from users that have the rights to make those changes already.

An alternative to farm solutions, introduced in 2010, are Sandboxed Solutions. However, Sandboxed Solutions that contain custom server-side code are deprecated, and will no longer be allowed in SharePoint Online. Simple Sandboxed Solutions that provision SharePoint artifacts, such as lists, libraries, and content types, on the site where they are installed can still be used. Note that, for SharePoint Online, the community is now recommending remote provisioning of these artifacts using the Office 365 APIs.

Despite the advantages that SharePoint Apps bring in terms of security, stability, and upgradeability, they are a relatively heavyweight approach. Integrating an app into its host web is a challenge, especially if responsive design is called for. Therefore, in situations where only one instance of the Sharepoint customization is going to be needed, consider creating the lists, libraries, etc. through SharePoint’s user interface and load JavaScript on the pages where it is needed through a Content Editor Web Part. This approach has traditionally been a “hack”, but has been legitimized by the pending rollout of the SharePoint Framework.

When an app is to be used internally, it’s published in your company’s app catalog. This could be a SharePoint Hosted or a Provider Hosted App, although more configuration is needed for a Provider Hosted App.

There should be guidelines in place concerning internal SharePoint app development, including testing, approval, and deployment to the app catalog, especially once it is in use. The App Framework provides for smooth upgrades if done right, but if not then users will have trouble upgrading and may risk losing production data. As a SharePoint application development company, we can recommend guidelines for you to use with your team, even if you don’t need us to do the development work.

Your App Catalog is the SharePoint site collection where your company’s internally-developed apps are loaded and stored. It is also where app requests are managed and where deployment of apps is controlled.

If you are a SharePoint Online customer, provisioning an app catalog is simple. Simple click on the “Apps” submenu in Central Administration and click on App Catalog to navigate to it. If not already created, it will be. When performing SharePoint Online app development, developers can target dev sites or the app catalog, but once an app is ready to be published, the catalog is used to do so.

If you are an on-premises customer, provisioning an app catalog is much more complex because of the need for a wildcard DNS entry for the app domain. Our team has handled SharePoint installation and provisioning of app catalogs many times, and we would be happy to assist you in getting this done.

Registered developers can publish their SharePoint apps on the SharePoint App Store, accessed by clicking on “Add an App” inside of SharePoint and then choosing to add an app from the SharePoint store. Some apps are free, some have a free trial period, others charge on a per user or per subscription basis.

Before engaging in custom development, especially if the thing you are developing solves a common problem, check out the SharePoint App Store for existing apps that may meet your needs. Even if they are not free, they will most likely be less expensive than building something from scratch. Only after you determine that there are no apps available in the store that will satisfy your needs should you move on to a custom approach.

Governing App Access

When we work with our clients to create a SharePoint Governance Document tailored to fit their needs, we always discuss and decide how access to apps should be governed. Typically, we recommend that Site Owners be allowed to request apps from the app store. One or more people in IT should be responsible for approving or rejecting these requests within a set time period. Additionally, there should be periodic audits of the apps that are installed so that security can be monitored and unused licenses removed.

Get Started with

Lorvenk Technologies

Thank you for your message. It has been sent.
There was an error trying to send your message. Please try again later.

Looking for help? Get in touch with us