SharePoint 2013 introduces this new development opportunity called the SharePoint App Model. My goal in this post is to give you a crash course on what they are and when they make sense. Before I go too far, let me state a few things:
- Solution Packages (farm & sandbox) are not deprecated or going away. These two options that we’ve had starting with SharePoint 2007 (in farm solutions) and extended in SharePoint 2010 (in sandbox solutions) are still present and viable. There is nothing new with either of them… everything you know is still true.
- SharePoint Server-Side Code in Apps is not allowed. Unlike the sandbox, you don’t even have access to a limited subset of the SharePoint server-side API. All code must run in the client (JavaScript) or outside of SharePoint (Azure or other hosting platforms) and connect back to SharePoint using client APIs.
- There are two types of development/extensibility options in SharePoint: Solution Packages & Apps. Each of these two options has sub-options. Solution Packages exist either as farm or sandbox solutions. Apps can be SharePoint-Hosted, Self-Hosted or Azure Auto-Hosted.
- Only SharePoint 2013 support the SharePoint App Model. You can’t build and host apps in prior versions of SharePoint.
Why Yet Another Development Option?
Looking back at SharePoint 2010, the common development approaches had a few challenges associated with them.
With Farm Solutions, AKA Fully Trusted Solutions, custom code was deployed to the server. These types of solutions generally meant there were a lot of things to deploy to the server, even if they were all deployed in a SharePoint solution package. This also meant that most deployments required a server touch as an IT Pro with console access would need to upload the solution to the server’s solution store for deployment. In addition server outages and most SharePoint errors could usually be traced to custom code deployed to the server. These types of solutions are only available with on-prem deployments and not with hosted deployments that only allow sandbox solutions.
Sandbox solutions have their own challenges in that they are limited in the number of things you can do. Developers can work within a subset of the full server-side API and are blocked from making external database or web service calls.
Both of these options, farm & sandbox solutions, require the developer to have a solid understanding and be familiar with the SharePoint server-side API.
From my perspective, there’s another reason for this new model: Microsoft wants us to get our code out of SharePoint. Why? Think about the SharePoint deployments you’ve upgraded form previous versions to SharePoint 2010. What were the ones that went the fastest and those that took the most time? Those that took longest likely had a lot of custom code that had to be tested, right?
App Characteristics
Before looking at the different types of apps, let me talk about a few characteristics of apps. Each of these is true across all types of apps you can build.
Apps are Completely Isolated. One app can’t talk to another app. This is implemented using special SharePoint sites (SPWeb’s) we call an AppWeb. When you install an app, SharePoint creates a special subsite in the existing site where the app is installed (the AppWeb). This site gets a special URL that looks something like this: http://app-bf473b5225nn0f.apps.contoso.com/SomeAppName . We could rewrite that like this: http://tenant-APPID1.domain.com/APPID2 . APPID1 is a unique string generated by SharePoint for this app that was installed in the current site. APPID2 is the ID of the app that is specified by the developer when they built the app (you’ll find it in the AppManifest.xml file).
There is no other way to get to the app except through this URL. If you tried to get to it using a relative reference from your HostWeb (the SharePoint site where the app was created from, or what you’d think of AppWeb’s parent. The primary reason for this is isolation… if the AppWeb were in the same domain the app could naturally using JavaScript to call services and access data within the site collection it resides in. That could be a sizeable security hole so Microsoft elected to stick it in a separate domain, unique to the app, so the app developer couldn’t engage in some cross site scripting attack.
App experiences - three different options on how your app is presented to consumers. There are three options, one exists for all apps and your app may use one or all three of them. Every app has what is called an (1) Immersive App Experience. This is when the app takes over the entire page similar to how the Office Web Apps work. Every app has this experience because every app has a start page. This may be as simple as a “About This App” or a help page. The other type is a (2) Part App. This is when the app is surfaced on part of a page, similar to how a Web Part works. Think about a weather app… it just provides a widget to show the weather from some location on a page. The last type is an (3) Custom Action App. In this scenario your app may just expose itself as a Ribbon control or menu item. A good example of this would be to submit a document to a printing service. The printing service may have an app in the Marketplace and when it is installed in a site, you get a new option on Word or PDF documents to submit to the printing company.
Scoping apps - two choices for how your apps are scoped. When building a new app you have to decide what the scope of the app will be. Will it be (1) Web Scoped in that your app’s resources will live only within the AppWeb or will it be (2) Tenant Scoped in that the app will connect to a bigger service that is architected in a multi-tenant way. Don’t go looking for some checkbox in Visual Studio 2012, this is more of a “how did you build it” type thing.
Obtain apps through the Public or Corporate Marketplace. Just like the phone, apps are published to the Marketplace where people can acquire them or even buy them. There is a Public Marketplace for Office 365… this works a lot like the phone Marketplace. The Corporate Marketplace is where a tenant [company] can have their own private Marketplace for their employees. Each Web App can get it’s own Corporate Marketplace.
Three Different Types of Apps Developers can Build
This new development model actually has three different types of implementations. Kind of like how you can build an app for the Windows Phone, but it can be either a Silverlight or XNA app. Each has their place…
- SharePoint-Hosted App: In this scenario everything stays “with SharePoint.” What I mean is that your app gets it’s own isolated AppWeb when installed and can create & leverage things in SharePoint like site columns, content types, lists, libraries and pages. Any business logic must run in the context of the client (browser) so we’re talking JavaScript.
- Self-Hosted / Developer-Hosted App: It will be curious to see what Microsoft tries to call this as it went by both names for a while in the betas. Basically in this scenario the bulk of the app, or the business logic, resized external to SharePoint. This could be using any technology (.NET Framework, Java, PHP, LAMP, etc) on any infrastructure (IIS, Apache, Windows Azure, Google Compete, Amazon EC2, etc). There is a SharePoint-hosted app that might not do anything but just be a launching pad to the external app, or it might have a good mix of both. The “self” or “developer” part of the name comes from the fact that the developer (or customer) is responsible for standing up the external piece & wiring the app & external piece together.
- Azure Auto-Hosted App: This one is quite interesting but is only available in the cloud (Office 365) at the time of RTM. Basically if your app needs to have an external component, you can build this type of app and deploy it to the Marketplace. When a user purchases/acquires your app and installs it, SharePoint not only creates the AppWeb to host the SharePoint piece of the app, but it automatically provisions a new Azure Web Site & optional SQL Azure database and automatically wires the SharePoint & Azure components together. The app would be installed in a special Azure subscription tied to your Office 365 account. Because these types of apps run in Azure, you’re only limitation are the different offerings Azure provides for platforms. These include .NET Framework, Java, PHP & Node.js.
When to Choose Solution Packages over Apps?
Now that you have a general idea about what an app is and the different characteristics as well as options in building them, you are probably asking the next question: when should I use an app, farm solution package or sandbox solution package? Like everything in SharePoint, we get lots of options to do the same thing and never do we have the best option but there can be a few bad options. In my mind you need to keep in mind some characteristics for each development option:
- Farm Solutions: these are the lowest level of extensions we can build & have full access to the full SharePoint server-side object model. However they can only be used in on-prem deployments. They can be scoped to an entire farm or down to just a specific site depending on what they do.
- Sandbox Solutions: these have access to a subset of the SharePoint server-side object model and are scoped at a site collection. They can be used in the cloud, but they can’t be sold through the marketplace.
- Apps: These can be sold through the marketplace and should be seen as an end-user construct. Everything in an app should be isolated in the sense that apps can’t depend or interact with other apps directly.
That’s it… the SharePoint App Model from a pretty high level. No pretty pictures… just everything explained.