App Development

SharePoint 2013 app model for developers

An Overview of SharePoint 2013 App Development Model  May 12, 2017 – 10:36 am
The SharePoint 2013 App Model

SharePoint 2013 is the next iteration of Microsoft’s SharePoint document management and collaboration platform, and you may have heard rumors about the new application development model that Microsoft has included in the release.

As a product architect for GimmalSoft, I had the opportunity to participate in the Office 15 Technology Access Program (TAP) which provided us training and access to the Office 15 platform almost a year ago. I was part of the GimmalSoft team that released an Office 15 application called the Gimmal Drop Zone App for SharePoint 2013 in the Office Store that runs on the new App model.

Needless to say, I’ve learned a lot along the way and I wanted to make sure everyone who is interested in SharePoint 2013 knows what is coming and what it means. In this article, we will discuss the new App development models and I’ll explain how it will affect your SharePoint development endeavors.

Introducing SharePoint Apps

Microsoft is moving to the cloud as quickly as the market will allow, and this means that their architecture is shifting towards a software-as-a-service model. As far as I can tell, the end-goal is to have a model where businesses pay a monthly subscription fee for their users to access a SharePoint instance that is owned and operated by Microsoft. When you think of the infrastructure, support, maintenance, and upgrades that come along with SharePoint then it’s not necessarily a bad proposition for many companies.

One problem with a hosted model, however, is that SharePoint is a lot more useful when it can be completely customized around the particular needs of a business. Out of the box, SharePoint’s functionality is certainly useful, but most organizations rely on custom SharePoint applications to realize the full potential of the platform. In a hosted environment, this is problematic because custom code runs in a shared environment; not all custom code is good code, and bad code can quickly bring a server to its knees and upset a number of different customers using that server.

With this in mind, Microsoft set out to create an extensibility point in SharePoint 2013 that would allow customers to build their own solutions for SharePoint without hurting the hosted model whenever a customer’s code was found to be ‘executionally challenged’. They came up with a model called a SharePoint App, which is simply a solution with no SharePoint server side code.

What Do You Mean No SharePoint Server Side Code? Seriously, I mean there is no server-side code that is executed by the SharePoint server. A SharePoint App is essentially a solution that can only include HTML, CSS, JavaScript, Silverlight XAP files, images, and any other static files. However, you can’t include an assembly with custom code because that would need to be executed on the server. Of course, this leads to the question ‘how do you build something useful without server side code in SharePoint?’

What are the Three SharePoint 2013 App Deployment Models?

Before we get into the details of how it’s possible to build useful apps without SharePoint server side code, we need to go over the three deployment models for SharePoint 2013 Apps:

  • SharePoint-hosted
  • Self-Hosted
  • Automatically Provisioned Azure Web Application

SharePoint-Hosted App

A SharePoint-Hosted App is an application made entirely of static files that reside directly in your instance of SharePoint. When you add an application to one of your sites, SharePoint deploys the files in your App to a special App domain where your App lives. When a user accesses your App, they are redirected to a page that lives in the App domain and from which, presumably, they can use your App. There is absolutely no server-side code allowed in this model.

Self-Hosted App

A Self-Hosted App is an application where the files for the application exist on an external server (e.g. you are hosting those files yourself somewhere outside of SharePoint). When a user accesses your application, they are redirected to a page on this external server where the application resides. In this model, you can run server-side code, but it has to be run on the external server. There is still no way to run custom code on the SharePoint server. One of the benefits of this model is that the external server does not need to be a Windows server: SharePoint is really just redirecting users to a web page, so you can use any operating system and application server you want as long as it can fulfill web requests. You could be a PHP developer with a Linux machine and still make SharePoint apps.

Another interesting reason to use this model is that it puts you in complete control of upgrades. Since you own the server, you can deploy updates and have them applied immediately for all of your clients. In the other models, the user has to take some action to upgrade because you do not have access to the server on which the App is hosted.

Automatically Provisioned Azure App

An Automatically-Provisioned Azure App is an interesting concept that requires a bit of a back story to describe. First, I believe this type of App is designed to be run only from Microsoft’s hosted SharePoint environment, so its primary audience is really software vendors looking to sell to SharePoint online customers. The other two App model options are available in the hosted SharePoint environment as well as on a SharePoint 2013 corporate install.

Now, if you are a software vendor creating an App for SharePoint you have a choice to make that will affect your budget. If you make a SharePoint-Hosted App, then you cannot run server side code, but you also do not have to pay for a server on which to host your app. If you opt for a Self-Hosted App, then you can run server side code but you are responsible for paying for that server to host your app.


Related posts:

  1. How to get your app idea developed?
  2. Best Mac os x apps for developers
  3. SharePoint online app development