I have been working A LOT with SharePoint 2013 apps since around November 2011 and AvePoint (where I work) released our first app Task & Calendar Sync to the store in June 2012 and our second called Meetings in April 2013. As the Architect and Product Manager on these apps I’ve learnt a lot about apps.

Andrew Connell has recently posted a great blog post on his thoughts on the App Model and Store and it’s definitely worth a read! Totally agree with Microsoft disclosing how big the marketplace reach is…make online/on-premises for auto-hosted and provider hosted transparent the top of my wish list!

I had a bunch of thoughts around all this and won’t repeat Andrew’s but will add to it.

Microsoft Migration Push

As Andrew said, Microsoft are making a HUGE push on using Apps over Solutions. Microsoft have created a great new landing page explaining the advantages of apps over solutions for customizing SharePoint 2013. It also includes videos on how to migrate from various artifacts in solutions to artifacts in apps. Visit http://msdn.microsoft.com/en-us/office/apps/dn133840. This includes a great whitepaper on why solutions vs apps http://download.microsoft.com/download/8/8/3/883C0889-72A8-4766-8D07-4BF2F048BE36/DecidingBetweenAppsForSharePointAndSharePointSolutions.pdf.

Why?

Making a Business Solution available to End Users
I personally think the ability of having an App is a great way for End Users to be able to consume Business Solutions you build regardless of whether its for internal organization use or for external customers. The reason being is that the traditional Solution approach really only thinks in times of Site Collection Features and Site Features that are activated and light stuff up OR provide Site Templates that can be used to create Sites with things automatically lit up. The ability to granularly show these Features or Site Templates to audiences of people is tough in the Solutions approach. With the new App Catalog, it’s very easy to dictate who can chose to Add the App.

Chose your language and get better ALM
You can write in JavaScript against Client-side object model already in Solutions no problems, what the Remote-Hosted Apps provides is a way to write in ASP.NET MVC, Java, PHP, HTML5 etc. and therefore have a much better mature Application Lifecycle Management (ALM) through these platforms rather than being tightly bound to the SharePoint execution and deployment model of Solution Packages. It really allows you to separate the presentation layer of SharePoint and your App as the surfaces of your app are either full page or in an App Part….technically it means you can build the app and shim the SharePoint API calls completely much easier than you could with Solution Package approach.

App has Identity
For the first time in the SharePoint World….I can build a Business Solution with an identity. When a Business User adds an App toa Site, they have to “Trust It” which essentially is given the App the right to talk to the SharePoint Parent Site (if it asks for those permissions) as the App…not as the Business User using the App. This is a huge step forward in Business Solutions.

Force of hand
I think you can see the writing on the wall in terms of both Full-Trust Solutions and Sandboxed Solutions in the future. In Microsoft eyes…On-Premises dead already so Full-Trust isn’t even an option and don’t expect any updates to this approach. Sandboxed Solutions are deprecated…so definitely don’t expect any updates here either…and as Andrew mentioned…I hope they don’t completely block them in SharePoint Online…but potentially they could.

This means you are almost being forced to move if you want to leverage anything else in the future that is introduced in Service Updates on SharePoint Online or Service Packs in SharePoint On-Premises. When I mean leverage…I mean:

• the Dev tooling will only be (I’m guessing) updated for Apps moving forward, the “legacy” Solutions Project Templates won’t be
• the Client-Side object model (Microsoft.SharePoint.Client.dll) will only be updated (I’m guessing) moving forward and not Server-Side object model (Microsoft.SharePoint.dll etc.)
• the training and documentation I’I’m guessing) will only be updated for Apps and Client-Side object model

General Apps Limitations

Branding
The biggest concern I have had so far from customers using Apps is that when you click on the App you lose a lot of the context you have in normal SharePoint pages. For instance, in the top chrome bar your “Outlook Calendar People Sites” etc. isn’t there. Although it can carry through the CSS theme, not all elements are there including the Site Navigation. In Sandbox Solutions you could deploy Application pages that actually leveraged the master page of the Site…not true with Apps.

App Security
Unfortunately, Apps don’t have security…I can “add an App” to a Site, but I can’t manage security to it like I can a List or Library (ooops I mean Document App 😉 ). This can cause issues and essentially you end up creating child sites and breaking inheritance on the child site and adding the App to that.

