In this post I am not going to go in detail of any App Model pros, there is plenty of bias content from Microsoft on the web. It is not secret they are almost forcing people into the cloud regardless of your business need so I cannot deny this is where the platform is going. As a SP developer you should learn how to build and deploy apps. However, I will clarify on a few points usually made as why the app model is considered more maintainable, secure, and stable than Farm, full trust solutions. It all boils down to bad code. The App Model is an attempt to ensure your bad code stays your problem and all other arguments are just noise and marketing fluff.
When should you use a SharePoint App?
Let’s start by stating the obvious, if you are on Office 365, Apps are your only option. Well, you could use Sandbox solutions
but they are deprecated by Microsoft so it is a dying technology. EDIT: Only Sandbox solutions that deploy code to the server are deprecated. (More info here) Another valid reason to use apps is when you want to sell and reuse the exact same feature. If you have an on-premise SP installation, you have options. There are three main things to consider but as a general rule regardless of your choice, move to front-end development when possible (CSOM, REST, HTML5)
First, think about your requirements. Can you accomplish everything you need by using the app model? To help you decide, I compiled the below list:
- The obvious, you cannot use any server side code. No big deal you say? Well, it is. The app model only exposes a very limited subset of the Server Side Object Model. There is a big list of technical things you cannot do but some of the more relevant for business are the limitations on custom branding & UX design. The inability to create custom administration tools or offline process (e.g. timer jobs), and the lack of support of top level site templates (onet.xml) files.
apps do not work with FBA or any kind of SAML authentication (ADFS for example). Also, no custom claims. Sure you can argue that you could accomplish this using Provider-hosted apps. However, this approach will force you to have a separate farm/server where you deploy your app’s code. I thought you didn’t want to manage a server.
- The upgrade process of SharePoint hosted apps is awful. The AppWeb, the separate web site that hosts your app, gets re-provisioned every time you reinstall/upgrade the App. All data lost. Also, When you delete an app which has been installed on the site – your app site gets deleted too. Again, all data lost. Have backups handy at all times.
- Although the SharePoint’s client API (CSOM, REST) is powerful, it more often than not, overcomplicates things. Expect a 2.5x to 4x of development time to build an app vs .wsp solution on bigger projects. BJØRN FURUKNAP, a well-recognized SharePoint developer wrote a spot on analogy:
- Also important and lot of times overlooked, getting the App model up and running on-premises isn’t a trivial thing, which again adds added complexity and cost to any project.
- Does your client have any desire to ever move to the cloud? If you’re on-premises and you have no short-to-medium aspirations to head to the cloud, then there is no justification for the steep learning curve, increased complexity and increased cost of building Apps. If there is a cloud Roadmap, take a look at the workflow below. I borrowed it from someone on the internet. I will give him/her credit as soon as I can track down the .ppt where I got it from.