A native platform API is the interface an operating system exposes for capabilities that belong to that platform. In a .NET MAUI app, these APIs sit below the unified .NET MAUI layer: Android, iOS, macOS, and Windows each provide their own APIs, while .NET MAUI supplies shared UI and device features where possible. section 1.2
Figure 1.2 .NET MAUI is built bottom-up. Each platform provides APIs, and there is a .NET runtime for each platform (WinRT on Windows, Mono on everything else) built on these APIs. Each layer provides APIs used to build the APIs in the layer above. Meanwhile, your code is written top-down: you write a .NET MAUI app, and the architecture encapsulates it for lower layers.
Use this layer diagram to distinguish the top-down workflow of writing .NET MAUI code from the lower platform APIs available beneath it. section 1.2
Native APIs matter when an app needs a feature that is specific to an operating system. .NET for Android and .NET for iOS provide bindings to their platform APIs, using types and namespaces familiar to Java, Kotlin, Objective-C, and Swift developers. Windows uses WinUI, and .NET for Mac follows the same platform-binding approach. section 1.2
Choose the API level by starting with the most portable option:
- Use .NET MAUI for common cross-platform UI, navigation, and hardware features such as Bluetooth, location services, and device storage. section 1.2
- Use a native platform API when the required capability is platform-specific, such as ARKit on iOS or ARCore on Android. section 1.2
- Keep platform-specific code optional: a cross-platform app can be written primarily with .NET MAUI and compiled for each target platform. section 1.2
Augmented reality as a platform-specific need
An augmented-reality app may need ARKit on iOS or ARCore on Android. These native APIs expose capabilities beyond a single shared API, making an installed application a practical choice when that access is required. section 1.2 section 1.3
Access to native APIs is also one reason to choose an installed binary app over a browser-based app. Browsers can reach some hardware features, including camera, location, and Bluetooth, but telephony and SMS can be difficult or impossible to access; installed apps provide more direct and reliable access to platform capabilities. section 1.3
Native APIs do not require abandoning cross-platform development. Start with the unified .NET MAUI API for the shared application, then add platform-specific access only where a required feature cannot be handled at the common layer. section 1.2
