Microsoft SharePoint introduced in 2001 but the first customization option i.e. farm solution was intro-duced in MOSS 2007. 

The farm solution contains custom managed code which is deployed to the SharePoint farm servers and communicates with SharePoint via the server-side object model. The code related assemblies, XML, and other files in the extension are bundled into a single file called a solution package. The solution package is a file with .wsp extension but it has .cab-based format. This package contains SharePoint features and their related components.  

Only a farm administrator is having access to upload/deploy a solution package into the farm's solution store. A feature of farm solution can have the site collection, web application or whole farm scope. These solutions are used to customize SharePoint administrative functions, such as custom timer jobs, custom Windows PowerShell cmdlets, extensions of Central Administration, etc. 

The assemblies of the farm solution always run with full trust, but an assembly can be deployed with custom code access security (CAS) system policy that gives the assembly less than full trust. Also, there are no resource usage restrictions.  

The farm solution code is hosted in IIS worker process (W3WP.exe). When any developer deploys or ac-tivate/deactivate the feature, system's IIS application pool recycle. The farm solution cannot be distributed through the Office Store and cannot be installed on SharePoint Online. 

Pros: 

Cons:

Microsoft has introduced Sandbox solutions in SharePoint 2010 version. 

Like to a farm solution, a sandbox solution is also a solution package (.wsp) file. But contradictory to farm solution, a sandbox solution authorizes the site collection administrator to install custom solutions without the interference of higher-level administrator. 

The sandbox solutions are stored in the solution gallery of a site collection. The components of a sand-boxed solution run under a significantly restricted Code Access Security (CAS) policy and resource access restrictions.  

The sandboxed solution can include code that runs against the SharePoint client-side object model. It is hosted in SharePoint user code solution worker process (SPUCWorkerProcess.exe).  

A sandboxed solution runs outside of the IIS worker process. So, when any developer deploys or acti-vate/deactivate the feature, System's IIS application pool does not recycle. The sandboxed solution packaged file runs only for site collection instead of the whole farm. 

The developer can use Sandbox solutions in SharePoint on-premise version and online version with No Code Sandbox solutions to deploy per site collection and Site collection administrator can only install it. It will not run on cross-domain site.

Pros: 

Cons:

Microsoft SharePoint Apps was introduced in SharePoint 2013 version. Later, they are called  SharePoint Add-ins. 

SharePoint Add-ins are self-contained extensions which may include cloud-based logic and data, Share-Point components, and client-side scripts, but not custom managed code that runs on SharePoint serv-ers. One can install them from either the Office Store or an organization add-in catalog. It can be in-stalled on either SharePoint on-premises farms or Microsoft SharePoint Online. 

There are two types of SharePoint Add-ins: 

It is centered on the SharePoint components including lists, pages, Web Parts, workflows, and more. No server-side code is included in it. The business logic included in it uses JavaScript either directly on the custom SharePoint pages or in the JavaScript file which is referenced from the custom page. The JavaScript version of the SharePoint object model (JSOM) is available to make it simple for the add-in to perform CRUD (create, read, update, and delete) operations on SharePoint data. One can also customize the SharePoint controls by using a client-side rendering option and custom JavaScript. 

The website, where the add-in is installed, is called the host web. From this site, the Add-ins are launched. The web site on which the add-in is deployed is called add-in web.

The JavaScript included in the SharePoint-hosted add-ins can access data and resources that are outside of the add-in web. To access the data, there are two ways to safely work around the browser’s same origin policy: a special JavaScript cross-domain library or a specific JavaScript Web Proxy class. Using these two techniques, a SharePoint-hosted add-in can work with data on the host web, its parent subscription, or anywhere on the Internet.

Pros:

Cons:

On contradict to SharePoint Hosted Add-in, the Provider Hosted add-in focuses around a remote web application or data source. It is not centered on the SharePoint components but can contain the SharePoint components. The business logic included in it is remote server-side code or code in non-Microsoft technology (e.g. Java, Python etc.). 

All its components are hosted outside of SharePoint farm and it has at least one remote component hosted externally from the SharePoint farm or SharePoint Online subscription. 

With .NET in presence of the implemented remote components, the managed code SharePoint Client-Side Object Model (CSOM) library is available. While without .Net, a set of REST/OData APIs can be used to access SharePoint data.

To access SharePoint data through this add-in, its principal is required to be authenticated and authorized, and so the add-in needs permissions to perform operations on SharePoint data in the host web.

It can handle SharePoint list and list-item events (e.g. adding an item to a document library) which the SharePoint Hosted Add-in can’t. It can also connect to any public or internal web service.

Pros: 

Cons: