.NET 10 on iOS: Updates and Notes for .NET MAUI Developers

Here’s what you may have missed in .NET 10 for .NET MAUI developers targeting iOS.

The new features in .NET 10 for .NET MAUI don’t stop ! 😎 In this article, we’ll dive into the iOS-specific updates introduced in .NET 10—improvements that directly impact performance, reliability and the overall development experience for mobile apps.

We’ll break down what’s changed, what’s been optimized and what you, as a .NET MAUI developer targeting iOS, should keep in mind to get the most out of this release.

🔧 Supported Platforms

One of the first questions I recommend asking when adopting a new version—specifically in this case for .NET iOS (although it applies to everything)—is knowing which versions are officially supported.

Why? Because this tells you which device and/or emulator versions your environment must match in order to fully take advantage of the new features!

For iOS, tvOS, Mac Catalyst and macOS, the following versions are supported:

• iOS 18.2
• tvOS 18.2
• Mac Catalyst 18.2
• macOS 15.2

Preview 7: Xcode 26 Beta 4

For now, Preview 7 still doesn’t include full builds for .NET 10, but it does introduce initial compatibility with Xcode 26 Beta 4, focused on .NET 9 projects.

Putting this into practice, to use the new APIs/bindings from iOS 26 (Xcode 26), you must add two important elements inside your <PropertyGroup> tag:

➖ Add the TargetFramework tag:

It specifies the version of the development environment, for example:

<TargetFramework>net9.0-ios26</TargetFramework>

➖ Then you must add a NoWarn:

<NoWarn>$(NoWarn);XCODE_26_0_PREVIEW</NoWarn>

⚠️ This NoWarn is necessary because Xcode 26 is still in Beta, and it prevents the project from showing compatibility warnings.

A complete example would look like this:

<Project Sdk="Microsoft.NET.Sdk"> 
    <PropertyGroup> 
	    <TargetFramework>net9.0-ios26</TargetFramework> 
	    <NoWarn>$(NoWarn);XCODE_26_0_PREVIEW</NoWarn> 
	    <!-- rest of your configuration --> 
    </PropertyGroup> 
</Project>

.NET MAUI Shell Rendering Issues

⚠️ Previously, there was an issue with .NET MAUI Shell rendering on iOS 26. You can now be confident that this problem has been resolved in .NET MAUI 9 Service Release 11 and .NET MAUI 10 RC1.

Previews: Extra Information

To learn more about .NET 10 on iOS, tvOS, Mac Catalyst and macOS, the official documentation recommends reviewing the known issues in .NET 10.

You can also explore the release notes for the .NET 10.0.1xx Preview versions:

• Release Candidate 1
• Preview 7
• Preview 6
• Preview 5
• Preview 4
• Preview 3
• Preview 2
• Preview 1

Trimmer

The trimmer is a .NET tool that performs a sort of “cleanup operation” on your app’s code. It analyzes your project, detects unused code and removes it. In other words, it helps your app become lighter, more efficient and much faster to load.

In .NET 10, two important improvements related to its behavior have been introduced.

1. Trimmer Enabled in More Configurations

With .NET 10, this “smart cleaner”—the Trimmer—can now be enabled by default in more scenarios, such as:

• iOS Simulator/arm64 (all configurations)
• tvOS Simulator/arm64 (all configurations)
• Mac Catalyst/arm64 (all configurations)

When you see all configurations, this means it applies to different build configurations such as Debug, Release and others.

2. Trimmer Warnings Enabled by Default

Previously, trimmer warnings were disabled by default. This was because the base class library produced its own trimmer warnings, making it impossible for the developer to fix all the warnings detected.

The good news is that in .NET 9, all iOS-related trimmer warnings were resolved, and thanks to that, trimmer warnings are now enabled by default.

However, if for some reason you want to disable them, you can do it very easily. Just add the SuppressTrimAnalysisWarnings property to your .csproj file as follows:

<PropertyGroup>  
    <SuppressTrimAnalysisWarnings>true</SuppressTrimAnalysisWarnings> 
</PropertyGroup>

Bundling Original Resources in Libraries

Library projects can contain different types of resources, such as:

• Storyboards
• XIBs
• Property lists (plist)
• Images
• CoreML models
• And others

These resources require processing tasks like compiling storyboards or XIBs, optimizing plist files and more. This processing comes with some important considerations, such as:

• Running on a Mac, because compiling storyboards/XIBs is only possible on macOS.
• Using Apple’s toolchain (xcodebuild, ibtool, actool, etc.).

All of these requirements can complicate building libraries because:

• You don’t always have access to a Mac.
• You cannot make decisions in the final app based on the original resources, because they were already “processed.”
• You only get the processed version.
• And, therefore, this limits the flexibility of the project consuming the library.

But Now We Have an Improvement 😎

In .NET 9, optional support (opt-in) was introduced that allowed including the original resources inside the library without processing them.

In .NET 10, things get even better! 😍 This support is now the default behavior (opt-out).

This makes our apps more flexible, removes the hard dependency on having a Mac available and results in much more consistent CI/CD builds.

How Do I Enable or Disable This Option?

If for some reason you want to revert this default behavior—meaning you don’t want to include the original resources and prefer the library to contain the processed ones—you can do so by adding the following tag in your project file:

<PropertyGroup> 
    <BundleOriginalResources>false</BundleOriginalResources> 
</PropertyGroup>

Build Binding Projects on Windows

Before, binding projects depended on Apple’s ecosystem tools (meaning you needed a Mac to compile them).

😎 With .NET 10, this changed!

Binding projects can now be built entirely on Windows, without requiring a Mac or any remote connection. This results in much faster builds on Windows. Woohoo! 🎉

This is a VERY big improvement for anyone working on Windows devices!

🔐 NSUrlSessionHandler No Longer Sets Minimum TLS Protocol Automatically

In case you didn’t know, TLS (Transport Layer Security) is a security protocol that protects communication between two endpoints—for example, your app and the server.

Previously, we had behavior like this:

• NSUrlSessionHandler relied on the value of ServicePointManager.SecurityProtocol to determine the minimum TLS protocol to use.
• But that approach is now deprecated, because ServicePointManager is no longer used.

So starting with .NET 10, if you want to define the minimum TLS protocol, you must do it manually before creating the NSUrlSessionHandler, as shown below:

var sessionConfiguration = NSUrlSessionConfiguration.DefaultSessionConfiguration;
    
sessionConfiguration.TlsMinimumSupportedProtocolVersion = TlsProtocolVersion.Tls13;
    
var handler = new NSUrlSessionHandler(sessionConfiguration);

🚫 The NSUrlSessionHandler.BypassBackgroundSessionCheck Property Is Now Ignored

This property existed as a workaround for an old issue in the Mono runtime. Since it’s no longer needed, the property is now ignored.

Conclusion

And that’s it! 🎉 In this article, you explored the key improvements that .NET 10 brings to iOS, tvOS, macOS and Mac Catalyst development. From expanded trimmer support and improved resource handling to faster Windows-based binding builds and updated networking defaults, these changes work together to create a more efficient, consistent and modern development experience.

Now you have a clearer understanding of how these updates impact your workflow—helping you build lighter apps, reduce platform-specific friction and take full advantage of what .NET 10 offers for Apple platforms.

If you have any questions or want me to cover more related topics, feel free to leave a comment—I’d be happy to help you! 💚

See you in the next article! 🙋‍♀️✨

References

The explanation was based on the official documentation:

• https://learn.microsoft.com/en-us/dotnet/maui/whats-new/dotnet-10?view=net-maui-10.0