On May 28, 2014, Xamarin introduced Xamarin.Forms, which allows you to write user-interface code that can be compiled for the iOS, Android, and Windows devices. 

The Xamarin.Forms option
Xamarin.Forms supports five distinct application platforms:
    iOS for programs that run on the iPhone, iPad, and iPod Touch.
    Android for programs that run on Android phones and tablets.
    The Universal Windows Platform (UWP) for applications that runs under Windows 10 or  Windows 10 Mobile.
    The Windows Runtime API of Windows 8.1.
    The Windows Runtime API of Windows Phone 8.1.
In this book, “Windows” or “Windows Phone” will generally be used as a generic term to describe all three of the Microsoft platforms. 

In the general case, a Xamarin.Forms application in Visual Studio consists of five separate projects for each of these five platforms, with a sixth project containing common code. But the five platform projects in a Xamarin.Forms application are typically quite small—often consisting of just stubs with a little boilerplate startup code. The PCL or SAP contains the bulk of the application, including the user-interface code. The following diagram shows just the iOS, Android, and Universal Windows Platform. The other two Windows platforms are similar to UWP: 

The Xamarin.Forms.Core and Xamarin.Forms.Xaml libraries implement the Xamarin.Forms API. Depending on the platform, Xamarin.Forms.Core then makes use of one of the Xamarin.Forms.Platform libraries. These libraries are mostly a collection of classes called renderers that transform the Xamarin.Forms user-interface objects into the platform-specific user interface.
The remainder of the diagram is the same as the one shown earlier.
For example, suppose you need the user-interface object discussed earlier that allows the user to toggle a Boolean value. When programming for Xamarin.Forms, this is called a Switch, and a class named Switch is implemented in the Xamarin.Forms.Core library. In the individual renderers for the three platforms, this Switch is mapped to a UISwitch on the iPhone, a Switch on Android, and a ToggleSwitch on Windows Phone.
Xamarin.Forms.Core also contains a class named Slider for displaying a horizontal bar that the user manipulates to choose a numeric value. In the renderers in the platform-specific libraries, this is mapped to a UISlider on the iPhone, a SeekBar on Android, and a Slider on Windows Phone.
This means that when you write a Xamarin.Forms program that has a Switch or a Slider, what’s actually displayed is the corresponding object implemented in each platform.
Here’s a little Xamarin.Forms program containing a Label reading “Hello, Xamarin.Forms!”, a  Button saying “Click Me!”, a Switch, and a Slider. The program is running on (from left to right) the iPhone, an Android phone, and a Windows 10 Mobile device: 

The iPhone screenshot is of an iPhone 6 simulator running iOS 9.2. The Android phone is an LG Nexus 5 running Android version 6. The Windows 10 Mobile device is a Nokia Lumia 935 running a Windows 10 Technical Preview.
You’ll encounter triple screenshots like this one throughout this book. They’re always in the same order—iPhone, Android, and Windows 10 Mobile—and they’re always running the same program.
As you can see, the Button, Switch, and Slider all have different appearances on the three phones because they are all rendered with the object specific to each platform.
What’s even more interesting is the inclusion in this program of six ToolBarItem objects, three identified as primary items with icons, and three as secondary items without icons. On the iPhone theseare rendered with UIBarButtonItem objects as the three icons and three buttons at the top of the page. On the Android, the first three are rendered as items on an ActionBar, also at the top of the page. On Windows 10 Mobile, they’re realized as items on the CommandBar at the page’s bottom.
The Android ActionBar has a vertical ellipsis and the Universal Windows Platform CommandBar has a horizontal ellipsis. Tapping this ellipsis causes the secondary items to be displayed in a manner appropriate to these two platforms: 

Most of the programs in this book are fairly simple, and hence designed to look their best on a phone screen in portrait mode. But they will also run in landscape mode and on tablets.
Here’s the UWP project on a Microsoft Surface Pro 3 running Windows 10: 

Notice the toolbar at the top of the screen. The ellipsis has already been pressed to reveal the three secondary items.
The other two platforms supported by Xamarin.Forms are Windows 8.1 and Windows Phone 8.1. Here’s the Windows 8.1 program running in a window on the Windows 10 desktop, and the Windows 8.1 program running on the Windows 10 Mobile device: 