Office 365 plans in general
It’s definitely worth looking at this chart to see what is supported and not in the different plans with regards to SharePoint Online in Office 365. notice for certain plan types the “App Hosting: Base” and “App Hosting: Per User” is not supported in Small Business and Midsize Business…so the reality is if you’re using apps you need an Enterprise Plan for full flexibility of store stuff.

On-Premise in general
By default, the Apps architecture is not configured in a SharePoint 2013 install. There are a few hurdles to get this up and running to even run SharePoint-Hosted apps let alone Cloud-Hosted ones. This can often be a problem if working with IT for SSL certificates etc. becomes a road block.

Farm Wide Apps
Some concepts just really don’t suit Apps, one of the biggest is a Business Solution that you would typically deploy to one site collection but then it calls object model code against all site collections. The biggest problem with Apps is that the user token that the App can use is bound to the Site Collection the App is installed in and can’t reach any further. In a server-side object model approach, elevated privileges could be used to overcome this in the Full-Trust Solution Package model. To a degree, search can be used to fetch data to get around this, but if you are looking to modify anything outside the site collection you are done for. The only real way is to deploy the App in all site collections and store all the user tokens for each app for each site collection and use them as you need them and refresh them before they expire.

SharePoint-Hosted Limitations

Provider-Hosted Limitations

Universal story
I think the first few things to bare in mind is that Auto-Hosted simply doesn’t work on-premises so you are either SharePoint-Hosted or Provider-Hosted to cover both SharePoint Online and SharePoint On-Premises.

Also take into account that a P1 plan in Office 365 does not support Provider-Hosted apps either.

Controls

As soon as you jump to either of the Cloud-Hosted approaches (Auto or Provider) you lose a bunch of things. For a start…you can’t just throw SharePoint User Controls on pages like the XSLT List View Web Parts or People Pickers.

Sadly this meant that we had to build our own People Picker leveraging the CSOM Search APIs so that we could fetch a list of all users…because if you just get AllUsers from the Site Collection it only returns users who have been granted access to the site or accessed the site as it reads from the User Information Lists.

High Trust story

There is a little bit more effort required to get Cloud-Hosted Apps running on-premises due to there being no OAuth via Windows Azure available on-premises. There is a good article on TechNet that explains how to configure an App for High Trust, it is certainly a complex approach that often confuses people and causes problems and I’m already finding that this is a lot of the reason people are mandating SharePoint-Hosted only.

Provider-hosted package Web Application hard coded reference

Sadly when you build a Provider-Hosted SharePoint App, it hard codes the URL of the Web Application that is part of the “Cloud-hosted” aspect of this. Also in the App is the SSL cert used and a secret, this is the same SSL cert that the Web Application component needs to be bound to in IIS (or wherever its hosted). What this means is that if you are building an App you want to provide to customers to install on-premises you either have to create unique App packages for them wwith their own SSL cert and pointing to the correct Web Application URL…OR enforce customers use the same SSL cert (that you provide) and same URL…which is not really feasible.

Versioning story

When you release an app as v1.0.0.0 and Business Users add the app, it stores this version. If you modify your App to v1.1.0.0 (or anything different from original) you may have added new artifacts like a SharePoint List to the App Web etc. If you deploy this into the App Catalog…it doesn’t automatically update all the App instances in the SharePoint 2013 Farm. It is up to the Business User to upgrade the App. In a Provider-Hosted model this means that your Web Application component needs to be aware of what version of the App is consuming it..e..g. if v1.0.0.0 is consuming it your business logic in your component can’t expect that list to be there. This is why Auto-Hosted would be so much easier as the Web Application component would be deployed with the App and therefore not so many versioning conflicts to be concerned with.

Conclusion

All in all, I’m very happy so far with the App architecture and you have to remember this is version 1.0. Microsoft don’t have a good history of v1, and I am happy to say I think that this is a lot more mature than we all expected it to be at launch.

Jeremy was a speaker at the ESPC 2013. Check out Jeremy’s blog for more insightfull content!

For more SharePoint content from Jeremy and other SharePoint specialists check out our resource centre!