New features of SharePoint 2013 is the introduction of the App Model. We are all familiar with the App Model from Apple’s App Store and Google Play. Microsoft set out to create an extensibility point in SharePoint 2013 that would allow customers to build their own solutions for SharePoint without hurting the hosted model whenever a customer’s code was found to be ‘executionally challenged’. They came up with a model called a SharePoint App, which is simply a solution with no SharePoint server side code. There is no server-side code that is executed by the SharePoint server. A SharePoint App is essentially a solution that can only include HTML, CSS, JavaScript, Silverlight XAP files, images, and any other static files. However, you can’t include an assembly with custom code because that would need to be executed on the server. Developers will be able to publish their apps to a public marketplace for download & purchases. In addition organizations will be able to create a private corporate marketplace where the apps would be available to the organization. There are three major types of SharePoint apps. Each one has its own benefits and limitations. Developers creating these apps need to understand these options. They should also be understood by those who are responsible for governance and change-management. These types are:

• SharePoint-Hosted Apps
• Provider-Hosted Apps
• Autohosted Apps

A type of app that has no server-side components. When deployed it installs everything it needs, including lists, workflows and content types. When you add an application to one of your sites, SharePoint deploys the files in your App to a special App domain where your App lives. When a user accesses your App, they are redirected to a page that lives in the App domain and from which, presumably, they can use your App. There is absolutely no server-side code allowed in this model. Provider Hosted App is one where the app is hosted outside of SharePoint. For Example, a server hosting IIS can host the app contents in a site. This is referred to as a remoteweb. This is more of a hybrid in that it can run a mix of both client and server side code. These apps include server-side components. This generally comes in the form of IIS hosted applications and Web services that are not installed to the SharePoint farm, but are still leveraged by the app when it is deployed to SharePoint. The server-side services themselves are hosted on a separate Web platform, such as Microsoft Azure. These remote components are deployed separately from the app. In a provider-hosted app, you are responsible for the infrastructure (again, external to SharePoint) where your app runs. You have lots of flexibility in the sense that you can run full-blown server side code and even take advantage of frameworks like ASP.NET MVC (or even use Java, PHP, or other non-Microsoft technologies as well), but you are also responsible for things like tenant isolation When Microsoft introduced SharePoint’s Application Model, they released a preview hosting option called "autohosting".  Autohosted apps were exclusive to SharePoint Online and allowed developers automatically provision websites and (optional) databases in Windows Azure on-demand. Developers didn’t even need a Windows Azure account...everything is provisioned automatically in a Microsoft-owned Azure tenant. This new type of app only relates to Office 365 and SharePoint Online. It has server-side components similar to Provider-Hosted Apps. What makes it unique is that it not only provisions the app in SharePoint, but also automatically provisions components into Azure. In an autohosted app, any web or database resources your app needs will automatically be deployed to Windows Azure and SQL Azure. You can run server-side code in your Windows Azure web site and multitenancy is provided automatically.