In a recent blog post, I walked through setting up a SharePoint 2013 development environment in the cloud. After doing that, the next most logical step was to start building apps. But that meant that I would have to understand what a SharePoint app really was and how it differed from SharePoint 2010 development. I mean sure, I could bang out the typical “Hello World” app, but to do anything meaningful, I needed to dig a little deeper.

Apps vs. Solutions

An app for SharePoint is a stand-alone, self-contained piece of functionality that extends the features and capabilities of a SharePoint site. Apps can bring together the best of both worlds; modern web technologies and all the familiar pieces of SharePoint. On top of that, users can discover and download apps on their own from the public Office Store or from their organization’s private App Catalog. In contrast, a solution is used to customize or enhance SharePoint sites and needs a farm administrator to deploy, manage and remove.

Why Apps?

The first question that I asked myself was why would you use an app? I would assume that the answer to this question might depend on who you polled, but as a developer, I am extremely excited that I can now leverage all of the exciting things that my “non-SharePoint” counterparts have been doing for quite some time. In my opinion, this paradigm shift is a smart move by Microsoft, and will go a long way in attracting more developers to the platform.

App Isolation

Apps are isolated. And by that, I mean that one app cannot talk with another app. By default, apps are deployed to their own web site in an isolated domain, rather than to a farm or sandbox. All processes run in that special domain. The foundation for understanding this new development model is to grasp the concept of how server-side code is handled. This new model says that no server-side code can be deployed to the SharePoint servers. SharePoint handles what it does well: Lists, Libraries, Workflows, Content, etc. But, if you need to extend the OOTB functionality of SharePoint, with custom logic, then all of that code will need to be hosted elsewhere.

Hosting Options for the SharePoint 2013 App Model

• SharePoint Hosted: A SharePoint-hosted app is one that contains no server-side components. Everything that it needs to function, such as lists, libraries, etc., it is able to deploy within the SharePoint environment.
• Provider Hosted: A Provider-hosted app is one that has server-side components. These components are usually contained within an ASP.NET application and you have to provide a separate environment to host them. These server-side pieces can be developed in any technology as long as you can leverage OAuth and make REST calls.
• Auto-Hosted: An Auto-hosted app runs on Office 365 and its SharePoint Online offering. Like a provider-hosted application, an auto-hosted app has server-side components, but when you deploy the app to SharePoint, the service fires up the server-side elements in an Azure layer.

App Scope

An app for SharePoint has an app scope. The two possible app scopes are web scope or tenant scope. The difference is not a property of the app, and you do not decide what the scope of your app is. This depends completely on the administrator who installs the app. When an app is installed in the App Catalog, it is available for installation to all websites in that Tenancy. When we install the app on each Website manually it is web scoped and when it is installed as a batch to all websites specified in a tenancy is a Tenant-scoped app.

Application Lifecycle

As I mentioned earlier, users can add and update apps for SharePoint on their own. As an added bonus, when a developer releases an update to an app, users are notified that an update exists and they can decide if and when to upgrade the app. If a user decides to stop using an app, all they need to do is uninstall it. The instance of the app and all related data is deleted.

Conclusion

Apps are a game-changer in SharePoint. This concept will attract developers to the platform and open up many possibilities. We will be able to use current Web programming skills and common web standards such as HTML, JavaScript and CSS. For me, I will certainly look to write apps over traditional SharePoint solutions. What about you?