Telerik blogs

Mobile platform API access is a happy story for .NET developers—let’s take a trip down memory lane on how we got here.

Today’s .NET is open source and a cross-platform developer platform with solid tooling. Modern .NET helps developers build native apps for various mobile form factors and a plethora of devices. With Xamarin, Xamarin.Forms and now .NET MAUI, .NET code stretches easily to iOS and Android with full access to native platform APIs.

However, developers quickly learned that native APIs are best used from .NET/C#—with underlying platform mappings exposed through an abstraction. Without this, .NET developers would have learn Java or Swift/Objective-C to access native APIs and, even worse, replicate native access code for each platform.

How we access native mobile APIs through .NET, however, has evolved over years. Let’s take a look at where .NET started with platform APIs and where things are heading—through the lens of a little American history.

Era #1: The Wild West

The Wild West was a period of American history, played out at the frontiers of westward expansion and settlements around the gold rush. While there were lawlessness and conflicts, the times are immortalized by media depictions of the cowboy image and rugged individualism.

Xamarin and Xamarin.Forms played a big part in democratizing .NET code that worked seamlessly on mobile devices running iOS/Android. Developers learned how to write business logic in C# code that would shared across platforms and even use C#/XAML as a cross-platform UI abstraction. However, when it came to accessing platform APIs, developers did not care about writing native code—couldn’t .NET do the job? The answer was plugins—little abstractions that wrapped platform-specific code and exposed functionality in straight C#.

There was a lot of enthusiasm—the developer community wrote a ton of Xamarin plugins, as did the folks at Microsoft. All Xamarin developers had to do was bring in NuGet packages—there were plugins for just about every platform API and device functionality. This eventually did lead to the situation of too much choice—there were multiple plugins to do the same thing. Enterprise apps needed support and developers were confused as to which packages to trust. Nevertheless, the .NET community fondly remembers the immense individual contributions that made Xamarin plugins a rich ecosystem.

Era #2: The United States

Thriteen colonies of Great Britain along the Atlantic seaboard issued the Declaration of Independence in July 1776, thus creating the American union. The birth of a nation is seldom easy—more states joined the union, often through conflict and an all-out civil war broke out, but the integrity of the combined states remained intact, thus leading to the United States of America.

For Xamarin developers, C# abstractions were the way to access platform APIs/functionality—the Xamarin plugin ecosystem had grown almost uncontrollably. Microsoft needed to combine all the goodness in one place and offer one stable solution to access native mobile APIs. Enter Xamarin.Essentials—the one library to rule them all. Android, iOS and UWP offered unique OS features/platform APIs that developers now had access to all in C#—get one NuGet package and be done with it.

Xamarin.Essentials represented a substantial effort in standardizing platform API access from .NET and provided Xamarin developers a stable canvas to depend on for native functionality—it is now bundled into Xamarin projects with default templates. With over 40 cross-platform APIs, .NET developers are spoiled with easy platform access—irrespective of how the app UI was composed. Xamarin.Essentials, to this day, remains the gold standard of standardizing cross-platform API and platform features, all united from the comfort of C#.

Era #3: Alaskan Merger

When world superpowers are at odds over imperial struggles, big portions of land sometimes change ownership. In 1867, the United States of America took possession of Alaska after purchasing it from Russia—eventually adding it as the 49th state to the union. While separated from the rest of continental states, Alaska is strategic in its position and home of beautiful untarnished natural landscapes.

Xamarin and Xamarin.Forms may have been the preferred way for .NET developers to write cross-platform apps, but there is also no denying some of the pain points in the ecosystem—targeting multiple platforms wasn’t easy, large mobile app projects got complicated, platform customizations were tricky and tooling could be better. Enter .NET MAUI—the next generation of cross-platform development baked into .NET.

While .NET MAUI started with a mobile-first mindset as the evolution of Xamarin.Forms, it has quickly evolved to target desktop platforms—all the while providing more developer confidence. .NET MAUI sports a truly single project targeting various platforms, has polished tooling and enables better code sharing with web apps. However, developers still need to access platform APIs, particularly on mobile platforms like iOS/Android—why throw away all the work that went into Xamarin.Essentials?

