First of all, I am a proponent of SharePoint apps. As I have said many times over, SharePoint Apps make me very ‘appy, they are very app-propriate. But there are some points to consider that make a bit app-rehensive.
These are all mentioned in my book “SharePoint 2013 - Planet of the Apps”,
.. but here are some thoughts of the negatives of Apps that I think we need to consider before diving in,
Mutliple Servers, More Complexity
Apps, by definition will include an extra server. This excludes SharePoint-hosted apps of course. Extra servers by definition will add more complexity. As it is, when you introduce SharePoint to an organization, the number of servers multiply like bunnies. Now you will have additional servers, and these servers talking with each other. You will have to maintain trusts, and you will have to patch more stuff, reset more “admin” passwords – you get my point. Additionally, the cross-domain authentication isn’t exactly simple. Basically, just like Kerberos, this cross-domain auth is like a little bird. It’s pretty cute until it shits on your head.
Simpler tasks are easier to do in Sandbox solutions
Well first the good news, if you had written sandbox solutions in SP2010, your upgrade to SharePoint apps is going to be quite boring – which I like. In SP2013 however, there are some scenarios that are just easier to do in sandbox solutions, provisioning content types, branding artifacts, adding a list etc. You could do them in an app, but it’s just more straightforward to do them in a sandbox solution. Now since Microsoft is pushing us to use apps heavily, well, I sorta miss being able to do simple stuff in sandbox solutions. I’m frankly not very sure what the future of sandbox solutions is – on one hand Microsoft says they are deprecated, on the other hand, they still offer some value. I guess I’ll just stick with apps and bit the complexity.
Security of provider based apps is questionable
Whoaaa! WTF! Blasphemy, how dare I say “questionable”. Well, imagine that you install a provider hosted app. Now, you give it “Manage” rights. Life is all hunky dory because your app does a certain task and it does it quite well. So you give it manage rights .. sure! But, at a later date, nothing prevents the app provider from changing the server side implementation of his app and do stuff that you didn’t think they were doing. Ouch! This does not apply to azure autohosted apps, or SharePoint hosted apps, but still a concern.
Allright, I’ll say it. SP2013 is UI challenged in many ways. No breadcrumbs? And that MDM strategy means frequently where business users are used to seeing a spinner spin in your browser’s TAB – well that no longer gives any feedback. Sometimes it says “Working on it” but sometimes it doesn’t. Add apps to it, and you have something that runs in a completely different context and doesn’t really blend well into the UI. The chrome control, I am sorry, doesn’t go far enough – especially when it comes to navigation. I think most app developers will end up reinventing the wheel in many different ways when it comes to common UI challenges – Microsoft, give us more guidance/tools on this please before letting the horse out of the gate.
Apps will require you to provision new domains on the fly – this is done by some clever DNS settings so there are no manual steps involved. However, you must use HTTPS for apps to be considered ‘secure’. I cannot in good faith recommend apps without SSL, anyone can sniff your access token and do whatever the hell they please under your identity for up to 1 hour. Way too insecure – but with HTTPS is absolutely fine. OAUTH2 requires HTTPS BTW, it is not considered OAUTH2 unless you use HTTPS. The issue of course is, your company will have to buy a wildcard SSL cert, which costs mucho bucks. One alternative I recommend for intranet scenarios is to provision your own certificate server – not a solution for extranets or internet facing sites though. You could go around creating provider hosted apps, with a hardcoded launch URL though, but you lose some flexibility there.
On-Premises and Office365 have some differences
Well, as of today, SP2013 On-Prem vs. Office 365 have some differences. I think these differences will continue to increase. This means, you can’t in many cases, just write an app and use on both. There will be workarounds etc. but something for you to consider.
Okay, I gotta run and catch a plane now, for more practical stuff like this, see my book “SharePoint 2013 - Planet of the Apps”,