In what is arguably the largest paradigm shift in the history of SharePoint development, Microsoft has made a strong push toward the App Model in SharePoint 2013. Unlike traditional farm solutions in prior versions of SharePoint, the App Model brings a level of code isolation not yet seen in the SharePoint world.

Simply, the App Model allows “bolt-on” functionality; this is opposed to previous generations that have a very “bolt-in” functionality. This model can be used for many of the same situations in which the farm-solutions model would have been employed. These solutions may include complex integrations with external systems, the need to perform complex business logic, and any other custom development needed for SharePoint.

Apps are broken down into three basic categories: SharePoint-hosted, auto-hosted and provider-hosted. In all of the models, you have the ability to deploy SharePoint artifacts such as Lists and Libraries, but there are significant differences among them.

SharePoint-hosted apps are run exclusively in SharePoint. They do not require any outside hosting for any portion of the app, but they are considerably limited. Given that the goal for the App Model was code isolation, there is no way to run server-side code in a SharePoint-hosted app. You are limited to HTML, CSS and JavaScript.

Auto-hosted and provider-hosted both allow server-side code, but in a different web application that is outside of SharePoint entirely. This is where things become a bit trickier. Auto-hosted apps will automatically provision a hosting environment for your server-side portion (known as the remote web), but they are only available in Office 365. It will also provision a new site for each instance of the app.

Provider-hosted apps are supported in both the Server version of SharePoint as well as in Office 365. The detriment here is that the hosting environment for the remote web is not automatically provisioned. You must actively provision the hosting environment and associate it with your app. The good news is that you can use a single remote web for multiple app instances. This ability eases the burden of sending updates to multiple instances by allowing you to update a single remote web across many instances.

When running server-side code in the app model, you have to contend with three entities. Your two SharePoint-based entities are the host web and the app web. Your custom code, as described above, is run in the remote web.

Your host web is the site in which the app was installed. Your app web is the site that was provisioned for your app at the time of install. This is where all of your SharePoint artifacts live. Your remote web is where your server-side code lives and, in many examples, where your user interaction takes place. (I add the caveat of “in many examples” because that is not your only option.)

The fact of the matter is that if the majority of your apps’ functionality could be completed in the standard SharePoint UI, the majority of the user experience for your app can live in the app web. As of this writing, there are still a few bugs in the implementation. Most notably, the “Compliance Details” screen is not available from an app context, but the option still appears in the context menus. I recently completed a project for which 90% of all user interactions with the app are actually performed from the app web. The fact that the user is able to maintain a consistent look and feel allows for greater user acceptance while minimizing the code necessary to build the UI.

Overall, the app model is a giant step in the right direction for SharePoint development. Developers are able to use their existing skillsets in .NET, Node.js or any other language that supports OAuth, and the admins don’t have to wonder about the stability of the code they are allowing into their environments. That being said, any shift in a development paradigm takes time to learn and adopt. The challenge now is for developers to step out of their farm-solution comfort zone and embrace the new model. Come on in, the water’s fine.

Brian Prigge is SharePoint architect at video data platform provider Ramp.