From the early days of .NET MAUI, the buzzword was .NET MAUI Essentials—the same stack of native cross-platform APIs that developers love. What evolved is changed ownership—.NET MAUI Essentials is now a core part of .NET, thus inspiring developer confidence. Under the hood, .NET MAUI Essentials provides the same platform API or functionality abstractions—all exposed neatly through C#. Essentials is a cornerstone of .NET MAUI—allowing various cross-platform UI stacks written in C#/XAML/Blazor to easily access native platform APIs.

Era #4: Hawaiian Archipelago

In August 1959, Hawaii became the 50th state of the United States of America. The Hawaiian Islands are an archipelago of eight major islands, several atolls and numerous smaller islets in the North Pacific Ocean. While a strategic U.S. state, the combined Hawaiian Islands exude in Polynesian history and culture and are considered to be a tropical paradise.

You know what happens when something is steeped in history, of key importance and ingrained in culture—it becomes obvious. .NET MAUI Essentials became such a strategic part of .NET MAUI that it is not explicitly there any more—it is assimilated and simply baked in. After being a prominent part of .NET MAUI Previews, just before the first Release Candidate, .NET MAUI Essentials was reimagined and the Essentials name is no more. Make no mistake—all of the goodness of .NET MAUI Essentials is still very much there, just baked in to be a part of .NET MAUI itself.

In the past, the monolithic Microsoft.Maui.Essentials namespace brought in all of .NET MAUI Essentials—whether developers needed all the platform APIs or not. Now, the objective is to keep things granular and have developers bring in namespaces when they are explicitly using specific platform APIs/features. Let’s take a look at some of the most popular groups:

Need mobile device specific APIs—like power source, orientation, display, flashlight, vibration and more? Use Microsoft.Maui.Devices.

Need media-access APIs—like the camera or photo library? Use Microsoft.Maui.Media.

Need the tap into APIs for a plethora of sensors on mobile devices? Use Microsoft.Maui.Sensors.

.NET MAUI developers should get the point—.NET MAUI Essentials is no more, but the same APIs are now baked in and grouped into granular namespaces.

One question is obvious though—wouldn’t this need developers to remember/look up which namespaces they need for the corresponding platform APIs they want access? Yes, in a way—but it could be a one-time thing per .NET MAUI project. Simply bring in the namespaces with a Global keyword and you will have access to all the APIs everywhere else in the .NET MAUI project. Better still, why not put all the needed namespaces in a project-level GlobalUsings.cs file—keep things organized in one place and call it a day?

But wait—the story gets better. Instead of developers having to bring in namespaces globally, wouldn’t it be nice if .NET MAUI did some of the work automatically? Done and done. Start up a new .NET MAUI project and take a look at the intermediate build file named XX.GlobalUsings.g.cs—most of the platform API namespaces are pre-wired for you! And at build/publish time, there is tree-shaking to make sure your app package only includes the bits you need for the platform APIs in actual use. Hallelujah.

In a past conversation, Gerald Versluis and David Ortinau had appropriately said .NET MAUI developers can simply use cross-platform native mobile APIs out of the box. No need to think about it—the APIs are just there with most namespaces pulled in already. You can try to bend the spoon, or realize there is no spoon. Just like the Hawaiian Islands, the mobile platform APIs work together as a built-in part of .NET MAUI—a small piece of paradise for developers.


Modern .NET allows developers to easily write cross-platform mobile/desktop apps. However, for a high-fidelity experience, developers often have to tap into platform-specific APIs or functionality. Through a decade of evolution, present-day .NET MAUI makes platform API access rather easy for developers—everything is baked in. Abstractions through C# mean customizing UI or UX on each platform, which is also seamless for .NET developers. It has taken time, with big contributions from the developer community and standardizations from Microsoft—.NET MAUI developers are in a happy place moving forward. Cheers.

Use a component library in sync with .NET MAUI’s release cadence. Try Telerik UI for .NET MAUI for free.

About the Author

Sam Basu

Sam Basu is a technologist, author, speaker, Microsoft MVP, gadget-lover and Progress Developer Advocate for Telerik products. With a long developer background, he now spends much of his time advocating modern web/mobile/cloud development platforms on Microsoft/Telerik technology stacks. His spare times call for travel, fast cars, cricket and culinary adventures with the family. You can find him on the internet.

Related Posts


Comments are disabled in preview mode.