6 Challenges of working with SharePoint 2013 App Model

Every major release of SharePoint has introduced a new development paradigm for developers to extend out of the box SharePoint features with custom solutions. The biggest breakthrough, in my humble opinion, came with the introduction of Web Parts in SharePoint 2003. The concept of dynamically associating UI widgets with individual user experience was certainly somethingsharepoint-2013-app-deployment-models lacking in typical web based offerings. Features based development and Solution based deployment was probably the best architectural initiatives in SharePoint 2007. By 2010 cloud adoption was on the rise and the framework had to be extended to support cloud based deployments. The introduction of sandbox solutions was aimed at supporting cloud based deployments but because of a fairly complicated development model, it could not gain enough acceptance in development community. Microsoft quickly realized that a new development platform is required to support the emerging cloud market for SharePoint 2013. Enter the new App Development Model.

The new App Development Model makes a lot of promises. Specially, the focus on HTML5 and JavaScript based development has gained significant acceptance in the development community. However if you ask any experienced SharePoint Developer, all is not well. I personally think that the new App development model presents significant challenges for an average developer. Although Microsoft recommends an “App First” development model but I think the framework is not there yet. I will try to list down some of the potential challenges an average developer may face while implementing a customization on SharePoint as an App.

1: Choosing a Hosting Architecture

The first challenge is understanding the hosting architecture of Apps. The hosting architecture directly affects the development, deployment and maintenance model for your SharePoint customizations. The App hosting architecture is significantly different from how Solution based deployment works. The basic reason for this change is that the App model targets Cloud as a first class citizen while Solution based deployment is not possible for Public clouds.
There are two deployment models for Apps. Microsoft provides a detailed overview of this under

SharePoint Hosted: Apps are deployed in an App Web which is a separate app domain within the current SharePoint web site. I would strongly suggest to go through the following links for a details understanding of the implications of this deployment model

Provider Hosted: Apps are hosted outside SharePoint in a different environment. The App as a component is visible in SharePoint but this component is essentially hosted in a different remote web server. For a detailed understanding of this hosting model, I would suggest to go through the following Microsoft link

2: Understanding the Development Options (Tools/Languages)

The choice of development language is dependent on the hosting option you choose for your App deployment. In case of the SharePoint hosted deployment model, only client side technologies like HTML and Javascript are allowed. The Provider hosted model is extremely flexible as it allows for development and hosting on any available web platform like ASP.NET, Java, PHP, Ruby etc. All in all it is fairly open ended and provides a lot of options but at the same time it brings significant adoption challenges for developers.

3: Understanding the Authentication and Authorization

In traditional SharePoint Solution based development, the security context of the current user is used to access SharePoint resources. Access to external resources like DB or BCS uses the security context of the Web Application Pool. For Apps the security context is either the App principal or App + User principal. In case of external Provider Hosted Apps there is this additional overhead of understanding the low trust and high trust authorization models. This is probably the most confusing and extremely loaded topic in understanding App development. The following MSDN link is an absolute must to get a better understanding on this

4: Understanding Resource Context & Data Storage options

In a traditional Solution based deployment, the resources specific to your solution are packaged and deployed as part of the web or site collection to which the feature is activated on. So within the context of a custom application, all the resources are considered to be local unless the application tries to access something from a different site collection or a different farm. The new App model effectively changes all that. Even with SharePoint hosted deployments the resources an App Web has to access are considered external and the App requires an explicit permission from the Host Web owner to access the resources.
SharePoint hosted apps usually store data in lists and libraries within the App Web. This is true of both SharePoint On-Premise and SharePoint Online. However, for Provider Hosted Apps the options for data storage are essentially limitless. The remote nature of App hosting removes all possible restrictions from the data storage mechanism. This also means that SharePoint can be easily extended to provide complex relational data models which are otherwise very complex and often not recommended inside SharePoint. The limited ability to reflect the natural relationships of entities within SharePoint has been a major pain point in successfully designing SharePoint based customizations. The following MSDN link provides a useful insight

5: Understanding Backup/Restore challenges

Successful Backup/Restore has always been a challenge when it comes to customizations in SharePoint. Since Apps are kept separate from SharePoint, their backup and restore paths are different as well. OOTB options in SharePoint 2013 provide a fairly decent option for backup and restore of SharePoint Hosted Apps. . provides a fairly decent overview.
Things are a little tricky in case of Provider Hosted Apps since most of the data is hosted remotely. Your backup strategy will also depend on how and where you have maintained the context of the App. Ideally, the remote DB will contain all the data and context necessary for app execution and this will essentially make your App as a plug and play feature. However, if the design of your App requires some context to be maintained within SharePoint as well then an additional overhead of maintaining the same context on a restored site is also required.

6: Understanding Upgrade/Migration challenges

Upgrade & Migration of SharePoint Hosted Apps is fairly straight forward. You can take your On-Premise SharePoint Hosted App and port it over to SharePoint Online (Office 365) and vice versa. The upgrade or migration of SharePoint does not really impact your Provider Hosted App. This is considered a big plus and provides the much needed flexibility required for majority of Production scenarios.

This small write-up was an effort to briefly summarize some of the major design and architecture related challenges associated with App development. There is a lot more into it then the above simplification. In my humble opinion, developers should continue to focus on developing Farm Solutions for On-Premise applications. For applications targeting both Cloud and On-Premise environments, the App framework is obviously the only choice.


Hassan Askari

Comments (2)

  1. Rico
    December 18, 2014

    I agree with you. Building apps on O365/SharePoint online is difficult.
    But if you want to do so WITHOUT any programming and 3X faster, I will be happy to show you how 🙂

  2. SharePoint 2013 Online Training
    September 7, 2017

    Awesome post… just what is needed for a beginner in APP Model!

Comments are closed.