The Windows 8.1 screen has been left-clicked with the mouse to reveal the toolbar items at the bottom. On this screen, the secondary items are at the left, but the program neglectfully forgot to assign them icons. On the Windows Phone 8.1 screen, the ellipsis at the bottom has been pressed.
The various implementations of the toolbar reveals that, in one sense, Xamarin.Forms is an API that virtualizes not only the user-interface elements on each platform, but also the user-interface paradigms. 

Xamarin.Forms also supports XAML (pronounced “zammel” to rhyme with “camel”), the XML-based Extensible Application Markup Language developed at Microsoft as a general-purpose markup language for instantiating and initializing objects. XAML isn’t limited to defining initial layouts of user  interfaces, but historically that’s how it’s been used the most, and that’s what it’s used for in Xamarin.Forms.
Here’s the XAML file for the program whose screenshots you’ve just seen: 

Unless you have experience with XAML, some syntax details might be a little obscure. (Don’t worry; you’ll learn all about them later on in this book.) But even so, you can see the Label, Button, Switch, and Slider tags. In a real program, the Button, Switch, and Slider would probably have event handlers attached that would be implemented in a C# code file. Here they do not. The VerticalOptions and HorizontalOptions attributes assist in layout; they are discussed in the next chapter. 

In the section of that XAML file involving the ToolbarItem, you can also see a tag named OnPlatform. This is one of several techniques in Xamarin.Forms that allow introducing some platform specificity in otherwise platform-independent code or markup. It’s used here because each of the separate platforms has somewhat different image format and size requirements associated with these icons.
A similar facility exists in code with the Device class. It’s possible to determine what platform the code is running on and to choose values or objects based on the platform. For example, you can specify different font sizes for each platform or run different blocks of code based on the platform. You might want to let the user manipulate a Slider to select a value in one platform but pick a number from a set of explicit values in another platform.
In some applications, deeper platform specificities might be desired. For example, suppose your application requires the GPS coordinates of the user’s phone. This is not something that Xamarin.Forms provides, so you’d need to write your own code specific to each platform to obtain this information.
The DependencyService class provides a way to do this in a structured manner. You define an interface with the methods you need (for example, IGetCurrentLocation) and then implement that interface with a class in each of the platform projects. You can then call the methods in that interface from the Xamarin.Forms project almost as easily as if it were part of the API.
Each of the standard Xamarin.Forms visual objects—such as Label, Button, Switch, and Slider—are supported by a renderer class in the various Xamarin.Forms.Platform libraries. Each renderer class implements the platform-specific object that maps to the Xamarin.Forms object.
You can create your own custom visual objects with your own custom renderers. The custom visual object goes in the common code project, and the custom renderers go in the individual platform projects. To make it a bit easier, generally you’ll want to derive from an existing class. Within the individual Xamarin.Forms platform libraries, all the corresponding renderers are public classes, and you can derive from them as well.
Xamarin.Forms allows you to be as platform independent or as platform specific as you need to be. Xamarin.Forms doesn’t replace Xamarin.iOS and Xamarin.Android; rather, it integrates with them. 

For the most part, Xamarin.Forms defines its abstractions with a focus on areas of the mobile user interface that are common to the iOS, Android, and Windows Runtime APIs. These Xamarin.Forms visual objects are mapped to platform-specific objects, but Xamarin.Forms has tended to avoid implementing anything that is unique to a particular platform.
For this reason, despite the enormous help that Xamarin.Forms can offer in creating platform-independent applications, it is not a complete replacement for native API programming. If your application relies heavily on native API features such as particular types of controls or widgets, then you might want to stick with Xamarin.iOS, Xamarin.Android, and the native Windows Phone API.
You’ll probably also want to stick with the native APIs for applications that require vector graphics or complex touch interaction. The current version of Xamarin.Forms is not quite ready for these scenarios.
On the other hand, Xamarin.Forms is great for prototyping or making a quick proof-of-concept application. And after you’ve done that, you might just find that you can continue using Xamarin.Forms features to build the entire application. Xamarin.Forms is ideal for line-of-business applications.
Even if you begin building an application with Xamarin.Forms and then implement major parts of it with platform APIs, you’re doing so within a framework that allows you to share code and that offers structured ways to make platform-specific visuals.