Why wouldn’t you use the App model for On-Premises SharePoint solutions?

It’s been a while since my last post, and due to a mini-hiatus I decided to take over the Christmas/New Years period in relation to certification studying, I figured it was time for a little something different on this blog. Truth be known, this is a conversation I’ve had with a number of pro-App model colleagues as far back as October last year. I tend not to be able to help myself when it comes to playing the devil’s advocate role (in fact I’ve been given the ‘black hat‘ on too many occasions to think it a coincidence) so this position did come perhaps a little too naturally for me, even with my bias towards heavily branded public facing solutions.

I was actually inspired to write about this from a recent #CollabTalk thread via a question posed by Christian Buckley (@buckleyplanet)


My favourite responses came from a cloud-focused Microsoft employee on the SharePoint team, Mark Kashman (@mkashman)


And a SharePoint Certified Master, Chris Beckett (@teknirvana)


I found the honesty of the responses refreshing.

It’s no secret Microsoft’s position on this one. You only have to read the official documentation on MSDN such as Deciding between apps for SharePoint and SharePoint solutions or Apps for SharePoint compared with SharePoint solutions to realise they’re pushing the App model in a big way. A couple of ‘tell us what you really think’ quotes that spring to mind from the aforementioned articles include ‘With these considerations in mind, apps should be looked at as the primary choice, and full-trust solutions should be looked at when the capability of the app model does not meet the business requirement.’ and ‘The most important guidance we can give you is to develop an app for SharePoint instead of a farm solution or NCSS whenever you can’.

The cynic in me however still believes there may be an ulterior motive to this position. Microsoft has been ‘all-in‘ for the cloud for a long time and there are a number of very good reasons why they would prefer clients be on Office 365 rather than managing their own on-premises farms. It therefore makes sense that they would want to remove as many barriers to entry to that transition as possible, full trust solutions being a significant one.

So as I always do, I set out to read as many decent articles as I could on the topic. I had remembered some time ago reading the SP-king-of-controversy, Bjørn Furuknap’s SharePoint 2013 App Model Solves Non-Problems Only? article and even though it was one of the only ones that would potentially back up my argument, it seemed to be arguing against the necessity of the App model rather than why it perhaps shouldn’t be used. That article introduced me to Doug Ware’s posts SharePoint 2013 Preview – Apps or Crapps?The SharePoint 2013 App Model is better than Farm Solutions and An Architecture for Provider SharePoint 2013 Hosted Apps on Azure which definitely argue the counter-point well.

Alaa Mostafa’s SharePoint 2013 Development (Apps versus Solutions) was a decent read which pushed the App model as was Jeremy Thake’s SharePoint Apps Playbook Series: Part 1 – SharePoint Apps vs SharePoint Solutions (was looking forward to the series, lets hope for more!). There was also a logged discussion SPChat transcript: App Model vs Solution Model with Jeremy Thake which helped frame my thoughts.

So what are those thoughts? Well, in a perfect world it’s clear that Apps would be the way to go. There are a number of things that concern me though looking from a wider consultancy view rather than just my own (where did I put that ‘these thoughts are my own’ disclaimer..):

  • The learning curve of developing with the App model against sticking to what most already know. The MSDN article I referenced before actually counters this point, arguing that it is not the only factor to consider and that it may be outweighed by the extensive lifecycle management process required for full-trust solutions. Not everyone is a senior consultant capable of making this transition on a client site however.
  • The ‘new’ nature of the beast. Anyone who has been around SharePoint long enough (and this has been particularly relevant with SP2013) would know that things rarely ‘just work’ in the first iteration. I can definitely see this causing a lot of unnecessary headaches on projects.
  • The added development time the above points could lead to. Increased complexity + less familiarity is sure to equal more $$. When you’re competing for work it’s not always best to ‘theoretically’ offer the best-MS-approved solution if you don’t get to implement it for being cost noncompetitive. It also wouldn’t paint the most rosy of pictures of any existing consultant banging their heads against the wall for a seemingly easy requirement.
  • Getting the App model up and running on-premises isn’t a trivial thing, which again adds added complexity and cost to any project which hasn’t already set up their environment for it.

I also wonder if its just me that thinks that this shouldn’t be a purely technical decision and should be one that involves the business. I believe that as consultants we should advise the client on the best way forward by giving them all the facts (and perhaps even some opinions) but allowing them to make a business decision with that information in front of them. Why should we push the App model if the client has no desire to ever move to the cloud? My argument is if you’re on-premises and you have no short-to-medium aspirations to head to the cloud, then where’s the justification for the steep learning curve, increased complexity and increased cost of building Apps.

Now that I feel I’ve made my point, i’m going to do a complete 180. The App model in my opinion should be on any consultant-worth-their-salt’s priority learning list. The direction is clear, and it will become THE way to develop for SharePoint sometime in the future. I’ve put my money where my mouth is in this case, registering for SPC14 with the aim to attend a number of cloud and App related sessions as well as Sonya Koptyev, Kirk Evans, and Richard diZerega‘s pre-conference sessions on Migrating Traditional SharePoint Solutions to the App Model and Refactoring Business Solutions into Apps for Office. One more excellent blog that should also be on the must-read list I feel I need to point out is Vesa Juvonen‘s – definitely worth following for those wanting to transition to the App model.

I’m curious to see if my view changes over time, particularly after SPC14 and hopefully after a number of healthy debates in regards to whether the App model should be chosen over full-trust solutions for on-premises SharePoint installations. If you care to add to the debate i’d be more than happy to hear from you through any medium you wish – i’m definitely prepared to be convinced either way.

25 Responses to Why wouldn’t you use the App model for On-Premises SharePoint solutions?

  1. Matt,

    My point with my original article (on apps solving non-problems only) is that there doesn’t seem any point in using apps. It is a completely arbitrary solution where nobody has said what the problem is.

    Let me ask this instead: You can now start writing code using one hand at a time only. Why would you do that? Because that’s much better.

    Any rational mind would put up some question after a statement like that.

    Why would I want to do this? What does ‘much better’ mean and for whom? Why do I need to write with severe limitations when I can be much more efficient and write exactly the same code without those limitations?

    The same questions should be asked on the app model as well. Why would I want to do this? Why is apps ‘much better’ and for whom? But most importantly, Why do I need to write with severe limitations when I can be much more efficient and write exactly the same code without those limitations?

    To answer your question here, though: You shouldn’t write apps because it is just an arbitrary limitation that will cost you money and give you nothing in return.

    Just like writing with one hand only would.


    • Matt says:

      I tend to agree to an extent – I think there may be a point for Microsoft to push the model because it enforces those coding practices. It was a little clearer when the prevailing thought was that sandboxed solutions were deprecated – the App model was the way forward for the cloud. The clarifications since tend to add credence to what you’re saying, a lot of the client-side coding could be done using SS rather than the App model. My main argument here however is purely on-premises, and I too don’t see the cost-benefit if there’s not one eye looking towards the cloud.

      As a consultant/developer though, I see the value in at least learning the App model. You never know what’s around the corner, and the messaging could again change without warning. The smart money would be on Apps closing the gap and becoming less of a limitation over time and at some point will be largely accepted as the way to develop for SharePoint. I wouldn’t want to be behind the curve too much if/when that happens.

      Thanks for the reply

      • The main reason for not going down every conceivable path is that doing so makes you a worse developer. You don’t get good at doing a vast array of different things, you get good by doing a few things extensively and for long periods of time. Michael Phelps didn’t become the number one swimmer by practicing a lot of different sports. Magnus Carlsen didn’t become world champion in chess by practicing javelin.

        Sure, clients wants someone who says they have experience in everything; it’s a lot cheaper to hire one person than ten people. That only makes clients ignorant, though; rather than getting good developers in one area, they get mediocrity across the board.

    • You don’t write apps because they are easier to write, but because they are easier to operate, easier to scale and – equally important – easier to get rid of if need be, in the cloud and on premises. Think about all the mess custom full trust solutions create in a farm, downtimes they cause when updating them, the mess they leave behind when the retract breaks in half. What about upgrading a SharePoint farm loaded with a metric crapload of custom solutions, web parts, timer jobs, site definitions…? What about poorly written solutions that bring down the entire w3wp.exe with them because of an uncaught exception or simply eat all the RAM because of memory leaks? Ever spoke to an administrator that has to maintain wsp solutions that only several users need but that cause 90% of problems in his farm? Solutions from different vendors overwriting each other’s web.config changes, common GAC dlls, javascript files…? Discovering that your farm in in an unsupported state because of some silly solution an anonimous consultant deployed several years ago that accesses the content db or uses reflection over SharePoint API to achieve things? The list goes on and on.

      So it’s absolutely not true that apps don’t solve any problems. They actually solve many of them, but it is also true that they do create a few new ones along the way, at least for now. Yes, the app model is currently at 1.0 (0.9 would probably be more accurate), some (major) things are still missing and it is definitely not a full replacement for the farm solutions – yet. But this is all short-term, give it 2-3 years until the next major release to mature and soon you will be writing only apps, whether you like it or not. This discussion is similar to the one we had 13 years ago when switching from VB6 to .NET – many VB6 community veterans of that time were cursing .NET because it didn’t have some random API that they had in VB6 and were saying that .NET doesn’t solve any problems because they could do all of that in VB6. 13 years later, we all know what happened to VB6 and to those who failed to grasp the change.

      • Matt says:

        All very good points Robert and I agree with you re this being the future moving forward. I’d counter argue that a lot of what you mention can be avoided by a good architect/developer/consultant, however we all know that’s a bit idealistic and in the real world the best of the best can’t work on everything out there. Thanks for the reply.

      • No, Robert. You seem to completely miss the entire point of SharePoint. You don’t write apps because they are easier to operate, scales better, or because the can be removed by clicking your heels together.

        You write solution because you want to solve a business problem and make or save money.

        The fact that you’re comparing a crappy developer’s spewing of gall isn’t helping you make your point. If you compare rotten apples to fresh durian, of course the durian will win.

        So no, you don’t have any points to make beyond “I’m right because I say I am!” which isn’t convincing anyone.


    • Matt says:

      Thanks Chris – I have read this article, I should have included you in the post to be honest, one of your tweets also got me excited and lead to me writing this article (however the 140 characters lead me to believe you it would be more of a FTC v CAM debate) – “Don’t use the #sharepoint App Model if you don’t have too”. Big fan of your work, looking forward to your SPC14 sessions!

  2. Hi Matt,

    While I agree on the Cloud story and Microsoft pushing hard to get rid ASAP of on-premises systems, I still don’t understand a few of your arguments (that I already discussed with Bjorn on his blog before):

    – Learning Curve : what learning curve? The App Model relies on either pure client-side applications involving mainly JavaScript for SharePoint-Hosted Apps. It means that many non SharePoint developers can get up & running very quickly…With the rise of mobile apps, JavaScript has become one of the most used languages. They just need to learn the SharePoint REST/JSOM APIs. For Provider-Hosted Apps, it’s even easier since they can choose the technology they want to write their app…So, I really don’t get this point

    – Something else that’s not taken into account in your remarks : only from a deployment perspective, the App Model is very promising. I’ve been working for the past 8 years with farms solutions and I’m still amazed to see the amount of developers not realizing how invasive and how harmful is their code…In many organizations, they lach of deployment strategy and end up with (too) many Farm Solutions deployed that actually pollute the farm. It makes it complicated to migrate or even to add a new WFE… Trust me, most of the developers just do a F5 with Visual Studio or right click -> deploy and have no clue of what’s going on behind the scenes but when their crap goes to the other level (integration/acceptance), it’s another story. In a big orgranization, you might end-up with a uncontrollable situation leading to a very unstable farm.

    The App Model *fixes* that since you leverage only Microsoft bits
    whatever kind of App your write, at the SharePoint level only Client.svc will be involved. So, it can’t really be harmful from a server resource & stability perspective unless if you spam the servers with tons of client requests of course.

    To me, those two arguments are clearly in favor of the App Model. Now, I agree that as you pointed out, it still needs to mature but I’m convinced that even for on-prem systems, the App Model is indeed the way to go if you’re not running under its limitations.

    PS : Bjorn : if you forget about SharePoint one minute, you’ll notice that pure .NET developers are already very familiar with the *new* technologies (a lof of JS, REST, OData etc…) and they are even further than SP 2013 since many of them are already using .NET 4.5. So, for that kind of developers, the App Model is at last a good means to enter the SharePoint world.

    Best Regards

    • Matt says:

      Hey Stephane. Firstly, to suggest that switching to a client-side methodology doesn’t introduce a learning curve is a bit wrong in my opinion. I’m one that has taken a step into that world and absolutely love it (I have a number of older posts on the topic) but I’m not making these arguments from the point of a flexible and talented developer. I’m thinking of consultants i’ve worked with in the past who have struggled to learn new things quite as quickly, which can leave a bad impression with a client. I also believe when the Apps get a little more complex, there is more to know about how the App model works rather than just client-side technologies.

      I agree with your second point, but similar to my response to Robert this should be avoidable by any decent architect/developer/consultant. If you’re not working with these types however, it does introduce a good safety net and is one of the reasons I cryptically alluded to in terms of why Microsoft have their reasons to push the model. Perhaps clients do as well if they think they need that safety net – but my argument is that it’s their choice to make.

      Thanks for the reply

      • Chris Quick says:


        I completely agree the learning curve for client-side development is not trivial. While there are a lot of new standards and frameworks have become stable — for someone that hasn’t already been exposed to client-side development there are a lot of choices. Each choice has trade-offs that may not be discovered until deeply engaged in the project. In my opinion, as someone moving to client-side development, there is a lot of noise with all of the the JavaScript frameworks available. While we are getting closer to a few leaders, this makes the initial selection of a framework overwhelming.

        There are still a large number of holes and use cases where the App Model just doesn’t seem to provide an answer. For example, composite applications are not trivial to build with the app model — you are either fully immersed in the application (which means you have to build all of the UI) or you utilize an App Part that doesn’t have any capability of understanding custom tokens (i.e. passing in a key value to ask the web part to render something based on that key value).

        I asked for any good use cases on the SPYammer Developers group and there has not been one response. This at least reveals to me that much of the community still doesn’t know what to do with the App Model.

    • Yeah, I guess from your description of what current .NET developers do, you have only worked with developer that do the F5 method of development. In other words, you’ve worked with newbies incapable of tying their own shoelaces, much less build anything that scales farther than they can spit.

      BTW, ‘cannot be harmful to the server’ is both completely and utterly wrong and also completely irrelevant all the while you can throw every browser and any security in the company out the window with a few well-placed JS commands.

      Because, as we all know, security and stability is best left with end users.


  3. Thanks matt for this post. Always good to be introspective.

    Of the 4 “points” you raised, I think “learning”, “new thing” are just the nature of what we do. There will always be new things. For me, JavaScript has been getting much more easier to do, and if a webpart can run using the browser instead of potentially bringing down the server (or a even the sandbox service) that I argue is a major move forward.

    On “additional development time”, for new developers, I’m finding promise/defer much easier to explain than memorize the ASPNET page lifecycle. For example: it takes a few hours to grok promise. Then you learn the pattern and it’s no longer an issue. ASPNET page lifecycle you thought you knew, then you go back and debug and debug and learn via your mistakes.

    The 4th point – where it’s difficult to move forward to the App model OnPremise, I consider _the_ major roadblock. It needs to be easier to set up the App model, and provide guidelines to migrate existing code to the App model.

    Two years ago, I wouldn’t consider any developer a true “SP developer” if they don’t understand the ASPNET lifecycle. Now, as long as they grasp the site structures, understand the API, and can wield JavaScript like a maniac they are awesome by me.

    • Matt says:

      Hey John good to hear from you again! You do raise a good point re the page lifecycle haha, I still find myself battling with that to this day on occassions.

      As you know we utilise client-side technologies fairly heavily where i’m based even with full-trust solutions so i’m already a convert (where it makes sense, I still feel there are reasons when it should be avoided for highly complex and sensitive applications). I definitely see the value of developers becoming familiar with everything client-side/Apps and perhaps like it seems you’re suggesting maybe it’s easier to get a new developer coding well like this than it is giving them the keys to full-trust. Thanks for the reply

      • I’d be scared witless if a developer who doesn’t understand the page lifecycle gets anywhere near the farm with full-trust, the damage they can do is crazy.

        I say this and I’m a dev!

  4. Dan Barker (@barkingd) says:

    I wrote a blog post in response to this. I don’t claim to know all the answers but I enjoy the conversation here. Great information to think about!


  5. @Matt : I don’t say you have nothing to learn. I just say that everyone else but SharePoint developer are already very familiar with Client-Side technologies 🙂

    @Bjorn 1: you don’t get my point at all and I’m not sure if you really want to understand it :). When I said code is not harmful : I mean that you’re relying on Microsoft bits so by nature they are less harmful than any custom code and I’m mainly thinking of resource consumption & platform stability. I’m not pointing out security at all. I’m doing web development for 12 years so I know how unsecure a web application can be, that said, this is also true for server-side…

    @Bjorn 2 : I was not targeting .NET developers but SharePoint developers who don’t always know what’s going on under the covers and it’s normal because it’s quite complex to know all the combinations of features/solution frameworks and their impacts. So I don’t blame anyone but I just notice in the *real-world* how it goes. From that point of view, I consider Apps as less harmful in terms of deployment and platform stability.

    Best Regards

  6. @rseso : sorry mate, I missed your comment but I agree 100% on it. You expressed better what I wanted to highlight!

    @Matt : sorry for the spam 🙂

  7. App model may be a mess,but I am also 100% in favor of it, I have never been a fan of full-trust solutions, I was an early adopter and supporter of sandbox solutions, and now the App model. The primary issue with the App model, is that with anyone else’s app model you need to: understand OAuth, and learn a REST API. It’s not that simple with the SharePoint App model. You have the JSOM, CSOM, and REST API, and they don’t have equivalent functionality.You can only use cross-domain proxy OR OAuth from your apps, not both. Advanced topics like integrating licensing, handling multi-lingual, etc., is not well documented and requires special considerations (not just in your app code). The packaging model for Apps (despite being based on an open specification) is proprietary and overly complex; why, because Microsoft wants you to have to use Visual Studio. The list goes on! Over-engineered, overly complex, littered with Microsoft “lockins”, and just underwhelming is the only way to describe too much that is being released by Microsoft these days. I remember fondly the days when Microsoft produced products that I really *wanted* to use, now I mostly only use them when I have to. That is a powerful reflection on how they company has changed over the years.

    • Matt says:

      Thanks for the comment Chris. I realise ripping those twitter quotes out without even the small amount of context twitter provides was a little rough, so thanks for providing that!

    • Chris,

      JSOM,CSOM and REST & OData were already present in 2010, I started blogging on that in 2009 so it’s not really new :).

      They’ve just been extended in 2013 to push the App Model and more generally stop deploying invasive FARM solutions and be compliant with Office 365.

      But as you pointed out, authentication & authorization has always been one of the biggest challenges over the years even when you stay within the Microsoft stack (except when you have a single domain with Kerb enabled – easy SSO). For advanced scenarios, things get little more complex indeed but isn’t it always the case when you do advanced things?

      I think that Microsoft is now leveraging more & more worldwide standards, after all, REST, OAuth, JavaScript (apps but also display templates etc…), HTML5 (see lightswitch for instance) are not Microsoft specific technologies. Should we blame them for that or should we keep regretting the good old CAML that noone else was keen on learning?

      To me, for a good old SharePoint developer, 2013 is indeed a big release but many new doors are now opened to welcome developers with a more generic experience.

      Best Regards

  8. Dan Barker (@barkingd) says:

    One point I think we are missing here (albeit a slight digression) from a business and enablement standpoint is the business problem and the users. The reason for the solution. The users who have been screaming for solutions to augment the gaps in the platform but have to depend on others to procure or build something for them. In a lot of ways they are completely helpless. Doing their best to use the tool to do their job, etc.

    This thread has a lot of great points about the difficulties in using the new app model and the technology behind it. I like to focus on the possibilities and resulting benefits for current business problems and users. I am a big fan of the users….mostly because I am one!!! One of the most exciting results of this progression in my mind is the ability for users to get tools/apps they need easily without all the current roadblocks. Many of the current issues will work themselves out as developers and engineers become more familiar with the new technologies. But in the end, the business owners and user should greatly benefit from the app store. I have been in the SharePoint space since the products inception and one of the most difficult challenges is delivering solutions that everyone can use. The reality is that only a few groups or projects get what they need. Unfortunately most of the users are unable to obtain the small improvements they need to better leverage the platform. Going forward I think user enablement will greatly improve and there will be a lot more solutions to choose from. Most importantly they will have the ability to procure and use them. Today users do not have this option. Not even close.

  9. Abner says:

    if (Apps == iFrame)
    Web.Accesible = false;

    How using fricking iFrames is any modern or good?
    For God’s sake, Microsoft loosing north…. again.

  10. Hello, as of today, would you still stick to the point? I am currently developing a solution to a client who wont go to cloud for next few years due to regulatory reasons. Should I stick to farm solutions?

    • Matt says:

      Hey Santhosh

      Actually no, these days everything we do is with a cloud-ready mindset. A lot of the arguments against the model here are a bit outdated. The client frameworks that are available to leverage along with SharePoint CSOM makes the argument a little harder to justify. A few years is a short time, and developing in a manner that will suit both an on-premises environment and a cloud one is worth pursuing.

      Depends what you’re looking to implement – but for small components we use app script parts predominantly. Essentially content editor web parts pointing to HTML snippets (text files) that harness client side libraries (Knockout, jQuery etc) and use either CSOM or REST to bring back data dynamically from SharePoint. Really simple and powerful.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: