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,

Multiple 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.

JavaScript can no longer be considered 100% secure

Well here is another big consideration – for the longest time we have considered JavaScript to be a secure platform because it runs inside a sandbox – that is your browser. Well, no longer buddy. Yes it won’t hurt your machine, or your SharePoint server. But it could steal your data given that you have provided OAuth based permissions to let it do so. SharePoint apps do not let you specify access at a specific list or specific web level. Which means, if you can write to my “Announcements” list – you can also write to my all other lists. Ouch! Additionally, OAuth access to other applications is hijackable. Lets say your App OAuths you into your bank account – a sandbox solution in the parent page can potentially hijack your identity and do stuff on your behalf – without asking you for it. Plus, clickjacking is just too easy for me to get a good comfy feel around this. Not that there aren’t solutions to this, but it will require more thought from developers. Developers who are always under the gun to produce functionality because their customers do not understand the value of doing good homework and ensuring good security and architecture ahead of time, because it costs more.

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.

UI Challenges

SSL certs

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.

SEO Concerns

Apps will launch either via complex javascript (usually), or run in a separate IFRAME, also called as the SEO walled garden. This basically means that if you use a discussion forum app on your internet facing site – you basically lose all the link-followage that dumb search robots use.

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“,

Check out our resource centre for more SharePoint content from Sahil and other SharePoint specialists!

Sahil Malik was a speaker at the European SharePoint Conference 2013.